Re: [PATCH v4 7/7] Input: Add "inhibited" property

[Andrzej Pietrasiewicz]

Hi Dmitry,

W dniu 05.10.2020 o 20:10, Dmitry Torokhov pisze:
> Hi Andrzej,
>
> On Mon, Jun 08, 2020 at 01:22:11PM +0200, Andrzej Pietrasiewicz wrote:
> > @@ -284,8 +284,11 @@ static int input_get_disposition(struct input_dev *dev,
> >   	case EV_KEY:
> >   		if (is_event_supported(code, dev->keybit, KEY_MAX)) {
> >   
> > -			/* auto-repeat bypasses state updates */
> > -			if (value == 2) {
> > +			/*
> > +			 * auto-repeat bypasses state updates but repeat
> > +			 * events are ignored if the key is not pressed
> > +			 */
> > +			if (value == 2 && test_bit(code, dev->key)) {
> >   				disposition = INPUT_PASS_TO_HANDLERS;
> >   				break;
> >   			}
>
> Is this chunk really part of inhibit support? I'd think we cancel
> autorepeat timer when we are releasing a key, no?

When I look at it now it seems to me the chunk might be redundant.
But let me explain what I had in mind when adding it.

It is a matter of what we do with input events generated while a
device is inhibited. If ->open()/->close() are not provided by the
driver then inhibiting amounts to merely ignoring input events from
a device while it remains active. What else can you do if the driver
does not provide a method to prepare the device for generating events/
to stop generating events?

In this special case a user might trigger a repeated event while the
device is inhibited, then the user keeps holding the key down and the
device is uninhibited. Do we pass anything to handlers then?

In my opinion we should not. Such an event is "illegal" in a sense that it
was generated at a time when nobody wanted any events from the device.
Hence the test to let only those auto-repeat events through for which
a key is actually pressed.

However, what I see now is that if a device is inhibited, no key
will ever reach neither the "1" nor "2" state because of the "if"
in the very beginning of input_handle_event().

Regards,

Andrzej