Open markmandel opened 6 months ago
We do have code specifically there to silence the spurious key events we get from MS Windows:
https://github.com/Xpra-org/xpra/blob/8f72bb11c02b9caeee885304093f581bf153b431/xpra/platform/win32/keyboard.py#L315-L327
And for sending the correct key modifier for AltGr
events:
https://github.com/Xpra-org/xpra/blob/8f72bb11c02b9caeee885304093f581bf153b431/xpra/platform/win32/keyboard.py#L143-L157
Can you try running your client with --env=XPRA_EMULATE_ALTGR=0
to see if that makes any difference?
Hey! That worked! Thanks!
As a note - this isn't on Windows, this is on Linux (Debian Trixie to be specific).
As a note - this isn't on Windows, this is on Linux
Are you sure? The environment variable has no effect on Linux clients.
As a note - this isn't on Windows, this is on Linux
Are you sure? The environment variable has no effect on Linux clients.
Yep - the only windows machine in this room are used for games.
Okay, this is 100% weird. I just tried it without the env var, and I didn't get the meta+alt combo.... so now i'm 100% confused.
❯ xpra start ssh://mark@oss --start=idea.sh --desktop-scaling=no --speaker=no
2023-12-09 10:24:45,349 Warning: missing audio module
2023-12-09 10:24:45,433 Xpra GTK3 client version 6.0-r34760 (g8fac1d473) beta
2023-12-09 10:24:45,444 running on Linux Debian n/a trixie
2023-12-09 10:24:45,444 cpython 3.11
2023-12-09 10:24:45,445 window manager is 'xmonad'
2023-12-09 10:24:45,929 created unix domain sockets:
2023-12-09 10:24:45,929 '/run/user/312365/xpra/clients/markmandel45-2169965'
2023-12-09 10:24:46,086 Connected (version 2.0, client OpenSSH_9.4p1)
2023-12-09 10:24:47,980 Authentication (publickey) successful!
2023-12-09 10:24:48,195 ssh server OS is 'linux-gnu'
2023-12-09 10:24:48,360 paramiko SSH agent forwarding enabled
2023-12-09 10:24:48,446 keyboard settings: rules=evdev, model=pc105, layout=us
2023-12-09 10:24:48,447 desktop size is 8960x1440:
2023-12-09 10:24:48,448 :1.0 (2370x381 mm - DPI: 96x96)
2023-12-09 10:24:48,448 LGD eDP1 2304x1440 at 0x0 (340x210 mm - DPI: 172x174) workarea: 2304x1440
2023-12-09 10:24:48,448 SAM DP2 5120x1440 at 3840x0 (1070x600 mm - DPI: 122x61) workarea: 5120x1440 at 3840x0
2023-12-09 10:24:48,449 Warning: the python netifaces package is missing
2023-12-09 10:24:48,449 some networking functionality will be unavailable
2023-12-09 10:24:48,658 SSH: 'Entering daemon mode; any further errors will be reported to:'
2023-12-09 10:24:48,658 SSH: " '/run/user/1000/xpra/S2000224/server.log'"
2023-12-09 10:24:49,929 SSH: 'Actual display used: :1'
2023-12-09 10:24:49,930 SSH: "Actual log file name is now: '/run/user/1000/xpra/1/server.log'"
2023-12-09 10:24:54,738 enabled remote logging
2023-12-09 10:24:54,739 Xpra X11 seamless server version 6.0
/usr/lib/python3/dist-packages/pyinotify.py:71: DeprecationWarning: The asyncore module is deprecated and will be removed in Python 3.12. The recommended replacement is asyncio
import asyncore
/usr/lib/python3/dist-packages/pyinotify.py:1476: DeprecationWarning: isSet() is deprecated, use is_set() instead
while not self._stop_event.isSet():
/usr/lib/python3/dist-packages/xpra/client/gtk3/statusicon_tray.py:38: DeprecationWarning: Gtk.StatusIcon.set_tooltip_text is deprecated
self.tray_widget.set_tooltip_text(self.tooltip or "Xpra")
/usr/lib/python3/dist-packages/xpra/client/gtk3/statusicon_tray.py:102: DeprecationWarning: Gtk.StatusIcon.get_x11_window_id is deprecated
if POSIX and os.environ.get("DISPLAY") and self.tray_widget.get_x11_window_id()==0:
/usr/lib/python3/dist-packages/xpra/client/gtk3/statusicon_tray.py:105: DeprecationWarning: Gtk.StatusIcon.get_geometry is deprecated
ag = self.tray_widget.get_geometry()
/usr/lib/python3/dist-packages/xpra/client/gtk3/statusicon_tray.py:166: DeprecationWarning: Gtk.StatusIcon.set_from_pixbuf is deprecated
self.tray_widget.set_from_pixbuf(tray_icon)
/usr/lib/python3/dist-packages/xpra/client/gtk3/statusicon_tray.py:45: DeprecationWarning: Gtk.StatusIcon.set_visible is deprecated
self.tray_widget.set_visible(True)
2023-12-09 10:24:55,035 running
So... that's weird. Maybe stuck meta key?
I misread:
Client OS: [e.g. Windows 10] Debian Trixie
I have no idea what is going on, sorry.
No worries - if I can't replicate reliably, I'll close the issue 👍🏻
Yeah, I can't replicate this. Closing.
Apologies for the noise!
I MANAGED TO REPLICATE THE ISSUE! 🥳
Same setup as before, just the latest Xpra.
❯ xpra --version
xpra v6.0-r34966 (gf449a7f8f) beta
It happens after an automatic reconnect/attach! It's fine one first connection, but if the network drops, it happens.
So to replicate:
xpra start
meta
key is included with the alt shortcut.Or do a manual disconnect and xpra attach
- same thing happens.
@markmandel please include the xpra info
output once connected and after re-connection.
Ideally also the server's -d keyboard
output when the second connection occurs.
Fixing this is going to be hard. Perhaps we can cheat and detect that the layout is the same and leave it alone the second time.. This won't help with sessions with multiple users connecting with different layouts, but should workaround the most common case.
Ideally also the server's -d keyboard output when the second connection occurs.
Sorry, I'm not quite sure what you mean by this one. -d
on what command?
But I have the xpra info
for you.
If it helps at all, I usually start xpra like so on my client:
xpra start ssh://markmandel@dev --start=idea.sh --desktop-scaling=no --speaker=no
Sorry, I'm not quite sure what you mean by this one. -d on what command?
Start your server separately via ssh:
xpra start --start=idea.sh -d keyboard
xpra_cmd.exe attach ssh://......
The (huge) log file will show the keyboard mapping step.
once connected and after re-connection
But I have the xpra info for you.
Only one copy, so I have nothing to compare it with.
My guess is that we're hitting this code path twice: https://github.com/Xpra-org/xpra/blob/777be6c88f6053411936cb13849a7c0c6b43f897/xpra/x11/server/keyboard_config.py#L361-L364 The first time works, the second one ends up making a mess.
I'm having the same issue.
If I start the xpra server normally (without --start=idea.sh
on the command line), then attach with xpra attach ssh://localhost
, and start IntellJ via the xpra status icon's start menu, then the Alt keyboard shortcuts work fine (verified by going to File->Settings->Keymap in IntelliJ and attempting to add the a new keyboard shortcut for the Navigate Back command, pressing Ctrl+Alt+Left shows Ctrl+Alt+Left). If I then ctrl-C the xpra attach
client and restart it, IntelliJ shows Meta+Ctrl+Alt+Left when I try again to add a new keyboard shortcut. I can only reproduce this in xpra, but this seems at least partially related to IntelliJ, because when I close and reopen IntelliJ within the same xpra client the problem goes away. I have seen this with anything other than IntelliJ.
If I start the xpra server with $ xpra start --start=/opt/intellij-ue-beta/bin/idea.sh -d keyboard
then the problem reproduces immediately on the first connection.
I've attached server.log with "-d keyboard" from the first sequence described (start server, connect client, start intellij, Ctrl+Alt+Left works, kill client, reconnect client, Ctrl+Alt+Left doesn't work, restart IntelliJ, Ctrl+Alt+Left works. server.log
@colincross thank you for doing the legwork for this - it's been on my todo list for weeks, but some family stuff got in the way.
@colincross / @markmandel please try to see if this is related to --input-method
.
because when I close and reopen IntelliJ within the same xpra client the problem goes away
Could be that Intellij
needs to reload the keymap to parse keyboard events correctly.
Thanks for the log, but please try to narrow it down - I don't have the time to parse 16617 lines.
Here's slightly trimmed diffs of the logs from the first and second connections:
@@ -10,8 +9,8 @@
get_keyboard_config(..)=KeyboardConfig(us,us / None / None)
setting key repeat rate from client: 500ms delay / 30ms interval
make_keymask_match: ignored as keynames_for_mod not assigned yet
-set_keymap(KeyboardConfig( / / ), {}, False, False) keyboard_config=KeyboardConfig(us,us / None / None)
-current keyboard id=///f40063fb0f9eba30e43d8aa79e7e0a2d17861664070fd949d685d4db44fffdff, new keyboard id=us,us/None/None/2fb8f478057e2da330c4d29b9ae47046d85d126b7b22e698eae1a7ea2f0ca533
+set_keymap(KeyboardConfig(us,us / None / None), {}, False, False) keyboard_config=KeyboardConfig(us,us / None / None)
+current keyboard id=us,us/None/None/6b67bb6825516e8a633cd7c4634e6a15dc99cdb7fb8ec1445fda277e895f8e75, new keyboard id=us,us/None/None/2fb8f478057e2da330c4d29b9ae47046d85d126b7b22e698eae1a7ea2f0ca533
set_keymap(False) layout='us,us', variant=None, options=None, query-struct={'rules': 'evdev', 'model': 'pc105', 'layout': 'us,us', 'variant': ''}
setting XKB layout group 0
do_set_keymap using xkbmap_query struct=typedict({'rules': 'evdev', 'model': 'pc105', 'layout': 'us,us', 'variant': ''})
@@ -23,9 +22,9 @@
setxkbmap: trying to load rules file b'/usr/share/X11/xkb/rules/evdev'...
setxkbmap: loaded rules from /usr/share/X11/xkb/rules/evdev
XkbRF_GetComponents(<hex>, <hex>, <hex>)=True
-getXkbProperties()={'rules': 'evdev', 'model': 'pc105', 'layout': 'us'}
-setxkbmap: properties={'rules': 'evdev', 'model': 'pc105', 'layout': 'us,us', 'keycodes': 'evdev+aliases(qwerty)', 'symbols': 'pc+us+us:2+inet(evdev)', 'types': 'complete', 'compat': 'complete', 'geometry': 'pc(pc105)'}
-setxkbmap: filtered properties={'rules': 'evdev', 'model': 'pc105', 'layout': 'us,us', 'keycodes': 'evdev+aliases', 'symbols': 'pc+us+us:2+inet', 'types': 'complete', 'compat': 'complete', 'geometry': 'pc'}
+getXkbProperties()={'rules': 'evdev', 'model': 'evdev', 'layout': 'us,us'}
+setxkbmap: properties={'rules': 'evdev', 'model': 'evdev', 'layout': 'us,us', 'keycodes': 'evdev+aliases(qwerty)', 'symbols': 'pc+us+us:2+inet(evdev)', 'types': 'complete', 'compat': 'complete', 'geometry': 'pc(pc105)'}
+setxkbmap: filtered properties={'rules': 'evdev', 'model': 'evdev', 'layout': 'us,us', 'keycodes': 'evdev+aliases', 'symbols': 'pc+us+us:2+inet', 'types': 'complete', 'compat': 'complete', 'geometry': 'pc'}
setxkbmap: XkbGetKeyboardByName returned <hex>
getXkbProperties()={'rules': 'evdev', 'model': "b'`\\xc8P\\x88\\xe1\\x7f'", 'layout': 'us,us'}
X11 keymap property updated: {'rules': 'evdev', 'model': "b'`\\xc8P\\x88\\xe1\\x7f'", 'layout': 'us,us'}
@@ -718,8 +711,8 @@
setxkbmap: properties={'rules': 'evdev', 'model': "b'`\\xc8P\\x88\\xe1\\x7f'", 'layout': 'us,us', 'keycodes': 'evdev+aliases(qwerty)', 'symbols': 'pc+us+us:2+inet(evdev)', 'types': 'complete', 'compat': 'complete', 'geometry': 'pc(pc105)'}
setxkbmap: filtered properties={'rules': 'evdev', 'model': "b'`\\xc8P\\x88\\xe1\\x7f'", 'layout': 'us,us', 'keycodes': 'evdev+aliases', 'symbols': 'pc+us+us:2+inet', 'types': 'complete', 'compat': 'complete', 'geometry': 'pc'}
setxkbmap: XkbGetKeyboardByName returned <hex>
-getXkbProperties()={'rules': 'evdev', 'model': 'evdev', 'layout': 'us,us'}
-X11 keymap property updated: {'rules': 'evdev', 'model': 'evdev', 'layout': 'us,us'}
+getXkbProperties()={'rules': 'evdev', 'model': '\x01', 'layout': 'us,us'}
+X11 keymap property updated: {'rules': 'evdev', 'model': '\x01', 'layout': 'us,us'}
set_keymap: query_struct={'rules': 'evdev', 'model': 'pc105', 'layout': 'us,us', 'variant': ''}
setting XKB layout group 0
set_xmodmap([('clear', 0), ('clear', 1), ('clear', 2), ('clear', 3), ('clear', 4), ('clear', 5), ('clear', 6), ('clear', 7)])
By the time it gets to the Ctrl-Alt-Left keypress everything looks the same except the wid
field:
do_get_keycode (113, Left)=113 (native keymap)
-process_key_action(('key-action', 7, 'Left', True, ('control', 'mod1'), 65361, '', 113, 0)) server keycode=113, group=0
+process_key_action(('key-action', 18, 'Left', True, ('control', 'mod1'), 65361, '', 113, 0)) server keycode=113, group=0
set_keyboard_layout_group(0) config=KeyboardConfig(us,us / None / None), current keyboard group=0
setting XKB layout group 0
filtered_modifiers_set(['control', 'mod1'])={'mod1', 'control'}
is_modifier(113) not found
-handle_key((7, True, 'Left', 65361, 113, ['control', 'mod1'], False, True))
+handle_key((18, True, 'Left', 65361, 113, ['control', 'mod1'], False, True))
handle keycode pressing 113: key 'Left'
fake_key(113, True)
scheduling key repeat timer with delay 500 for Left / 113
-process_key_action(('key-action', 7, 'Left', False, ('control', 'mod1'), 65361, '', 113, 0)) server keycode=113, group=0
+process_key_action(('key-action', 18, 'Left', False, ('control', 'mod1'), 65361, '', 113, 0)) server keycode=113, group=0
set_keyboard_layout_group(0) config=KeyboardConfig(us,us / None / None), current keyboard group=0
setting XKB layout group 0
filtered_modifiers_set(['control', 'mod1'])={'mod1', 'control'}
is_modifier(113) not found
-handle_key((7, False, 'Left', 65361, 113, ['control', 'mod1'], False, True))
+handle_key((18, False, 'Left', 65361, 113, ['control', 'mod1'], False, True))
handle keycode unpressing 113: key 'Left'
fake_key(113, False)
'model': '\x01'
That bit looks wrong and could be causing problems.
Your two clients don't have the same keyboard definition - can you show the keyboard messages of your client? Are they the same OS? The same system?
the same except the
wid
field
That's just the window id.
My "two clients" are two instances of xpra attach ssh://localhost
run in the same terminal, no keyboard changes.
Well then, I think we found the bug.
Every xpra attach
should provide the same keyboard layout definition.
And in your case, it does not.
Please show your xpra attach
command output - in both cases.
Describe the bug When pressing Alt+ on the client app, it is sent through to the client application as Meta+Alt+.
For example - using IntelliJ as my key tracking when using shortcut keys Alt+F12 or Alt+N:
To Reproduce Steps to reproduce the behavior:
Hit Alt+ on the client.
System Information (please complete the following information):
Additional context
Xpra is awesome 😄