@User i am very interested to know if you found any workaround for the 'offscreen 1st point' when creating wires/lines. In the mean time i found a strange issue with your xev output. In X11 when a KeyPress is generated an event is sent to the application receiving the input focus. This event contains the key code ('w' in our tests), state of modifiers (alt/ctrl/shift/capslock etc) and also x and y coordinates of the mouse when event was generated. In your xev output i see some strange values: KeyPress event, serial 28, synthetic NO, window 0x4a00001, root 0x3ac, subw 0x0, time 9053515, (

173,1157

), root:(173,1186), state 0x0, keycode 25 (keysym 0x77, w), same_screen YES, XLookupString gives 1 bytes: (77) "w" XmbLookupString gives 1 bytes: (77) "w" XFilterEvent returns: False The 173,1157 coordinates should be the position of the mouse (relative to xev upper-left window corner). Are these numbers correct? unless you resized xev's window its size is usually small (178x178). Can you please verify again?

The work-around for the off-screen 1st point of wires is to use the menu to select add wire with the mouse rather than the w key which works better because the first point is not defined until I click on the component pin with the mouse at which time it starts the wire in the right place. I will re-do the test you suggested with xev.

yes before drawing things in xschem always ensure the application has input focus. On some desktop environments you need to click the window area, in other configurations the focus follows mouse so no click is necessary. Thank you for your tests

I just redid the xev testing and I think the large number in the coordinate relative to the xev window is because I had "click to focus" (default behaviour for fresh debian kde plasma installation) so that xev still had focus even though the mouse cursor was not near the xev window when I pressed w.

Ok, thank you !

I think it is highly likely that the root cause is that I am a very poor linux sysadmin, so I feel slightly guilty about using your time when perhaps I should just copy more closely what someone else has done.

another very interesting test is to start '`wish`' (or

wish8.6

depending on installation) and write this simple program in the tcl console:

bind . <KeyPress> {puts "%N, %x, %y"}

Now of you click and point the wish graphical window, and start giving some keys you should see printed the ascii code of the key and x,y coordinates relative to wish upper left coordinate. Does that work?

So, what it does is when I press w with the focus on the wish window, it always prints the same coordinates regardless of the mouse cursor location, but when I move the wish window on the desktop it subsequently prints different coordinates (again not dependent on the mouse cursor location).

see this...

No, that is very different from what I get. It seems like when I press a key, the coordinates are what on your machine you would get if you had put (and kept) your mouse cursor at the top left of the screen, not near the wish window.

i think something is doing nasty, may be in the VM.. yes i saw the big negative numbers, these are clearly strange. Events coordinates should always be 'relative' to the window origin.

I can try the wish experiment on the host OS, it is also Debian, the same version.

ok. Otherwise there is an issue with the window manager. you are using kde plasma?

yes

and may be you are in a wayland session?

hrm, I don't even know what that is...

so we can narrow down the problem to the Virtual machine

It seems that way. I am very new to using virtual machines and have found setting them up difficult and it is likely that I have made poor choices. I'm using qemu/kvm, and created the vm from virt-manager.

Can you please try this command on the VM? echo $XDG_SESSION_TYPE

x11

o, so no wayland, this makes debug easier

The pointer always seems to be aligned in my case, it just seems to report to wish the coordinate of the top-left of the screen (relative to the window origin) rather than reporting the mouse cursor (relative to the window origin)

yes, that's weird...

and only for keypresses, not for mouse clicks - I guess the latter would be so obvious that someone would have fixed it.

xschem event processing is simple, it gets keys and coordinates from the x11 server, If you press a mouse button , does then keypresses report the correct coordinates?

Not sure I understand what to do here sorry...

Start the wish program, enter into the wish window with the mouse, do a button click, then press 'w' moving the pointer around. Are coordinates still wrong (negative) ?

clicking inside the wish window does not alter the behaviour on subsequent keypresses.

ok

Thank you! I really appreciate your help and I know one way to fix this - run on the host. (Also, I hope nobody is upset about how many slack messages I have forced out of the collective memory by this discussion. If so, sorry!)

On many sites i see this suggestion:

Add " -usb -usbdevice tablet" to your qemu commandline.

When I do ps -ef |grep qemu to see the command line, it has -device usb-tablet,id=input0,bus=usb.0,port=1 and in virt-manager it is set to EvTouch usb graphics tablet. I might try adding some different command line arguments but if I persist with libvirt then I have to mess with their xml config file which I have so far found quite frustrating (when I tried to share a folder between guest and host).

ok thank you..

hi @Stefan Schippers, I tried creating a new VM and installing Ubuntu 20.04.1-desktop-amd64 on it, and then I did the test with "wish" that you showed me before. It behaves like on the debian host and like on your machine, not like the debian-10.6.0-amd64 KDE/Plasma VM that I was using with xschem. So it looks like the bug is specific to something in the debian vm, not qemu or the host debian. Therefore I predict that xschem will work on this ubuntu VM that runs gnome. Maybe I will try some other distros first though, as it would not be my preferred OS!....

check what xserver driver is running on this new VM and compare with the debian VM (if you still have it) 🙂 look in ~/.local/share/xorg/Xorg.0.log (some systems log in /var/log):

[   128.986]    loading driver: radeon
[   128.986] (==) Matched radeon as autoconfigured driver 0

may be you see some differences...

As well as working in gnome ubuntu, the wish experiment seems to work in lubuntu-20.04.1-desktop-amd64 in a VM also. I kept the debian VM. I looked at the Xorg.0.log files though I'm not really sure what to look for. One difference: debian uses

that's weird. If problem persists let me know, may be i can use the winfo command to get coordinates instead of the variables set by the event handler.

Thanks for replying. For now I have installed a fresh Ubuntu VM and that is working for now, which disproves my theory that it was some update on the host OS. I now think that it is not worth asking you to do some work-around because I found that it also makes MAGIC unusable, and probably other software. One day if I get to the stage of trying to debug it, I might ask for more help though.

not surprsingly also MAGIC uses tcl, so they share the same problem. However its not tcl fault as it strictly follows the X11 specification regarding event handling...