2023-02-27 18:59:28

by Werner Sembach

[permalink] [raw]
Subject: [PATCH v2 0/2] Fix "Input: i8042 - add TUXEDO devices to i8042 quirk tables for partial fix"

This is a continuation of
https://lore.kernel.org/linux-input/[email protected]/

That fix did fix the keyboard not responding at all sometimes after resume,
but at the price of it being laggy for some time after boot. Additionally
setting atkbd.reset removes that lag.

This patch comes in 2 parts: The first one adds a quirk to atkbd to set
atkbd.reset and the second one then applies that and the i8042 quirks to
the affected devices.




2023-02-27 18:59:30

by Werner Sembach

[permalink] [raw]
Subject: [PATCH v2 1/2] Input: atkbd - Make it possible to apply atkbd.reset via kernel quirk

atkbd.reset was only a command line parameter. Some devices might have a
known bug that can be worked around by just permanently applying this
quirk.

This patch adds the ability to do this on the kernel level for known buggy
devices.

Signed-off-by: Werner Sembach <[email protected]>
Cc: [email protected]
---
drivers/input/keyboard/atkbd.c | 6 ++++++
1 file changed, 6 insertions(+)

diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
index 246958795f60..ef65c46c4efe 100644
--- a/drivers/input/keyboard/atkbd.c
+++ b/drivers/input/keyboard/atkbd.c
@@ -1731,6 +1731,12 @@ static int __init atkbd_deactivate_fixup(const struct dmi_system_id *id)
return 1;
}

