Support FreeBSD and other BSDs

[joshgoebel]

trafficstars

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]

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:

• Dependencies: Mostly 👍. FreeBSD already has them all ported (think "source packages") and packaged ("precompiled binary ports")
• Except: inotify_simple. FreeBSD doesn't have inotify(2) syscall. We have kqueue(2).

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

• Pinned (eg: python-xlib == 0.31) versions are problematic, as runtime breaks when that dependency port/package is updated. We usually patch these to >= and hope it continues to work, but a better outcome is upstream just uses/tests/ci's with >= too to pickup issues earlier (pre release). Having test suites packaged with the PyPI sdist is helpful in this regard for our downstream QA, if they're not already.

• Cirrus CI supports FreeBSD natively via a single yaml file like travis for per-commit CI (free for OpenSource). Be great to get that setup in workflows to stay ahead of the game.

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

[joshgoebel]

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]

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]

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]

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]

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]

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]

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]

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

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

[joshgoebel]

@koobs You still out there? :)

[koobs]

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

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]

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