[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID:
<CY5PR19MB614758F6060B4B07D06158D0BA552@CY5PR19MB6147.namprd19.prod.outlook.com>
Date: Thu, 31 Oct 2024 16:26:56 +0000
From: "Tudor, Laurentiu" <Laurentiu.Tudor1@...l.com>
To: Aleksandrs Vinarskis <alex.vinarskis@...il.com>,
Jiri Kosina
<jikos@...nel.org>, Hans de Goede <hdegoede@...hat.com>,
"linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
CC: Benjamin Tissoires <bentiss@...nel.org>,
"Kemp, Bryan"
<Bryan.Kemp@...l.com>
Subject: RE: [PATCH v2 0/2] HID: i2c-hid: re-power-on quirk for QTEC kbrd
Internal Use - Confidential
> -----Original Message-----
> From: Aleksandrs Vinarskis <alex.vinarskis@...il.com>
> Sent: Thursday, October 31, 2024 9:32 AM
>
> Resolve keyboard not working out of the box for Dell XPS 9345 13"
> codenamed 'tributo'. X1E80100-based laptop's initial support is currently being
> upstreamed [1].
>
> In present state, keyboard is succesfully initialized, however attempt to type
> anything throws 'incomplete report' errors. When utilizing
> I2C_HID_QUIRK_BAD_INPUT_SIZE quirk the error is gone, however raw data
> coming from the keyboard is always the same, no matter the key pressed. Issue
> 'resolves' itself when suspending and resuming the device.
>
> It appears that calling power on command one more time after device
> initialization before finishing off the probing fixes this weird behavior, and
> keyboard works right away.
>
> Introduce a new quirk for such behaviour, and enable it for particular
> keyboard.
> Vendor is shown as 'QTEC', however device id is reported as 0000. Given that
> vendor was not present before, using HID_ANY_ID to match the device should
> be okay in this case.
>
> In v1 it was suggested to make a dedicated i2c-of-qtec driver, but I was not sure
> how to proceed at the time. I have now drafted a dedicated driver, and it really
> is just probe method being extended to call powerup command again. Given
> that a similarly 'ugly' quirk was just merged to i2c-hid-core.c for a Goodix
> device [2], and that (IMO) creating a dedicated driver for such a small change
> without any plan on extending it will be just polluting, I am asking you to
> consider this change again. Alternatively, if it is yet still strongly preferred to
> have a dedicated driver to include this quirk, please let me know so I can
> proceed accordingly.
>
> --------
For the series:
Reviewed-by: Laurentiu Tudor <Laurentiu.Tudor1@...l.com>
Tested-by: Laurentiu Tudor <Laurentiu.Tudor1@...l.com>
---
Thanks & Best Regards, Laurentiu
> Changes to V1:
> * Rebase on top of latest linux-next
> * Update coverletter's reasoning and links
> * link:
> https://urldefense.com/v3/__https://lore.kernel.org/all/20240925100303.911
> 2-1-
> alex.vinarskis@...il.com/__;!!LpKI!hTYUmNdAbx06nnU3DlrMQn9PGzi4y9Ne
> SOTjPf2SPO67ore1XymZjywoQN19RvKaVHbNs5VLc9_77mwvQAT8em7dODeJ
> $ [lore[.]kernel[.]org]
>
> Aleksandrs Vinarskis (2):
> HID: i2c-hid: introduce re-power-on quirk
> HID: i2c-hid: introduce qtec vendor, enable re-power-on quirk
>
> drivers/hid/hid-ids.h | 2 ++
> drivers/hid/i2c-hid/i2c-hid-core.c | 12 +++++++++++-
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> --
> 2.45.2
Powered by blists - more mailing lists