14 ms·

Wayland on OpenBSD

213 points by type0 3y ago

kelnos 3y ago
I know this is just a "hack it together" effort, but I wonder if it even makes sense to emulate/support libevdev and libinput on non-Linux OSes. While the Wayland protocol does reuse some libinput names/enums/etc., I don't believe there's anything in it that requires those particular implementations or APIs (that is, wl_pointer and wl_keyboard doesn't have to be populated by libinput). Maybe wlroots should have OpenBSD-specific parts to its backend abstraction that use OpenBSD's usual input handling primitives. Granted, this would mean non-wlroots compositors would also have to implement this if they want OpenBSD support, but I'm not sure I'm convinced it's good for the OS ecosystem in general to standardize the userland interface that's provided to interact with more and more hardware. Put another way, libinput seems fine to me, but part of the reason to have different OSes in the first place is to allow people to explore different approaches to doing things. Requiring that every OS that wants to have Wayland do things the libinput way seems counterproductive. Relatedly, it seems silly to me to get seatd running on OpenBSD if OpenBSD doesn't support the concept of multiple seats. Compositors should just have a mode where a single, static seat is defined that owns all input and display devices.
- themerone 3y ago
  I think this is about preparing for a post X11 future. As Wayland continues to mature, classic X will attract fewer developer resources. I think it will eventually start to suffer benign neglect, and stop keeping up with new hardware.
  - hist_thr 3y ago
    Wayland is a replacement for X11 in the same way that a tricycle is a replacement for a tractor. They have thrown everything difficult out of the spec and only implemented the most trivial functionality around a security model which you must actively break to get actual work (like screen shots) done. That Wayland is 10 years old and still barely usable should tell you how far software developers have fallen in the last 30 years.
    - teekert 3y ago
      When I'm on Gnome, and I select Gnome on X, my trackpad functions as one expects from Linux. When I'm on Wayland, it's like a macbook.
      - bandrami 3y ago
        And can't be configured. The loss of function for clickpads is particularly egregious; they're basically unusable under Wayland.
        teekert 3y ago
        It's funny how I finally find my touchpad usable under wayland ¯\_(ツ)_/¯
        bandrami 3y ago
        Notice I said clickpads. Touchpads work fine once you work around Wayland's bizarre fear of enabling tap-to-click.
        teekert 3y ago
        Ah, I don't like tap-to-click, I always disable it, I need that clicky feeling, often I'll hook up a mouse as well :)
        oynqr 3y ago
        s/Wayland/Gnome/g
        bandrami 3y ago
        IIRC the culprit is libinput, which worries tap to click is "confusing" for some reason. Which is why I use synaptics when I'm on X.
    - rodgerd 3y ago
  - kelnos 3y ago
    Not sure what your comment has to do with mine? I'm not debating whether or not X11 will stick around, or whether getting Wayland working on OpenBSD is a good idea or not. I was talking about the specific software dependency choices used for this rough port.
  - badsectoracula 3y ago
    > I think it will eventually start to suffer benign neglect, and stop keeping up with new hardware. At least on Linux, Xorg and Wayland compositors use the same underlying APIs, so the chances of Xorg not running somewhere Wayland runs are pretty much zero - unless said new hardware is only exposed via a new kernel API and nobody bothers to update the modesetting driver for it and/or to write a new Xorg driver for the new API.
    - csande17 3y ago
      > unless said new hardware is only exposed via a new kernel API and nobody bothers to update the modesetting driver for it And this is actually really unlikely for Wayland, isn't it? The whole idea is that each desktop environment implements its own display server using the modesetting API. That's why there's all kinds of drama about Nvidia "not supporting Wayland"; their kernel driver exposes some nonstandard APIs, and they can patch Xorg to support those APIs, but they can't patch every Wayland compositor in the world. I guess Xorg could hit bugs in the modesetting driver that the most popular Wayland compositors don't hit. IIRC that was an issue for Asahi Linux's Apple M1 video driver.
      - badsectoracula 3y ago
        Might be unlikely but not impossible - after all if people cared about not breaking existing software Wayland itself wouldn't exist in the first place :-P Xorg is open source and drivers can be fixed as long as there are enough people to notice and care. Worst case you can run an X root window on top of Wayland compositor and pretend the latter is just a graphics driver :-P.
    - shmerl 3y ago
      > Xorg and Wayland compositors use the same underlying APIs Not really. KWin has Wayland specific paths that simply don't work on X and developers are increasingly simply not bothering to go out of their way with X if something isn't possible to implement over it. So X use case is going to further deteriorate, that's inevitable.
      - 3y ago
  - bandrami 3y ago
    The OpenBSD team maintains and updates their own port of Xorg so the whole "what if xorg disappears?" hysteria doesn't really apply to that platform.
- shmerl 3y ago
  I think standardizing on libinput is a big deal, even if it's not required for Wayland use case. Otherwise it would have become a constant reinvention of the wheel. Same goes for other similar use cases that aren't tied to Wayland protocols, but are critical for Wayland compositors to function and before used to be handled by Xorg in some unified fashion.
  - deleted 3y ago
    [deleted]
- emersion 3y ago
  seatd isn't just about multi-seat. In fact, seatd doesn't even support multi-seat at the moment. See this post for more details: https://lists.sr.ht/~kennylevinsen/seatd-devel/%3C3561460.kQq0lBPeGt%40tycho%3E#%3CH0L3KQ.8EO3ABVY6CGC3@kl.wtf%3E https://lists.sr.ht/~kennylevinsen/seatd-devel/%3C3561460.kQ...
- mananaysiempre 3y ago
  > Maybe wlroots should have OpenBSD-specific parts to its backend abstraction that use OpenBSD's usual input handling primitives. My (shallow and likely out-of-date) impression was that wlroots the library baking in Linux things was a more serious problem for porting than Wayland the protocol actually mandating anything seriously Linux-specific (I understand how the choice to use Linux key codes might be annoying, but still, meh). Have they gotten around to excising the event loop library out of there, for example?
Ericson2314 3y ago
We've been doing some BSD cross work with Nixpkgs. A hope is that if we can extend that to NixOS too, and then it should be quite easy to checkpoint and share work like this for anyone to reproduce and pick up the baton on.
- 1MachineElf 3y ago
  Can you share any more information about the BSD cross work with Nixpkgs?
  - Ericson2314 3y ago
    How to use it? Or what we've done? For using it, you can try nix-build 'channel:nixpkgs-unstable' -A pkgsCross.x86_64-netbsd.libcpuid nix-build 'channel:nixpkgs-unstable' -A pkgsCross.x86_64-freebsd.libcpuid For the gory details, check out https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/bsd/netbsd/default.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specifi... and https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/bsd/freebsd/default.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specifi...
shrubble 3y ago
I as a user haven't seen any reason to care about Wayland. And losing/dropping X11's network transparency seems rather surprising in a heavily networked world...
- dagenix 3y ago
  In my experience, running X11 over a network worked very poorly. There is significant overlap between former X11 developers and Wayland developers. They didn't drop it because they are incompetent which seems to be what your are implying. The people that decided to drop it are probably the people that know X11 the best.
  - pengaru 3y ago
    It didn't work poorly back when X clients were actually using Xlib for drawing primitives performed by the display server. It started working poorly when X clients started rendering everything locally in the client and simply pushing pixels to the display server.
    - bitwize 3y ago
      > It started working poorly when X clients started rendering everything locally in the client and simply pushing pixels to the display server. Which means it works poorly for modern apps. Modern apps use the GPU for client-side rendering. And it absolutely worked poorly even in the 90s. It was virtually impossible to run X apps over anything but a fast local LAN. That's what "Broadway"/LBX was about. It was kind of a failure. RDP has been a better networked display protocol than X for a couple decades now. Let's not fool ourselves that X isn't obsolete on every axis.
      - pengaru 3y ago
        > Let's not fool ourselves that X isn't obsolete on every axis. I'm not sure who you're replying to here, because it certainly isn't me.
  - 3y ago
bitwize 3y ago
Now that Xorg development is moribund, people have been telling me "oh, there's always Xenocara". It seems even in BSD-land, people are thinking seriously about moving on from X. Netcraft sure as hell confirms it now: X11 is dying.
klardotsh 3y ago
I've been wanting to give OpenBSD an honest shot on the desktop for years, but going back to X has always been a deal breaker for me (HiDPI and mixed/scaled DPI support, and tear-less graphics, are hard requirements that X handles horribly - yes, before the X apologists brigade me, I know because I used to hack X into horribly supporting these things). This could finally let me dive into the only BSD that really catches my attention for potential to switch over - I applaud this effort!
- amatecha 3y ago
  OpenBSD is pretty sweet! been daily-driving as desktop OS (as in, not a server) for ~2 years now. Though, on a 1366x768 ThinkPad, so not too concerned about DPI hahah
