Kay, Greg we are also discussing this on the xorg list. Pieces seems
to be discussed on hotplug, usb-devel, xorg, hal, etc list. What would
be a good central place to discuss this topic?
"Background:
All this makes it possible to manage usb devices with udev instead of
the devfs solution. We are currently working on a pam_console/resmgr
replacement driven by udev and a pam-helper. It applies ACL's to device
nodes, which is required for modern desktop functionality like
"Fast User Switching" or multiple local login support."
On 7/30/05, Jesse Barnes <jbarnes at virtuousgeek.org> wrote:
> On Saturday, July 30, 2005 9:32 am, Daniel Stone wrote:
> > It's entirely possible -- the main stumbling points are thus:
> > * Working out (initially) which is which.
> > * Dealing with hotplugging.
> >
> > The former is relatively easy. Parse /proc/bus/input/devices (or
> > whatever it is) for a list of all the event devices you're interested
> > in, and poll them all until you get input.
> >
> > So, pop up a dialog box saying 'press some keys on the third
> > keyboard' now, and poll across all the keyboard devices you come up
> > with to see which one is the third keyboard. Ditto mice.
>
> I was imagining an even more manual system, where the administrator
> would follow the cables (i.e. hm this hub is plugged into port #2, I'll
> assign that to head #4, and everything plugged into that hub belongs to
> head #4).
The lowest cost solution I can see is a USB keyboard with two port
hub. They are common and cheap. Plug in a USB mouse and USB headset
and you're done. If you need to plug in a key unplug the headset. You
can get the three device for $30 total if you shop around.
A monitor with USB hub is better but more expensive. You can get four
ports and power. That's room for keyboard, mouse, headset, key. A
standalone hub is always an option too.
The keyboard/monitor USB hub combo is not going to physically move
around much. That will make it work with a scheme that tracks devices
plugged into a hub as belonging to the hub owner.
We also need a scheme for associating the display head device with the
usb hub. Then all of this needs to be assigned to the user at login.
Since there are multiple clients for this service we need to build it
in a way that can be shared.
> > The second is not so easy. Basically all you can do is keep track of
> > what disappeared and assume that will be the next thing to get
> > plugged in.
>
> Unless you use the topology like I describe above, then you just assume
> that things are physically setup correctly and somewhat securely (i.e.
> Dick can see his hub and will know if Jane tries to steal his USB key).
>
> > It's all entirely possible, it just requires a lot of fiddling around
> > and gap-filling, usually on behalf of the distributor. Oh, and
> > careful selection of video card.
>
> Definitely. Those damn video cards keep crashing the party...
>
> Jesse
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>
--
Jon Smirl
jonsmirl at gmaD
D
D
D/drivers////
D/s3mmio////
D/s3newmmio////
List-Received-Date: Sat, 30 Jul 2005 20:53:41 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jesse Barnes wrote:
> On Friday, July 29, 2005 11:00 pm, Dave Airlie wrote:
>
>>I've just started a wiki page at http://wiki.x.org/wiki/ModeSetting
>>
>>I'd like to get the API requirements list to be complete first, and
>>solve any open questions on the API, the initial implementation isn't
>>something we need to worry about yet... I'm all about APIs :-)
>
> Regarding hotplug of screens, should the modesetting library deal with
> that at all? Or should there be another agent that receives hotplug
> events and polls for new displays? At the very least, the modesetting
> library should have a small core that just takes a device, screen, and
> mode and does the actual mode set (after asking for memory from DRM and
> making sure the screen won't be damaged of course). Screen enumeration
> and tracking seem somewhat orthogonal to the actual mode setting.
I agree. If nothing else, keeping the two separate allows us to get
*soemthing* working while the other part is being designed. That also
means that we need to be sure the mode setting part is flexable enough
to deal with whatever API we end up with for screen enumeration.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFC6+jIX1gOwKyEAw8RAo5KAJ9+j6bbyldWKG8Q4S1eyjglpblJIQCfWlSf
9E61UXx1hpxPc39ypoQKSEk=uTnD
-----END PGP SIGNATURE-----