~kennylevinsen

Denmark

https://kl.wtf/

This space intentionally left blank.

Trackers

~kennylevinsen/wlsunset

Last active 2 months ago

~kennylevinsen/greetd

Last active 2 months ago

~kennylevinsen/seatd

Last active 5 months ago

~kennylevinsen/gtkgreet

Last active 6 months ago

~kennylevinsen/poweralertd

Last active 1 year, 5 months ago

~kennylevinsen/wldash

Last active 1 year, 8 months ago

#27 greetd doesn't properly handle logind TTY variable 11 days ago

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.

#27 greetd doesn't properly handle logind TTY variable 11 days ago

on ~kennylevinsen/greetd

[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.

#27 greetd doesn't properly handle logind TTY variable 11 days ago

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.

#27 greetd doesn't properly handle logind TTY variable 11 days ago

on ~kennylevinsen/greetd

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.service should be updated to have Conflicts=systemd-logind,elogind (not tested, only checked systemd.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

#27 greetd doesn't properly handle logind TTY variable 11 days ago

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.service should be updated to have Conflicts=systemd-logind,elogind (not tested, only checked systemd.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.

#27 greetd doesn't properly handle logind TTY variable a month ago

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

#27 greetd doesn't properly handle logind TTY variable a month ago

Comment by ~kennylevinsen on ~kennylevinsen/greetd

The problem lies between the two points you've provided debug for. The expected flow is:

  1. Create logind session which by default ends up being of the TTY type.
  2. 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").
  3. 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 monitor on 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.

#3 Limit device access to seat-local devices a month ago

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.

#16 acl on audio and video devices a month ago

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

#9 Support for SXMO 2 months ago

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.log and 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.