Support for International (AZERTY, etc.) keyboard layouts

[danisla]

Add support for AZERTY (French) keyboard layout.

Addenum by @ehfd: Read #9 (comment) for the required interventions to fix this problem in general.

[ehfd]

See: novnc/noVNC#1578

May be useful: Xpra-org/xpra-html5#48 Xpra-org/xpra-html5#15

Relevant code: https://github.com/selkies-project/selkies-gstreamer/blob/master/src/selkies_gstreamer/webrtc_input.py

Would be relatively trivial if code is borrowed over from noVNC or Guacamole.

[andymaier]

Is there a chance to have also support for QWERTZ Layout?

I getting this when try to use an "@" on QWERTZ Layout:

(xfce4-terminal:323): dbind-WARNING **: 00:57:13.907: AT-SPI: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files Traceback (most recent call last): File "/usr/local/lib/python3.10/dist-packages/selkies_gstreamer/gstwebrtc_app.py", line 1007, in <lambda> 'on-message-string', lambda _, msg: self.on_data_message(msg)) File "/usr/local/lib/python3.10/dist-packages/selkies_gstreamer/webrtc_input.py", line 533, in on_message self.send_x11_keypress(int(toks[1]), down=True) File "/usr/local/lib/python3.10/dist-packages/selkies_gstreamer/webrtc_input.py", line 321, in send_x11_keypress self.keyboard.press(keycode) File "/usr/local/lib/python3.10/dist-packages/pynput/keyboard/_base.py", line 392, in press self._handle(resolved, True) File "/usr/local/lib/python3.10/dist-packages/pynput/keyboard/_xorg.py", line 242, in _handle with display_manager(self._display) as dm: File "/usr/lib/python3.10/contextlib.py", line 142, in __exit__ next(self.gen) File "/usr/local/lib/python3.10/dist-packages/pynput/_util/xorg.py", line 78, in display_manager display.sync() File "/usr/local/lib/python3.10/dist-packages/Xlib/display.py", line 182, in sync self.get_pointer_control() File "/usr/local/lib/python3.10/dist-packages/Xlib/display.py", line 833, in get_pointer_control return request.GetPointerControl(display = self.display) File "/usr/local/lib/python3.10/dist-packages/Xlib/protocol/rq.py", line 1368, in __init__ self.reply() File "/usr/local/lib/python3.10/dist-packages/Xlib/protocol/rq.py", line 1380, in reply self._display.send_and_recv(request = self._serial) File "/usr/local/lib/python3.10/dist-packages/Xlib/protocol/display.py", line 612, in send_and_recv gotreq = self.parse_response(request) File "/usr/local/lib/python3.10/dist-packages/Xlib/protocol/display.py", line 719, in parse_response gotreq = self.parse_error_response(request) or gotreq File "/usr/local/lib/python3.10/dist-packages/Xlib/protocol/display.py", line 745, in parse_error_response req = self.get_waiting_request(e.sequence_number) AttributeError: 'BadRRModeError' object has no attribute 'sequence_number'

[ehfd]

Revamping of the Javascript libraries are necessary, especially vuetify and guacamole-keyboard.

[andymaier]

hello guys, is there any news on that topic? I am looking forward for this. I am able to help?
regards

[danisla]

I have no near term plans to work on this feature. It sounds like there may be some blocking browser related issues.

If you have time and would like to work on it then I would be happy to review a PR and test.

[ehfd]

Connected to #84

[ehfd]

AttributeError: 'BadRRModeError' object has no attribute 'sequence_number'

This error itself should be fixed in v1.6.0 with #84. AZERTY and QWERTZ might even work. Insufficient.

About supporting arbitrary keyboard symbols, this will take some more time.

[ehfd]

@cruizba We're still in progress of porting the .so to ctypes, and we've stumbled on this error where the keycode is mapped outside of accepted bounds. It happens with the .so file method. Do you have any thoughts about this?

From @m1k1o: that could happen if you map too many keysyms that are not mapped to any keycode, and we don't have any more keycodes left. obvious solution is to get number of free keycodes at the beginning and create circular linked list, so that they are overwritten as needed.

[ehfd]

https://w3c.github.io/uievents/tools/key-event-viewer.html

To see if this might be a browser-side issue.

[ehfd]

Leaving this here as it is very relevant to solving the issues: #85 (comment)

[m1k1o]

Also this might be relevant, where I explained my findings when looking into this issue for neko: m1k1o/neko#45 (comment)

[ehfd]

Oh, thanks. @m1k1o I'll leave the fix (m1k1o/neko#46) here too.

[ehfd]

xkb-implementation.tar.gz

The above file contains the developments made by @PMohanJ some time ago to replicate #85 (comment) in pure Python or Cython (ctypes). The ones with _24xxxx at the end are older revisions, and ones without such suffixes are the most recent files. Files starting withpy-xlib is the effort towards a pure Python implementation and files starting with xkb-ctypes is the effort towards a Cython implementation. Text files contain relevant segfaults (to xkb-ctypes) or basic guides.

The fundamental task would be to implement main...cruizba:selkies-gstreamer:fix-inputs (https://github.com/cruizba/selkies-gstreamer/tree/fix-inputs / #85 (comment)) in pure Python or Cython (ctypes), because I do not intend to approve bundling a shared object library to an otherwise pure Python server codebase.

However, Cython has been observed to exhibit various segfaults.
If going to the pure Python direction, we are currently relying on a fork located in https://github.com/selkies-project/python-xlib, so we have the liberty to add or modify as much of the code there as needed, and cherry-pick PRs (https://github.com/python-xlib/python-xlib/pulls) as necessary.

This will ultimately remove the dependency for pynput.

Moreover, it would also be most useful to solve #9 (comment) by implementing a circular linked list for the keysym-keycode dictionary in order to purge old keycodes to make way for new ones.

m1k1o/neko#45 (comment) and m1k1o/neko#46 has also been provided for additional context and information.