Messages in this thread | | | From | Dmitry Torokhov <> | Subject | Re: input.c: start on release | Date | Sat, 24 Feb 2007 11:57:07 -0500 |
| |
On Friday 23 February 2007 19:44, Pete Zaitcev wrote: > On Fri, 23 Feb 2007 10:06:14 -0500, "Dmitry Torokhov" <dmitry.torokhov@gmail.com> wrote: > > On 2/23/07, Pete Zaitcev <zaitcev@redhat.com> wrote: > > > > void input_release_device(struct input_handle *handle) > > > { > > > .... > > > if (handle->handler->start) > > > handle->handler->start(handle); > > > It should be ->start(). You are probably confused a little by the name > > of the function. input_release_device() is called when userspace > > issues ioctl(fd, EVIOCGRAB, 0) releasing (or ungrabbing) the device > > (as opposed to xxx_release(file, inode) type functions that are called > > when last user of a file drops off). In our case we want to give > > handlers a chance to resume their control over device. Right now > > standard keyboard driver uses start method do bring back in sync LED > > state of a keyborad-like device after it was released (ungrabbed). > > Thanks for the explanation. I suspect people asked you 100 times before. > I can see why we would want to do this when a grab ends, but why do > we do this on every close of /dev/input/mice? The call path is: > > mousedev_release -> > mixdev_release (optional for some majors) > input_close_device -> > input_release_device >
The actual work withing input_release_device happens only when called for handle that grabbed the device earlier. The reason why we call it when closing a device so that device is not left in grabbed state if userspace forgot to release it voluntarily.
> Same thing happens upon disconnect, though this is probably harmless, > as the device is gone already anyway. > > To tell you the truth, all I really want is to hold a static mutex > across a call to input_close_device(). Can I do that?
Are you trying to fix locking in mousedev?
-- Dmitry - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |