BoppreH

It uses `ctypes`, so it needs an update before supporting an ARM-based CPU like M1. Unfortunately I don't have a Mac to develop on, so I rely 100% on community...

@rasoolmohammedy It's somewhere in https://github.com/boppreh/keyboard/blob/master/keyboard/_darwinkeyboard.py , though where exactly needs more testing. Some places that could be: - the [ctypes functions](https://github.com/boppreh/keyboard/blob/master/keyboard/_darwinkeyboard.py#L72) have an incorrect type somewhere; - the [Carbon](https://github.com/boppreh/keyboard/blob/538ea9168bd50ed89465981b1ff638ef3475a7d9/keyboard/_darwinkeyboard.py#L17) /...

Note: not ready yet for merging. Deep changes with little testing and non-optimized structures.

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...

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...

@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 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...

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...

@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...

@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...