On Fri, Jun 17, 2016 at 08:37:38AM -0300, Mauro Carvalho Chehab wrote:
> Em Fri, 17 Jun 2016 13:09:10 +0200
> Hans Verkuil <hverkuil@xxxxxxxxx> escreveu:
>
> > On 06/17/2016 11:50 AM, Mauro Carvalho Chehab wrote:
> > One area where I am uncertain is when remote control messages are received and
> > passed on by the framework to the RC input device.
> >
> > Suppose the application is the one receiving a password, then that password appears
> > both in the input device and the cec device. What I think will be useful is if the
> > application can prevent the use of an input device to pass on remote control messages.
> >
> > CEC_ADAP_S_LOG_ADDRS has a flags field that I intended for just that purpose.
> >
> > Note that RC messages are always passed on to CEC followers even if there is an
> > input device since some RC messages have additional arguments that the rc subsystem
> > can't handle. Also I think that it is often easier to handle all messages from the
> > same CEC device instead of having to read from two devices (cec and input). I
> > actually considered removing the input support, but it turned out to be useful in
> > existing video streaming apps since they don't need to add special cec support to
> > handle remote control presses.
> >
> > Question: is there a way for applications to get exclusive access to an input device?
> > Or can anyone always read from it?
>
> That's a very good question. I did a quick test to check how this is
> currently protected, by running:
>
> $ strace ir-keytable -t
> ...
> open("/dev/input/event12", O_RDONLY) = -1 EACCES (Permission denied)
> ...
>
> It turns that the input device was created by udev with those
> permissions:
>
> crw-rw---- 1 root input 13, 76 Jun 17 08:26 /dev/input/event12
>
> Changing access to 666 allowed to run ir-keytable -t without the
> need of being root.
>
> Yet, maybe there's a way to get exclusive access to input/event
> device, but I never needed to go that deep at the input subsystem.
> Maybe Dmitry could shed some light on that. Adding him in the loop.
EVIOCGRAB ioctl will do what you want.
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
