Moving `services.xserver.displayManager` to `services.displayManager`?

Development
1

Display managers are not necessarily tied to X11. Many of the supported display managers can be used with Wayland. However, the current options to enable/configure these are all behind services.xserver, and require services.xserver.enable = true; for any of the options to be used properly. This makes it quite difficult to run a pure-Wayland system without installing an entire X11 server along with a bunch of utilities.

Is there any reason we shouldn’t move these options outside of services.xserver? Does anyone know of anything that would break in doing so?

4 Likes
2

I think currently a lot of things still require XWayland, so you probably will have xorg in the closure anyway, I guess? But +1 on renaming the option and decoupling as far as possible!

1 Like
3

It might also help to package something like greetd (~kennylevinsen/greetd - A login manager daemon - sourcehut git), as a somewhat more technology agnostic approach to login management.

4

There actually seems to be quite a few non-graphical based login-managers:

None are dependent on X (or even Wayland). Maybe having a services.loginManager section would make more sense?

I think the biggest question is what exactly would need to be done to decouple these options while not losing any functionality that it gives.

1 Like
5

Since it seems you guys might touch this codebase, I want to link a problem and some of my initial research that I could not continue.

My personal problem is that my X disallows me from opening new windows after a rebuild switch (I use startx).