Re: [ibm-acpi-devel] [PATCH v4 7/7] Input: Add "inhibited" property
On Tue, Oct 06, 2020 at 06:12:49PM -0700, Dmitry Torokhov wrote:
> On Tue, Oct 06, 2020 at 06:11:02PM -0700, Dmitry Torokhov wrote:
> > 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.
>
> And by that I mean that I will drop it myself, no need to resend. I will
> be applying this shortly.
Well, "shortly" was just a tad optimistic, but I did apply it ;)
Thanks.
--
Dmitry
___
ibm-acpi-devel mailing list
ibm-acpi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] [PATCH v2] Input: document inhibiting
On Wed, Jun 17, 2020 at 12:18:22PM +0200, Andrzej Pietrasiewicz wrote: > Document inhibiting input devices and its relation to being > a wakeup source. > > Signed-off-by: Andrzej Pietrasiewicz Applied, thank you. -- Dmitry ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] [PATCH v4 1/7] Input: add input_device_enabled()
On Mon, Jun 08, 2020 at 01:22:05PM +0200, Andrzej Pietrasiewicz wrote: > A helper function for drivers to decide if the device is used or not. > A lockdep check is introduced as inspecting ->users should be done under > input device's mutex. > > Signed-off-by: Andrzej Pietrasiewicz Applied, thank you. -- Dmitry ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] [PATCH v4 2/7] Input: use input_device_enabled()
On Mon, Jun 08, 2020 at 01:22:06PM +0200, Andrzej Pietrasiewicz wrote: > Use the newly added helper in relevant input drivers. > > Signed-off-by: Andrzej Pietrasiewicz Applied, thank you. -- Dmitry ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
Re: [ibm-acpi-devel] [PATCH] platform/x86: thinkpad_acpi: remove trailing semicolon in macro definition
Hi, On 11/27/20 7:10 PM, t...@redhat.com wrote: > From: Tom Rix > > The macro use will already have a semicolon. > > Signed-off-by: Tom Rix Thank you for your patch, I've applied this patch to my review-hans branch: https://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86.git/log/?h=review-hans Note it will show up in my review-hans branch once I've pushed my local branch there, which might take a while. Once I've run some tests on this branch the patches there will be added to the platform-drivers-x86/for-next branch and eventually will be included in the pdx86 pull-request to Linus for the next merge-window. Regards, Hans > --- > drivers/platform/x86/thinkpad_acpi.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/platform/x86/thinkpad_acpi.c > b/drivers/platform/x86/thinkpad_acpi.c > index 36d9594bca7f..5bbb378d1a37 100644 > --- a/drivers/platform/x86/thinkpad_acpi.c > +++ b/drivers/platform/x86/thinkpad_acpi.c > @@ -1025,7 +1025,7 @@ static struct attribute_set *create_attr_set(unsigned > int max_members, > } > > #define destroy_attr_set(_set) \ > - kfree(_set); > + kfree(_set) > > /* not multi-threaded safe, use it in a single thread per set */ > static int add_to_attr_set(struct attribute_set *s, struct attribute *attr) > ___ ibm-acpi-devel mailing list ibm-acpi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
