Denmark
This space intentionally left blank.
Comment by ~kennylevinsen on ~kennylevinsen/greetd
On Tue, Sep 13 2022 at 12:12:20 PM +00:00:00, Haelwenn (lanodan) Monnier outgoing@sr.ht wrote:
As I said earlier, I'm the package maintainer for seatd for gentoo
Ah yeah, sorry about that, was mixing up who I was responding to.
That's not the case and I don't think it will be at any point, doesn't prevents users from being trigger-happy on enabling it though.
Not much we can do about users being blindly trigger-happy. We do have an FAQ/Wiki that could mention such things (https://man.sr.ht/~kennylevinsen/seatd/), but it only helps those that read it. Same goes for the seatd and elogind pages, which could refer to each other.
[2022-09-13 11:47:30+0000] ~kennylevinsen:
On Tue, Sep 13 2022 at 10:56:56 AM +00:00:00, Haelwenn (lanodan) Monnier outgoing@sr.ht wrote:
there isn't a setup documentation/guide other than the manpages and README.md from the seatd project.
If you are using (e)logind, the applicable documentation would be that from systemd or elogind. It's strictly speaking not seatd's job to document how to use other projects in its place.
[^1]: seatd enabled by default, while most users probably already have (e)logind enabled
Talk to your package managers. If your distribution is init-system agnostic, it might also want to offer seatd as alternative to elogind when not using systemd. libseat is often packaged separately from seatd, so that packages can depend on the library without needing to installing the daemon.
As I said earlier, I'm the package maintainer for seatd for gentoo, which is init-system agnostic. I effectively just missed that (e)logind was set as a system default for desktop users, so seatd being built by default didn't made sense.
And there isn't install-time package splits in gentoo, usually USE-flags are just used to disable/enable features instead.
If your distribution likes to enable services by default for convenience, then this might be a better option than breaking pattern for seatd.
That's not the case and I don't think it will be at any point, doesn't prevents users from being trigger-happy on enabling it though.
Comment by ~kennylevinsen on ~kennylevinsen/greetd
On Tue, Sep 13 2022 at 10:56:56 AM +00:00:00, Haelwenn (lanodan) Monnier outgoing@sr.ht wrote:
there isn't a setup documentation/guide other than the manpages and README.md from the seatd project.
If you are using (e)logind, the applicable documentation would be that from systemd or elogind. It's strictly speaking not seatd's job to document how to use other projects in its place.
[^1]: seatd enabled by default, while most users probably already have (e)logind enabled
Talk to your package managers. If your distribution is init-system agnostic, it might also want to offer seatd as alternative to elogind when not using systemd. libseat is often packaged separately from seatd, so that packages can depend on the library without needing to installing the daemon. If your distribution likes to enable services by default for convenience, then this might be a better option than breaking pattern for seatd.
Thanks for the clarifications, sent https://github.com/gentoo/gentoo/pull/27235 to address this problem.
[2022-09-13 09:14:30+0000] ~kennylevinsen:
On Wed, Aug 17 2022 at 03:01:06 PM +00:00:00, Haelwenn (lanodan) Monnier outgoing@sr.ht wrote:
Then, I guess
contrib/systemd/seatd.serviceshould be updated to haveConflicts=systemd-logind,elogind(not tested, only checkedsystemd.unit(5)).No, I wouldn't see that as the conclusion. One shouldn't start random services just because they're included in packages - even when they do need to run, starting them isn't always the right thing to do.
Whatever setup documentation/guide was followed might need to clarify that (e)logind should be started if one is using that. If one is installing a system entirely on their own, the manpages of (e)logind should be followed.
Well it was more like a case of a bad default[^1] and bad assumption from a user, there isn't a setup documentation/guide other than the manpages and README.md from the seatd project.
[^1]: seatd enabled by default, while most users probably already have (e)logind enabled
Comment by ~kennylevinsen on ~kennylevinsen/greetd
On Wed, Aug 17 2022 at 03:01:06 PM +00:00:00, Haelwenn (lanodan) Monnier outgoing@sr.ht wrote:
So, just to be sure, this is purely a runtime issue and there can be setups with systemd-logind / elogind being installed but not launched?
This particular issue? Yes. Having (e)logind, not starting it, starting seatd instead and expecting (e)logind behaviors.
Then, I guess
contrib/systemd/seatd.serviceshould be updated to haveConflicts=systemd-logind,elogind(not tested, only checkedsystemd.unit(5)).No, I wouldn't see that as the conclusion. One shouldn't start random services just because they're included in packages - even when they do need to run, starting them isn't always the right thing to do.
Whatever setup documentation/guide was followed might need to clarify that (e)logind should be started if one is using that. If one is installing a system entirely on their own, the manpages of (e)logind should be followed.
Which sadly doesn't seems to be an option in OpenRC[1], but I guess elogind could refuse to start when seatd is started and vice-versa.
seatd and (e)logind are used in tandem in certain setups. It is very common for both to be used during development of display servers on (e)logind based systems as seatd makes it trivial to start a compositor over SSH (one cannot easily debug a display server on the same machine one works on). (e)logind requires considerable fiddling to do the same.
Comment by ~kennylevinsen on ~kennylevinsen/greetd
End-users do not need to run both - seatd is for those who do not have or do not wish to use logind, with libseat supporting both.
They do sometimes co-exist, especially for developers as seatd is far easier to use than logind when working over SSH (common when writing/debugging display servers), in CI and similar. Regarding changes, note that being packaged and being enabled differs, so maybe all that is needed is a documentation update.
REPORTED RESOLVED CLOSED
Comment by ~kennylevinsen on ~kennylevinsen/greetd
The problem lies between the two points you've provided debug for. The expected flow is:
- Create logind session which by default ends up being of the TTY type.
- Your target application starts, which end up calling the SetType dbus endpoint to change the type appropriately. libseat will take care of this if XDG_SESSION_TYPE is set to something if the logind backend is used for seat management (i.e., not using seatd, seatd-launch or "builtin").
- Your compositor tries to call SetIdleHint.
You have debug on 1 and 3, but the issue must lie with 2. The question we need to answer is why does SetType either not work or not get called in the first place. One way is to use
sudo busctl monitoron a different TTY to look for the SetType call and return value.SetType was introduced in systemd v246, and should be in Debian Bullseye from what I can tell.
Comment by ~kennylevinsen on ~kennylevinsen/seatd
Multiple daemons could indeed be used to offer the seats, but the primary problem remains knowing what seat a device belongs to, so that other seats can be blocked from opening unrelated devices.
Comment by ~kennylevinsen on ~kennylevinsen/seatd
The explanation is correct. In logind this is handled by an entirely separate mechanism tied to udev and generally unrelated to seat management as the clients involved are not seat aware.
pam_uaccess is an implementation that handles this without a server, although with a few limitations listed in the readme. Someone could write a uaccessd or a udev hook script to fix some of those limitations if they are important.
REPORTED RESOLVED BY_DESIGN
Comment by ~kennylevinsen on ~kennylevinsen/wlsunset
This could be a hardware or driver limitation. You should check the sway debug log by starting sway with
sway -d 2>sway.logand see if it says anything. You can also check drm_info for the legacy "Gamma size" and modern "GAMMA_LUT_SIZE" property. At least one of them should have a decent size.