Re: [multiseat] How to make automatic ACL creation via udev "uaccess" tag work for seats other than seat0?

[Christian Pernegger <pernegger@xxxxxxxxx>]

Am Fr., 1. Sept. 2023 um 11:48 Uhr schrieb Lennart Poettering
<lennart@xxxxxxxxxxxxxx>:
> > It makes no sense for /dev/rfkill to belong to a specific seat,
> > though.
>
> Typically any RF kill buttons are attached to the main seat of a
> laptop only, hence this assignment.

If there's some form of physical RF kill button (dedicated, hard-wired
keyboard shortcut, whatever), it makes perfect sense to assign that
*button* to a specific seat.
But /dev/rfkill, the rfkill *mechanism*, doesn't depend on the
presence or absence of an RF kill button, does it? Just the presence
of wireless hardware. You always have soft rfkill, don't you? (This
particular box is a desktop without any physical RF kill buttons.)

Of course, if you want to take the position that it's a bit weird for
GNOME to use /dev/rfkill to detect the presence of BT devices, I can't
argue against that. :)

(From a use case perspective, it would be nice if paired BT devices
could somehow be tagged. I.e. so that each seat can pair devices and
manage them, but not see or manage ones paired by other seats and/or
users.)

> You cannot attach devices to multiple seats.

Roger that. Is there a way to exempt devices from the multiseat
mechanism, though? Mark them not seat-specific? Or is that hard-coded?

> You should be able to assign the device to a different seat though.

systemctl attach won't let me, at least not using the path seat-status
spits out. But I'm sure the version of systemd in Ubuntu 22.04 is
ancient, and/or they may have done something to it. If you like, I can
try whether adding a udev rule manually works, but personally I'm not
too bothered about this particular issue.

> /dev/kvm is 0666 by default, except of some distros [...]

Oh. I see. Sorry about that, then.

> fb is obsolete.

Alright. I only played around with it in the hopes that it would help
me get some VTs (and VT switching) on seat1. So far, no luck on that
front.

> that's how things work and people assume them to work: graphics render
> services are used to bring stuff to screen.

I don't know about this. Yes, seat1 could hog the GPU that seat0's
outputs are attached to, or vice versa, but seat1 could just as well
hog all the RAM or saturate the CPU. My point being, seats share the
host's CPU power, RAM, ..., already, why not the rendering/compute
power as well. IMVHO it's really just inputs and outputs that should
be seat-specific. Restricting the shared resources available to a
given seat, allocating them fairly, etc., is a different problem (and
arguably one that I'd tackle per user and not per seat).

Anyway, thanks for getting back to me. Have a nice weekend!

Christian Pernegger