X Tutup
The Wayback Machine - https://web.archive.org/web/20210106130911/https://github.com/python-xlib/python-xlib/issues/140
Skip to content

/ python-xlib

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

Jump to bottom

Documentation for keycode_to_keysym? #140

Open
cryzed opened this issue Feb 23, 2019 · 2 comments
Open

Documentation for keycode_to_keysym? #140

cryzed opened this issue Feb 23, 2019 · 2 comments
Labels
enhancement

Comments

@cryzed
Copy link

@cryzed cryzed commented Feb 23, 2019 •
edited

I've checked your examples, specifically the record_demo.py. The keysym you get here simply passes 0 as the shift index, which is not correct, so the output is always the unshifted character (for example lowercase 'a' instead of 'A' or 'a' instead of 'ä'). I know why you have likely done this, because it's very hard to find documentation on how to actually calculate the shift index out of the event.detail field (possibly combined with other state).

So in hopes that someone does know, can you point me to a place where I could possibly learn more about on how to correctly determine the shift index? I've attempted this ages ago on my own, and came up with something more or less working here, which seems to work in all cases for my keyboard configuration (including Alt-Gr or "left alt" special xkb mappings), but this doesn't feel correct and I'm sure there are scenarios where this wouldn't just work.
@vasily-v-ryabov
Copy link
Collaborator

@vasily-v-ryabov vasily-v-ryabov commented May 21, 2019

Sorry, I can't help with the sources to learn. But if you were able to find good solution, I'd be happy to review a PR (maybe with some delay since python-xlib is not the highest priority for me).
@Szunti
Copy link

@Szunti Szunti commented Jun 20, 2019

I'm not expert, but as I see, you need to use the xkb extension to handle Alt Gr correctly.

The problem is that core protocol can only get a one dimensional list of keysyms per keycode and only the first four elements have a fixed meaning: 2 groups with 2 levels each. But there can be arbitrary number of additional keysyms in the list without a defined meaning.

Xkb can have up to 4 groups and I think any number of levels per group. Groups can have different number of levels too. In the common layouts Alt Gr is the third level, Alt Gr+Shift is fourth.

The extra keysyms are reported to the core request GetKeyboardMapping, but without knowing the number of groups and the number of levels in each group you can't tell the correct index.
Even Xlib redefines the common keysym related functions with Xkb using variants as seen in https://gitlab.freedesktop.org/xorg/lib/libx11/blob/master/src/KeyBind.c#L54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
No milestone
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
@cryzed @Szunti @vasily-v-ryabov
You can’t perform that action at this time.
X Tutup