Hi Anshul, On Sun, Jan 04, 2015 at 12:25:55AM -0800, Anshul Garg wrote: > From: Anshul Garg <[email protected]> > > If input device is grabbed then client which has grabbed the device can > flush or write to the device so for other clients -EINVAL should be returned. > > Signed-off-by: Anshul Garg <[email protected]> > --- > drivers/input/evdev.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c > index b1a52ab..105e489 100644 > --- a/drivers/input/evdev.c > +++ b/drivers/input/evdev.c > @@ -277,6 +277,8 @@ static int evdev_flush(struct file *file, fl_owner_t id) > > if (!evdev->exist || client->revoked) > retval = -ENODEV; > + else if (evdev->grab && evdev->grab != client) > + retval = -EINVAL; > else > retval = input_flush_device(&evdev->handle, file); > > @@ -475,6 +477,11 @@ static ssize_t evdev_write(struct file *file, const char > __user *buffer, > goto out; > } > > + > + if (evdev->grab && evdev->grab != client) { > + retval = -EINVAL; > + goto out; > + }
Grab is supposed to be transparent to the other users, so returning error here is not desirable. Also, input_inject_event() will already ignore events if device is grabbed, so everything is good as far as evdev_write() concerned. Flush is a bit trickier: the driver should only "flush" data that belongs to the user that issued flush request (and the owner is identified by file handle passed to flush() method). I think it is OK to allow owner to flush its own data even while device is grabbed. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