w0ne 3y ago
Hopefully one day we will see Wayland achieve the reputation it deserves and let it replace Xorg!
AJRF 3y ago
I am an outside observer but in any discussion of Wayland I always see this article referenced: https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277 https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d... It seems like so much stuff is broken but the devs deny it is broken? And even with that situation - every major distro is making in roads to adopting it? Is that a fair characterisation or am I off the mark?
- vetinari 3y ago
  It not broken. The complains on the linked gist remind me complaining, how introducing protected memory broke applications. And you couldn't read or write i/o ports directly in our app anymore, you had to go through so-called kernel! So much bloat! So I put wayland is broken, because it doesn't allow what x11 did in the same way, ideally stomping on the others into the same category. For screenshots and capture, there's an API now (controlled, user is in the control, cannot be done behind his back. Scoped also, with granularity from window to desktop). For global shortcuts, there's an API in the making.
  - rcxdude 3y ago
    > For global shortcuts, there's an API in the making. This is kind of the problem, though. X11's model of 'everything can access everything' is obviously bad, but when wayland went with a more restrictive model they didn't provide a means for legitimate functionality like this. That's basically the origin of all the objection: things that worked on X11 don't work on wayland, because wayland's developers seem to be very slow to recognise and provide for things which were extremely common on X11. It's been 14 years and the API for global shortcuts is still in the making! (And I know there's DE-specific interfaces for a lot of these things. But when you tell app developers this they're either going to implement it for their DE or not bother to implement it at all, as opposed to going through each DE and working it out, especially if it's more complex to support granular permissions and so on. So then users will see that app functionality breaks on wayland, and blame wayland, somewhat fairly)
    - vetinari 3y ago
mrweasel 3y ago
If OpenBSD manages to get Wayland working just the way they want it, with Pledge, Unveil, privileged separation and what have you, I would not be at all surprised if they also came up with their own compositor / window manager thing and a plan for removing X11 in future releases a few years later.

213 points by type0 3y ago

I know this is just a "hack it together" effort, but I wonder if it even makes sense to emulate/support libevdev and libinput on non-Linux OSes. While the Wayland protocol does reuse some libinput names/enums/etc., I don't believe there's anything in it that requires those particular implementations or APIs (that is, wl_pointer and wl_keyboard doesn't have to be populated by libinput). Maybe wlroots should have OpenBSD-specific parts to its backend abstraction that use OpenBSD's usual input handling primitives. Granted, this would mean non-wlroots compositors would also have to implement this if they want OpenBSD support, but I'm not sure I'm convinced it's good for the OS ecosystem in general to standardize the userland interface that's provided to interact with more and more hardware. Put another way, libinput seems fine to me, but part of the reason to have different OSes in the first place is to allow people to explore different approaches to doing things. Requiring that every OS that wants to have Wayland do things the libinput way seems counterproductive. Relatedly, it seems silly to me to get seatd running on OpenBSD if OpenBSD doesn't support the concept of multiple seats. Compositors should just have a mode where a single, static seat is defined that owns all input and display devices.

themerone 3y ago
I think this is about preparing for a post X11 future. As Wayland continues to mature, classic X will attract fewer developer resources. I think it will eventually start to suffer benign neglect, and stop keeping up with new hardware.
- hist_thr 3y ago
  Wayland is a replacement for X11 in the same way that a tricycle is a replacement for a tractor. They have thrown everything difficult out of the spec and only implemented the most trivial functionality around a security model which you must actively break to get actual work (like screen shots) done. That Wayland is 10 years old and still barely usable should tell you how far software developers have fallen in the last 30 years.
  - teekert 3y ago
    When I'm on Gnome, and I select Gnome on X, my trackpad functions as one expects from Linux. When I'm on Wayland, it's like a macbook.
    - bandrami 3y ago
      And can't be configured. The loss of function for clickpads is particularly egregious; they're basically unusable under Wayland.
      - teekert 3y ago
        It's funny how I finally find my touchpad usable under wayland ¯\_(ツ)_/¯
        bandrami 3y ago
        Notice I said clickpads. Touchpads work fine once you work around Wayland's bizarre fear of enabling tap-to-click.
        teekert 3y ago
        Ah, I don't like tap-to-click, I always disable it, I need that clicky feeling, often I'll hook up a mouse as well :)
        oynqr 3y ago
        s/Wayland/Gnome/g
        bandrami 3y ago
        IIRC the culprit is libinput, which worries tap to click is "confusing" for some reason. Which is why I use synaptics when I'm on X.
  - rodgerd 3y ago
