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
|
