On Tue, Oct 06, 2020 at 03:04:28PM +0200, Andrzej Pietrasiewicz wrote:
> 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().
OK, then let's drop it for now. We can revisit if we see that a problem.
Thanks.
--
Dmitry
_______________________________________________
ibm-acpi-devel mailing list
ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
