[systemd-devel] Automatic multi-seat HP T100 zero client

[Matthew Cox]

Gotcha. I had saw that file before and tried copying and adding a
similar section as the MIMO detection already, but apparently I did
something wrong. I am now able to get it to create a new seat by using
just the PID/VID of the USB hub by adding into 71-seat.rules:
# HP T100
SUBSYSTEM=="usb", ATTR{idVendor}=="0424" , ATTR{idProduct}=="2514",
ENV{ID_AUTOSEAT}="1"

I totally understand not wanting to add a generic USB hub into the
defaults, but for my purposes this should work well. So thank you for
your help! :)

Back to my second question: I am still not getting a spawned login
manager on the hub, and I'm guessing it's because my X11 version (
xorg-x11-server 7.6_1.13.2-1.2.1 , from OpenSUSE 12.3 64-bit repos )
isn't new enough to listen to the Udev requests. Can anyone confirm
what version those changes occurred? This system does not seem to have
the multiseat-X-wrapper to force it (systemd version 195-13.11.1).

On Wed, Mar 20, 2013 at 10:15 AM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Tue, 19.03.13 17:51, Matthew Cox (m.cox99 at gmail.com) wrote:
>
>> I'm trying to get HP T100s to work for a multiseat configuration. I
>> was unable to find the hardware IDs in the database files and believe
>> that may fix the issue. Currently maintained are the Plugable usb
>> hwid's. One includes the DL-125 chipset, which is the same chipset the
>> HP T100 uses. HP T100's DisplayLink HWID (based on the samples I have)
>> are 17e9:030b attached to USB root hub of "Standard Microsystems Corp.
>> USB 2.0 Hub" with HWID 0424:2514. Can these be added in the same
>> manner as the Plugabe 125 to allow for automatic multiseat?
>
> Well, the plugable devices actually are properly recognizable by the hub
> already, i.e. Plugable set VID/PID values that it owns, and distuingish
> it from any normal hub. Your hub 0424:2514 however looks like a generic
> hub chipset that could be built into any normal hub too. If we'd
> consider all those hubs automatic seats then things would be weird for
> people who happen to have this chipset in a normal hub.
>
> Now, not all is lost. First, there might be other ways to detect the
> hub, "udevadm info --attribute-walk" might indicate some other field (for
> example ATTR{product}= or so) which indicates that this is a HP
> device.
>
> If that's not available, it gets trickier. In many cases, we can do what
> we do for the Mimo 720: on the Mimo the hub itself is not recognizable
> as mimo device, but the graphics device connected to it contains a
> product string that identifies it as Mimo device. Now, normally we
> cannot access the subdevice's info during hotplug from the hub's rules,
> since the subdevice will show up later only. So, what we do here is
> retrigger the hub as soon as we recognized the subdevice. In this second
> run we can then easily detect from the hub that it's actually a mimo.
>
> Sounds nasty? It is, but it is quite reliable.
>
> The rules for this are in 71-seat.rules. Please have a look, and check
> if you can make sense of it and adapt it to your device.
>
> Lennart
>
> --
> Lennart Poettering - Red Hat, Inc.