[systemd-devel] Someone working on gui for multiseat?

[Lennart Poettering]

On Tue, 29.01.13 13:28, Stef Bon (stefbon at gmail.com) wrote:

> Defaults? No I don't think so. I think this is a discussion about
> flexibility and let users decide what to do with these devices.
> 
> Right now in the 71-seat.rules :
> 
> # 'Plugable' USB hub, sound, network, graphics adapter
> SUBSYSTEM=="usb", ATTR{idVendor}=="2230", ATTR{idProduct}=="000[13]",
> ENV{ID_AUTOSEAT}="1"
> 
> in my opinion it should be better:
> 
> SUBSYSTEM=="usb", PROGRAM="test_autoseat ATTR{idVendor} ATTR{idProduct}",
> RESULT="1", ENV{ID_AUTOSEAT}="1"
> 
> 
> where this test_autoseat script does check vendor and product id's, and
> tests the default set for this machine.
> 
> First this way the hardcoded setting of devices in the udev rules is a bit
> clumsy. It's not that flexible. By using a script a simple textlist of
> devices or small db is sufficient.  It's better updatable then a udev rule,
> which should not be changed just when a device is released.
> 
> But that does count for a lot of devices, not only these.
> When looking at for example at 95-keymap.rules, a lot of rules are made for
> a specific device, running keymap with specific parameters. Isn't it better
> to use an external textfile or db in combination with a specfic script for
> this purpose??

It sounds as if you are asking for the for the udev hardware database
stuff we recently added which allows looking up static data by USB/PCI
vendor/product IDs (actually, the lookup is done via kernel modalias
strings, and hence also supports all kinds of other bus ids) in an
indexed database, rather then via rules. Currently, this is already used
for looking up vendor/product strings, but sooner or later the plan is
to move the keymap matching logic into it as well.

https://fedoraproject.org/wiki/Features/SystemdHardwareDatabase

And yes, the vid/pid checking to detect the Plugable device should move
into this database, too.

> Futher the test_autoseat can check the policy, which can override the
> "default" behaviour for this device. This policy is settable by admins.

We already have a way to persistenly change the seat assignment of a
device, we don't need multiple ways to say that a specific port
replicator/multi seat device locally should be treated as something
different than the default.

ID_AUTOSEAT only has an effect if there is no explicit seat assignment
of the hardware set anyway. ID_AUTOSEAT is hence strictly about
defaults, and is overriden by any user configuration made with "loginctl
attach-device".

Lennart

-- 
Lennart Poettering - Red Hat, Inc.