If I switch away from xrpa windows to another desktop with shortcut (i.e. with Super+2 in my case) and then return back to xpra window using mouse, Super key would still be pressed on server, until some key event is sent to xpra window. Client should release all key presses when its windows loose focus.
That should already be the case, can you attach a -d keyboard
debug output to this ticket?
And include more keyboard debugging information (layout, etc), see wiki/Keyboard - include desktop environment, etc..
Output attached. What I did: in a leafpad window (remote) typed 'qwerty', switched away using shortcut, returned using mouse, typed 'u' nothing happened, typed 'u' again, it typed.
Please see comment:1 for providing more details, and in particular wiki/Keyboard, are you using keyboard sync?
I can see a key event for Super_L
, but rightly or wrongly the key is not found in the modifiers list (modifiers': []
). Maybe the client debug output would help.
The only other option would be to always unpress all the keys (but not modifiers?) whenever xpra windows are not in focus.
layouts: us,ru. Both client and server switched to us in this test.
Toggling keyboard sync does not affect the outcome.
setxkbmap -print
is identical on client machine and in xpra session:
xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete+ledscroll(group_lock)" }; xkb_symbols { include "pc+us+ru:2+inet(evdev)+group(alt_shift_toggle)+terminate(ctrl_alt_bksp)" }; xkb_geometry { include "pc(pc105)" }; };
setxkbmap -query
:
rules: evdev model: pc105 layout: us,ru variant: , # this line does not present in xpra session, but present local options: grp_led:scroll,terminate:ctrl_alt_bksp,grp:alt_shift_toggle,terminate:ctrl_alt_bksp,grp_led:scroll
xkbprint -label name $DISPLAY
returns nothing.
Additional info will be in file soon.
releasing keys when no xpra window has focus seems logical to me.
releasing keys when no xpra window has focus seems logical to me.
If we have to, we will - but I fear that this could well cause us some new problems..
As expected, the key is defined as a modifier:
mod4 Super_L (0x85), Super_R (0x86), Super_L (0xce), Hyper_L (0xcf)
So I'm really not sure why it isn't included in the list of modifiers as "mod4" with the key events.
Can you run the keyboard test script and see if it recognises the key as a modifier: browser/xpra/trunk/src/xpra/gtk_common/gtk_view_keyboard.py. The modifiers are shown at the top and key events below. (it should already be included when you install xpra)
Test script's window shows it as modifier, mod4. It disappears when I switch away from this window with shortcut, but after returning to it with mouse, it not react or list the next key press, only the one after that.
I think I've got this one: when we click away from the window, we already unpress all the keys (you can see this by running the server with "-d keyboard,focus"), but then the client window has its attributes changed (ie: focus window attribute gets unset) so we send a configure-window packet back to the server, and this packet includes the modifiers... so we then re-set them! r13575 should fix this.
@psycho_zs: please close if this works for you.
latest build (r13590) fails to launch, seemingly because it tries to resolve config directory as /home/user/~/.xpra
Or rather it adds pwd to the path:
$ xpra start :100 ^R using systemd-run to wrap 'start' server command 'systemd-run' '--scope' '--user' '/usr/bin/xpra' 'start' ':100' Running scope as unit: run-rcd50ed61bbe642a5af3428869fba6fb1.scope ^R [Errno 2] No such file or directory: '/home/user/src/xpra/xpra-svn/~/.xpra' xpra main error: Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/xpra/scripts/main.py", line 124, in main return run_mode(script_file, err, options, args, mode, defaults) File "/usr/lib/python2.7/dist-packages/xpra/scripts/main.py", line 1133, in run_mode return run_server(error_cb, options, mode, script_file, args, current_display) File "/usr/lib/python2.7/dist-packages/xpra/scripts/server.py", line 1017, in run_server logfd = open_log_file(log_filename0) File "/usr/lib/python2.7/dist-packages/xpra/scripts/server.py", line 554, in open_log_file return os.open(logpath, os.O_WRONLY | os.O_CREAT | os.O_TRUNC, 0o666) OSError: [Errno 2] No such file or directory: '/home/user/src/xpra/xpra-svn/~/.xpra/:100.log'
OSError: [Errno 2] No such file or directory: '/home/user/src/xpra/xpra-svn/~/.xpra/:100.log'
That's odd, probably caused by r13507, does r13593 help? If not, please include the build and install commands that you've used as part of those paths are generated at build time.
r13593 works.
But the first key pressed after returning to window is still ignored.
Attaching keyboard.log: pressed 1 2 3 4, switched away with Super+1, returned with mouse, pressed 5 two times, only second one is printed.
The client side looks fine (the events are seen and sent without any modifiers), can you please post the server side "-d keyboard,focus" log? What desktop environment do I need to reproduce this?
I use openbox, shorcuts Super+[1-5] to switch between desktops.
Another update: it happens only when there are more than one window in Xpra session, and when returning to the same window you left. In the latest test I had two leafpad windows. First keypress after returning to window is at 07:45:15 in the log.
Added keyboard_server_2.log​, with focus debug this time. I did two tests series in this session: first with single leafpad window: 1,2,3, switch away, back, 4, 4. It worked. Then opened the second leafpad window, did the same, first "4" was ignored. See around 07:55:15 for second return.
I think I can see what is going wrong here: r231 (a very very old changeset, see ticket:138#comment:11 for details) makes us call the focus change method via a main loop callback, and so our keyboard call to fake_key(13, True)
happens just before the focus event... and lands on the root window instead of the window we want.
Partial revert of r231 applied in r13600. I've tested with win32 clients and "git gui" as per #138 and this does not seem to cause a regression (yet), so it looks like ticket:138#comment:15 was correct and the proper fix for the focus issue was r2003.
@psycho_zs: does that work for you?
This issue seems to be resolved. Thank you!
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1293