<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2013/1/29 Lennart Poettering <span dir="ltr"><<a href="mailto:lennart@poettering.net" target="_blank">lennart@poettering.net</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, 29.01.13 13:28, Stef Bon (<a href="mailto:stefbon@gmail.com">stefbon@gmail.com</a>) wrote:<br>> to use an external textfile or db in combination with a specfic script for<br>
> this purpose??<br>
<br>
</div>It sounds as if you are asking for the for the udev hardware database<br>
stuff we recently added which allows looking up static data by USB/PCI<br>
vendor/product IDs (actually, the lookup is done via kernel modalias<br>
strings, and hence also supports all kinds of other bus ids) in an<br>
indexed database, rather then via rules. Currently, this is already used<br>
for looking up vendor/product strings, but sooner or later the plan is<br>
to move the keymap matching logic into it as well.<br>
<br>
<a href="https://fedoraproject.org/wiki/Features/SystemdHardwareDatabase" target="_blank">https://fedoraproject.org/wiki/Features/SystemdHardwareDatabase</a><br>
<br>
And yes, the vid/pid checking to detect the Plugable device should move<br>
into this database, too.<br></blockquote><div><br></div><div style>Aha. Sounds very good te me. </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> Futher the test_autoseat can check the policy, which can override the<br>
> "default" behaviour for this device. This policy is settable by admins.<br>
<br>
</div>We already have a way to persistenly change the seat assignment of a<br>
device, we don't need multiple ways to say that a specific port<br>
replicator/multi seat device locally should be treated as something<br>
different than the default.<br>
<br>
ID_AUTOSEAT only has an effect if there is no explicit seat assignment<br>
of the hardware set anyway. ID_AUTOSEAT is hence strictly about<br>
defaults, and is overriden by any user configuration made with "loginctl<br>
attach-device".<br></blockquote><div><br></div><div style>I think I misunderstood the assigning of a device to a seat.</div><div style>The creation of a seat is not done by the udev rules, what I assumed first, but only some properties (tags) are set, like ID_AUTOSEAT, SEAT and ID_FOR_SEAT.</div>
<div style>It's up to the programs who controle the sessions to create a real seat. This is right?</div><div style><br></div><div style>What program is doing this now? Indeed gdm?</div><div style><br></div><div style>
Stef</div></div></div></div>