10 ms·

Write a Wayland Compositor [video]

114 points by pantalaimon 4y ago

guerrilla 4y ago
from scratch or with wlroots?
- bdhcuidbebe 4y ago
  [flagged]
- sprash 4y ago
  He recommends wlroots. (Which means it won't work with Nvidia GPUs btw.)
  - synergy20 4y ago
    was trying to run swaywm this morning to no avail as it refused to start when it detects nvidia driver is in use. why did not wlroots work with nvidia drivers? is it because nvidia drivers are closed that wlroots(i.e. swaywm) can not work with it? a bit disappointed.
    - loeg 4y ago
      Some discussion here: https://news.ycombinator.com/item?id=21628494 https://news.ycombinator.com/item?id=21628494
      - arghwhat 4y ago
        That discussion is outdated. Current Nvidia drivers support GBM, and thus should work with wlroots. Their status of unsupported mean that the wlroots maintainers cannot help if it does not work as they cannot debug a closed source driver, making it impossible to see what might be wrong. General improvements that help nvidia compatibility are accepted though if other's identify an issue.
    - singron 4y ago
      Every other driver uses GBM, which is well supported by all the various software related to gpu buffer management. Nvidia decided to not use GBM and instead use this EGLStreams thing, which meant it wasn't compatible. Politically, this was contentious since nvidia was offloading a huge development burden onto the ecosystem to create parallel implementations of buffer management specifically for nvidia. Wlroots ended up deciding this was such an inane thing for nvidia to do, that they refused to implement EGLStreams at all. Eventually, nvidia backpedaled and decided to implement GBM. Now they are just behind, but everything will probably eventually support nvidia.
    - vetinari 4y ago
      > why did not wlroots work with nvidia drivers? Because nvidia drivers traditionally didn't provide APIs that sway and other wayland compositors expected (drm, dmabuf, atomic) and tried to do it's own things (EGLStreams). For compositors it meant to have to code paths, one nvidia-specific and another one generic. Some compositors implemented both, others implemented generic only. For comparison, it would be like complaining that Windows/DirectX games do not run with a GPU that doesn't come with DirectX driver. Well, duh. However, Nvidia signaled a u-turn, that they are going to be more cooperative. How and when, well, it remains to be seen.
    - mnd999 4y ago
      It does work, you have to add —unsupported-gpu and there’s a bunch of other tweaks to make it good. There’s a long thread on the Nvidia UNIX driver forums on how to configure it. It is still unsupported though as wlroots only actively support open source video drivers.
  - deagle50 4y ago
    0.16 works with Nvidia proprietary driver. I'm using it right now.
    - synergy20 4y ago
      https://gitlab.freedesktop.org/wlroots/wlroots/-/releases https://gitlab.freedesktop.org/wlroots/wlroots/-/releases has the newest wlroots,google still leads to github wlroots which has an old 0.14 release
    - Jorengarenar 4y ago
      Wait, weren't Nvidia drivers finally open-sourced not so long ago?
      - delusional 4y ago
        They open-sourced a kernel intermediary driver that talks to a proprietary binary blob running in userspace. The driver itself is still proprietary.
        monocasa 4y ago
        And a massive multiple MB proprietary blob running on the GPU. It seems they ported most of their privileged driver to running on the GPU itself.
        hsbauauvhabzb 4y ago
        Has this made any real world impacts yet? Has it been implemented in mainline? Will this mean fedora can be used without leveraging contrib repos?
    - deagle50 4y ago
      Forgot to add, Xwayland is still busted, at least on my Arch setup (sway-git and wlroots-git from AUR).
  - ajarofpinecones 4y ago
    *she, also newer Nvidia drivers support GBM supposedly, so this (hopefully) won’t be true for much longer
    - pixelfarmer 4y ago
      IIRC, the blob stuff should be able to handle buffers it created itself no problem. The issue here are foreign buffers that are not supported, yet. Supposedly version 525.x will do that, so lets see how that goes.
    - arghwhat 4y ago
      nvidia drivers generally work but will remain unsupported for as long as they are not fully open source. Providing support requires the ability to debug the driver when issues arise. (Improvements to Nvidia support is accepted, if it is a general improvement and not just a hack around a driver bug.)
      - pwdisswordfish9 4y ago
        > if it is a general improvement and not just a hack around a driver bug And that's why linux on nvidia is doomed.
        arghwhat 4y ago
        That policy does not doom anything. wlroots does not accept driver bug hacks for any driver, and is merely consistent in that regard. It works for others, so it can work for Nvidia. Things will just always move slow as long as Nvidia are the only ones that can fix bugs. Maybe it will be better one day: They are (also slowly) moving in the right direction though, and nouveau might be revived by taking some bits from their new (barebone) kernel driver. But until then, swear your allegiance to the GPU vendors that play nice.
wing-_-nuts 4y ago
I really wanted to like wayland as the 'next big thing', but for the life of me I can't. * I've yet to see any actual, honest to god benefits for the end user. Literally everything I've seen is the fact that it makes development easier for the wayland devs and harder for literally everyone else. * Trying to use a wayland window manager outside of gnome or kde leaves you reliant on a bunch of hackish utilities (redshift, taskbar, screen recording / sharing, etc) which are available on AUR and basically no where else * Scaling and perf for xwayland apps (i.e. most apps) is pretty bad. Is wayland the future? Maybe, but I'll happily use xorg for the next decade if needed until the user experience is rock solid over on wayland.
- guerrilla 4y ago
  > * I've yet to see any actual, honest to god benefits for the end user. Literally everything I've seen is the fact that it makes development easier for the wayland devs and harder for literally everyone else. You can see some small benefits in GNOME like movies still playing while window switching, nice shadows, no more tearing, etc. but honestly who cares but aesthetes. None of this was in popular demand. The security is nice but when was that ever exploited in the wild? Mostly I see downsides, like now there's multiple ways (or no way in some compositors) to dim screens... I'm sure eventually we'll get all our features back but for now it's mostly a bunch of small irritations that add up.
  - amelius 4y ago
    > but honestly who cares but aesthetes Someone building the next Apple might care.
    - guerrilla 4y ago
      So, aesthetes making up virtually zero percent of Linux desktop users while handicapping the rest for years.
  - adrian_b 4y ago
    Under X11, I do not remember to have ever seen any disturbance in movie playing during window switching, but I have also never used GNOME. If Wayland improves movie playing under GNOME, then it solves a GNOME bug, not an X11 bug.
pwdisswordfish9 4y ago
[flagged]
- deleted 4y ago
  [deleted]
selfhifive 4y ago
Does screen sharing work on wayland now?
- vetinari 4y ago
  It does for a long time. However, applications that just grabbed X11 framebuffer won't work. They have to use respective APIs with user control ("portals") for that. Some do (Chrome, Firefox), some don't (MS Teams).
  - Arnavion 4y ago
    If you're forced to use an application that only supports the X API, you can kludge it to work by VNCing to yourself with x11vnc and then screencasting the x11vnc window.
- sheerun 4y ago
  The best app for this task doesn't support it: https://github.com/rustdesk/rustdesk/issues/56 https://github.com/rustdesk/rustdesk/issues/56
- horsawlarway 4y ago
  Yes, and has basically since early covid... So does RDP and VNC, if you're interested... Across most every variant (wlroots based - ex: sway, gnome - mutter, kde - plasma wayland)
  - selfhifive 4y ago
    A friend of mine couldn't share his screen on meet or teams and I had to change it from Wayland to X11 to make it work. His was a Ubuntu 22.04 distro (GNOME) 4 month old install. Wonder why that happened.
- vladharbuz 4y ago
  It seems to work for a lot of people, but I still get constant crashes using xdg-desktop-portal-wlr, despite trying multiple GPUs, extensive testing etc. I will probably dive into the code when I get some time.
fhackenberger 4y ago
Bit off-topic: My major pain point a while ago was that Gnome-shell crashes take down all running applications. Is that still the case?
- deleted 4y ago
  [deleted]
- sprash 4y ago
  Yes. Similarly a crash of Xorg will bring down all running applications. However thanks to standardized interfaces in X11 both the window manager and the compositor can independently crash or even replaced at runtime by a different program without affecting running programs. This just shows how much further ahead X11 is on a conceptual level and how bad the Wayland design philosophy really is.
  - turkeybased 4y ago
    > This just shows how much further ahead X11 is on a conceptual level and how bad the Wayland design philosophy really is. I agree that the isolated failure mechanism in this case is a strength of X11, but it's too far to extrapolate that to the designs as a whole.
  - amiga-workbench 4y ago
    Yup, under an X11 session when Gnome goes completely mad you can hit ALT+F2, R, Enter and restart it without losing all of your state.
yxhuvud 4y ago
I'd rather not. More people should write wayland clients though, and complain to the makers of existing compositors where they fall short. Which is in a lot of places, and they are definitely not sufficiently robust.
- deleted 4y ago
  [deleted]
- sprash 4y ago
  The presenter says that you should not write native Wayland clients at all but use either Gtk or Qt.
  - yxhuvud 4y ago
    That make no sense. Those are big and doesn't fit all purposes. It would also be a shame as the underlying protocol is just fine and reasonable easy to integrate with, even if it is poorly documented in many places. Which is not really something that can be said about the big toolkits which tend to dictate how execution happen. But that attitude certainly seems common among the people that build compositors. Having more alternative implementations would be very healthy for the environment.
    - sprash 4y ago
      > That make no sense. Those are big and doesn't fit all purposes. It makes sense because Wayland was invented for the purpose of forcing hobbyists and power users into ecosystems that are 100% corporate controlled.
LAC-Tech 4y ago
Is it worth switching to Wayland? Can't tell if we're at the point where the momentum has shifted or not.
- turkeybased 4y ago
  On a whole, the momentum has shifted: developers have shifted to Wayland. I've switched to Wayland. On GNOME I haven't noticed any benefits, nor any costs. It has been a no-op.
- deleted 4y ago
  [deleted]
  - deleted 4y ago
    [deleted]
- amalgamated_inc 4y ago
  I honestly only notice the difference once in a while, when an obscure app isn't compatible. And screen sharing is still kinda hit or miss.
- yjftsjthsd-h 4y ago
  If X works, why bother? If you're missing something it's not hard to test, but if there's nothing driving you to it then why bother at this point? It'll keep getting better over time
sylware 4y ago
Waiting for the steam client to have wayland->x11 fallback runtime tables of functions. xwayland is there for software which has no more technical maintenance (not the steam client, yet). But I plan to write my own wayland compositor, probably based on linux dma-buf, like the one running on the steam deck (basically an improved fork of valve one). And in assembly, x86_64 at first, but I am lurking on risc-v.
esjeon 4y ago
Not really a relevant thing to talk about here, but I find there's this trend in Linux ecosystem that people are explicitly implementing more and more policies on the code level instead of making flexible abstractions and data-fying user decisions. I'm not talking about exposing user-friendly configuration options, but is about mechanism-over-policy. The presenter mentioned "use-case over mechanism/policy", but, given a good mechanism, use-cases are just policies. Although I do understand the value of the current approach in the industry (i.e. MVP), I think it does come with a cost - you get a large corpus of low density code that gives a lot of surprises in many different corners. Redhat-funded projects are really leading this trend (I'm looking at you systemd, the project). If you read their code, you'll instantly notice that they are becoming more and more labor-intensive, and less and less hacker-friendly. We are losing smartness for the sake of grunting. Some might think Wayland is a smart approach, but it's actually not. It's mostly just pure grunting - a showcase of large engineering horsepower. It's a large-scale refactoring & optimization of the modern day X11 desktop ecosystem. Everything works in the exact same way, but things happen in slightly different places, and some features are banned by policy (arbitrarily outlined by wayland devs). These missing special features now need to be implemented explicitly as "protocols". Now, I really want to ask - where are we heading here? Are we really stepping forward? I don't think so. We're just going side ways.
pengaru 4y ago
This talk hurts to watch. All the block diagrams prominently putting systemd-logind between X11/Wayland-compositor are very misleading, and seems likely to create more misinformed ire for systemd. systemd-logind is basically just an arbiter of the seats for reasons like you can only have one drm-master on a given drm device at a time. It's not involved in all X11/Wayland-compositor<->kernel interactions. Once the seat has been acquired it gets out of the way. That should not be some huge box right in the middle of the two. You can trivially confirm this by stracing systemd-logind on your system while interacting with your desktop. It's just sitting idle in epoll_wait().
- ihatepython 4y ago
  I don't really understand what is a 'seat'. This abstraction seems kind of arbitrary and unnecessary?
  - pengaru 4y ago
    It's to handle multiseat scenarios where a single linux box handles multiple "seats" as in numerous monitor+input sets facilitating multiple seated irl users. Imagine multiple kiosks in a train station/airport running off a single box in a corner. Or a library with a dozen monitors+keyboards hanging off a single box. Consumer PCs are so powerful these days it's quite practical to do such things, at least in terms of the hardware. *NIX has historically cared about such multi-user use cases, and Linux/Libre software specifically has proudly facilitated making more use of our hardware vs. being wasteful by forcing purchase of more machines through superficial software limitations. The entire era of shared web hosting that arguably made Linux a commercial success throughout the 90s and early 2000s was a product of hosting more customers per less expensive commodity PC.
bullen 4y ago
I'm still using TWM. Next I'll just install xserver. A menu is clutter.

114 points by pantalaimon 4y ago

guerrilla 4y ago

from scratch or with wlroots?

bdhcuidbebe 4y ago
[flagged]
sprash 4y ago
He recommends wlroots. (Which means it won't work with Nvidia GPUs btw.)
- synergy20 4y ago
  was trying to run swaywm this morning to no avail as it refused to start when it detects nvidia driver is in use. why did not wlroots work with nvidia drivers? is it because nvidia drivers are closed that wlroots(i.e. swaywm) can not work with it? a bit disappointed.
  - loeg 4y ago
    Some discussion here: https://news.ycombinator.com/item?id=21628494 https://news.ycombinator.com/item?id=21628494
    - arghwhat 4y ago
      That discussion is outdated. Current Nvidia drivers support GBM, and thus should work with wlroots. Their status of unsupported mean that the wlroots maintainers cannot help if it does not work as they cannot debug a closed source driver, making it impossible to see what might be wrong. General improvements that help nvidia compatibility are accepted though if other's identify an issue.
  - singron 4y ago
    Every other driver uses GBM, which is well supported by all the various software related to gpu buffer management. Nvidia decided to not use GBM and instead use this EGLStreams thing, which meant it wasn't compatible. Politically, this was contentious since nvidia was offloading a huge development burden onto the ecosystem to create parallel implementations of buffer management specifically for nvidia. Wlroots ended up deciding this was such an inane thing for nvidia to do, that they refused to implement EGLStreams at all. Eventually, nvidia backpedaled and decided to implement GBM. Now they are just behind, but everything will probably eventually support nvidia.
  - vetinari 4y ago
    > why did not wlroots work with nvidia drivers? Because nvidia drivers traditionally didn't provide APIs that sway and other wayland compositors expected (drm, dmabuf, atomic) and tried to do it's own things (EGLStreams). For compositors it meant to have to code paths, one nvidia-specific and another one generic. Some compositors implemented both, others implemented generic only. For comparison, it would be like complaining that Windows/DirectX games do not run with a GPU that doesn't come with DirectX driver. Well, duh. However, Nvidia signaled a u-turn, that they are going to be more cooperative. How and when, well, it remains to be seen.
  - mnd999 4y ago
    It does work, you have to add —unsupported-gpu and there’s a bunch of other tweaks to make it good. There’s a long thread on the Nvidia UNIX driver forums on how to configure it. It is still unsupported though as wlroots only actively support open source video drivers.
- deagle50 4y ago
  0.16 works with Nvidia proprietary driver. I'm using it right now.
  - synergy20 4y ago
    https://gitlab.freedesktop.org/wlroots/wlroots/-/releases https://gitlab.freedesktop.org/wlroots/wlroots/-/releases has the newest wlroots,google still leads to github wlroots which has an old 0.14 release
  - Jorengarenar 4y ago
    Wait, weren't Nvidia drivers finally open-sourced not so long ago?
    - delusional 4y ago
      They open-sourced a kernel intermediary driver that talks to a proprietary binary blob running in userspace. The driver itself is still proprietary.
      - monocasa 4y ago
        And a massive multiple MB proprietary blob running on the GPU. It seems they ported most of their privileged driver to running on the GPU itself.
      - hsbauauvhabzb 4y ago
        Has this made any real world impacts yet? Has it been implemented in mainline? Will this mean fedora can be used without leveraging contrib repos?
  - deagle50 4y ago
    Forgot to add, Xwayland is still busted, at least on my Arch setup (sway-git and wlroots-git from AUR).
- ajarofpinecones 4y ago
  *she, also newer Nvidia drivers support GBM supposedly, so this (hopefully) won’t be true for much longer
  - pixelfarmer 4y ago
    IIRC, the blob stuff should be able to handle buffers it created itself no problem. The issue here are foreign buffers that are not supported, yet. Supposedly version 525.x will do that, so lets see how that goes.
  - arghwhat 4y ago
    nvidia drivers generally work but will remain unsupported for as long as they are not fully open source. Providing support requires the ability to debug the driver when issues arise. (Improvements to Nvidia support is accepted, if it is a general improvement and not just a hack around a driver bug.)
    - pwdisswordfish9 4y ago
      > if it is a general improvement and not just a hack around a driver bug And that's why linux on nvidia is doomed.
      - arghwhat 4y ago
        That policy does not doom anything. wlroots does not accept driver bug hacks for any driver, and is merely consistent in that regard. It works for others, so it can work for Nvidia. Things will just always move slow as long as Nvidia are the only ones that can fix bugs. Maybe it will be better one day: They are (also slowly) moving in the right direction though, and nouveau might be revived by taking some bits from their new (barebone) kernel driver. But until then, swear your allegiance to the GPU vendors that play nice.

wing-_-nuts 4y ago

I really wanted to like wayland as the 'next big thing', but for the life of me I can't. * I've yet to see any actual, honest to god benefits for the end user. Literally everything I've seen is the fact that it makes development easier for the wayland devs and harder for literally everyone else. * Trying to use a wayland window manager outside of gnome or kde leaves you reliant on a bunch of hackish utilities (redshift, taskbar, screen recording / sharing, etc) which are available on AUR and basically no where else * Scaling and perf for xwayland apps (i.e. most apps) is pretty bad. Is wayland the future? Maybe, but I'll happily use xorg for the next decade if needed until the user experience is rock solid over on wayland.

guerrilla 4y ago
> * I've yet to see any actual, honest to god benefits for the end user. Literally everything I've seen is the fact that it makes development easier for the wayland devs and harder for literally everyone else. You can see some small benefits in GNOME like movies still playing while window switching, nice shadows, no more tearing, etc. but honestly who cares but aesthetes. None of this was in popular demand. The security is nice but when was that ever exploited in the wild? Mostly I see downsides, like now there's multiple ways (or no way in some compositors) to dim screens... I'm sure eventually we'll get all our features back but for now it's mostly a bunch of small irritations that add up.
- amelius 4y ago
  > but honestly who cares but aesthetes Someone building the next Apple might care.
  - guerrilla 4y ago
    So, aesthetes making up virtually zero percent of Linux desktop users while handicapping the rest for years.
- adrian_b 4y ago
  Under X11, I do not remember to have ever seen any disturbance in movie playing during window switching, but I have also never used GNOME. If Wayland improves movie playing under GNOME, then it solves a GNOME bug, not an X11 bug.

pwdisswordfish9 4y ago

[flagged]

deleted 4y ago
[deleted]

selfhifive 4y ago

Does screen sharing work on wayland now?

vetinari 4y ago
It does for a long time. However, applications that just grabbed X11 framebuffer won't work. They have to use respective APIs with user control ("portals") for that. Some do (Chrome, Firefox), some don't (MS Teams).
- Arnavion 4y ago
  If you're forced to use an application that only supports the X API, you can kludge it to work by VNCing to yourself with x11vnc and then screencasting the x11vnc window.
sheerun 4y ago
The best app for this task doesn't support it: https://github.com/rustdesk/rustdesk/issues/56 https://github.com/rustdesk/rustdesk/issues/56
horsawlarway 4y ago
Yes, and has basically since early covid... So does RDP and VNC, if you're interested... Across most every variant (wlroots based - ex: sway, gnome - mutter, kde - plasma wayland)
- selfhifive 4y ago
  A friend of mine couldn't share his screen on meet or teams and I had to change it from Wayland to X11 to make it work. His was a Ubuntu 22.04 distro (GNOME) 4 month old install. Wonder why that happened.
vladharbuz 4y ago
It seems to work for a lot of people, but I still get constant crashes using xdg-desktop-portal-wlr, despite trying multiple GPUs, extensive testing etc. I will probably dive into the code when I get some time.

fhackenberger 4y ago

Bit off-topic: My major pain point a while ago was that Gnome-shell crashes take down all running applications. Is that still the case?

deleted 4y ago
[deleted]
sprash 4y ago
Yes. Similarly a crash of Xorg will bring down all running applications. However thanks to standardized interfaces in X11 both the window manager and the compositor can independently crash or even replaced at runtime by a different program without affecting running programs. This just shows how much further ahead X11 is on a conceptual level and how bad the Wayland design philosophy really is.
- turkeybased 4y ago
  > This just shows how much further ahead X11 is on a conceptual level and how bad the Wayland design philosophy really is. I agree that the isolated failure mechanism in this case is a strength of X11, but it's too far to extrapolate that to the designs as a whole.
- amiga-workbench 4y ago
  Yup, under an X11 session when Gnome goes completely mad you can hit ALT+F2, R, Enter and restart it without losing all of your state.

yxhuvud 4y ago

I'd rather not. More people should write wayland clients though, and complain to the makers of existing compositors where they fall short. Which is in a lot of places, and they are definitely not sufficiently robust.

deleted 4y ago
[deleted]
sprash 4y ago
The presenter says that you should not write native Wayland clients at all but use either Gtk or Qt.
- yxhuvud 4y ago
  That make no sense. Those are big and doesn't fit all purposes. It would also be a shame as the underlying protocol is just fine and reasonable easy to integrate with, even if it is poorly documented in many places. Which is not really something that can be said about the big toolkits which tend to dictate how execution happen. But that attitude certainly seems common among the people that build compositors. Having more alternative implementations would be very healthy for the environment.
  - sprash 4y ago
    > That make no sense. Those are big and doesn't fit all purposes. It makes sense because Wayland was invented for the purpose of forcing hobbyists and power users into ecosystems that are 100% corporate controlled.

LAC-Tech 4y ago

Is it worth switching to Wayland? Can't tell if we're at the point where the momentum has shifted or not.

turkeybased 4y ago
On a whole, the momentum has shifted: developers have shifted to Wayland. I've switched to Wayland. On GNOME I haven't noticed any benefits, nor any costs. It has been a no-op.
deleted 4y ago
[deleted]
- deleted 4y ago
  [deleted]
amalgamated_inc 4y ago
I honestly only notice the difference once in a while, when an obscure app isn't compatible. And screen sharing is still kinda hit or miss.
yjftsjthsd-h 4y ago
If X works, why bother? If you're missing something it's not hard to test, but if there's nothing driving you to it then why bother at this point? It'll keep getting better over time

sylware 4y ago

Waiting for the steam client to have wayland->x11 fallback runtime tables of functions. xwayland is there for software which has no more technical maintenance (not the steam client, yet). But I plan to write my own wayland compositor, probably based on linux dma-buf, like the one running on the steam deck (basically an improved fork of valve one). And in assembly, x86_64 at first, but I am lurking on risc-v.

esjeon 4y ago

Not really a relevant thing to talk about here, but I find there's this trend in Linux ecosystem that people are explicitly implementing more and more policies on the code level instead of making flexible abstractions and data-fying user decisions. I'm not talking about exposing user-friendly configuration options, but is about mechanism-over-policy. The presenter mentioned "use-case over mechanism/policy", but, given a good mechanism, use-cases are just policies. Although I do understand the value of the current approach in the industry (i.e. MVP), I think it does come with a cost - you get a large corpus of low density code that gives a lot of surprises in many different corners. Redhat-funded projects are really leading this trend (I'm looking at you systemd, the project). If you read their code, you'll instantly notice that they are becoming more and more labor-intensive, and less and less hacker-friendly. We are losing smartness for the sake of grunting. Some might think Wayland is a smart approach, but it's actually not. It's mostly just pure grunting - a showcase of large engineering horsepower. It's a large-scale refactoring & optimization of the modern day X11 desktop ecosystem. Everything works in the exact same way, but things happen in slightly different places, and some features are banned by policy (arbitrarily outlined by wayland devs). These missing special features now need to be implemented explicitly as "protocols". Now, I really want to ask - where are we heading here? Are we really stepping forward? I don't think so. We're just going side ways.

pengaru 4y ago

This talk hurts to watch. All the block diagrams prominently putting systemd-logind between X11/Wayland-compositor are very misleading, and seems likely to create more misinformed ire for systemd. systemd-logind is basically just an arbiter of the seats for reasons like you can only have one drm-master on a given drm device at a time. It's not involved in all X11/Wayland-compositor<->kernel interactions. Once the seat has been acquired it gets out of the way. That should not be some huge box right in the middle of the two. You can trivially confirm this by stracing systemd-logind on your system while interacting with your desktop. It's just sitting idle in epoll_wait().

ihatepython 4y ago
I don't really understand what is a 'seat'. This abstraction seems kind of arbitrary and unnecessary?
- pengaru 4y ago
  It's to handle multiseat scenarios where a single linux box handles multiple "seats" as in numerous monitor+input sets facilitating multiple seated irl users. Imagine multiple kiosks in a train station/airport running off a single box in a corner. Or a library with a dozen monitors+keyboards hanging off a single box. Consumer PCs are so powerful these days it's quite practical to do such things, at least in terms of the hardware. *NIX has historically cared about such multi-user use cases, and Linux/Libre software specifically has proudly facilitated making more use of our hardware vs. being wasteful by forcing purchase of more machines through superficial software limitations. The entire era of shared web hosting that arguably made Linux a commercial success throughout the 90s and early 2000s was a product of hosting more customers per less expensive commodity PC.

bullen 4y ago

I'm still using TWM. Next I'll just install xserver. A menu is clutter.