xserver-xsdl
xserver-xsdl copied to clipboard
pelya
Odd <Caps lock> key behavor using hardware keyboard
This issue has always been present for me...
Caps lock has an odd behavor using hardware keyboard. I am getting this with multiple devices...
Sometimes on first keypress it will do nothing, then it will get "stuck" on uppercase then (maybe) on lowercase.
To restore the correct function (or mode) of the keyboard the caps lock key itself must be pressed several times (maybe hitting it after a space or random letters). I did not figure out a pattern...
If i manage to "restore" the situation it appears (some times) that , on android side, the mode of the keys are inverted... e.g: android will issue a lowercase, Xserver XSDL an uppercase
I use debian with xfce...
Anybody having this issue? Cannot be only me ;-)
Hi! Also I have this kind of situation, specially when I type Shift key (not all times), it gets "stuck" and the letters appear uppercase and can't restore until I press Shift + random letters and release Shift. It's so cumbersome when i need to edit texts.
Caps Lock key does not "synchronize" the upper/lower status with Android.
I'm using Debian with i3wm, but i have experienced this issue with other environments, and previous versions of xserver-xsdl.
Thanks for your help!
I have done my best to found some information related to this problem. I think, that there are various Android keyboard modules apps build as system app for various Android versions. Because I have The similar issue also with other VNC viewer for Android on Android 8.0. For example, Numeric Insert can not be detected. So I think, that there is complex programmers problem caused by The internal behaviour of Android keyboard system application. The bbest Android keyboard system app has The Android 6.0.
Unfortunately, The best interaction between Xserver XSDL and its key detection routines was on Android 6.0. In this Android release, there was Android keyboard AOSP. And this system app have worked excellently. But unfortunately, starting with Android 7.0 The detection of scan codes have been started to be very unreliable. Sad story. This is The reason, why I Am still using X11-vnc and XVFB or video dummy driver. Because only in this case I can have The ensurance, That The most key strokes will be detected correctly. But also for Android VNC lclient apps there is A problem related to detected keys. And buy paied version of some apps such as Mocha VNC is not The solution. Also this Android VNC client app is suffering because of some keyboard scan codes issues. Some keys such as left or right Capslock or similar keys do not work.
There should be a way to get better keyboard support. On my old rooted tablet I was using Sparkle, an app that allows one to run Xwayland on Android. The performance isn't much better than Xsdl (because it still uses software rendering), but the keyboard support is nearly perfect. (I had the same caps lock problem with Xsdl on that tablet too.)
I'd still be using Sparkle/Xwayland but sadly it requires root and that's not possible on my new tablet.
https://gitlab.com/mogryph/sparkle-w-2
I have done my best to found some information related to this problem. I think, that there are various Android keyboard modules apps build as system app for various Android versions. Because I have The similar issue also with other VNC viewer for Android on Android 8.0. For example, Numeric Insert can not be detected. So I think, that there is complex programmers problem caused by The internal behaviour of Android keyboard system application. The bbest Android keyboard system app has The Android 6.0.
I'm interested to know more details about it. Could you please share some information you found?
What's the difference between these applications (xsdl, vnc clients, ...) and other native applications in the way of handling the input? For example, in Termux, i don't have issues of this kind (I suppose they use the same system keyboard app). Or maybe i'm not understanding the concept.
It seems that I found a way to somewhat fix the caps lock problem...
- From xfce go to Settings > Keyboard > Layout tab
- In the "Change layout option" select "Caps Lock (while pressed), Alt+Caps Lock for the original Caps Lock action " (put the window fullscreen if you can not read the entire string
setxkbmap -print before the change:
xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+ch(fr)+us:2+inet(evdev)" }; xkb_geometry { include "pc(pc105)" }; };
setxkbmap -print after the change:
xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+ch(fr)+us:2+inet(evdev)+capslock(groupshift)" }; xkb_geometry { include "pc(pc105)" }; };
the part that does the trick appears be +capslock(groupshift)
not sure what is going on but it seems that the intended reconfiguration of the caps lock key will not work and it also appears that the "original bug" gets moved to "ALT+CAPS LOCK", so in other words to reprodure the bug you now must press ALT+CAPS LOCK"
Can someone test this with other window managers?
Probably not related to the issue itself, but I noticed a strange thing about the "linux" clipboard:
If you, for example, type a word like "hello" at put it in the clipboard with CTRL+C... The string gets inserted into the clipboard correctly... and pressing CTRL+V will paste the copied text, fine...
Now I type some "simple" characters, say "a" then "b" then "c". Everything is fine, CTRL+V will still paste my text...
At this point if I type a character that is not present on the US keyboard, for example "à" or "é" or "è"... The clipboard contents gets overwritten with THAT character! So at that point pressing CTRL+V will paste "à" or "é" or "è" !!!
strange...
That's how the text input works in XSDL. I can't control your keyboard switcher app inside whatever desktop environment you are running, and send the correct scancodes, so Unicode characters are entered using the clipboard.
On Wed, 2 Jun 2021, 14:17 zanfix, @.***> wrote:
Probably not related to the issue itself, but I noticed a strange thing about the "linux" clipboard:
If you, for example, type a word like "hello" at put it in the clipboard with CTRL+C... The string gets inserted into the clipboard correctly... and pressing CTRL+V will paste the copied text, fine...
Now I type some "simple" characters, say "a" then "b" then "c". Everything is fine, CTRL+V will still paste my text...
At this point if I type a character that is not present on the US keyboard, for example "à" or "é" or "è"... The clipboard contents gets overwritten with THAT character! So at that point pressing CTRL+V will paste "à" or "é" or "è" !!!
strange...
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pelya/xserver-xsdl/issues/118#issuecomment-852941550, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABF5QEDB3G3CRRIXYFMWX3TQYHKZANCNFSM4K5YMYDA .
Other strange ones that are very frequent:
- using the " character...
Say i want to write "hello". (with the quotation marks) I type the " character that on my keyboard is above the 2 key, so must be reached using SHIFT+2
At that point the typing gets stuck in some kind of loop of ' characters until i press another key
something like:
"'''''''''''''''''
- using the @ character
On my swiss french (or swiss german) keyboards the @ character is ALT GR + 2
What happens is that i press ALT GR + 2. The @ is output fine but also the SHIFT key got (internally?) pressed and remains so until i press the SHIFT key again!
something like:
smb://[email protected] outputs smb://user@!(@>!^*>!>!
That's how the text input works in XSDL. I can't control your keyboard switcher app inside whatever desktop environment you are running, and send the correct scancodes, so Unicode characters are entered using the clipboard. … On Wed, 2 Jun 2021, 14:17 zanfix, @.***> wrote: Probably not related to the issue itself, but I noticed a strange thing about the "linux" clipboard: If you, for example, type a word like "hello" at put it in the clipboard with CTRL+C... The string gets inserted into the clipboard correctly... and pressing CTRL+V will paste the copied text, fine... Now I type some "simple" characters, say "a" then "b" then "c". Everything is fine, CTRL+V will still paste my text... At this point if I type a character that is not present on the US keyboard, for example "à" or "é" or "è"... The clipboard contents gets overwritten with THAT character! So at that point pressing CTRL+V will paste "à" or "é" or "è" !!! strange... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#118 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABF5QEDB3G3CRRIXYFMWX3TQYHKZANCNFSM4K5YMYDA .
OK... i see
Other strange ones that are very frequent:
- using the " character...
Say i want to write "hello". (with the quotation marks) I type the " character that on my keyboard is above the 2 key, so must be reached using SHIFT+2
At that point the typing gets stuck in some kind of loop of ' characters until i press another key
something like:
"'''''''''''''''''
- using the @ character
On my swiss french (or swiss german) keyboards the @ character is ALT GR + 2
What happens is that i press ALT GR + 2. The @ is output fine but also the SHIFT key got (internally?) pressed and remains so until i press the SHIFT key again!
something like:
smb://[email protected] outputs smb://user@!(@>!^*>!>!
I noticed just now that in that situation (when the SHIFT is stuck) i will loose the mousewheel... (until I press SHIFT again... ahah
This issue is reproducible in Android 13. Once the CAPS key is enabled you can only disable it by pressing the key three times. Both shift keys are also problematic, sometimes they don´t respond at all or get stuck.
