joshgoebel / keyszer

a smart, flexible keymapper for X11 (a fork/reboot of xkeysnail )
Other
70 stars 15 forks source link

Support FreeBSD and other BSDs #46

Open joshgoebel opened 2 years ago

joshgoebel commented 2 years ago

Creating a placeholder for this discussion. I'm not sure if this would be a welcome addition since another platform (esp. one I don't actually use) could significantly complicate supporting and developing the software - but perhaps if the patch was small enough... I really don't know enough about BSD's hardware input pieces to speculate.

I'm at least open to a discussion and seeing where this might go if someone was interested in doing the actual work/research.

koobs commented 2 years ago

Hey Josh, I'm from the FreeBSD Project and Python Team. Happy to help answer any questions you have now or going forward, just ping.

On an initial pass, keyszer looks relatively simple to port and package (good job). Here's some initial thoughts/feedback items:

The watchdog Python package supports Linux (inotify), BSD (kqueue), macOS (FSEvents), and Windows file system events API's and might prove useful here.

joshgoebel commented 2 years ago

Thanks for reaching out. I guess I was more worried about the low-level kernel support for input/output devices... such as the evdev and uinput APIs we're built on... are those just drop in the same on BSD such that python-evdev is just going to work for us exactly the same as it does on Linux?

joshgoebel commented 2 years ago

The watchdog Python package supports Linux (inotify), BSD (kqueue), macOS (FSEvents), and Windows file system events API's and might prove useful here.

Looks a bit too high level and complex to me (considering what we do now). Threads, locks, etc... right now our asyncio input loop is very light and simple... our inotify code is primarily like 2-3 lines:

inotify = INotify()
inotify.add_watch("/dev/input", flags.CREATE | flags.ATTRIB | flags.DELETE)
loop.add_reader(inotify.fd, _inotify_handler, devices, device_filter, inotify)

From my reading it seems select.kqueue can be used this way as well (set it up, get a file descriptor to hand off to add_reader) so we'd probably go that route... finding something similar in weight to simple_inotify would be a boon, but we could probably get by without.

joshgoebel commented 2 years ago

All the inotify stuff is hidden behind the --watch argument... if someone was OK with the startup device polling (and didn't need live plug) that library isn't necessary at all... so if all the other pieces "just work" out of the box it should be possible to roughly test things on FreeBSD, just don't use --watch...

joshgoebel commented 2 years ago

I can create a proof-of-concept keyszer FreeBSD Port, run tests and provide feedback on issues, gaps, other problems.

That sounds super helpful - esp if you can also run the actual program and see if the basic I/O flow works... whether it can proxy keys from the input to output successful... the tests just mock out that part.

koobs commented 2 years ago

Thanks for reaching out. I guess I was more worried about the low-level kernel support for input/output devices... such as the evdev and uinput APIs we're built on... are those just drop in the same on BSD such that python-evdev is just going to work for us exactly the same as it does on Linux?

Given we've packaged them it's a positive sign, as there will be Python packages in freebsd ports/packages that consume these as dependencies.

I'll run all dependency test suites to validate the assumption and report back.

koobs commented 2 years ago

I can create a proof-of-concept keyszer FreeBSD Port, run tests and provide feedback on issues, gaps, other problems.

That sounds super helpful - esp if you can also run the actual program and see if the basic I/O flow works... whether it can proxy keys from the input to output successful... the tests just mock out that part.

I should have a PoC and initial feedback either today or tomorrow

joshgoebel commented 2 years ago

https://github.com/rvaiya/keyd/issues/8 FreeBSD is one of the few (only?) BSDs that implement evdev and uinput. It may be possible to port keyd to it with minimal (no?) changes.

Oh so things might actually be easy, at least for FreeBSD...

RedBearAK commented 2 years ago

@joshgoebel

I know one of the reasons I haven't spent much time trying to mess with desktop BSD distros is that I knew I probably couldn't get Kinto working there, and I can't stand any desktop environment for very long without Mac shortcuts. I've also seen multiple issues for Kinto from BSD users wanting to use Kinto on a BSD platform. I'm sure it would be very much appreciated if keyszer could work for the BSDs, and Kinto could tweak the installer a bit if needed.

Certainly a number of desktop-oriented BSD variants are based on FreeBSD. So if you can get working on FreeBSD that's already a big step in the right direction.

Big thumbs up for even looking into this.

joshgoebel commented 2 years ago

I'm not sure what this would mean for Kinto, but one thing at a time.

joshgoebel commented 2 years ago

@koobs You still out there? :)

koobs commented 2 years ago

@koobs You still out there? :)

Yeh mate, my apologies. Limited cycles at the moment, but will continue to make progress where I can. Last update was needing to install "X universe" to run all the tests and I don't run a GUI environment, so that was ... problematic :)

joshgoebel commented 2 years ago

You could test the basic functionality without an X server but to test the actual conditional window name stuff yeah you need a GUI.

lispstudent commented 1 year ago

Let me know if you need a tester, I run FreeBSD 13.1.