- kelnos 3y ago
  Not sure what your comment has to do with mine? I'm not debating whether or not X11 will stick around, or whether getting Wayland working on OpenBSD is a good idea or not. I was talking about the specific software dependency choices used for this rough port.
- badsectoracula 3y ago
  > I think it will eventually start to suffer benign neglect, and stop keeping up with new hardware. At least on Linux, Xorg and Wayland compositors use the same underlying APIs, so the chances of Xorg not running somewhere Wayland runs are pretty much zero - unless said new hardware is only exposed via a new kernel API and nobody bothers to update the modesetting driver for it and/or to write a new Xorg driver for the new API.
  - csande17 3y ago
    > unless said new hardware is only exposed via a new kernel API and nobody bothers to update the modesetting driver for it And this is actually really unlikely for Wayland, isn't it? The whole idea is that each desktop environment implements its own display server using the modesetting API. That's why there's all kinds of drama about Nvidia "not supporting Wayland"; their kernel driver exposes some nonstandard APIs, and they can patch Xorg to support those APIs, but they can't patch every Wayland compositor in the world. I guess Xorg could hit bugs in the modesetting driver that the most popular Wayland compositors don't hit. IIRC that was an issue for Asahi Linux's Apple M1 video driver.
    - badsectoracula 3y ago
      Might be unlikely but not impossible - after all if people cared about not breaking existing software Wayland itself wouldn't exist in the first place :-P Xorg is open source and drivers can be fixed as long as there are enough people to notice and care. Worst case you can run an X root window on top of Wayland compositor and pretend the latter is just a graphics driver :-P.
  - shmerl 3y ago
    > Xorg and Wayland compositors use the same underlying APIs Not really. KWin has Wayland specific paths that simply don't work on X and developers are increasingly simply not bothering to go out of their way with X if something isn't possible to implement over it. So X use case is going to further deteriorate, that's inevitable.
    - 3y ago
- bandrami 3y ago
  The OpenBSD team maintains and updates their own port of Xorg so the whole "what if xorg disappears?" hysteria doesn't really apply to that platform.
shmerl 3y ago
I think standardizing on libinput is a big deal, even if it's not required for Wayland use case. Otherwise it would have become a constant reinvention of the wheel. Same goes for other similar use cases that aren't tied to Wayland protocols, but are critical for Wayland compositors to function and before used to be handled by Xorg in some unified fashion.
- deleted 3y ago
  [deleted]
emersion 3y ago
seatd isn't just about multi-seat. In fact, seatd doesn't even support multi-seat at the moment. See this post for more details: https://lists.sr.ht/~kennylevinsen/seatd-devel/%3C3561460.kQq0lBPeGt%40tycho%3E#%3CH0L3KQ.8EO3ABVY6CGC3@kl.wtf%3E https://lists.sr.ht/~kennylevinsen/seatd-devel/%3C3561460.kQ...
mananaysiempre 3y ago
> Maybe wlroots should have OpenBSD-specific parts to its backend abstraction that use OpenBSD's usual input handling primitives. My (shallow and likely out-of-date) impression was that wlroots the library baking in Linux things was a more serious problem for porting than Wayland the protocol actually mandating anything seriously Linux-specific (I understand how the choice to use Linux key codes might be annoying, but still, meh). Have they gotten around to excising the event loop library out of there, for example?

Ericson2314 3y ago

We've been doing some BSD cross work with Nixpkgs. A hope is that if we can extend that to NixOS too, and then it should be quite easy to checkpoint and share work like this for anyone to reproduce and pick up the baton on.

1MachineElf 3y ago
Can you share any more information about the BSD cross work with Nixpkgs?
- Ericson2314 3y ago
  How to use it? Or what we've done? For using it, you can try nix-build 'channel:nixpkgs-unstable' -A pkgsCross.x86_64-netbsd.libcpuid nix-build 'channel:nixpkgs-unstable' -A pkgsCross.x86_64-freebsd.libcpuid For the gory details, check out https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/bsd/netbsd/default.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specifi... and https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specific/bsd/freebsd/default.nix https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specifi...

