X Inputs about keyboard

[boppreh]

Good news, xlib integration is being worked on: https://github.com/boppreh/keyboard/tree/xlib

I'm following @lenisko's idea of importing xlib when it's available, or falling back to raw devices. If the import fails due to lack of sudo, the message will also reflect that using xlib is an option.

Right now basic hooks are working, so if you have python-xlib installed you can just python -m keyboard and record yourself.

Feature roadmap:

1. Send events.
2. Get actual scan code and not just keysym, for portability with other systems.
3. Correct key names (standardize, accept non-ASCII, reflect modifiers).
4. (at this point we have feature parity with the raw device files, so we can release a new version with this optional backend)
5. Enable key suppression on Linux (finally!).
6. Use new xlib knowledge to try going ctypes-only and avoid the dependency.

I'll also give udev a try (#124), maybe we get multiple Linux backends.

[xlucn]

Will there be any update on this? There seems to be no actual xlib code pushed to the branch.

[boppreh]

@lenisko That's not ideal, but I like the idea. I'll see what I can do.

I'm not sure why your access control changes are not working.

[lenisko]

@xoviat I wouldn't expect instant switch on all distributions, for example I'm not using Wayland.

@badtyprr what about keyboard-sudoless as addition to basic library? it could install everything needed to get hotkeys without need to use sudo. In main package we can just check if it exist to enable this functionality.

For now library is useless on Unix systems I mean using sudo to get hotkeys in application is just bad. But I bet there are use cases where someone doesn't care 😅 about that.

I'll monitor your changes, cheers!

[boppreh]

@izik1 : thank you for your interest.

These functions need to be implemented in a submodule for it to be a "backend":

• init(): if there's anything to preload or cache (e.g. key name tables), do so here to avoid slowing down the import.
• listen(callback): starts a listener that calls callback(event) for every keyboard event, passing a KeyboardEvent object. If the callback returns False, the event should be suppressed (if supported).
• map_name(name): maps a string name to a list of different ways to get that value, as [scan_code, modifier_names]. For example, a valid return for map_name('&') may be [(8, ('shift',))] (i.e. you can get "&" by holding shift and pressing the key number 8).
• press(code) and release(code): send a press or a release event for a specific scan code.
• type_unicode(letter): if supported, sends a keyboard event that types a given unicode symbol without actually mapping it to any keys. Windows has a special syscall for this, for example, and most unix systems support a key combination that allows typing the unicode code point. To be used when the user tries to send an event for a symbol that is not available in the keyboard.

Once you have this basic functions in a submodule, the main module can tap into it as a backend and add all the hotkey/macro/recording stuff. You can look at the other OS backends to see how it's usually done, or look for "os_keyboard." invocations in the main module to see how its used.

I realize this explanation is very bare bones, but I've started working again on this library so I'll do my best to support you on this.

[Avasam]

Would you be interested in an X-based global hotkey capture?

Absolutely. I already rely on X anyway to find windows location and record them.

Telling my users to add themselves to groups, setting rules and permission. Is not a viable long-term solution, at best it's a patch while I'm working on full feature-parity with Windows. If it's still the case by the time I'm done with all other features, I'll simply have to drop the keyboard module and rewrite all of my hotkeys code. Which I would rather not have to do ^^"

[boppreh]

That's an interesting idea, thank you. I have had some success in calling X code directly with ctypes, so maybe the python-xlib dependency could be removed. Yes, eliminating the need for root would be awesome. I'll look into it when I get home. Thank you.

[Xcelled]

I originally started out using ctypes, but when I got to XEvent, which is a huge union, I said "forget this!" and switched to a lib. Here's what I have so far, though it's obviously incomplete: https://github.com/Xcelled/shorty/blob/master/x11.py

By the way, here is some more code that may be helpful: https://github.com/PyUserInput/PyUserInput/blob/master/pykeyboard/x11.py

[lenisko]

Any update on this one? running root is little overkill for most cases, would be really nice to find a proper solution to avoid that

[boppreh]

I've been trying to use ctypes + the system's xlib.so, but couldn't make it work (calls either do nothing or segfault).

The next options are trying raw sockets to connect to the X server (a lot more work, but doesn't depend on .so files) and, failing that, using python-xlib and sacrificing the "dependency-less" property of the library.

Suggestions welcome.

[lenisko]

What do you think about trying to import python-xlib if it fails leave current way with sudo if it's in there just use it? this way we could avoid using root with one dependency.

From what I can see current solution is adding permissions to /usr/bin/dumpkeys and adding user to input group to avoid using root privileges. But still it's failing on newly created event (in my case event17) dunno why.

[lenisko]

@boppreh any update on this one?

The update is that this had become a complete nightmare, IIUC. Wayland is going to replace X and it has no global hotkey handler.

[boppreh]

@lenisko Tried again and still couldn't get pure X + ctypes working, haven't got around to adding Xlib yet. I'll also have to check how to add optional dependencies in pip, I don't want the people on Raspberry Pi needlessly installing xorg because of this.

@xoviat That is indeed a problem. For the record, here's a thread about similar issues where they mention "Wayland doesn't allow clients to have an active grab" and "[Applications] won't be able to get events for key combos that are registered as global shortcuts in the compositor". For now, Xlib will help at least some of the cases.

[arigit]

@boppreh will capturing from raw devices still work on Wayland? planning to build a mini service to capture hotkeys regardless of whether there is a display connected and trying to understand if this library is wayland-friendly; this is for an HTPC running Xorg but sooner or later wayland is coming

[boppreh]

@arigit The current behavior of capturing raw devices is not going to go away. I'm still thinking on how to let the user decide which backend to use, but at the moment you need to have python-xlib installed to have anything other than raw device capture.

[izik1]

I'd be willing to work on this (and or #124), what would I need to do?

[akibrhast]

@boppreh welcome back!!

[nartes]

It seems like for a rootless access on linux the following is enough:

• add user to input group, allows input subsystem access
• add custom udev rule, to account for uinput

ACTION!="add", GOTO="default_end"

SUBSYSTEM=="misc", DEVPATH=="/devices/virtual/misc/uinput", GROUP="input"
SUBSYSTEM=="misc", DEVPATH=="/devices/virtual/misc/uinput", MODE="0660"

LABEL="default_end"

• stub dumpkeys calls with translate tables, e.g.

sudo dumpkeys --keys-only > dump_keys_only.txt
sudo dumpkeys --long-info > dump_long_info.txt

[Froloket64]

@nartes, it's not a solution though, it's just a hack.
I don't want users of my script/program to have to do all of the above in order to just use it.

But thanks for a temporary workaround nonetheless