On Mon, Nov 11, 2002 at 03:12:49PM +1100, Brad Hards wrote: <snip> > > Hmm, obviously this makes my current identification method rather > > suboptimial. > Depends on the problem we need to solve. If the machine only has one of each > device, then it doesn't matter where it is plugged in, and we can use > EVIOCGNAME or EVIOCGID. > > If the machine is multi-headed, then perhaps the physical path will be better. > > > What about using the bus, vendor, product, and version tags? (Returned > > by EVIOCGID) > That isn't different to using the strings on USB, except for the odd case > where the string just says "mouse" or something silly. > > > The main catch is that I don't have a clue what those would be set to > > for ADB or PS2 mice for 2.5.x. > They will exist, but may not be unique (same as if you have two identical > mice). There is an ioctl() for a unique identifier (EVIOCGUNIQ), but on most > devices, it'll return NULL.
Hmm, this is really starting to tell me that we need the ability to specify any of these, not too hard, I think. > > > > However if you plug it into another port (or you plug another input > > > device into that port), you are basically screwed. It'd still be a nice > > > option to offer for configuration though. > > > > > > We still need proper hotplugging though. > > > > We /can't/ support proper hotplugging under linux because to my > > knowledge no interface exists that can tell us that a new device has > > been plugged in. > Ah, but there is. /sbin/hotplug will be invoked by the linux kernel > whenever a new device is attached or an existing device is detached. > All the interesting devices can do this. You get the device > information as environment variables. /sbin/hotplug is normally a > script, but it can be anything. Or the script can exec() some other > code. See http://linux-hotplug.sf.net Judging from the existing hotplug code, I think the thing to do would be to have X listen on a FIFO or socket, and just have the scripts dump that information to the FIFO/socket. The real trick is getting X to listen on it, and activate and deactivate drivers based on it. Sadly, that is a good bit beyond my knowledge of X internals, and documentation is, not exactly present as far as I can find. > > > This really sucks, but it is beyond the scope of this patch to try and > > make that happen, though it is clearly something that must happen. > I see your patch as a first step, and one that is very welcome. Next thing > would be to generalise the interface to work for a keyboard. Hmm, it is currently using the mouse framework for two reasons, the first is that it is what the other code I was basing it off of was for. The second is a bit more tricky, the mouse framework has things like the axis mapping, and button remapping, and while that could be reimplemented, I've never been a fan of code duplication. > > > (I have some thoughts on what might work, but they seem USB specific.) > Unfortunately /sbin/hotplug is Linux specific. I don't know if the > *BSD guys have something similar. OTOH, the BSD guys already have HID layer support for mice at least, so a little less of a problem. Not a lot I can do about that, not having a *BSD system. Zephaniah E. Hull. -- 1024D/E65A7801 Zephaniah E. Hull <[EMAIL PROTECTED]> 92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801 CCs of replies from mailing lists are requested. Emergency medicine: It's like sysadminning, but with better LARTs and more blood. -- Mike Sugimoto on ASR.
msg10723/pgp00000.pgp
Description: PGP signature