shrubble 3y ago

I as a user haven't seen any reason to care about Wayland. And losing/dropping X11's network transparency seems rather surprising in a heavily networked world...

dagenix 3y ago
In my experience, running X11 over a network worked very poorly. There is significant overlap between former X11 developers and Wayland developers. They didn't drop it because they are incompetent which seems to be what your are implying. The people that decided to drop it are probably the people that know X11 the best.
- pengaru 3y ago
  It didn't work poorly back when X clients were actually using Xlib for drawing primitives performed by the display server. It started working poorly when X clients started rendering everything locally in the client and simply pushing pixels to the display server.
  - bitwize 3y ago
    > It started working poorly when X clients started rendering everything locally in the client and simply pushing pixels to the display server. Which means it works poorly for modern apps. Modern apps use the GPU for client-side rendering. And it absolutely worked poorly even in the 90s. It was virtually impossible to run X apps over anything but a fast local LAN. That's what "Broadway"/LBX was about. It was kind of a failure. RDP has been a better networked display protocol than X for a couple decades now. Let's not fool ourselves that X isn't obsolete on every axis.
    - pengaru 3y ago
      > Let's not fool ourselves that X isn't obsolete on every axis. I'm not sure who you're replying to here, because it certainly isn't me.
- 3y ago

bitwize 3y ago

Now that Xorg development is moribund, people have been telling me "oh, there's always Xenocara". It seems even in BSD-land, people are thinking seriously about moving on from X. Netcraft sure as hell confirms it now: X11 is dying.

klardotsh 3y ago

I've been wanting to give OpenBSD an honest shot on the desktop for years, but going back to X has always been a deal breaker for me (HiDPI and mixed/scaled DPI support, and tear-less graphics, are hard requirements that X handles horribly - yes, before the X apologists brigade me, I know because I used to hack X into horribly supporting these things). This could finally let me dive into the only BSD that really catches my attention for potential to switch over - I applaud this effort!

amatecha 3y ago
OpenBSD is pretty sweet! been daily-driving as desktop OS (as in, not a server) for ~2 years now. Though, on a 1366x768 ThinkPad, so not too concerned about DPI hahah

w0ne 3y ago

Hopefully one day we will see Wayland achieve the reputation it deserves and let it replace Xorg!

AJRF 3y ago

I am an outside observer but in any discussion of Wayland I always see this article referenced: https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277 https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d... It seems like so much stuff is broken but the devs deny it is broken? And even with that situation - every major distro is making in roads to adopting it? Is that a fair characterisation or am I off the mark?

vetinari 3y ago
It not broken. The complains on the linked gist remind me complaining, how introducing protected memory broke applications. And you couldn't read or write i/o ports directly in our app anymore, you had to go through so-called kernel! So much bloat! So I put wayland is broken, because it doesn't allow what x11 did in the same way, ideally stomping on the others into the same category. For screenshots and capture, there's an API now (controlled, user is in the control, cannot be done behind his back. Scoped also, with granularity from window to desktop). For global shortcuts, there's an API in the making.
- rcxdude 3y ago
  > For global shortcuts, there's an API in the making. This is kind of the problem, though. X11's model of 'everything can access everything' is obviously bad, but when wayland went with a more restrictive model they didn't provide a means for legitimate functionality like this. That's basically the origin of all the objection: things that worked on X11 don't work on wayland, because wayland's developers seem to be very slow to recognise and provide for things which were extremely common on X11. It's been 14 years and the API for global shortcuts is still in the making! (And I know there's DE-specific interfaces for a lot of these things. But when you tell app developers this they're either going to implement it for their DE or not bother to implement it at all, as opposed to going through each DE and working it out, especially if it's more complex to support granular permissions and so on. So then users will see that app functionality breaks on wayland, and blame wayland, somewhat fairly)
  - vetinari 3y ago

mrweasel 3y ago

If OpenBSD manages to get Wayland working just the way they want it, with Pledge, Unveil, privileged separation and what have you, I would not be at all surprised if they also came up with their own compositor / window manager thing and a plan for removing X11 in future releases a few years later.