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 <[email protected]> wrote: > On Tue, 19.03.13 17:51, Matthew Cox ([email protected]) 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. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