+static int __init atkbd_reset_fixup(const struct dmi_system_id *id)
+{
+ atkbd_reset = true;
+ return 1;
+}
+
/*
* NOTE: do not add any more "force release" quirks to this table. The
* task of adjusting list of keys that should be "released" automatically
--
2.34.1


2023-02-28 07:34:26

by Greg Kroah-Hartman

[permalink] [raw]
Subject: Re: [PATCH v2 1/2] Input: atkbd - Make it possible to apply atkbd.reset via kernel quirk

On Mon, Feb 27, 2023 at 07:59:06PM +0100, Werner Sembach wrote:
> atkbd.reset was only a command line parameter. Some devices might have a
> known bug that can be worked around by just permanently applying this
> quirk.
>
> This patch adds the ability to do this on the kernel level for known buggy
> devices.
>
> Signed-off-by: Werner Sembach <[email protected]>
> Cc: [email protected]
> ---
> drivers/input/keyboard/atkbd.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
> index 246958795f60..ef65c46c4efe 100644
> --- a/drivers/input/keyboard/atkbd.c
> +++ b/drivers/input/keyboard/atkbd.c
> @@ -1731,6 +1731,12 @@ static int __init atkbd_deactivate_fixup(const struct dmi_system_id *id)
> return 1;
> }
>
> +static int __init atkbd_reset_fixup(const struct dmi_system_id *id)
> +{
> + atkbd_reset = true;
> + return 1;

Why is this returning 1? Who calls this?

And this should be a per-device attribute, not a global one, right?

thanks,

greg k-h

2023-02-28 08:42:10

by Hans de Goede

[permalink] [raw]
Subject: Re: [PATCH v2 0/2] Fix "Input: i8042 - add TUXEDO devices to i8042 quirk tables for partial fix"

Hi Werner,

On 2/27/23 19:59, Werner Sembach wrote:
> This is a continuation of
> https://lore.kernel.org/linux-input/[email protected]/
>
> That fix did fix the keyboard not responding at all sometimes after resume,
> but at the price of it being laggy for some time after boot. Additionally
> setting atkbd.reset removes that lag.
>
> This patch comes in 2 parts: The first one adds a quirk to atkbd to set
> atkbd.reset and the second one then applies that and the i8042 quirks to
> the affected devices.

Can you please rework this series so that the quirk based setting of
the "atkbd.reset" equivalent on the kernel commandline becomes another
SERIO_QUIRK_* flag and avoid the duplication of the DMI ids?

Regards,

Hans




2023-02-28 10:59:06

by Werner Sembach

[permalink] [raw]
Subject: Re: [PATCH v2 1/2] Input: atkbd - Make it possible to apply atkbd.reset via kernel quirk


Am 28.02.23 um 08:34 schrieb Greg KH:
> On Mon, Feb 27, 2023 at 07:59:06PM +0100, Werner Sembach wrote:
>> atkbd.reset was only a command line parameter. Some devices might have a
>> known bug that can be worked around by just permanently applying this
>> quirk.
>>
>> This patch adds the ability to do this on the kernel level for known buggy
>> devices.
>>
>> Signed-off-by: Werner Sembach <[email protected]>
>> Cc: [email protected]
>> ---
>> drivers/input/keyboard/atkbd.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c
>> index 246958795f60..ef65c46c4efe 100644
>> --- a/drivers/input/keyboard/atkbd.c
>> +++ b/drivers/input/keyboard/atkbd.c
>> @@ -1731,6 +1731,12 @@ static int __init atkbd_deactivate_fixup(const struct dmi_system_id *id)
>> return 1;
>> }
>>
>> +static int __init atkbd_reset_fixup(const struct dmi_system_id *id)
>> +{
>> + atkbd_reset = true;
>> + return 1;
> Why is this returning 1? Who calls this?

This function is following the format of the other fixup functions directly
above it.

It is there to be called as a callback via the atkbd_dmi_quirk_table on a per
device basis. See 2nd patch of this patchset.

Greetings,

Werner

>
> And this should be a per-device attribute, not a global one, right?
>
> thanks,
>
> greg k-h

2023-02-28 11:07:13

by Werner Sembach

[permalink] [raw]
Subject: Re: [PATCH v2 0/2] Fix "Input: i8042 - add TUXEDO devices to i8042 quirk tables for partial fix"


Am 28.02.23 um 09:41 schrieb Hans de Goede:
> Hi Werner,
>
> On 2/27/23 19:59, Werner Sembach wrote:
>> This is a continuation of
>> https://lore.kernel.org/linux-input/[email protected]/
>>
>> That fix did fix the keyboard not responding at all sometimes after resume,
>> but at the price of it being laggy for some time after boot. Additionally
>> setting atkbd.reset removes that lag.
>>
>> This patch comes in 2 parts: The first one adds a quirk to atkbd to set
>> atkbd.reset and the second one then applies that and the i8042 quirks to
>> the affected devices.
> Can you please rework this series so that the quirk based setting of
> the "atkbd.reset" equivalent on the kernel commandline becomes another
> SERIO_QUIRK_* flag and avoid the duplication of the DMI ids?

I'm not sure how to cleanly do this, since atkbd is an own module?

Kind Regards,

Werner

>
> Regards,
>
> Hans
>
>
>

2023-03-01 16:57:57

by Werner Sembach

[permalink] [raw]
Subject: Re: [PATCH v2 0/2] Fix "Input: i8042 - add TUXEDO devices to i8042 quirk tables for partial fix"


Am 27.02.23 um 19:59 schrieb Werner Sembach:
> This is a continuation of
> https://lore.kernel.org/linux-input/[email protected]/
>
> That fix did fix the keyboard not responding at all sometimes after resume,
> but at the price of it being laggy for some time after boot. Additionally
> setting atkbd.reset removes that lag.
>
> This patch comes in 2 parts: The first one adds a quirk to atkbd to set
> atkbd.reset and the second one then applies that and the i8042 quirks to
> the affected devices.
>
>
Somehow, for my testing last week these patches seemed work, but now i still see
occasional laggy keyboard after boot. So sadly the atkbd_reset quirk didn't fix
the issue after all.

2023-03-01 17:53:35

by Hans de Goede

[permalink] [raw]
Subject: Re: [PATCH v2 0/2] Fix "Input: i8042 - add TUXEDO devices to i8042 quirk tables for partial fix"

Hi,

On 3/1/23 17:57, Werner Sembach wrote:
>
> Am 27.02.23 um 19:59 schrieb Werner Sembach:
>> This is a continuation of
>> https://lore.kernel.org/linux-input/[email protected]/
>>
>> That fix did fix the keyboard not responding at all sometimes after resume,
>> but at the price of it being laggy for some time after boot. Additionally
>> setting atkbd.reset removes that lag.
>>
>> This patch comes in 2 parts: The first one adds a quirk to atkbd to set
>> atkbd.reset and the second one then applies that and the i8042 quirks to
>> the affected devices.
>>
>>
> Somehow, for my testing last week these patches seemed work, but now i still see occasional laggy keyboard after boot. So sadly the atkbd_reset quirk didn't fix the issue after all.

Ok, well I guess that also resolves the discussion about trying to avoid
the duplicate DMI table entries.

FWIW I did not realize that the other quirk was in another module and
I don't have a good answer how to solve this in a way that avoids
adding the DMI matches twice.

Regards,

Hans