Re: backport of uinput.c to 2.4, fixes for 2.5

[Vojtech P. <vo...@su...>]

On Thu, Oct 10, 2002 at 05:52:27PM -0700, Zach Welch wrote:

> 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.

Fixes for 2.5 applied. I'll probably not be pushing the backport until
the 2.5 input is stable, at which point I'll backport it to 2.4 as a
whole (except, of course, keeping 2.4 keyboard and mice as they are).

> 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.

This is planned, you send an event (EV_SYN, SYN_CONFIG) when you changed
the values. 

> 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?

Create it.

-- 
Vojtech Pavlik
SuSE Labs