1. 19
  1.  

  2. 9

    Adopt evdev in your kernel. Stop trying to get people to use your legacy input API. Resistance is futile. :P

    Seriously, libinput includes years of effort that went into developing full, high-quality support for touchpads and pen tablets. You are not going to reimplement all that. By trying to stick with old input APIs, you’re practically limiting yourself to only supporting basic mouse input, and you’ll need to keep patching everything all the time.

    Legacy APIs like wscons (Linux had one like that too in the old days) are extremely restrictive and prescriptive — “this is a mouse, it has X/Y and scroll and buttons”. evdev is fully open-ended, it’s kinda like passing HID events through to userspace with slight simplification/normalization. This lets userspace (libinput) interpret all the things in the best way possible and support all the awesome new kinds of input.

    So in FreeBSD we can just, say, run RetroArch or Kodi directly on DRM/KMS with full input support including PS4 and Xbox360 gamepads, without patching anything because we have the evdev drivers. The evdev ecosystem is so rich that I could even like, forward said gamepad over the network. I can record multi-touch gestures on my laptop and replay the events on my desktop for testing applications. And so on.

    In pkgsrc we’ve patched the libraries to add kqueue(2) support

    libepoll-shim already supports all the BSDs. It’s been heavily tested by years of daily use on lots of FreeBSD desktops. You can just use it instead of spending time on patching, which inevitably includes developing additional bugs for yourself to debug ;)

    Updating the NetBSD kernel DRM/KMS stack

    Huh, it’s so out of date that it doesn’t have atomic modesetting? OpenBSD is very up to date, with Linux 5.7 code even — I just kind of assumed that NetBSD was keeping up with OpenBSD, guess I was very wrong?

    1. 10

      “This lets userspace (libinput) interpret all the things in the best way possible and support all the awesome new kinds of input.”

      It barely supports any of what is actually ‘new’ kinds of input devices (true for both evdev and libinput), the support it has for what little it can do is rigid as all hell and not ‘the best way possible’; if you want to go ‘appeal to authority’ we should just suck it up and port libhardware/inputhub as that is the evdev abstraction with billions of hours of use behind it. Ultimately we’ll hit the same “oh this design permeates everything and irreparably blocks latency and performance work and we can’t hack around it the way windows does” but fdo desktop won’t reach that point in half a decade still, if ever.

      For the sake of it, I wrote this reply using only my eyes and no evdev.

      1. 5

        Multi-touch touchpads, touchscreens, drawing tablets and high-res-wheel mice are very “new” relative to what legacy APIs like wscons support, which is literally only basic mice. I wonder what “even newer” devices you have in mind. (upd: I guess “wrote this reply using only my eyes” is a hint.) You’re always ahead of the whole world and smarter than everyone else :)

        1. 5

          And that’s why the touchscreen on my ThinkPad Yoga was working out of the box in 2018 and Wacom tablets just work on NetBSD as well.
          Give it a rest.

            1. 3

              Be honest, have you been on Github for the last ~ 20 minutes? :) (edited time)

          1. 5

            Except the “distance” from wscons to those devices is smaller than the over-generic crap evdev provides, ignoring the bits about force-feedback, LEDs and identity (what “is” /dev/input/event0 ? a race condition if you have systemd.) where it entirely fails to capture what the devices can do and settle for a “1999- usb-hid 1.1) model (that’s where evdev design stopped by the way). Extend the structs as time progress, sizeof() for versioning, bump the kernel and be done with it – not this whole ioctl-“EVIOCGUNIQ, EVIOCGBIT, EVIOCGBIT’ 1kloc switch to figure out that a mouse is a mouse but perhaps it is a keyboard in a mouse or it is a mouse that identifies as a keyboard with a scroll wheel schtick. For ’BSD a reasonably simple device model is the least of their struggles.

            WIth pratical evdev in linux userspace, anyone who actually factually is forced to use the thing ends up with heuristics, databases and tears. Nothing is certain and nothing is stable even if the kernel knows or could know better. “Oh this here device, if it exposes 63 buttons it is a gamepad but 67 it is a keyboard” – that’s in udev somewhere btw.). Don’t take my word for it, why should you, just look at the SDL2 database of “fixups”. That’s still “analog + digital” not even the spectrum of what it tries to expose (force-feedback and LEDs).

            The grander problem with the ‘model’ is that read(), unpack(), filter(), foward() looks super simple when you write it and post to phoronix about the grand project. Then somewhere along the road comes “this here PS4 controller has 48 analog axes that sample at 1kHz / s. each amounting to a syscall or 4 before it reaches the consumer and now 40% of my CPU is doing nonesense”. As soon as you step out of the ‘simple’ model you are either underperforming and hiding the fact (evdev) or have an actual interface for the purpose.

            I wonder what “even newer” devices you have in mind. (upd: I guess “wrote this reply using only my eyes” is a hint.)

            Some examples that you can get today without qualifying for disabilities, dabble in VR, collect arcade hardware or have a 3d-modeller at AAA gamedev tool budget for - 3Dconnextion space-nav, Tobii-5C, Asus ScreenPad, ElGato Stream Deck (all in the big box of toys for the moment).

            You’re always ahead of the whole world and smarter than everyone else :)

            Well I’m not - but, I did work on a SONY specialist team with input, graphics and security (they’re connected) from ~2009 into 2015, and I switched to doing work on assistive devices for special needs since then. I had “group” therapy with themaister/squarepusher back when they had the ‘evdev’ struggle for rarch. More importantly, I do have frequent beers with people who actually advance the field and that helps.

            1. 3

              Extend the structs as time progress, sizeof() for versioning, bump the kernel and be done with it

              Okay sure whatever, have fun patching everything that expects evdev. But nobody has done that in practice yet :/ This is what gets me – it’s late 2020 and the evdev-resistant BSDs still haven’t extended their APIs for multi-touch. How can anyone live without multi-touch? Without touchpad gestures?

              what “is” /dev/input/event0 ? a race condition if you have systemd.

              I’m not sure when a race condition would matter here (nothing should rely on fixed device numbers), but I always disliked how Linux populates /dev from userspace..

              1kloc switch to figure out that a mouse is a mouse but perhaps it is a keyboard in a mouse

              Usually this doesn’t need that many lines, a simple heuristic takes like 150 lines max and works really well if your kernel exposes a “keyboard in a mouse” as a separate device.

              The kernel has to do heuristics on USB HID anyway, and it’s not guaranteed that it would know better. Certainly in userspace it’s easier and faster to update them?

              this here PS4 controller has 48 analog axes that sample at 1kHz

              That sounds ridiculous, I wonder what the device is (VR something..?) Why would it sample so much faster than the system can render? Competitive Counter-Strike players love their 1000Hz mice because they think they can feel the microscopic latency advantage, but that should not matter for a console.

              1. 1

                That sounds ridiculous, I wonder what the device is (VR something..?) Why would it sample so much faster than the system can render? Competitive Counter-Strike players love their 1000Hz mice because they think they can feel the microscopic latency advantage, but that should not matter for a console.

                Even your touch display is typically clocked and dynamically re-clocked at multiples of the display (processing naturally ‘bins’ around display vrefresh clock) so that samples are artificially paced or can be resampled to compensate for poor event processing further down the chain, 1000Hz isn’t much at all. You also sample at much higher rates and then filter later in the chain to account for the hardware degrading over time; fail to provide the right controls at the right layer for that and you have the ‘analog drift’ recall / repair that, for instance, Nintendo Switch suffers.

                It’s not exactly 48 but it’s not that far off on the dual shock itself* if you start looking at what the thing can do though current firmwares are much better at not fire-hosing the rest of the system - Recall it has multi-touch, a full IMU, an extension bus, builtin- speakers. (Feature set shifted a bit, PS3 version was notoriously loud as even the dpad/square,tri,… buttons were pressure sensitive).

                1. 1

                  Touch displays on mobile devices were 60 Hz for a long time. IIRC Apple loudly advertised their switch to 120Hz touch, probably as a marketing trick to kind of leverage people’s hype for higher-Hz display :)

                  PS3 version was notoriously loud as even the dpad/square,tri,… buttons were pressure sensitive

                  Hoooooly shit, TIL. I suppose none of the PS3 games leveraged that though? Haven’t heard about this from the RPCS3 emulator devs..

                  can be resampled

                  Heh, rarely has anyone bothered to do that in the freedesktop world.. until I landed a kinetic-scrolling-on-gtk patch in Firefox and one person noticed that it feels kinda jittery on their external trackpad, and eventually patched GTK to interpolate the events.

                  1. 1

                    What the specs or marketing said I don’t really care, you could squeeze it much higher but getting it reliable/accurate is a different story, but now it’s close to NDA territory. Working with the raw “heightmap” is much more interesting than the I2C/SPI aftermath (and there it becomes obvious why some advanced forms of arthritis and similar conditions have problems with multitouch). https://www.youtube.com/watch?v=bW07-iPqaEk is literally a video from parts of a measurement rig on the thing back in ~2014.

                    Hoooooly shit, TIL. I suppose none of the PS3 games leveraged that though? Haven’t heard about this from the RPCS3 emulator devs..

                    AFAIR there were some driving games, some choking gimmick in metal gear solid and probably elsewhere. I would suspect some enterprising fighting games would use it for latency, it’s not like you can easily “stop” when you’ve started. Fun tidbit, same is true for touch - before you make contact with the surface the sensor knows you’re there and what you are about to do, an opportune time to increase some clocks and adjust scheduling ..

                2. 1

                  kay sure whatever, have fun patching everything that expects evdev. But nobody has done that in practice yet :/ This is what gets me – it’s late 2020 and the evdev-resistant BSDs still haven’t extended their APIs for multi-touch. How can anyone live without multi-touch? Without touchpad gestures?

                  As for Net/Open not doing the work to expand wscons in particular; I don’t think it’s more complicated than having much bigger fish to fry in order to maintain or widen the niche that even reflecting on these things is not really on the map. Should the situation remain the same when I am at that stage of performance tuning I’ll happily write the patches.

                  Personally I don’t know for what case you would want touchpads, much less multi-touch gestures, outside of mobile for anything other than explicit “pointing” - fragile, imprecise and poor haptics. Scroll/zoom/pan are better with 3D mice or, for smaller budgets, rotary controllers.

                  Usually this doesn’t need that many lines, a simple heuristic takes like 150 lines max and works really well if your kernel exposes a “keyboard in a mouse” as a separate device. The kernel has to do heuristics on USB HID anyway, and it’s not guaranteed that it would know better. Certainly in userspace it’s easier and faster to update them?

                  You want the filterchain to be consistent and configurable across every layer so that you can remap, reconfigure increment/decrement sample rates, Kalman-esque sensor fusion and mask / discard at the earliest stage possible or input will remain the same jittery mess. If that would take some BPFy solution so be it. Udev and worse fixup databases are anything but the way to go. Linux is too far along that there really isn’t a choice anymore but to further the ad-hoc hackfest they’ve created for themselves. BSDs can lead by example and not spread the taint.

                  1. 1

                    Scroll/zoom/pan are better with 3D mice

                    You’re not gonna carry a 3D mouse to zoom a PDF on a laptop on the go, right?

                    Have you never used a MacBook? When I got one in 2010, I became instantly used to panning, zooming and rotating images and PDFs, and flicking between desktops with four finger swipes. I don’t even use multiple desktops that much, swiping between them just feels good. I literally reimplemented that feature in Wayfire so I could do that again in my compositor of choice :)

                    increment/decrement sample rates

                    Hmm, but usually HID is interrupt driven, the only sample rate change I know of is that my mouse can do that in its firmware in response to me toggling a physical switch. You could skip every Nth interrupt to reduce rate on the computer side but idk how that would work with relative axes especially..

                    1. 1

                      I have a macbook pro or three in the pile though they are exclusively for doing unsavoury things to iphones.

                      GPD Pocket 2, kobo reader and Surface Go mostly when mobile - still I use the surface dial or modified capto-glove for anything analog.

                      Hmm, but usually HID is interrupt driven, the only sample rate change I know of is that my mouse can do that in its firmware in response to me toggling a physical switch. You could skip every Nth interrupt to reduce rate on the computer side but idk how that would work with relative axes especially..

                      You can still have an accumulator and some filters on interrupt before passing onwards. Although it would surprise me greatly if it is not polling on the wire but appears interrupt driven in software, but with everything-goes when HoG and whatever USB3 has added into the mix I don’t think I know anything about that space anymore. Anyhow, quick linux ref (https://wiki.archlinux.org/index.php/Mouse_polling_rate).

          2. 7

            Stop trying to get people to use your legacy input API.

            Tech is full of people who are convinced that their way is the only correct or “non-legacy” way of doing things. Other fields have mostly matured past this.

            this is a mouse, it has X/Y and scroll and buttons

            It’s not the only way of doing things, but it’s a convenient abstraction to program for. If you read a lot of code that does libinput things, this is often all it cares about… Absolute or relative coordinates from one or more pointing device, buttons, and scrolling.

            libepoll-shim already supports all the BSDs.

            This is definitely news to me, and to the patches in our tree. Did you only test it on FreeBSD?

            Huh, it’s so out of date that it doesn’t have atomic modesetting?

            Yes, we have less funds and less humanpower than your project. And yes, we’re at 4.4.

            Anything else you’d like to be smug about today?

            1. 2

              This is definitely news to me

              Note that the upstream is https://github.com/jiixyj/epoll-shim – there is an outdated fork on the FreeBSDDesktop organization, ignore that. The readme definitely suggests the author has tested it everywhere.

              yes, we’re at 4.4

              Oh, atomic landed in 4.2 so you should have it?..

          3. 5

            These libraries currently have hard dependencies on Linux kernel APIs like epoll. In pkgsrc we’ve patched the libraries to add kqueue(2) support, but the patches haven’t been accepted upstream.

            Wayland is written with the assumption of Linux to the extent that every client application tends to #include <linux/input.h> because Wayland’s designers didn’t see the need to define a OS-neutral way to get mouse button IDs.

            It’s sad this is the direction freedesktop / Xorg went.