Closed xaverm closed 1 year ago
There are two options for using German layout.
Prefer scancodes when possible
and DE with german layout set with setxkbmap
or with DE settings.I am still testing too and in 54 I will describe my knowledge in comparison to 1.02.04 when I'm done.
Prefer scancodes when possible
, just no instructions for occupancy the buttons[]
to check.I make a little video with the often used german keys 7089 and toggle keys (shift/altgr) to get {}[] ()
It is displayed here xterm with fluxbox, whereby the Taskbar is covered by EK - that was better at 1.02.04!
@twaik There are two options for using German layout.
I'm sorry, but even if this request was closed, I beg to differ.
1. Termux-x11 with `Prefer scancodes when possible` and DE with german layout set with `setxkbmap` or with DE settings.
Before posting I certainly tested (also) the
Prefer scancodes when possible
preference setting. For me, this option does not work. Let me describe:
The closest I can get to a working external (Logitech K810) DE keyboard in termux-x11 is (i) using the Prefer scancodes when possible
settings, (ii) a German (no dead keys) keyboard layout in xfce4 settings, and (iii) the tablet's manufacturer (Samsung) internal keyboard with German language set as standard keyboard.
But even then, the "<, >, |" key behaves incorrect. I.e. it produces single quotation marks. Even worse, in this situation, the "<, >, |" characters have disappeared from the keyboard completely.
Let me also mention, that it is absolutely confusing, that there seems to be an erratic correlation between the internal keyboard, I mean the soft-keyboard of the Android device, set to be the standard keyboard, and the degree to which the external keyboard will eventually function with termux-x11. I.e., say, a 'Hackers keyboard' set to 'Standard' will lead to less correct keys than an 'External Keyboard Helper Pro', a.s.o. There should be some statement for users: "You should set your internal soft-keyboard to xyz with abc language". I'm also missing that.
2. Using text field of additional key bar (swipe it to the right). It is possible to switch extra key bar with three-finger swipe down or with volume down key (with enabled preference of course).
Even if this may work (I will test), this is not really a reasonable 'option': Keys like "<, >, |" are bread-n-butter keys for various coding tasks. Your are certainly not suggesting, we should physically switch back and fro on a once-per-second basis between an external keyboard and an on-screen key bar, while working?
Let me just state once more, that with all this hard and fantastic work on termux-x11, it is such a pity that many potential users will be excluded, simply because we cannot properly interface to it.
Let me also mention, that it is absolutely confusing, that there seems to be an erratic correlation between the internal keyboard, I mean the soft-keyboard of the Android device, set to be the standard keyboard, and the degree to which the external keyboard will eventually function with termux-x11. I.e., say, a 'Hackers keyboard' set to 'Standard' will lead to less correct keys than an 'External Keyboard Helper Pro', a.s.o. There should be some statement for users: "You should set your internal soft-keyboard to xyz with abc language". I'm also missing that.
Unfortunately there is no way to achieve better accuracy in getting scancodes on Android devices. You can try to change keyboard maps in /data/data/com.termux/usr/share/X11/xkb
or use xmodmap for this.
@agnostic-apollo maybe you know the way to get correct symbols when View.OnKeyListener
is applied to SurfaceView? For some reason some keyboards do not send correct symbols and scancodes when SurfaceView is focused.
@xaverm You are right with "Fantastic Work on Termux-X11" by @Twaik. The keys <|>
are on my Logitech-BT-KB right next to Shift and Ctrl -so easy to reach. If an XClient does not depend on the implementation of the WM=Window Managers, this can also be done by the key code, which I do in some cases of my own developments.
As I said above, I am not yet finished with my comparison check. The three-finger campaign for EK can also be done by the Vol-Down button. Three finger can also be four or more, which bothers in direct mode, because EK is constantly switched on/off and I can no longer see my taskbar (or anything else is hidden). ...OnKey...
by @agnostic-apollo is a good idea! If in return he takes over the Fullscreen function of x11 in app, both APK profit of it :)
If hardware keyboard or android is sending wrong keycodes, then an app cannot just guess the correct keycodes. The user would have to define a mapping somehow. You can try looking into custom keyboard layouts.
https://github.com/termux/termux-app/pull/2237#issuecomment-906028913
If hardware keyboard or android is sending wrong keycodes, then an app cannot just guess the correct keycodes.
xaverm says that keycodes/scancodes sent by Android depend on current IME. For some reasons IME behaviour when it sends events to SurfaceView differs from behaviour when it sends events to EditText. Is there a way to make it behave the same way?
I haven't looked into how android behaves internally but there is indeed some influence of the soft keyboard on the hardware keyboard. For termux-app, it gets solved by disabling the software keyboard for the activity. I don't know if this applies to termux-x11.
I think a problem appears because SurfaceView is not recognised as a text editor. When I set german layout on my phone it sends hardware keyboard events corresponding to english layout. Is there a way to override this behaviour?
I assume you mean Language and Input
-> Physical keyboards -> Specific Keyboard -> Set up keyboard layouts. If you setup German as the language and switch to it with ctrl+space, then on an english QWERTY
keyboard, the letter y
should type z
for the german layout since it should default t to QWERTZ
.
The layouts listed are provided by individual apps, which mainly may be the default system keyboard or gboard, etc. Like Japanese 109A
is provided by gboard for me and all others by Android keyboard.
Gboard also prevents language change of even the softkeyboard with the earth key and says to use ctrl+space if a hardware keyboard is connected, so there is some additional inter-linkage.
If layout change is not working for you, then could be your device bug.
https://xiaomi.eu/community/threads/change-physical-keyboard-layout.60396/
I think a problem appears because SurfaceView is not recognised as a text editor.
You may try overriding View.onCreateInputConnection()
like termux does and implement it properly, but hardware keyboard events are generally not sent to commitText()
.
@agnostic-apollo
If hardware keyboard or android is sending wrong keycodes, then an app cannot just guess the correct keycodes.
In post on keyboard issues in termux-x11, I occasionally read similar statements. I just never understand what to make out of them.
1) Regarding the 1st part, i.e., that the "hardware keyboard might be sending wrong keycodes":
Every external keyboard can be hooked up onto a "real" linux machine and be tested with xev
for what keycodes it emits.
Certainly, before bugging people with posts on keyboard issues, I do test that my external keyboard does work flawlessly on common linux boxes.
I also did that before posting here. So once again: The Logitech K810 DE keyboard works like a charm on any linux machine I've ever used it on and xev
show that it emits proper keycodes on those machines for the key which I have mentioned here, i.e., the <>|
key.
That is why I am posting here, and that is why I am asking for when termux-x11 might eventually also work with external DE keyboards.
2) Regarding the 2nd part, i.e., your statement that "android might be sending wrong keycodes": Can you pls. explain, how an average-ball-cap-user can determine if this issue is indeed happening(?), and even more so how to fix it without screwing up once Android device?
Finally one less related thing:
Every external keyboard can be hooked up onto a "real" linux machine and be tested with
xev
for what keycodes it emits.
I can not force keyboard mapping to replace symbols. It seems like there are some different "wrong keycodes" sent on different devices and different IME.
Every external keyboard can be hooked up onto a "real" linux machine and be tested with
xev
for what keycodes it emits.I can not force keyboard mapping to replace symbols. It seems like there are some different "wrong keycodes" sent on different devices and different IME.
So you are suggesting, that there will be certain Android devices and certain IMEs which will just not allow termux-x11 to be used with DE external keyboards?
While this is beyond me, it would certainly be a grim perspective. Hopefully you will find a solution down the line. I'll keep my fingers crossed.
There is a hope that android sends right symbols to InputConnection so I'll be able to intercept them and override symbols I get from KeyEvent.
In the standard termux terminal app all is fine hier means @xaverm.
I cannot confirm that except for one (SM-A33) of my 5 Android devices. If I use an ssh terminal, a TeamViewer connection or a scrcpy copy of the device on my Win-PC, the 9=6+3 buttons (above{[]}()+<|>
) are correctly reproduced above.
However, if I try coupling the KB with Bluetooth, I am also wrong in the termux app with 4 devices. In all cases I use the newest version 0.118.0+d7bab73
. With regard to x11 there are all 5 wrong.
In the standard termux terminal app all is fine
I cannot confirm that except for one (SM-A33)
Weird?
But anyway, this is a plain termux issue for you then, and not a termux-x11 issue, as for me. For me and for many years and on several different Samsung tablets (currently SM-X906B), using Logitech and Pearl external DE bluetooth keyboards has never caused a single glitch for any key. And since I mainly use termux for typing math documents with Emacs and LaTeX on the go, you can rest assured that practically any crazy combination of all possible symbol keys on the keyboard arise while typing.
I'd like to have this functionality also on termux-x11 + xfce4 running. That's why I'm posting here ... and maybe @twaik can get it done.
The development of the app is operated by @agnostic-apollo and x11 by @twaik . If the two can agree on common functions in the two APK and that works correctly on all devices would be helped.
My Samsung Pad is an SM-P610 with stylus. Unfortunately, even without a chance to use my BT keyboard Logitech K370/K375-DE for the 9=6+3 keys. Only my SM-A33-5G cell phone and only app is ok.
But we also have different XClients as the goal. I try to develop "WM-free ones", that work exclusively with fingers on a small display. The detours described above to use my BT-KB, are also ok for me and on the Pad I use often pop view for both apps on one display, which leads to double EK but only one On-Screen-KB. Here also the two APK do not work well together.
Regarding the 1st part, i.e., that the "hardware keyboard might be sending wrong keycodes":
This situation is less likely for decent brands but termux app does have at least one fix for this situation.
https://github.com/termux/termux-app/commit/913c474d32db136308d87e7504b9f0fea5ca2353
Regarding the 2nd part, i.e., your statement that "android might be sending wrong keycodes":
This can happen too, depending on the key character map files that are installed in the /system
partition of the android build. Different vendors could have their own specific mappings for regions, etc. Then there is also the user selecting a layout that is not "desired" or correct in android language and input settings. Accessibility services may also filter but not modify key events (also done by x11).
https://source.android.com/docs/core/interaction/input/key-character-map-files
Can you pls. explain, how an average-ball-cap-user can determine if this issue is indeed happening(?),
Normal apps have no control over such preprocessing before events are delivered. For termux app at least, you can enable Terminal View Key Logging
in termux app settings and then run logcat
command in terminal to see the events being received.
https://github.com/termux/termux-app#debugging
x11 seems to log codes too.
All the issues my external keyboard has are only within termux-x11. In the standard termux terminal app all is fine. Sigh.
Then issue is with x11 app and you shouldn't have to fix anything. x11 app will need fixing. But then again ralf is getting issues on both.
Termux terminal overrides onKeyUp
and onKeyDown
for hardware events instead of onKey
via View.OnKeyListener
, although may not make a difference if handled properly.
You could still play around with custom layouts as mentioned in https://github.com/termux/termux-app/pull/2237#issuecomment-906028913.
https://github.com/ris58h/custom-keyboard-layout
It is pretty much weird. When I set German (CH)
layout on my phone it sends events of external keyboard correctly, but if I set Schwiizerdütsch
it sends events of last selected layout (russian in my case). The same situation happens to EditText
, not only LorieView
.
@agnostic-apollo I tried to override onCreateInputConnection
method. It sends correct symbols to InputConnection.commitText()
method, but when I am typing with external keyboard it sends regular KeyEvent
s and does not invoke any InputConnection
's methods.
Are you using Ctrl + space
to switch to correct layout?
Its' not going to, it's meant for soft keyboard events, hardware keyboard events are normally only sent to onKey*()
methods, other than possible bugs https://github.com/termux/termux-app/issues/3265
Are you using
Ctrl + space
to switch to correct layout?
Yes.
Its' not going to, it's meant for soft keyboard events, hardware keyboard events are normally only sent to
onKey*()
I've set OnKeyListener on my view so it is catching all possible events.
I meant commitText()
is ideally not gonna be called for hardware events.
https://developer.android.com/develop/ui/views/touch-and-input/keyboard-input/commands
Note that termux calls KeyEvent.getUnicodeChar()
for the event and also handles dead keys. Read the javadocs for onKeyDown()
I have added.
https://developer.android.com/reference/android/view/KeyEvent#getUnicodeChar(int)
I am using KeyEvent.getUnicodeChar()
in key handling function here. But it still happens.
Does it happen in termux app?
I am not sure. I did not check thi since I do not speak any languages which alphabet uses dead keys.
If everyone could just use ASCII, that would be great, make all our lives so much easier.
Also weird thing. When I hold AltGr+LeftAlt and trying to send ä
key or ö
Android simply does not send KeyEvent. It is pretty sad...
Maybe your or some other accessibility service is messing things up, turn them off. Also dumpsys input
should print your keyboard config and getevent
should print events.
https://source.android.com/docs/core/interaction/input/getevent
https://stackoverflow.com/questions/12280657/does-anyone-know-what-the-output-from-getevent-means
Maybe your or some other accessibility service is messing things up, turn them off.
I did not enable any.
Also
dumpsys input
should print your keyboard config
Is there a way to implement process-local IME or test IME in process without enabling it globally?
If everyone could just use ASCII, that would be great, make all our lives so much easier.
Not realy, the {[(<|>)]}
keys has to positioned on every national KB at the same place! These are important for each programmer.
Not realy, the
{[(<>)]}
keys has to positioned on every national KB at the same place! These are important for each programmer.
Not really. On russian layout there are Хх(БЮ)ъЪ
symbols in place of {[(<>)]}
.
@xaverm @RalfWerner Can you please test the latest build with external keyboard?
I used my german BT-KB that can be coupled via Special Keys with up to 3 devices. I connected my AM-A33 to PC by ssh, opened there an aterm
, entered 9 keys on the PC (top left), then the KB coupled with the SM-A33 and entered the same 9 keys there and finally "hello" typed. Result:
https://github.com/termux/termux-x11/assets/45426380/14b5cfd9-f799-4760-8978-8635662aa63a
This is done with last artifact (still 1.03.00 but created:15. August 2023, 15:12:46
). should I try with differend Preferences or with 1.02.04 (ekeys) too?
@RalfWerner I do not really understand what exactly happens on this video and what keys were pressed...
I do not really understand what exactly happens on this video and what keys were pressed...
All Steps decribed in the second sentence!
entered 9 keys
What 9 keys? Did it work as expected or it was wrong?
above! it was wrong!
It was three weeks ago... Ok.
Does it happen with enabled prefer scancodes
preference? What keyboard layout is set in your environment (setxkbmap?)?
I've checked prefer scancodes
and it works fine with setxkbmap de
. It fits to this table.
Step pkg install xorg-setxkbmap
was not done and I've switchoff prefereces, start setxkbmap and than retype the 9 keys :) looks better! @twaik - you are a genius! Your de-KB looks like mine BT-KB, even without preference prefer scancodes
. Not correct is the BT-KB on PC and check on scrcpy
mirror on PC but that doesn't matter!
In the video:26 above with the short description is in addition to aterm
also the WM=fluxbox
, which also contains feh --bg
. In addition to X -keys, this viewer also processes stdin
. Xclient aterm
support that actually not. If I start this Xclient by ssh
(PC) on my SM-A33, the KB input of the 9 keys (above in the video) on the PC would not have been possible, because Xclient feh
would use it alternative to the X-keys.
However, since the keyboard is coupled to the PC, xorg-setxkbmap
does not have an effect.
The xorg-setxkbmap
package should definitely has to be part of OTS and switchoff or removed from the prefereces! I compared this to my other favortite versions basic and ekeys but need some time to complete the comparison, with x11a from which there will some improvement requests.
You don't need to answer here - better in Discord or when I finished comparison with ekeys.
You are using too much too many abbreviations, I had no success in decrypting it...
That doesn't matter! You could follow the links to get more information or check the actions by yourself. Only stdin
from feh
is relevant on the topic here.
With the rest I will continue to annoy you in #54 when I have done something repeatable. I hope a little more understandable. I've deleted the rest above and added a picture of my BT-keyboard and devices.
I've been testing new versions from this repo for several months now ... many really nice improvements!
But the 1st and foremost thing one would like to do, i.e., type in stuff into desktop apps from an external keyboard - which is a K810 with German layout in my case - has never ever worked for me, regarding the complete symbol set. I've tried myriads of combinations of Android internal standard keyboards, xfce keyboard settings, and termux-x11 preferences. It just won't work. At the end there are always a few keys remaining, that function incorrect, if at all.
If in principle termux-x11 is not only meant for people with US system localization US keyboards, then it might of great help for potential users, if on termux-x11 repo's front page there would be a description for some tested and working setups using some typical external keyboards with international layouts (obviously including a German one ;) )