-
-
Notifications
You must be signed in to change notification settings - Fork 178
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
no dead keys with german keyboard from windows client to linux server #4449
Comments
Keyboard debug log output
|
Have you tried switching input methods with |
TILs, the key events seen:
I would need to look at the server log to see what events are being produced there. |
Here is the server log...
|
Here are my test results with different
|
TBH, I have no idea which input method should be the default! ( Are you problems fully resolved? |
Using However the keys are working as dead keys now, which is rather cumbersome when coding. (I have to press them twice to obtain the corresponding character.) On my linux systems I'm using the nodeadkeys keyboard variant to avoid that. But in this case I am connecting from a windows client (which doesn't have a nodeadkeys variant) and I was trying to set up an xpra session to a linux server using Do you have a hint how to configure |
Ah, gotcha. I never use these kinds of layouts myself, so I am a bit lost. One way forward would be to connect from a working Linux X11 client, then post the server log so we can see what "correct" settings are being used to get The fact that nothing works at all for you with Another idea, the latest commits also allow you to change the keyboard model: #4445 (comment) |
First, I assume that you have mixed up your client and server in the bug description?
This should be the same as the default ( Lines 162 to 168 in a181b0c
The ibus documentation is seriously lacking. According to ibus/ibus#1878 : This is an expected warning but not an error. The warning happens whether your pinyin has a problem or not.
Good, but not very user friendly!
Xpra does not set anything in ibus, it only starts it.
IIRC, it never worked properly.
Or maybe this is all superfluous and #4463 fixes it? |
Oops! Sorry. I updated the info in the original post.
Unfortunately not. I just tried xpra-6.3-10.r37076 on the (Rocky Linux 9) server side. However I could not reproduce this issue:
|
I found some easy examples using gi Use |
this prevents the hello packet from growing too large
Cool!
Hmm - strange. |
Maybe a component is missing, perhaps the There are some newer builds in the beta area, maybe that will help? d690dd9 also adds a |
FYI: all the beta builds now have support for ibus debugging via I am closing this ticket since I can't get it to misbehave. (these layouts are definitely from ibus since we don't get the full name and description from xkb) |
I just tried with 6.3-r37229 on the windows client and 6.3-r37228 on the linux server. However querying the available ibus layouts seems to work (see the attached server log).
Any idea? --leo |
As per xpra/xpra/client/gtk3/tray_menu.py Lines 1189 to 1194 in e77abe2
The client should be showing the ibus layouts received from the server if you run with -d ibus .I would also remove --input-method=IBus (the default) and --keyboard-layout=de (should be detected properly).
|
The new ibus keyboard layout menu only works for me when connecting to an existing session, not when starting a new session. Startup of a new session produces the following output:
Note that no ibus data is transmitted. After disconnecting from this session and reconnecting with the same commandline, the keyboard menu gets populated correctly:
Now I am able to select a different keyboard layout using the menu. Unfortunately it does not make any difference whether "German" or "German (no dead keys)" is selected. It seems to actually select a different layout: But accent keys still do not work as "nodeadkeys". However, if I select exactly the same keyboard layout by running |
I tried again with 6.3-r37331 on the windows client and 6.3-10.r37314 on the RockyLinux server:
The keyboard layout menu is still not populated on session startup. Initial keyboard layout still is german without any accent keys working. The server log shows that it is loading the layouts from ibus:
... but the
After disconnecting:
and reconnecting, the server log shows
Initial keyboard layout still is german without and accent keys are still not functional. I can now select keyboard layout German from the menu:
.... and accent keys start working as expected. (as "dead keys") 2025-02-09 10:12:16,912 client 2 @23.359 Warning: window 1 requested static gravity Now I tried to select German (no dead keys) but somehow the terminal doesn't update it's content anymore: Note that the cursor symbol is not "filled". Keyboard input is accepted but the window is not updated. However the German (no dead keys) layout selected from the xpra client menu doesn't show an effect even in a new konsole window. But I guess my build is too old to contain your changes from #4449 (comment) |
I noticed that disconnecting and reconnecting fixes this konsole window. All keypresses and new tab actions done in the previous session had been applied, because now the konsole window shows that input and the added tabs. |
Then it's very likely that there's an server side error which should be in your server log. |
I just tested with fresh sessions several times (start session, enter client keyboard variants menu and switch back to konsole window). The "window updates get stuck" problem occurs only sometimes. In those cases, the server log shows:
|
That's a transient client-side sluggishness issue, which should not cause screen updates to stop. FYI: there are |
During those tests, I saw two other issues:
|
Just noted another issue: xpra should log the pid of the ibus daemon:
However PID 2397919 doesn't seem to stay alive:
Instead, it looks like the ibus daemon forks and the actual daemon seems to be the child process:
Besides |
What window?
I don't understand what that means.
Then we should probably skip recording its pid. |
The KDE konsole window, that was the initial window of the new session.
Until today, your new ibus keyboard layout menu didn't work when starting a brand new xpra session. It only showed up when reconnecting to an existing xpra session. See #4449 (comment) and #4449 (comment). However today, while testing the "konsole window isn't updated" problem (#4449 (comment)), there was one xpra session startup, where the new xpra keyboard layout client menu was surprisingly correctly populated with ibus keyboard layouts on the initial session startup.
I was only mentioning this because I was thinking about a possible race condition at startup time: My guess was that xpra probably does interpret ibus startup as complete too early and runs the ibus layout query at a time where ibus startup hasn't already completed. But looking at my first log output at #4449 (comment), this can't be true because the xpra server successfully reads all the layouts. So ibus startup timings cannot be the culprit and the ibus pid issue is just cosmetic. Please ignore. |
Here is the server.log from 6.3-r37350:
Still no ibus keyboard layouts in the xpra client menu. After disconnecting and reconnecting to the same session, querying ibus and sending the layouts works fine:
However after the reconnect, the "no windows updates" problem is again present: #4449 (comment) So disconnect again and reconnect. Now the konsole window gets updated correctly again. These windows update problems are unrelated to ibus and I'll open a new ticket for them. The initial keyboard layout still has no working accent keys. |
Good catch. |
Can you run this: /usr/lib64/python3.*/site-packages/xpra/keyboard/ibus.py That's what |
I've added a Now querying and sending ibus layouts works even on initial session startup: (note the delay after "LEO waiting for some seconds")
So it looks like the ibus daemon needs some startup time. |
I haven't looked at gdbus sources yet, but maybe the python equivalent of |
For a PoC I added some code to wait for ibus to appear on dbus:
It looks like this fixes the startup timing problem for me. |
Yes, that would explain it.
Nice. |
I've tried using |
Cool! Seems to work great:
Thanks! |
The commit above will update the user's keyboard configuration with whatever options are selected from the tray menu. |
Thanks!
Did you implement such loose matching? Is there a way to set the ibus keyboard layout using |
There is a 6.3-r37367 MS Windows x86_64 build now.
No.
Yes, just choose one from the tray menu then have a look at your user config file to see the options needed.
|
Unfortunately neither selecting a layout via commandline options nor from the config works for me. When selecting a new layout from the xpra tray menu, a
However when starting a new session with
... there is no |
Caused a regression:
|
When connecting from a Windows 10 client to a linux server, dead keys (accent keys that need a subsequent key) do not work. (E.g. ^ followed by SPACE yields just the SPACE). The keys
^
,`
and´
produce no output.--no-keyboard-sync
doesn't make a difference--keyboard-layout=de --keyboard-variant=nodeadkeys
.dead-circumflex
,dead-grave
anddead-acute
(see below).System Information (please complete the following information):
Additional context
On the Windows client
.\Keymap_info.exe
.\Keymap_info.exe
On the Linux server
$ setxkbmap -print
$ setxkbmap -query
$ xmodmap -pke
$ xmodmap -pm
xev
doesn't show an event when pressing the corresponding keys.The text was updated successfully, but these errors were encountered: