backport of uinput.c to 2.4, fixes for 2.5

[Zach W. <zw...@su...>]

Hi all,

Attached is a quick backport of the 2.5 user level input driver,
diffed against the latest linux-2.4 BK tree.  It's pretty much exactly
what I was dreaming about writing, so thanks to everyone that beat me to
the punch.  I've also attached a patch against the latest 2.5 BK tree 
that includes the fixes I've made.  For historical reference, the 
Makefile versions are 2.4.20-pre9 and 2.5.41.

I changed the semantics of the read function, as changed by Vojtech 
yesterday.  It seems to me that you don't want to block on read waiting 
for "an event to arrive AND the device to be created" (quote is 
paraphrasing of wait condition code).  That will never wake up in a 
single threaded program, as creation requires an ioctl to be sent - but 
you're blocking... e.g cat will require SIGINT....

Instead, I changed read to check that the device exists or return ENODEV 
at the very start, which then simplifies the existing async code and 
wait condition.  The wait condition was also changed to handle the event 
of the device being destroyed in another thread, so the reader will then 
correctly receive a ENODEV in that case as well. The second case might 
better be considered an EOF condition instead, as the device did exist 
when the call was started.  That should be a trivial change as well, but 
it is left as an exercise for the reader. :)

Why can't the device attributes be changed once the input device is
registered?  For example, we want to be able to dynamically adjust the
abs* fields. And yes, I know it's sick, but it seems like it will be
worse if our program frequently registers and unregisters its devices.
If we want to effect a change to a number of devices, there will be
quite a bit of thrashing around in the system.  I suppose the real
problem lies in notifying the consumers of the device that its
attributes have changed.  Oh well.  Something for us to thing about.

Also, is there a 'virtual' bus id that can be used?   With its own space
of assigned vendor/product keys?  We're currently using our USB device
id and what, but we will want to be able to create input devices with no
matching hardware.  Thoughts?

Cheers,

Zach Welch
Superlucidity Services