* Re: [BUG: 6.3 kernel] Logitech Trackball M575 misidentified
From: Bastien Nocera @ 2023-05-31 8:50 UTC (permalink / raw)
To: Linux regressions mailing list, Xose Vazquez Perez, linux-input
Cc: Filipe Laíns, Jiri Kosina, Benjamin Tissoires, LKML
In-Reply-To: <8941c5f2-3861-da68-06ca-adc68a37e53b@leemhuis.info>
On Tue, 2023-05-16 at 14:33 +0200, Linux regression tracking (Thorsten
Leemhuis) wrote:
> [CCing a few people and the the regression list, as it should be in
> the
> loop for regressions:
> https://docs.kernel.org/admin-guide/reporting-regressions.html]
>
> On 11.05.23 23:22, Xose Vazquez Perez wrote:
> >
> > 6.3.2 kernel identifies "Logitech" "ERGO M575" as "Logitech"
> > "(\xc9_O\x04)",
> > 6.2.15 works fine.
> >
> >
> > 6.2.15 boot log:
> > input: Logitech ERGO M575 as
> > /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.3/3-
> > 1.3:1.2/0003:046D:C52B.0003/0003:046D:4096.0005/input/input15
> > logitech-hidpp-device 0003:046D:4096.0005: input,hidraw1: USB HID
> > v1.11
> > Mouse [Logitech ERGO M575] on usb-0000:00:1a.0-1.3/input2:1
> >
> > 6.3.2 boot log:
> > input: Logitech \xc9_O\x04 as
> > /devices/pci0000:00/0000:00:1a.0/usb3/3-1/3-1.3/3-
> > 1.3:1.2/0003:046D:C52B.0003/0003:046D:4096.0005/input/input15
> > logitech-hidpp-device 0003:046D:4096.0005: input,hidraw2: USB HID
> > v1.11
> > Mouse [Logitech \xc9_O\x04] on usb-0000:00:1a.0-1.3/input2:1
>
> I wonder if this if this is some related to this issue:
> https://bugzilla.kernel.org/show_bug.cgi?id=217412
> ("Since kernel 6.3.1 logitech unify receiver not working properly")
>
> That one so far seems to be ignored by the developers. Your report
> one
> also didn't get any reply yet.
>
> Could you maybe perform a bisection to get down to this?
>
> Side note: there is also
> https://bugzilla.kernel.org/show_bug.cgi?id=217330
> ("Broken Logitech unifying battery names in hid-next tree")
The device name problem is tracked in 217330, which I filed.
A bisection would definitely help me if you have time, otherwise I'll
get to it, but it's probably not going to be before a couple of weeks.
You can also test this patch on top of the latest kernel tree:
https://patchwork.kernel.org/project/linux-input/patch/20230531082428.21763-1-hadess@hadess.net/
although I don't expect it to make a difference.
Cheers
>
>
> Anyway, for the rest of this mail:
>
> [TLDR: I'm adding this report to the list of tracked Linux kernel
> regressions; the text you find below is based on a few templates
> paragraphs you might have encountered already in similar form.
> See link in footer if these mails annoy you.]
>
> Thanks for the report. To be sure the issue doesn't fall through the
> cracks unnoticed, I'm adding it to regzbot, the Linux kernel
> regression
> tracking bot:
>
> #regzbot ^introduced v6.2..v6.3
> #regzbot title input: Logitech Trackball M575 misidentified
> #regzbot ignore-activity
>
> This isn't a regression? This issue or a fix for it are already
> discussed somewhere else? It was fixed already? You want to clarify
> when
> the regression started to happen? Or point out I got the title or
> something else totally wrong? Then just reply and tell me -- ideally
> while also telling regzbot about it, as explained by the page listed
> in
> the footer of this mail.
>
> Developers: When fixing the issue, remember to add 'Link:' tags
> pointing
> to the report (the parent of this mail). See page linked in footer
> for
> details.
>
> Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker'
> hat)
> --
> Everything you wanna know about Linux kernel regression tracking:
> https://linux-regtracking.leemhuis.info/about/#tldr
> That page also explains what to do if mails like this annoy you.
^ permalink raw reply
* Re: [regression] Since kernel 6.3.1 logitech unify receiver not working properly
From: Bastien Nocera @ 2023-05-31 8:46 UTC (permalink / raw)
To: Linus Torvalds, Linux regressions mailing list
Cc: Benjamin Tissoires, Bagas Sanjaya, Filipe Laíns, Jiri Kosina,
open list:HID CORE LAYER, LKML, guy.b
In-Reply-To: <CAHk-=whvhkSk6m8_AidhofgR9nq0Md+HbNad5r1RE69tZgbv6Q@mail.gmail.com>
On Mon, 2023-05-22 at 11:23 -0700, Linus Torvalds wrote:
> On Mon, May 22, 2023 at 5:38 AM Linux regression tracking (Thorsten
> Leemhuis) <regressions@leemhuis.info> wrote:
> >
> > FWIW, in case anybody is interested in a status update: one
> > reporter
> > bisected the problem down to 586e8fede79 ("HID: logitech-hidpp:
> > Retry
> > commands when device is busy"); reverting that commit on-top of 6.3
> > fixes the problem for that reporter. For that reporter things also
> > work
> > on 6.4-rc; but for someone else that is affected that's not the
> > case.
>
> Hmm. It's likely timing-dependent.
>
> But that code is clearly buggy.
>
> If the wait_event_timeout() returns early, the device hasn't replied,
> but the code does
>
> if (!wait_event_timeout(hidpp->wait, hidpp-
> >answer_available,
> 5*HZ)) {
> dbg_hid("%s:timeout waiting for response\n",
> __func__);
> memset(response, 0, sizeof(struct
> hidpp_report));
> ret = -ETIMEDOUT;
> }
>
> and then continues to look at the response _anyway_.
>
> Now, depending on out hardening options, that response may have been
> initialized by the compiler, or may just be random stack contents.
It's kzalloc()'ed in the 2 places it's used, hidpp_send_message_sync().
> That bug is pre-existing (ie the problem was not introduced by that
> commit), but who knows if the retry makes things worse (ie if it then
> triggers on a retry, the response data will be the *previous*
> response).
>
> The whole "goto exit" games should be removed too, because we're in a
> for-loop, and instead of "goto exit" it should just do "break".
>
> IOW, something like this might be worth testing.
>
> That said, while I think the code is buggy, I doubt this is the
> actual
> cause of the problem people are reporting. But it would be lovely to
> hear if the attached patch makes any difference, and I think this is
> fixing a real - but unlikely - problem anyway.
>
> And obviously it might be helpful to actually enable those dbg_hid()
> messages, but I didn't look at what the magic config option to do so
> was.
Thomas Weißschuh's patch ("HID: use standard debug APIs") linked all
those debug calls to the dynamic debugging system, so something like
this will work after boot:
echo 'file hid-logitech-hidpp.c +p' > /sys/kernel/debug/dynamic_debug/control
Adding this to the kernel command-line to get some debug during boot
should work:
dyndbg="file hid-logitech-hidpp.c +p"
In both cases, check it's enabled and that the messages can be printed
with:
grep -i hidpp /sys/kernel/debug/dynamic_debug/control
> NOTE! Patch below *ENTIRELY* untested. I just looked at the code when
> that commit was mentioned, and went "that's not right"...
I sent a similar patch before seeing your version, in answer to a
separate report I was sent. It doesn't change the style of the code,
and just fixes that one omission:
https://patchwork.kernel.org/project/linux-input/patch/20230531082428.21763-1-hadess@hadess.net/
Cheers
>
> Linus
^ permalink raw reply
* Re: [regression] Since kernel 6.3.1 logitech unify receiver not working properly
From: Jiri Kosina @ 2023-05-31 8:43 UTC (permalink / raw)
To: Thorsten Leemhuis
Cc: Benjamin Tissoires, Linus Torvalds,
Linux regressions mailing list, Bagas Sanjaya, Filipe Laíns,
Bastien Nocera, open list:HID CORE LAYER, LKML, guy.b
In-Reply-To: <746720e5-318c-6d9e-2d5a-a6ebf6b4b0c6@leemhuis.info>
On Sun, 28 May 2023, Thorsten Leemhuis wrote:
> > who is able to reproduce the issue please check whether
> > reverting
> >
> > 586e8fede7953b16 ("HID: logitech-hidpp: Retry commands when device is busy")
> >
> > has any observable effect?
>
> See https://bugzilla.kernel.org/show_bug.cgi?id=217412#c26 and later –
> it at least solved the problem for one user.
>
> But it's all a mess (at least afaics). Earlier in that ticket some other
> user said things work with 6.4-rc kernel, while for another confirmed
> things are still broken. So maybe we deal with more than one problem. Or
> testing went sideways for some of the users.
The patch that needs to be tested now by the affected users is here:
https://patchwork.kernel.org/project/linux-input/patch/20230531082428.21763-1-hadess@hadess.net/
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Fotowoltaika- propozycja instalacji
From: Norbert Karecki @ 2023-05-31 8:15 UTC (permalink / raw)
To: linux-input
Dzień dobry,
Czy rozważali Państwo montaż systemu fotowoltaicznego?
Instalacja fotowoltaiczna jest najlepszym sposobem na obniżenie wysokości rachunków za prąd (pozostają tylko opłaty stałe) i zabezpieczenie się przed rosnącymi cenami energii elektrycznej. Jest to w pełni odnawialne i bezemisyjne źródło energii, dzięki czemu przyczyniamy się do ochrony środowiska naturalnego.
Działamy od wielu lat na rynku energetycznym. Przygotujemy projekt, wycenę oraz kompleksowo wykonamy i zgłosimy realizację do zakładu energetycznego.
Czy chcą Państwo poznać naszą propozycję?
Pozdrawiam,
Norbert Karecki
^ permalink raw reply
* [PATCH] HID: logitech-hidpp: Handle timeout differently from busy
From: Bastien Nocera @ 2023-05-31 8:24 UTC (permalink / raw)
To: linux-input
Cc: linux-kernel, Jiri Kosina, Benjamin Tissoires,
Peter F . Patel-Schneider, Filipe Laíns, Nestor Lopez Casado,
Mark Lord
If an attempt at contacting a receiver or a device fails because the
receiver or device never responds, don't restart the communication, only
restart it if the receiver or device answers that it's busy, as originally
intended.
This was the behaviour on communication timeout before commit 586e8fede795
("HID: logitech-hidpp: Retry commands when device is busy").
This fixes some overly long waits in a critical path on boot, when
checking whether the device is connected by getting its HID++ version.
Signed-off-by: Bastien Nocera <hadess@hadess.net>
Suggested-by: Mark Lord <mlord@pobox.com>
Fixes: 586e8fede795 ("HID: logitech-hidpp: Retry commands when device is busy")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217412
---
drivers/hid/hid-logitech-hidpp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 0fcfd85fea0f..2246044b1639 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -314,6 +314,7 @@ static int hidpp_send_message_sync(struct hidpp_device *hidpp,
dbg_hid("%s:timeout waiting for response\n", __func__);
memset(response, 0, sizeof(struct hidpp_report));
ret = -ETIMEDOUT;
+ goto exit;
}
if (response->report_id == REPORT_ID_HIDPP_SHORT &&
--
2.40.1
^ permalink raw reply related
* Re: [PATCH v2] hid-wiimote-debug.c: Drop error checking for debugfs_create_file
From: David Rheinsberg @ 2023-05-31 6:35 UTC (permalink / raw)
To: Osama Muhammad; +Cc: jikos, benjamin.tissoires, linux-input, linux-kernel
In-Reply-To: <20230530154252.7895-1-osmtendev@gmail.com>
Hi
On Tue, 30 May 2023 at 17:43, Osama Muhammad <osmtendev@gmail.com> wrote:
>
> This patch removes the error checking for debugfs_create_file
> in hid-wiimote-debug.c.c. This is because the debugfs_create_file()
> does not return NULL but an ERR_PTR after an error.
> The DebugFS kernel API is developed in a way that the
> caller can safely ignore the errors that occur during
> the creation of DebugFS nodes.The debugfs Api handles
> it gracefully. The check is unnecessary.
>
> Link to the comment above debugfs_create_file:
> https://elixir.bootlin.com/linux/latest/source/fs/debugfs/inode.c#L451
>
> Signed-off-by: Osama Muhammad <osmtendev@gmail.com>
Looks good, thanks!
Reviewed-by: David Rheinsberg <david@readahead.eu>
Thanks
David
> ---
> changes since v1
> -In v1 the IS_ERR was used for error checking which is dropped now.
> ---
> drivers/hid/hid-wiimote-debug.c | 10 ----------
> 1 file changed, 10 deletions(-)
>
> diff --git a/drivers/hid/hid-wiimote-debug.c b/drivers/hid/hid-wiimote-debug.c
> index a99dcca2e099..00f9be55f148 100644
> --- a/drivers/hid/hid-wiimote-debug.c
> +++ b/drivers/hid/hid-wiimote-debug.c
> @@ -173,7 +173,6 @@ int wiidebug_init(struct wiimote_data *wdata)
> {
> struct wiimote_debug *dbg;
> unsigned long flags;
> - int ret = -ENOMEM;
>
> dbg = kzalloc(sizeof(*dbg), GFP_KERNEL);
> if (!dbg)
> @@ -183,13 +182,9 @@ int wiidebug_init(struct wiimote_data *wdata)
>
> dbg->eeprom = debugfs_create_file("eeprom", S_IRUSR,
> dbg->wdata->hdev->debug_dir, dbg, &wiidebug_eeprom_fops);
> - if (!dbg->eeprom)
> - goto err;
>
> dbg->drm = debugfs_create_file("drm", S_IRUSR,
> dbg->wdata->hdev->debug_dir, dbg, &wiidebug_drm_fops);
> - if (!dbg->drm)
> - goto err_drm;
>
> spin_lock_irqsave(&wdata->state.lock, flags);
> wdata->debug = dbg;
> @@ -197,11 +192,6 @@ int wiidebug_init(struct wiimote_data *wdata)
>
> return 0;
>
> -err_drm:
> - debugfs_remove(dbg->eeprom);
> -err:
> - kfree(dbg);
> - return ret;
> }
>
> void wiidebug_deinit(struct wiimote_data *wdata)
> --
> 2.34.1
>
^ permalink raw reply
* [PATCH 2/2] Input: iqs7222 - add support for Azoteq IQS7222D
From: Jeff LaBundy @ 2023-05-31 1:51 UTC (permalink / raw)
To: dmitry.torokhov, robh+dt; +Cc: linux-input, devicetree, jeff
In-Reply-To: <ZHanv+8fOYhpyMEC@nixie71>
The vendor has introduced a new variant of silicon which is highly
similar to the existing IQS7222A, but with its independent sliders
essentially replaced with a single-contact trackpad.
Update the common driver to support this new device's register map
and report trackpad events. As with the IQS7222A, the new IQS7222D
can report both raw coordinates as well as gestures.
Signed-off-by: Jeff LaBundy <jeff@labundy.com>
---
drivers/input/misc/Kconfig | 4 +-
drivers/input/misc/iqs7222.c | 468 ++++++++++++++++++++++++++++++++++-
2 files changed, 461 insertions(+), 11 deletions(-)
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 81a54a59e13c..c47eecc6f83b 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -791,10 +791,10 @@ config INPUT_IQS626A
module will be called iqs626a.
config INPUT_IQS7222
- tristate "Azoteq IQS7222A/B/C capacitive touch controller"
+ tristate "Azoteq IQS7222A/B/C/D capacitive touch controller"
depends on I2C
help
- Say Y to enable support for the Azoteq IQS7222A/B/C family
+ Say Y to enable support for the Azoteq IQS7222A/B/C/D family
of capacitive touch controllers.
To compile this driver as a module, choose M here: the
diff --git a/drivers/input/misc/iqs7222.c b/drivers/input/misc/iqs7222.c
index 096b0925f41b..b837274b03f0 100644
--- a/drivers/input/misc/iqs7222.c
+++ b/drivers/input/misc/iqs7222.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
- * Azoteq IQS7222A/B/C Capacitive Touch Controller
+ * Azoteq IQS7222A/B/C/D Capacitive Touch Controller
*
* Copyright (C) 2022 Jeff LaBundy <jeff@labundy.com>
*/
@@ -12,6 +12,7 @@
#include <linux/gpio/consumer.h>
#include <linux/i2c.h>
#include <linux/input.h>
+#include <linux/input/touchscreen.h>
#include <linux/interrupt.h>
#include <linux/kernel.h>
#include <linux/ktime.h>
@@ -25,6 +26,7 @@
#define IQS7222_PROD_NUM_A 840
#define IQS7222_PROD_NUM_B 698
#define IQS7222_PROD_NUM_C 863
+#define IQS7222_PROD_NUM_D 1046
#define IQS7222_SYS_STATUS 0x10
#define IQS7222_SYS_STATUS_RESET BIT(3)
@@ -54,6 +56,7 @@
#define IQS7222_EVENT_MASK_ATI BIT(12)
#define IQS7222_EVENT_MASK_SLDR BIT(10)
+#define IQS7222_EVENT_MASK_TPAD IQS7222_EVENT_MASK_SLDR
#define IQS7222_EVENT_MASK_TOUCH BIT(1)
#define IQS7222_EVENT_MASK_PROX BIT(0)
@@ -71,6 +74,7 @@
#define IQS7222_MAX_COLS_CHAN 6
#define IQS7222_MAX_COLS_FILT 2
#define IQS7222_MAX_COLS_SLDR 11
+#define IQS7222_MAX_COLS_TPAD 24
#define IQS7222_MAX_COLS_GPIO 3
#define IQS7222_MAX_COLS_SYS 13
@@ -102,16 +106,18 @@ enum iqs7222_reg_grp_id {
IQS7222_REG_GRP_BTN,
IQS7222_REG_GRP_CHAN,
IQS7222_REG_GRP_SLDR,
+ IQS7222_REG_GRP_TPAD,
IQS7222_REG_GRP_GPIO,
IQS7222_REG_GRP_SYS,
IQS7222_NUM_REG_GRPS
};
static const char * const iqs7222_reg_grp_names[IQS7222_NUM_REG_GRPS] = {
- [IQS7222_REG_GRP_CYCLE] = "cycle",
- [IQS7222_REG_GRP_CHAN] = "channel",
- [IQS7222_REG_GRP_SLDR] = "slider",
- [IQS7222_REG_GRP_GPIO] = "gpio",
+ [IQS7222_REG_GRP_CYCLE] = "cycle-%d",
+ [IQS7222_REG_GRP_CHAN] = "channel-%d",
+ [IQS7222_REG_GRP_SLDR] = "slider-%d",
+ [IQS7222_REG_GRP_TPAD] = "trackpad",
+ [IQS7222_REG_GRP_GPIO] = "gpio-%d",
};
static const unsigned int iqs7222_max_cols[IQS7222_NUM_REG_GRPS] = {
@@ -122,6 +128,7 @@ static const unsigned int iqs7222_max_cols[IQS7222_NUM_REG_GRPS] = {
[IQS7222_REG_GRP_CHAN] = IQS7222_MAX_COLS_CHAN,
[IQS7222_REG_GRP_FILT] = IQS7222_MAX_COLS_FILT,
[IQS7222_REG_GRP_SLDR] = IQS7222_MAX_COLS_SLDR,
+ [IQS7222_REG_GRP_TPAD] = IQS7222_MAX_COLS_TPAD,
[IQS7222_REG_GRP_GPIO] = IQS7222_MAX_COLS_GPIO,
[IQS7222_REG_GRP_SYS] = IQS7222_MAX_COLS_SYS,
};
@@ -130,8 +137,10 @@ static const unsigned int iqs7222_gpio_links[] = { 2, 5, 6, };
struct iqs7222_event_desc {
const char *name;
+ u16 link;
u16 mask;
u16 val;
+ u16 strict;
u16 enable;
enum iqs7222_reg_key_id reg_key;
};
@@ -188,6 +197,93 @@ static const struct iqs7222_event_desc iqs7222_sl_events[] = {
},
};
+static const struct iqs7222_event_desc iqs7222_tp_events[] = {
+ {
+ .name = "event-press",
+ .link = BIT(7),
+ },
+ {
+ .name = "event-tap",
+ .link = BIT(0),
+ .mask = BIT(0),
+ .val = BIT(0),
+ .enable = BIT(0),
+ .reg_key = IQS7222_REG_KEY_TAP,
+ },
+ {
+ .name = "event-swipe-x-pos",
+ .link = BIT(2),
+ .mask = BIT(2) | BIT(1),
+ .val = BIT(2),
+ .strict = BIT(4),
+ .enable = BIT(1),
+ .reg_key = IQS7222_REG_KEY_AXIAL,
+ },
+ {
+ .name = "event-swipe-y-pos",
+ .link = BIT(3),
+ .mask = BIT(3) | BIT(1),
+ .val = BIT(3),
+ .strict = BIT(3),
+ .enable = BIT(1),
+ .reg_key = IQS7222_REG_KEY_AXIAL,
+ },
+ {
+ .name = "event-swipe-x-neg",
+ .link = BIT(4),
+ .mask = BIT(4) | BIT(1),
+ .val = BIT(4),
+ .strict = BIT(4),
+ .enable = BIT(1),
+ .reg_key = IQS7222_REG_KEY_AXIAL,
+ },
+ {
+ .name = "event-swipe-y-neg",
+ .link = BIT(5),
+ .mask = BIT(5) | BIT(1),
+ .val = BIT(5),
+ .strict = BIT(3),
+ .enable = BIT(1),
+ .reg_key = IQS7222_REG_KEY_AXIAL,
+ },
+ {
+ .name = "event-flick-x-pos",
+ .link = BIT(2),
+ .mask = BIT(2) | BIT(1),
+ .val = BIT(2) | BIT(1),
+ .strict = BIT(4),
+ .enable = BIT(2),
+ .reg_key = IQS7222_REG_KEY_AXIAL,
+ },
+ {
+ .name = "event-flick-y-pos",
+ .link = BIT(3),
+ .mask = BIT(3) | BIT(1),
+ .val = BIT(3) | BIT(1),
+ .strict = BIT(3),
+ .enable = BIT(2),
+ .reg_key = IQS7222_REG_KEY_AXIAL,
+ },
+ {
+ .name = "event-flick-x-neg",
+ .link = BIT(4),
+ .mask = BIT(4) | BIT(1),
+ .val = BIT(4) | BIT(1),
+ .strict = BIT(4),
+ .enable = BIT(2),
+ .reg_key = IQS7222_REG_KEY_AXIAL,
+ },
+ {
+ .name = "event-flick-y-neg",
+ .link = BIT(5),
+ .mask = BIT(5) | BIT(1),
+ .val = BIT(5) | BIT(1),
+ .strict = BIT(3),
+ .enable = BIT(2),
+ .reg_key = IQS7222_REG_KEY_AXIAL,
+ },
+};
+
struct iqs7222_reg_grp_desc {
u16 base;
int num_row;
@@ -524,6 +620,62 @@ static const struct iqs7222_dev_desc iqs7222_devs[] = {
},
},
},
+ {
+ .prod_num = IQS7222_PROD_NUM_D,
+ .fw_major = 0,
+ .fw_minor = 37,
+ .touch_link = 1770,
+ .allow_offset = 9,
+ .event_offset = 10,
+ .comms_offset = 11,
+ .reg_grps = {
+ [IQS7222_REG_GRP_STAT] = {
+ .base = IQS7222_SYS_STATUS,
+ .num_row = 1,
+ .num_col = 7,
+ },
+ [IQS7222_REG_GRP_CYCLE] = {
+ .base = 0x8000,
+ .num_row = 7,
+ .num_col = 2,
+ },
+ [IQS7222_REG_GRP_GLBL] = {
+ .base = 0x8700,
+ .num_row = 1,
+ .num_col = 3,
+ },
+ [IQS7222_REG_GRP_BTN] = {
+ .base = 0x9000,
+ .num_row = 14,
+ .num_col = 3,
+ },
+ [IQS7222_REG_GRP_CHAN] = {
+ .base = 0xA000,
+ .num_row = 14,
+ .num_col = 4,
+ },
+ [IQS7222_REG_GRP_FILT] = {
+ .base = 0xAE00,
+ .num_row = 1,
+ .num_col = 2,
+ },
+ [IQS7222_REG_GRP_TPAD] = {
+ .base = 0xB000,
+ .num_row = 1,
+ .num_col = 24,
+ },
+ [IQS7222_REG_GRP_GPIO] = {
+ .base = 0xC000,
+ .num_row = 3,
+ .num_col = 3,
+ },
+ [IQS7222_REG_GRP_SYS] = {
+ .base = IQS7222_SYS_SETUP,
+ .num_row = 1,
+ .num_col = 12,
+ },
+ },
+ },
};
struct iqs7222_prop_desc {
@@ -1008,6 +1160,123 @@ static const struct iqs7222_prop_desc iqs7222_props[] = {
.val_pitch = 4,
.label = "maximum gesture time",
},
+ {
+ .name = "azoteq,num-rows",
+ .reg_grp = IQS7222_REG_GRP_TPAD,
+ .reg_offset = 0,
+ .reg_shift = 4,
+ .reg_width = 4,
+ .val_min = 1,
+ .val_max = 12,
+ .label = "number of rows",
+ },
+ {
+ .name = "azoteq,num-cols",
+ .reg_grp = IQS7222_REG_GRP_TPAD,
+ .reg_offset = 0,
+ .reg_shift = 0,
+ .reg_width = 4,
+ .val_min = 1,
+ .val_max = 12,
+ .label = "number of columns",
+ },
+ {
+ .name = "azoteq,lower-cal-y",
+ .reg_grp = IQS7222_REG_GRP_TPAD,
+ .reg_offset = 1,
+ .reg_shift = 8,
+ .reg_width = 8,
+ .label = "lower vertical calibration",
+ },
+ {
+ .name = "azoteq,lower-cal-x",
+ .reg_grp = IQS7222_REG_GRP_TPAD,
+ .reg_offset = 1,
+ .reg_shift = 0,
+ .reg_width = 8,
+ .label = "lower horizontal calibration",
+ },
+ {
+ .name = "azoteq,upper-cal-y",
+ .reg_grp = IQS7222_REG_GRP_TPAD,
+ .reg_offset = 2,
+ .reg_shift = 8,
+ .reg_width = 8,
+ .label = "upper vertical calibration",
+ },
+ {
+ .name = "azoteq,upper-cal-x",
+ .reg_grp = IQS7222_REG_GRP_TPAD,
+ .reg_offset = 2,
+ .reg_shift = 0,
+ .reg_width = 8,
+ .label = "upper horizontal calibration",
+ },
+ {
+ .name = "azoteq,top-speed",
+ .reg_grp = IQS7222_REG_GRP_TPAD,
+ .reg_offset = 3,
+ .reg_shift = 8,
+ .reg_width = 8,
+ .val_pitch = 4,
+ .label = "top speed",
+ },
+ {
+ .name = "azoteq,bottom-speed",
+ .reg_grp = IQS7222_REG_GRP_TPAD,
+ .reg_offset = 3,
+ .reg_shift = 0,
+ .reg_width = 8,
+ .label = "bottom speed",
+ },
+ {
+ .name = "azoteq,gesture-min-ms",
+ .reg_grp = IQS7222_REG_GRP_TPAD,
+ .reg_key = IQS7222_REG_KEY_TAP,
+ .reg_offset = 20,
+ .reg_shift = 8,
+ .reg_width = 8,
+ .val_pitch = 16,
+ .label = "minimum gesture time",
+ },
+ {
+ .name = "azoteq,gesture-max-ms",
+ .reg_grp = IQS7222_REG_GRP_TPAD,
+ .reg_key = IQS7222_REG_KEY_AXIAL,
+ .reg_offset = 21,
+ .reg_shift = 8,
+ .reg_width = 8,
+ .val_pitch = 16,
+ .label = "maximum gesture time",
+ },
+ {
+ .name = "azoteq,gesture-max-ms",
+ .reg_grp = IQS7222_REG_GRP_TPAD,
+ .reg_key = IQS7222_REG_KEY_TAP,
+ .reg_offset = 21,
+ .reg_shift = 0,
+ .reg_width = 8,
+ .val_pitch = 16,
+ .label = "maximum gesture time",
+ },
+ {
+ .name = "azoteq,gesture-dist",
+ .reg_grp = IQS7222_REG_GRP_TPAD,
+ .reg_key = IQS7222_REG_KEY_TAP,
+ .reg_offset = 22,
+ .reg_shift = 0,
+ .reg_width = 16,
+ .label = "gesture distance",
+ },
+ {
+ .name = "azoteq,gesture-dist",
+ .reg_grp = IQS7222_REG_GRP_TPAD,
+ .reg_key = IQS7222_REG_KEY_AXIAL,
+ .reg_offset = 23,
+ .reg_shift = 0,
+ .reg_width = 16,
+ .label = "gesture distance",
+ },
{
.name = "drive-open-drain",
.reg_grp = IQS7222_REG_GRP_GPIO,
@@ -1091,16 +1360,19 @@ struct iqs7222_private {
struct gpio_desc *irq_gpio;
struct i2c_client *client;
struct input_dev *keypad;
+ struct touchscreen_properties prop;
unsigned int kp_type[IQS7222_MAX_CHAN][ARRAY_SIZE(iqs7222_kp_events)];
unsigned int kp_code[IQS7222_MAX_CHAN][ARRAY_SIZE(iqs7222_kp_events)];
unsigned int sl_code[IQS7222_MAX_SLDR][ARRAY_SIZE(iqs7222_sl_events)];
unsigned int sl_axis[IQS7222_MAX_SLDR];
+ unsigned int tp_code[ARRAY_SIZE(iqs7222_tp_events)];
u16 cycle_setup[IQS7222_MAX_CHAN / 2][IQS7222_MAX_COLS_CYCLE];
u16 glbl_setup[IQS7222_MAX_COLS_GLBL];
u16 btn_setup[IQS7222_MAX_CHAN][IQS7222_MAX_COLS_BTN];
u16 chan_setup[IQS7222_MAX_CHAN][IQS7222_MAX_COLS_CHAN];
u16 filt_setup[IQS7222_MAX_COLS_FILT];
u16 sldr_setup[IQS7222_MAX_SLDR][IQS7222_MAX_COLS_SLDR];
+ u16 tpad_setup[IQS7222_MAX_COLS_TPAD];
u16 gpio_setup[ARRAY_SIZE(iqs7222_gpio_links)][IQS7222_MAX_COLS_GPIO];
u16 sys_setup[IQS7222_MAX_COLS_SYS];
};
@@ -1127,6 +1399,9 @@ static u16 *iqs7222_setup(struct iqs7222_private *iqs7222,
case IQS7222_REG_GRP_SLDR:
return iqs7222->sldr_setup[row];
+ case IQS7222_REG_GRP_TPAD:
+ return iqs7222->tpad_setup;
+
case IQS7222_REG_GRP_GPIO:
return iqs7222->gpio_setup[row];
@@ -1936,6 +2211,14 @@ static int iqs7222_parse_chan(struct iqs7222_private *iqs7222,
ref_setup[4] = dev_desc->touch_link;
if (fwnode_property_present(chan_node, "azoteq,use-prox"))
ref_setup[4] -= 2;
+ } else if (dev_desc->reg_grps[IQS7222_REG_GRP_TPAD].num_row &&
+ fwnode_property_present(chan_node,
+ "azoteq,counts-filt-enable")) {
+ /*
+ * In the case of IQS7222D, however, the reference mode field
+ * is partially repurposed as a counts filter enable control.
+ */
+ chan_setup[0] |= IQS7222_CHAN_SETUP_0_REF_MODE_REF;
}
if (fwnode_property_present(chan_node, "azoteq,rx-enable")) {
@@ -2278,6 +2561,136 @@ static int iqs7222_parse_sldr(struct iqs7222_private *iqs7222,
IQS7222_REG_KEY_NO_WHEEL);
}
+static int iqs7222_parse_tpad(struct iqs7222_private *iqs7222,
+ struct fwnode_handle *tpad_node, int tpad_index)
+{
+ const struct iqs7222_dev_desc *dev_desc = iqs7222->dev_desc;
+ struct touchscreen_properties *prop = &iqs7222->prop;
+ struct i2c_client *client = iqs7222->client;
+ int num_chan = dev_desc->reg_grps[IQS7222_REG_GRP_CHAN].num_row;
+ int count, error, i;
+ u16 *event_mask = &iqs7222->sys_setup[dev_desc->event_offset];
+ u16 *tpad_setup = iqs7222->tpad_setup;
+ unsigned int chan_sel[12], val;
+
+ error = iqs7222_parse_props(iqs7222, tpad_node, tpad_index,
+ IQS7222_REG_GRP_TPAD,
+ IQS7222_REG_KEY_NONE);
+ if (error)
+ return error;
+
+ count = fwnode_property_count_u32(tpad_node, "azoteq,channel-select");
+ if (count < 0) {
+ dev_err(&client->dev, "Failed to count %s channels: %d\n",
+ fwnode_get_name(tpad_node), count);
+ return count;
+ } else if (!count || count > ARRAY_SIZE(chan_sel)) {
+ dev_err(&client->dev, "Invalid number of %s channels\n",
+ fwnode_get_name(tpad_node));
+ return -EINVAL;
+ }
+
+ error = fwnode_property_read_u32_array(tpad_node,
+ "azoteq,channel-select",
+ chan_sel, count);
+ if (error) {
+ dev_err(&client->dev, "Failed to read %s channels: %d\n",
+ fwnode_get_name(tpad_node), error);
+ return error;
+ }
+
+ tpad_setup[6] &= ~GENMASK(num_chan - 1, 0);
+
+ for (i = 0; i < ARRAY_SIZE(chan_sel); i++) {
+ tpad_setup[8 + i] = 0;
+ if (i >= count || chan_sel[i] == U8_MAX)
+ continue;
+
+ if (chan_sel[i] >= num_chan) {
+ dev_err(&client->dev, "Invalid %s channel: %u\n",
+ fwnode_get_name(tpad_node), chan_sel[i]);
+ return -EINVAL;
+ }
+
+ /*
+ * The following fields indicate which channels participate in
+ * the trackpad, as well as each channel's relative placement.
+ */
+ tpad_setup[6] |= BIT(chan_sel[i]);
+ tpad_setup[8 + i] = chan_sel[i] * 34 + 1072;
+ }
+
+ tpad_setup[7] = dev_desc->touch_link;
+ if (fwnode_property_present(tpad_node, "azoteq,use-prox"))
+ tpad_setup[7] -= 2;
+
+ for (i = 0; i < ARRAY_SIZE(iqs7222_tp_events); i++)
+ tpad_setup[20] &= ~(iqs7222_tp_events[i].strict |
+ iqs7222_tp_events[i].enable);
+
+ for (i = 0; i < ARRAY_SIZE(iqs7222_tp_events); i++) {
+ const char *event_name = iqs7222_tp_events[i].name;
+ struct fwnode_handle *event_node;
+
+ event_node = fwnode_get_named_child_node(tpad_node, event_name);
+ if (!event_node)
+ continue;
+
+ if (fwnode_property_present(event_node,
+ "azoteq,gesture-angle-tighten"))
+ tpad_setup[20] |= iqs7222_tp_events[i].strict;
+
+ tpad_setup[20] |= iqs7222_tp_events[i].enable;
+
+ error = iqs7222_parse_event(iqs7222, event_node, tpad_index,
+ IQS7222_REG_GRP_TPAD,
+ iqs7222_tp_events[i].reg_key,
+ iqs7222_tp_events[i].link, 1566,
+ NULL,
+ &iqs7222->tp_code[i]);
+ fwnode_handle_put(event_node);
+ if (error)
+ return error;
+
+ if (!dev_desc->event_offset)
+ continue;
+
+ /*
+ * The press/release event is determined based on whether the
+ * coordinate fields report 0xFFFF and solely relies on touch
+ * or proximity interrupts to be unmasked.
+ */
+ if (i)
+ *event_mask |= IQS7222_EVENT_MASK_TPAD;
+ else if (tpad_setup[7] == dev_desc->touch_link)
+ *event_mask |= IQS7222_EVENT_MASK_TOUCH;
+ else
+ *event_mask |= IQS7222_EVENT_MASK_PROX;
+ }
+
+ if (!iqs7222->tp_code[0])
+ return 0;
+
+ input_set_abs_params(iqs7222->keypad, ABS_X,
+ 0, (tpad_setup[4] ? : 1) - 1, 0, 0);
+
+ input_set_abs_params(iqs7222->keypad, ABS_Y,
+ 0, (tpad_setup[5] ? : 1) - 1, 0, 0);
+
+ touchscreen_parse_properties(iqs7222->keypad, false, prop);
+
+ if (prop->max_x >= U16_MAX || prop->max_y >= U16_MAX) {
+ dev_err(&client->dev, "Invalid trackpad size: %u*%u\n",
+ prop->max_x, prop->max_y);
+ return -EINVAL;
+ }
+
+ tpad_setup[4] = prop->max_x + 1;
+ tpad_setup[5] = prop->max_y + 1;
+
+ return 0;
+}
+
static int (*iqs7222_parse_extra[IQS7222_NUM_REG_GRPS])
(struct iqs7222_private *iqs7222,
struct fwnode_handle *reg_grp_node,
@@ -2285,6 +2698,7 @@ static int (*iqs7222_parse_extra[IQS7222_NUM_REG_GRPS])
[IQS7222_REG_GRP_CYCLE] = iqs7222_parse_cycle,
[IQS7222_REG_GRP_CHAN] = iqs7222_parse_chan,
[IQS7222_REG_GRP_SLDR] = iqs7222_parse_sldr,
+ [IQS7222_REG_GRP_TPAD] = iqs7222_parse_tpad,
};
static int iqs7222_parse_reg_grp(struct iqs7222_private *iqs7222,
@@ -2298,7 +2712,7 @@ static int iqs7222_parse_reg_grp(struct iqs7222_private *iqs7222,
if (iqs7222_reg_grp_names[reg_grp]) {
char reg_grp_name[16];
- snprintf(reg_grp_name, sizeof(reg_grp_name), "%s-%d",
+ snprintf(reg_grp_name, sizeof(reg_grp_name),
iqs7222_reg_grp_names[reg_grp], reg_grp_index);
reg_grp_node = device_get_named_child_node(&client->dev,
@@ -2346,8 +2760,8 @@ static int iqs7222_parse_all(struct iqs7222_private *iqs7222)
continue;
/*
- * The IQS7222C exposes multiple GPIO and must be informed
- * as to which GPIO this group represents.
+ * The IQS7222C and IQS7222D expose multiple GPIO and must be
+ * informed as to which GPIO this group represents.
*/
for (j = 0; j < ARRAY_SIZE(iqs7222_gpio_links); j++)
gpio_setup[0] &= ~BIT(iqs7222_gpio_links[j]);
@@ -2480,6 +2894,41 @@ static int iqs7222_report(struct iqs7222_private *iqs7222)
iqs7222->sl_code[i][j], 0);
}
+ for (i = 0; i < dev_desc->reg_grps[IQS7222_REG_GRP_TPAD].num_row; i++) {
+ u16 tpad_pos_x = le16_to_cpu(status[4]);
+ u16 tpad_pos_y = le16_to_cpu(status[5]);
+ u16 state = le16_to_cpu(status[6]);
+
+ input_report_key(iqs7222->keypad, iqs7222->tp_code[0],
+ tpad_pos_x < U16_MAX);
+
+ if (tpad_pos_x < U16_MAX)
+ touchscreen_report_pos(iqs7222->keypad, &iqs7222->prop,
+ tpad_pos_x, tpad_pos_y, false);
+
+ if (!(le16_to_cpu(status[1]) & IQS7222_EVENT_MASK_TPAD))
+ continue;
+
+ /*
+ * Skip the press/release event, as it does not have separate
+ * status fields and is handled separately.
+ */
+ for (j = 1; j < ARRAY_SIZE(iqs7222_tp_events); j++) {
+ u16 mask = iqs7222_tp_events[j].mask;
+ u16 val = iqs7222_tp_events[j].val;
+
+ input_report_key(iqs7222->keypad,
+ iqs7222->tp_code[j],
+ (state & mask) == val);
+ }
+
+ input_sync(iqs7222->keypad);
+
+ for (j = 1; j < ARRAY_SIZE(iqs7222_tp_events); j++)
+ input_report_key(iqs7222->keypad,
+ iqs7222->tp_code[j], 0);
+ }
+
input_sync(iqs7222->keypad);
return 0;
@@ -2584,6 +3033,7 @@ static const struct of_device_id iqs7222_of_match[] = {
{ .compatible = "azoteq,iqs7222a" },
{ .compatible = "azoteq,iqs7222b" },
{ .compatible = "azoteq,iqs7222c" },
+ { .compatible = "azoteq,iqs7222d" },
{ }
};
MODULE_DEVICE_TABLE(of, iqs7222_of_match);
@@ -2598,5 +3048,5 @@ static struct i2c_driver iqs7222_i2c_driver = {
module_i2c_driver(iqs7222_i2c_driver);
MODULE_AUTHOR("Jeff LaBundy <jeff@labundy.com>");
-MODULE_DESCRIPTION("Azoteq IQS7222A/B/C Capacitive Touch Controller");
+MODULE_DESCRIPTION("Azoteq IQS7222A/B/C/D Capacitive Touch Controller");
MODULE_LICENSE("GPL");
--
2.34.1
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: input: iqs7222: Add properties for Azoteq IQS7222D
From: Jeff LaBundy @ 2023-05-31 1:49 UTC (permalink / raw)
To: dmitry.torokhov, robh+dt; +Cc: linux-input, devicetree, jeff
Extend the common binding to include a new variant of the silicon.
Signed-off-by: Jeff LaBundy <jeff@labundy.com>
---
.../bindings/input/azoteq,iqs7222.yaml | 202 +++++++++++++++++-
1 file changed, 192 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/azoteq,iqs7222.yaml b/Documentation/devicetree/bindings/input/azoteq,iqs7222.yaml
index 9ddba7f2e7aa..a4c251a430fa 100644
--- a/Documentation/devicetree/bindings/input/azoteq,iqs7222.yaml
+++ b/Documentation/devicetree/bindings/input/azoteq,iqs7222.yaml
@@ -4,14 +4,14 @@
$id: http://devicetree.org/schemas/input/azoteq,iqs7222.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Azoteq IQS7222A/B/C Capacitive Touch Controller
+title: Azoteq IQS7222A/B/C/D Capacitive Touch Controller
maintainers:
- Jeff LaBundy <jeff@labundy.com>
description: |
- The Azoteq IQS7222A, IQS7222B and IQS7222C are multichannel capacitive touch
- controllers that feature additional sensing capabilities.
+ The Azoteq IQS7222A, IQS7222B, IQS7222C and IQS7222D are multichannel capac-
+ itive touch controllers that feature additional sensing capabilities.
Link to datasheets: https://www.azoteq.com/
@@ -21,6 +21,7 @@ properties:
- azoteq,iqs7222a
- azoteq,iqs7222b
- azoteq,iqs7222c
+ - azoteq,iqs7222d
reg:
maxItems: 1
@@ -173,6 +174,148 @@ properties:
maximum: 3000
description: Specifies the report rate (in ms) during ultra-low-power mode.
+ touchscreen-size-x: true
+ touchscreen-size-y: true
+ touchscreen-inverted-x: true
+ touchscreen-inverted-y: true
+ touchscreen-swapped-x-y: true
+
+ trackpad:
+ type: object
+ description: Represents all channels associated with the trackpad.
+
+ properties:
+ azoteq,channel-select:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 12
+ items:
+ minimum: 0
+ maximum: 13
+ description:
+ Specifies the order of the channels that participate in the trackpad.
+ Specify 255 to omit a given channel for the purpose of mapping a non-
+ rectangular trackpad.
+
+ azoteq,num-rows:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ maximum: 12
+ description: Specifies the number of rows that comprise the trackpad.
+
+ azoteq,num-cols:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 1
+ maximum: 12
+ description: Specifies the number of columns that comprise the trackpad.
+
+ azoteq,top-speed:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ multipleOf: 4
+ minimum: 0
+ maximum: 1020
+ description:
+ Specifies the speed of movement after which coordinate filtering is
+ no longer applied.
+
+ azoteq,bottom-speed:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ description:
+ Specifies the speed of movement after which coordinate filtering is
+ linearly reduced.
+
+ azoteq,use-prox:
+ type: boolean
+ description:
+ Directs the trackpad to respond to the proximity states of the se-
+ lected channels instead of their corresponding touch states. Note
+ the trackpad cannot report granular coordinates during a state of
+ proximity.
+
+ patternProperties:
+ "^azoteq,lower-cal-(x|y)$":
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ description: Specifies the trackpad's lower starting points.
+
+ "^azoteq,upper-cal-(x|y)$":
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 255
+ description: Specifies the trackpad's upper starting points.
+
+ "^event-(press|tap|(swipe|flick)-(x|y)-(pos|neg))$":
+ type: object
+ $ref: input.yaml#
+ description:
+ Represents a press or gesture event reported by the trackpad. Specify
+ 'linux,code' under the press event to report absolute coordinates.
+
+ properties:
+ linux,code: true
+
+ azoteq,gesture-angle-tighten:
+ type: boolean
+ description:
+ Limits the tangent of the gesture angle to 0.5 (axial gestures
+ only). If specified in one direction, the effect is applied in
+ either direction.
+
+ azoteq,gesture-max-ms:
+ multipleOf: 16
+ minimum: 0
+ maximum: 4080
+ description:
+ Specifies the length of time (in ms) within which a tap, swipe
+ or flick gesture must be completed in order to be acknowledged
+ by the device. The number specified for any one swipe or flick
+ gesture applies to all other swipe or flick gestures.
+
+ azoteq,gesture-min-ms:
+ multipleOf: 16
+ minimum: 0
+ maximum: 4080
+ description:
+ Specifies the length of time (in ms) for which a tap gesture must
+ be held in order to be acknowledged by the device.
+
+ azoteq,gesture-dist:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 65535
+ description:
+ Specifies the distance across which a tap, swipe or flick gesture
+ must travel in order to be acknowledged by the device. The number
+ specified for any one swipe or flick gesture applies to all other
+ swipe or flick gestures.
+
+ azoteq,gpio-select:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 3
+ items:
+ minimum: 0
+ maximum: 2
+ description: |
+ Specifies one or more GPIO mapped to the event as follows:
+ 0: GPIO0
+ 1: GPIO3
+ 2: GPIO4
+
+ Note that although multiple events can be mapped to a single
+ GPIO, they must all be of the same type (proximity, touch or
+ trackpad gesture).
+
+ additionalProperties: false
+
+ required:
+ - azoteq,channel-select
+
+ additionalProperties: false
+
patternProperties:
"^cycle-[0-9]$":
type: object
@@ -288,6 +431,10 @@ patternProperties:
Activates the reference channel in response to proximity events
instead of touch events.
+ azoteq,counts-filt-enable:
+ type: boolean
+ description: Applies counts filtering to the channel.
+
azoteq,ati-band:
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3]
@@ -432,12 +579,12 @@ patternProperties:
description: |
Specifies one or more GPIO mapped to the event as follows:
0: GPIO0
- 1: GPIO3 (IQS7222C only)
- 2: GPIO4 (IQS7222C only)
+ 1: GPIO3
+ 2: GPIO4
Note that although multiple events can be mapped to a single
GPIO, they must all be of the same type (proximity, touch or
- slider gesture).
+ slider/trackpad gesture).
azoteq,thresh:
$ref: /schemas/types.yaml#/definitions/uint32
@@ -610,8 +757,8 @@ patternProperties:
description: |
Specifies one or more GPIO mapped to the event as follows:
0: GPIO0
- 1: GPIO3 (IQS7222C only)
- 2: GPIO4 (IQS7222C only)
+ 1: GPIO3
+ 2: GPIO4
Note that although multiple events can be mapped to a single
GPIO, they must all be of the same type (proximity, touch or
@@ -629,8 +776,8 @@ patternProperties:
description: |
Represents a GPIO mapped to one or more events as follows:
gpio-0: GPIO0
- gpio-1: GPIO3 (IQS7222C only)
- gpio-2: GPIO4 (IQS7222C only)
+ gpio-1: GPIO3
+ gpio-2: GPIO4
allOf:
- $ref: ../pinctrl/pincfg-node.yaml#
@@ -641,6 +788,41 @@ patternProperties:
additionalProperties: false
allOf:
+ - $ref: touchscreen/touchscreen.yaml#
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: azoteq,iqs7222d
+
+ then:
+ patternProperties:
+ "^cycle-[0-9]$":
+ properties:
+ azoteq,iref-enable: false
+
+ "^channel-([0-9]|1[0-9])$":
+ properties:
+ azoteq,ref-select: false
+
+ "^slider-[0-1]$": false
+
+ else:
+ properties:
+ touchscreen-size-x: false
+ touchscreen-size-y: false
+ touchscreen-inverted-x: false
+ touchscreen-inverted-y: false
+ touchscreen-swapped-x-y: false
+
+ trackpad: false
+
+ patternProperties:
+ "^channel-([0-9]|1[0-9])$":
+ properties:
+ azoteq,counts-filt-enable: false
+
- if:
properties:
compatible:
--
2.34.1
^ permalink raw reply related
* Re: [v2 1/2] HID: i2c-hid: elan: Add ili9882t timing
From: Dmitry Torokhov @ 2023-05-30 21:24 UTC (permalink / raw)
To: Doug Anderson
Cc: Cong Yang, benjamin.tissoires, devicetree, hsinyi, jikos,
linux-input, linux-kernel, mka
In-Reply-To: <CAD=FV=Xpe=zOeq2pG17Q0n_SZZHAFmaE+6C=SnuHqnHN6uObog@mail.gmail.com>
On Mon, May 22, 2023 at 08:27:38AM -0700, Doug Anderson wrote:
> Hi,
>
> On Fri, May 19, 2023 at 10:07 PM Cong Yang
> <yangcong5@huaqin.corp-partner.google.com> wrote:
> >
> > The ili9882t is a TDDI IC ((Touch with Display Driver)). It requires the
> > panel reset gpio to be high before i2c commands. Use a longer delay in
> > post_power_delay_ms to ensure the poweron sequence.
> >
> > Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com>
> > ---
> > drivers/hid/i2c-hid/i2c-hid-of-elan.c | 7 +++++++
> > 1 file changed, 7 insertions(+)
>
> This seems OK to me. The one thing I'd also do is to update the
> Kconfig description to say that this driver is also used for Ilitek. I
> think it's fine to keep the symbol name as I2C_HID_OF_ELAN but just
> change the description.
Does ilitek have the same set of regulators, etc, or is it only the
timing? I'd probably make it a separate mini-driver...
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [v2 2/2] dt-bindings: input: touchscreen: Add ilitek 9882T touchscreen chip
From: Doug Anderson @ 2023-05-30 16:58 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Cong Yang, benjamin.tissoires, devicetree, dmitry.torokhov,
hsinyi, jikos, linux-input, linux-kernel, mka, Rob Herring,
Conor Dooley
In-Reply-To: <bd19f71b-59ee-80e7-9ff1-1cc26ecc49a7@kernel.org>
Hi,
On Tue, May 30, 2023 at 4:56 AM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 22/05/2023 17:33, Doug Anderson wrote:
> > Hi,
> >
> > On Fri, May 19, 2023 at 10:07 PM Cong Yang
> > <yangcong5@huaqin.corp-partner.google.com> wrote:
> >>
> >> Add an ilitek touch screen chip ili9882t.
> >>
> >> Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com>
> >> ---
> >> .../devicetree/bindings/input/elan,ekth6915.yaml | 9 +++++++--
> >> 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > I'm curious about the DT maintainers opinion here. Should this be a
> > new bindings file, or should it be together in the elan file. If
> > nothing else, I think the secondary voltage rail name is wrong. I took
> > a quick peek at a datasheet I found and I don't even see a 3.3V rail
> > going to the ili9882t. That makes it weird to reuse "vcc33-supply" for
> > a second supply...
>
> It's easier if they are CCed...
Crud. I just assumed and didn't check the CC list. Cong: can you
resend and make sure you're CCing the people that get_maintainers
points at. One way to find that would be:
./scripts/get_maintainer.pl -f
Documentation/devicetree/bindings/input/elan,ekth6915.yaml
^ permalink raw reply
* Re: [PATCH 1/9] dt-bindings: HID: i2c-hid: Add "panel" property to i2c-hid backed panels
From: Doug Anderson @ 2023-05-30 16:52 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Jiri Kosina, Benjamin Tissoires, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Sam Ravnborg, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
dri-devel, linux-input, Dmitry Torokhov, hsinyi, devicetree,
yangcong5, linux-kernel, Daniel Vetter, linux-arm-msm,
cros-qcom-dts-watchers
In-Reply-To: <10457cab-f9b0-c38b-9f11-36853b71c7e8@linaro.org>
Hi,
On Tue, May 30, 2023 at 8:34 AM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 23/05/2023 21:27, Douglas Anderson wrote:
> > As talked about in the patch ("drm/panel: Add a way for other devices
> > to follow panel state"), touchscreens that are connected to panels are
> > generally expected to be power sequenced together with the panel
> > they're attached to. Today, nothing provides information allowing you
> > to find out that a touchscreen is connected to a panel. Let's add a
> > phandle for this.
> >
> > Signed-off-by: Douglas Anderson <dianders@chromium.org>
> > ---
> >
> > Documentation/devicetree/bindings/input/elan,ekth6915.yaml | 6 ++++++
> > Documentation/devicetree/bindings/input/goodix,gt7375p.yaml | 6 ++++++
> > Documentation/devicetree/bindings/input/hid-over-i2c.yaml | 6 ++++++
> > 3 files changed, 18 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/input/elan,ekth6915.yaml b/Documentation/devicetree/bindings/input/elan,ekth6915.yaml
> > index 05e6f2df604c..d55b03bd3ec4 100644
> > --- a/Documentation/devicetree/bindings/input/elan,ekth6915.yaml
> > +++ b/Documentation/devicetree/bindings/input/elan,ekth6915.yaml
> > @@ -24,6 +24,12 @@ properties:
> > interrupts:
> > maxItems: 1
> >
> > + panel:
> > + description: If this is a touchscreen, the panel it's connected to. This
>
> Hm, can there be different setup? Touchscreen without panel? What would
> it be then?
For a touchscreen that's a discrete device (not sharing logic / power
rails with the panel) you'd just leave off the panel node like we've
always done. Assuming folks like this series in general, I'll try to
improve the wording for v2.
> Why only these touchscreens? This looks generic, so maybe in
> touchscreen.yaml?
Ah, that makes sense. I guess we need to add an include of that file
from the elan and goodix bindings. The hid-over-i2c.yaml already has
it, though. I'm not 100% sure the existing "hid-over-i2c" driver in
Linux actually calls the function to parse all those properties, but I
guess that's a Linux problem and not a DT bindings problem. ;-)
-Doug
^ permalink raw reply
* [PATCH v2] hid-wiimote-debug.c: Drop error checking for debugfs_create_file
From: Osama Muhammad @ 2023-05-30 15:42 UTC (permalink / raw)
To: david.rheinsberg, jikos, benjamin.tissoires
Cc: linux-input, linux-kernel, Osama Muhammad
This patch removes the error checking for debugfs_create_file
in hid-wiimote-debug.c.c. This is because the debugfs_create_file()
does not return NULL but an ERR_PTR after an error.
The DebugFS kernel API is developed in a way that the
caller can safely ignore the errors that occur during
the creation of DebugFS nodes.The debugfs Api handles
it gracefully. The check is unnecessary.
Link to the comment above debugfs_create_file:
https://elixir.bootlin.com/linux/latest/source/fs/debugfs/inode.c#L451
Signed-off-by: Osama Muhammad <osmtendev@gmail.com>
---
changes since v1
-In v1 the IS_ERR was used for error checking which is dropped now.
---
drivers/hid/hid-wiimote-debug.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/drivers/hid/hid-wiimote-debug.c b/drivers/hid/hid-wiimote-debug.c
index a99dcca2e099..00f9be55f148 100644
--- a/drivers/hid/hid-wiimote-debug.c
+++ b/drivers/hid/hid-wiimote-debug.c
@@ -173,7 +173,6 @@ int wiidebug_init(struct wiimote_data *wdata)
{
struct wiimote_debug *dbg;
unsigned long flags;
- int ret = -ENOMEM;
dbg = kzalloc(sizeof(*dbg), GFP_KERNEL);
if (!dbg)
@@ -183,13 +182,9 @@ int wiidebug_init(struct wiimote_data *wdata)
dbg->eeprom = debugfs_create_file("eeprom", S_IRUSR,
dbg->wdata->hdev->debug_dir, dbg, &wiidebug_eeprom_fops);
- if (!dbg->eeprom)
- goto err;
dbg->drm = debugfs_create_file("drm", S_IRUSR,
dbg->wdata->hdev->debug_dir, dbg, &wiidebug_drm_fops);
- if (!dbg->drm)
- goto err_drm;
spin_lock_irqsave(&wdata->state.lock, flags);
wdata->debug = dbg;
@@ -197,11 +192,6 @@ int wiidebug_init(struct wiimote_data *wdata)
return 0;
-err_drm:
- debugfs_remove(dbg->eeprom);
-err:
- kfree(dbg);
- return ret;
}
void wiidebug_deinit(struct wiimote_data *wdata)
--
2.34.1
^ permalink raw reply related
* [PATCH] HID: i2c-hid: Block a rogue device on ASUS TUF A16
From: Friedrich Vock @ 2023-05-30 15:40 UTC (permalink / raw)
To: linux-input; +Cc: Jiri Kosina, Benjamin Tissoires, Friedrich Vock
On these laptops, there seems to be a device that, when probed by
i2c-hid, constantly sends bogus interrupts and interferes with the
keyboard controller. When the device is enabled, it takes the keyboard
around 8 seconds to register that keys are being pressed or released.
Nothing I tried seemed to make the device work, and preventing the
device from being probed doesn't seem to break any functionality of
the laptop.
Signed-off-by: Friedrich Vock <friedrich.vock@gmx.de>
---
drivers/hid/i2c-hid/i2c-hid-core.c | 5 +++
drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c | 48 ++++++++++++++++++++++++
drivers/hid/i2c-hid/i2c-hid.h | 3 ++
3 files changed, 56 insertions(+)
diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c
index efbba0465eef..5f0686d058df 100644
--- a/drivers/hid/i2c-hid/i2c-hid-core.c
+++ b/drivers/hid/i2c-hid/i2c-hid-core.c
@@ -1035,6 +1035,11 @@ int i2c_hid_core_probe(struct i2c_client *client, struct i2chid_ops *ops,
ihid->quirks = i2c_hid_lookup_quirk(hid->vendor, hid->product);
+ if (i2c_hid_device_blocked(hid->vendor, hid->product)) {
+ ret = -ENODEV;
+ goto err_irq;
+ }
+
ret = hid_add_device(hid);
if (ret) {
if (ret != -ENODEV)
diff --git a/drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c b/drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c
index 210f17c3a0be..d2c2806b64b4 100644
--- a/drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c
+++ b/drivers/hid/i2c-hid/i2c-hid-dmi-quirks.c
@@ -440,6 +440,38 @@ static const struct dmi_system_id i2c_hid_dmi_quirk_table[] = {
{ } /* Terminate list */
};
+static const struct hid_device_id i2c_hid_blocked_ite_device = {
+ HID_DEVICE(BUS_I2C, HID_GROUP_GENERIC, USB_VENDOR_ID_ITE, 0x8051)
+};
+
+/*
+ * This list contains devices that can't be activated at all, for example
+ * because activating them breaks other important parts of the system.
+ */
+static const struct dmi_system_id i2c_hid_dmi_block_table[] = {
+ /*
+ * On ASUS TUF Gaming A16 laptops, there is a device that will make the
+ * keyboard controller stop working correctly and flood the CPU with bogus
+ * interrupts.
+ */
+ {
+ .ident = "ASUS TUF Gaming A16 (Ryzen 7 7735HS)",
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "FA617NS"),
+ },
+ .driver_data = (void *)&i2c_hid_blocked_ite_device,
+ },
+ {
+ .ident = "ASUS TUF Gaming A16 (Ryzen 9 7940HS)",
+ .matches = {
+ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "FA617XS"),
+ },
+ .driver_data = (void *)&i2c_hid_blocked_ite_device,
+ },
+ { } /* Terminate list */
+};
struct i2c_hid_desc *i2c_hid_get_dmi_i2c_hid_desc_override(uint8_t *i2c_name)
{
@@ -492,3 +524,19 @@ u32 i2c_hid_get_dmi_quirks(const u16 vendor, const u16 product)
return quirks;
}
+
+bool i2c_hid_device_blocked(const u16 vendor, const u16 product)
+{
+ const struct dmi_system_id *system_id =
+ dmi_first_match(i2c_hid_dmi_block_table);
+
+ if (system_id) {
+ const struct hid_device_id *device_id =
+ (struct hid_device_id *)(system_id->driver_data);
+
+ if (device_id && device_id->vendor == vendor &&
+ device_id->product == product)
+ return true;
+ }
+ return false;
+}
diff --git a/drivers/hid/i2c-hid/i2c-hid.h b/drivers/hid/i2c-hid/i2c-hid.h
index 2c7b66d5caa0..e17bdd758f39 100644
--- a/drivers/hid/i2c-hid/i2c-hid.h
+++ b/drivers/hid/i2c-hid/i2c-hid.h
@@ -10,6 +10,7 @@ struct i2c_hid_desc *i2c_hid_get_dmi_i2c_hid_desc_override(uint8_t *i2c_name);
char *i2c_hid_get_dmi_hid_report_desc_override(uint8_t *i2c_name,
unsigned int *size);
u32 i2c_hid_get_dmi_quirks(const u16 vendor, const u16 product);
+bool i2c_hid_device_blocked(const u16 vendor, const u16 product);
#else
static inline struct i2c_hid_desc
*i2c_hid_get_dmi_i2c_hid_desc_override(uint8_t *i2c_name)
@@ -19,6 +20,8 @@ static inline char *i2c_hid_get_dmi_hid_report_desc_override(uint8_t *i2c_name,
{ return NULL; }
static inline u32 i2c_hid_get_dmi_quirks(const u16 vendor, const u16 product)
{ return 0; }
+static inline bool i2c_hid_device_blocked(const u16 vendor, const u16 product)
+{ return false; }
#endif
/**
--
2.40.1
^ permalink raw reply related
* [PATCH] Input: i8042 - Add quirk for polling the KBD port
From: Friedrich Vock @ 2023-05-30 15:36 UTC (permalink / raw)
To: linux-input; +Cc: Dmitry Torokhov, Friedrich Vock
It seems like there are some devices in the ASUS TUF A16 laptops that
just don't send any keyboard interrupts until you read from the KBD port.
Signed-off-by: Friedrich Vock <friedrich.vock@gmx.de>
---
drivers/input/serio/i8042-acpipnpio.h | 30 +++++++++++++++--
drivers/input/serio/i8042.c | 47 ++++++++++++++++++++++-----
drivers/input/serio/i8042.h | 2 +-
3 files changed, 67 insertions(+), 12 deletions(-)
diff --git a/drivers/input/serio/i8042-acpipnpio.h b/drivers/input/serio/i8042-acpipnpio.h
index 028e45bd050b..be2e72aaa658 100644
--- a/drivers/input/serio/i8042-acpipnpio.h
+++ b/drivers/input/serio/i8042-acpipnpio.h
@@ -83,6 +83,7 @@ static inline void i8042_write_command(int val)
#define SERIO_QUIRK_KBDRESET BIT(12)
#define SERIO_QUIRK_DRITEK BIT(13)
#define SERIO_QUIRK_NOPNP BIT(14)
+#define SERIO_QUIRK_POLL_KBD BIT(15)
/* Quirk table for different mainboards. Options similar or identical to i8042
* module parameters.
@@ -99,6 +100,26 @@ static const struct dmi_system_id i8042_dmi_quirk_table[] __initconst = {
},
.driver_data = (void *)(SERIO_QUIRK_NOMUX)
},
+ /* Some laptops seem to not trigger any keyboard interrupts at all,
+ * even when there is data available. On these devices, manually
+ * polling the keyboard port is required.
+ */
+ {
+ /* ASUS TUF Gaming A16 with Ryzen 7 7735HS */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "FA617NS"),
+ },
+ .driver_data = (void *)(SERIO_QUIRK_POLL_KBD)
+ },
+ {
+ /* ASUS TUF Gaming A16 with Ryzen 9 7940HS */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "FA617XS"),
+ },
+ .driver_data = (void *)(SERIO_QUIRK_POLL_KBD)
+ },
{
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
@@ -1634,6 +1655,8 @@ static void __init i8042_check_quirks(void)
if (quirks & SERIO_QUIRK_NOPNP)
i8042_nopnp = true;
#endif
+ if (quirks & SERIO_QUIRK_POLL_KBD)
+ i8042_poll_kbd = true;
}
#else
static inline void i8042_check_quirks(void) {}
@@ -1667,7 +1690,7 @@ static int __init i8042_platform_init(void)
i8042_check_quirks();
- pr_debug("Active quirks (empty means none):%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
+ pr_debug("Active quirks (empty means none):%s%s%s%s%s%s%s%s%s%s%s%s%s%s\n",
i8042_nokbd ? " nokbd" : "",
i8042_noaux ? " noaux" : "",
i8042_nomux ? " nomux" : "",
@@ -1687,10 +1710,11 @@ static int __init i8042_platform_init(void)
"",
#endif
#ifdef CONFIG_PNP
- i8042_nopnp ? " nopnp" : "");
+ i8042_nopnp ? " nopnp" : "",
#else
- "");
+ "",
#endif
+ i8042_poll_kbd ? "poll_kbd" : "");
retval = i8042_pnp_init();
if (retval)
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index 6dac7c1853a5..7212263d3a41 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -115,6 +115,10 @@ module_param_named(nopnp, i8042_nopnp, bool, 0);
MODULE_PARM_DESC(nopnp, "Do not use PNP to detect controller settings");
#endif
+static bool i8042_poll_kbd;
+module_param_named(poll_kbd, i8042_poll_kbd, bool, 0);
+MODULE_PARM_DESC(poll_kbd, "Continuously poll the KBD port instead of relying on interrupts");
+
#define DEBUG
#ifdef DEBUG
static bool i8042_debug;
@@ -178,6 +182,24 @@ static irqreturn_t i8042_interrupt(int irq, void *dev_id);
static bool (*i8042_platform_filter)(unsigned char data, unsigned char str,
struct serio *serio);
+#define POLL_TIME 1
+static void i8042_poll_func(struct timer_list *timer)
+{
+ unsigned char status;
+ unsigned long flags;
+
+ do {
+ spin_lock_irqsave(&i8042_lock, flags);
+ status = i8042_read_status();
+ spin_unlock_irqrestore(&i8042_lock, flags);
+ if (status & I8042_STR_OBF)
+ i8042_interrupt(0, NULL);
+ } while (status & I8042_STR_OBF);
+ mod_timer(timer, jiffies + msecs_to_jiffies(POLL_TIME));
+}
+
+DEFINE_TIMER(poll_timer, i8042_poll_func);
+
void i8042_lock_chip(void)
{
mutex_lock(&i8042_mutex);
@@ -1437,13 +1459,15 @@ static void i8042_unregister_ports(void)
}
}
+
static void i8042_free_irqs(void)
{
if (i8042_aux_irq_registered)
free_irq(I8042_AUX_IRQ, i8042_platform_device);
- if (i8042_kbd_irq_registered)
+ if (i8042_poll_kbd)
+ del_timer(&poll_timer);
+ else if (i8042_kbd_irq_registered)
free_irq(I8042_KBD_IRQ, i8042_platform_device);
-
i8042_aux_irq_registered = i8042_kbd_irq_registered = false;
}
@@ -1497,10 +1521,14 @@ static int i8042_setup_kbd(void)
if (error)
return error;
- error = request_irq(I8042_KBD_IRQ, i8042_interrupt, IRQF_SHARED,
- "i8042", i8042_platform_device);
- if (error)
- goto err_free_port;
+ if (i8042_poll_kbd)
+ mod_timer(&poll_timer, msecs_to_jiffies(POLL_TIME));
+ else {
+ error = request_irq(I8042_KBD_IRQ, i8042_interrupt, IRQF_SHARED,
+ "i8042", i8042_platform_device);
+ if (error)
+ goto err_free_port;
+ }
error = i8042_enable_kbd_port();
if (error)
@@ -1510,8 +1538,11 @@ static int i8042_setup_kbd(void)
return 0;
err_free_irq:
- free_irq(I8042_KBD_IRQ, i8042_platform_device);
- err_free_port:
+ if (i8042_poll_kbd)
+ del_timer(&poll_timer);
+ else
+ free_irq(I8042_KBD_IRQ, i8042_platform_device);
+err_free_port:
i8042_free_kbd_port();
return error;
}
--
2.40.1
^ permalink raw reply related
* Re: [PATCH 1/9] dt-bindings: HID: i2c-hid: Add "panel" property to i2c-hid backed panels
From: Krzysztof Kozlowski @ 2023-05-30 15:34 UTC (permalink / raw)
To: Douglas Anderson, Jiri Kosina, Benjamin Tissoires,
Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Sam Ravnborg, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann
Cc: dri-devel, linux-input, Dmitry Torokhov, hsinyi, devicetree,
yangcong5, linux-kernel, Daniel Vetter, linux-arm-msm,
cros-qcom-dts-watchers
In-Reply-To: <20230523122802.1.Id68e30343bb1e11470582a9078b086176cfec46b@changeid>
On 23/05/2023 21:27, Douglas Anderson wrote:
> As talked about in the patch ("drm/panel: Add a way for other devices
> to follow panel state"), touchscreens that are connected to panels are
> generally expected to be power sequenced together with the panel
> they're attached to. Today, nothing provides information allowing you
> to find out that a touchscreen is connected to a panel. Let's add a
> phandle for this.
>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> ---
>
> Documentation/devicetree/bindings/input/elan,ekth6915.yaml | 6 ++++++
> Documentation/devicetree/bindings/input/goodix,gt7375p.yaml | 6 ++++++
> Documentation/devicetree/bindings/input/hid-over-i2c.yaml | 6 ++++++
> 3 files changed, 18 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/elan,ekth6915.yaml b/Documentation/devicetree/bindings/input/elan,ekth6915.yaml
> index 05e6f2df604c..d55b03bd3ec4 100644
> --- a/Documentation/devicetree/bindings/input/elan,ekth6915.yaml
> +++ b/Documentation/devicetree/bindings/input/elan,ekth6915.yaml
> @@ -24,6 +24,12 @@ properties:
> interrupts:
> maxItems: 1
>
> + panel:
> + description: If this is a touchscreen, the panel it's connected to. This
Hm, can there be different setup? Touchscreen without panel? What would
it be then?
Why only these touchscreens? This looks generic, so maybe in
touchscreen.yaml?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] input: Add new keyboard backlight control keys to match modern notebooks
From: Werner Sembach @ 2023-05-30 15:30 UTC (permalink / raw)
To: Dmitry Torokhov, Bastien Nocera; +Cc: linux-input, linux-kernel
In-Reply-To: <20230530110550.18289-1-wse@tuxedocomputers.com>
Am 30.05.23 um 13:05 schrieb Werner Sembach:
> The old three KEY_KBDILLUM* keycodes don't reflect the current situation
> modern notebooks anymore. Especially the ones with RGB keyboards.
>
> e.g.
> - Clevo NL50NU has a toggle, an up, a down and a color-cycle key
> - TongFang PH4ARX1 doesn't have a toggle key, but one that cycles through
> off, half-brightness, and full-brightness.
>
> Also, on some devices these keys are already implemented in firmware. It
> would still be nice if there is a way to let userspace know when one of
> these keys is pressed to display the OSD, but don't advice it to actually
> do anything. This is the intended purpose of the KEY_KBDILLUMCHANGE define.
Nevermind the KEY_KBDILLUMCHANGE. I just found out there is already a way to
communicate this from kernel to userspace via sysfs
https://docs.kernel.org/leds/leds-class.html#led-registration-api ->
brightness_hw_changed
>
> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> ---
> include/uapi/linux/input-event-codes.h | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
> index 022a520e31fc2..05287bf9a77f7 100644
> --- a/include/uapi/linux/input-event-codes.h
> +++ b/include/uapi/linux/input-event-codes.h
> @@ -803,6 +803,10 @@
> #define BTN_TRIGGER_HAPPY39 0x2e6
> #define BTN_TRIGGER_HAPPY40 0x2e7
>
> +#define KEY_KBDILLUMCYCLE 0x2e8
> +#define KEY_KBDILLUMCOLORCYCLE 0x2e9
> +#define KEY_KBDILLUMCHANGE 0x2ea
> +
> /* We avoid low common keys in module aliases so they don't get huge. */
> #define KEY_MIN_INTERESTING KEY_MUTE
> #define KEY_MAX 0x2ff
^ permalink raw reply
* Re: [PATCH] input: Add new keyboard backlight control keys to match modern notebooks
From: Werner Sembach @ 2023-05-30 14:49 UTC (permalink / raw)
To: Bastien Nocera, Dmitry Torokhov; +Cc: linux-input, linux-kernel
In-Reply-To: <44574d05-3a2a-2249-b808-7e929feea36d@tuxedocomputers.com>
Am 30.05.23 um 16:28 schrieb Werner Sembach:
> Hi,
>
> Am 30.05.23 um 15:33 schrieb Bastien Nocera:
>> On Tue, 2023-05-30 at 13:05 +0200, Werner Sembach wrote:
>>> The old three KEY_KBDILLUM* keycodes don't reflect the current
>>> situation
>>> modern notebooks anymore. Especially the ones with RGB keyboards.
>>>
>>> e.g.
>>> - Clevo NL50NU has a toggle, an up, a down and a color-cycle key
>>> - TongFang PH4ARX1 doesn't have a toggle key, but one that cycles
>>> through
>>> off, half-brightness, and full-brightness.
>>>
>>> Also, on some devices these keys are already implemented in firmware.
>>> It
>>> would still be nice if there is a way to let userspace know when one
>>> of
>>> these keys is pressed to display the OSD, but don't advice it to
>>> actually
>>> do anything. This is the intended purpose of the KEY_KBDILLUMCHANGE
>>> define.
>>>
>>> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
>> Can you please point to the user-space patches (or issues filed) that
>> would integrate the support for those keycodes, and make the key
>> presses do something?
>
> I'm sorry to say that these don't exist yet. So I guess the process is similar
> to DRM uAPI additions?
> https://docs.kernel.org/gpu/drm-uapi.html#open-source-userspace-requirements
I asked the KDE and Gnome maintainers for feedback:
https://bugs.kde.org/show_bug.cgi?id=470453
https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/issues/746
>
>>
>> Has anyone tested that those keycodes are fit for purpose when mixed
>> with other brightness changes that don't happen through key presses?
>
> Color control is not yet implemented in any DE afaik, so there is not yet a
> collision with the color cycle key.
>
> For the brightness cycle key, I would assume that it functions the same as the
> brightness up key unless brightness == brightness max. In this case it sets
> brightness to 0. I don't see a logical collision here as brightness up and
> brightness down are already implemented just fine in most DEs
>
>>
>>> ---
>>> include/uapi/linux/input-event-codes.h | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/include/uapi/linux/input-event-codes.h
>>> b/include/uapi/linux/input-event-codes.h
>>> index 022a520e31fc2..05287bf9a77f7 100644
>>> --- a/include/uapi/linux/input-event-codes.h
>>> +++ b/include/uapi/linux/input-event-codes.h
>>> @@ -803,6 +803,10 @@
>>> #define BTN_TRIGGER_HAPPY39 0x2e6
>>> #define BTN_TRIGGER_HAPPY40 0x2e7
>>> +#define KEY_KBDILLUMCYCLE 0x2e8
>>> +#define KEY_KBDILLUMCOLORCYCLE 0x2e9
>>> +#define KEY_KBDILLUMCHANGE 0x2ea
>>> +
>>> /* We avoid low common keys in module aliases so they don't get
>>> huge. */
>>> #define KEY_MIN_INTERESTING KEY_MUTE
>>> #define KEY_MAX 0x2ff
^ permalink raw reply
* [PATCH v2] HID: logitech-hidpp: Add USB and Bluetooth IDs for the Logitech G915 TKL Keyboard
From: Stuart Hayhurst @ 2023-05-30 14:44 UTC (permalink / raw)
Cc: stuarthayhurst, jikos, Filipe Laíns, Benjamin Tissoires,
linux-input, linux-kernel, Bastien Nocera
From: stuarthayhurst <stuart.a.hayhurst@gmail.com>
Adds the USB and Bluetooth IDs for the Logitech G915 TKL keyboard, for device detection
For this device, this provides battery reporting on top of hid-generic
Reviewed-by: Bastien Nocera <hadess@hadess.net>
Signed-off-by: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
---
drivers/hid/hid-logitech-hidpp.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index b2cd7527de19..28761272afe5 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -4403,6 +4403,8 @@ static const struct hid_device_id hidpp_devices[] = {
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC086) },
{ /* Logitech G903 Hero Gaming Mouse over USB */
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC091) },
+ { /* Logitech G915 TKL Keyboard over USB */
+ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC343) },
{ /* Logitech G920 Wheel over USB */
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_G920_WHEEL),
.driver_data = HIDPP_QUIRK_CLASS_G920 | HIDPP_QUIRK_FORCE_OUTPUT_REPORTS},
@@ -4418,6 +4420,8 @@ static const struct hid_device_id hidpp_devices[] = {
{ /* MX5500 keyboard over Bluetooth */
HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb30b),
.driver_data = HIDPP_QUIRK_HIDPP_CONSUMER_VENDOR_KEYS },
+ { /* Logitech G915 TKL keyboard over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb35f) },
{ /* M-RCQ142 V470 Cordless Laser Mouse over Bluetooth */
HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb008) },
{ /* MX Master mouse over Bluetooth */
--
2.40.1.521.gf1e218fcd8
^ permalink raw reply related
* Re: [PATCH 1/1] HID: logitech-hidpp: Add USB and Bluetooth IDs for the Logitech G915 TKL Keyboard
From: Stuart @ 2023-05-30 14:40 UTC (permalink / raw)
To: Bastien Nocera
Cc: jikos, Filipe Laíns, Benjamin Tissoires, linux-input,
linux-kernel
In-Reply-To: <8d3ba2cf2bf09af9e15a1453212d68bfd41f9399.camel@hadess.net>
Oops, didn't realise it needed a v2, sorry.
Thanks,
Stuart
On Tue, May 30, 2023 at 3:33 PM Bastien Nocera <hadess@hadess.net> wrote:
>
> On Tue, 2023-05-30 at 15:16 +0100, Stuart Hayhurst wrote:
> > Adds the USB and Bluetooth IDs for the Logitech G915 TKL keyboard,
> > for device detection
> > For this device, this provides battery reporting on top of hid-
> > generic
> >
> > Signed-off-by: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
>
> You can add my:
>
> Reviewed-by: Bastien Nocera <hadess@hadess.net>
>
> to the v2 patch that you should send, otherwise the tree maintainers
> will get confused.
>
> Cheers
>
> > ---
> > drivers/hid/hid-logitech-hidpp.c | 4 ++++
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-
> > logitech-hidpp.c
> > index b2cd7527de19..28761272afe5 100644
> > --- a/drivers/hid/hid-logitech-hidpp.c
> > +++ b/drivers/hid/hid-logitech-hidpp.c
> > @@ -4403,6 +4403,8 @@ static const struct hid_device_id
> > hidpp_devices[] = {
> > HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC086) },
> > { /* Logitech G903 Hero Gaming Mouse over USB */
> > HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC091) },
> > + { /* Logitech G915 TKL Keyboard over USB */
> > + HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC343) },
> > { /* Logitech G920 Wheel over USB */
> > HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
> > USB_DEVICE_ID_LOGITECH_G920_WHEEL),
> > .driver_data = HIDPP_QUIRK_CLASS_G920 |
> > HIDPP_QUIRK_FORCE_OUTPUT_REPORTS},
> > @@ -4418,6 +4420,8 @@ static const struct hid_device_id
> > hidpp_devices[] = {
> > { /* MX5500 keyboard over Bluetooth */
> > HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb30b),
> > .driver_data = HIDPP_QUIRK_HIDPP_CONSUMER_VENDOR_KEYS },
> > + { /* Logitech G915 TKL keyboard over Bluetooth */
> > + HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb35f) },
> > { /* M-RCQ142 V470 Cordless Laser Mouse over Bluetooth */
> > HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb008) },
> > { /* MX Master mouse over Bluetooth */
>
^ permalink raw reply
* Re: [PATCH 1/1] HID: logitech-hidpp: Add USB and Bluetooth IDs for the Logitech G915 TKL Keyboard
From: Bastien Nocera @ 2023-05-30 14:33 UTC (permalink / raw)
To: Stuart Hayhurst
Cc: jikos, Filipe Laíns, Benjamin Tissoires, linux-input,
linux-kernel
In-Reply-To: <20230530141628.21290-1-stuart.a.hayhurst@gmail.com>
On Tue, 2023-05-30 at 15:16 +0100, Stuart Hayhurst wrote:
> Adds the USB and Bluetooth IDs for the Logitech G915 TKL keyboard,
> for device detection
> For this device, this provides battery reporting on top of hid-
> generic
>
> Signed-off-by: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
You can add my:
Reviewed-by: Bastien Nocera <hadess@hadess.net>
to the v2 patch that you should send, otherwise the tree maintainers
will get confused.
Cheers
> ---
> drivers/hid/hid-logitech-hidpp.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-
> logitech-hidpp.c
> index b2cd7527de19..28761272afe5 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -4403,6 +4403,8 @@ static const struct hid_device_id
> hidpp_devices[] = {
> HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC086) },
> { /* Logitech G903 Hero Gaming Mouse over USB */
> HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC091) },
> + { /* Logitech G915 TKL Keyboard over USB */
> + HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC343) },
> { /* Logitech G920 Wheel over USB */
> HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH,
> USB_DEVICE_ID_LOGITECH_G920_WHEEL),
> .driver_data = HIDPP_QUIRK_CLASS_G920 |
> HIDPP_QUIRK_FORCE_OUTPUT_REPORTS},
> @@ -4418,6 +4420,8 @@ static const struct hid_device_id
> hidpp_devices[] = {
> { /* MX5500 keyboard over Bluetooth */
> HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb30b),
> .driver_data = HIDPP_QUIRK_HIDPP_CONSUMER_VENDOR_KEYS },
> + { /* Logitech G915 TKL keyboard over Bluetooth */
> + HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb35f) },
> { /* M-RCQ142 V470 Cordless Laser Mouse over Bluetooth */
> HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb008) },
> { /* MX Master mouse over Bluetooth */
^ permalink raw reply
* Re: [PATCH] input: Add new keyboard backlight control keys to match modern notebooks
From: Werner Sembach @ 2023-05-30 14:28 UTC (permalink / raw)
To: Bastien Nocera, Dmitry Torokhov; +Cc: linux-input, linux-kernel
In-Reply-To: <d4d6eb1da42de6536e708331100fc33e9cfae140.camel@hadess.net>
Hi,
Am 30.05.23 um 15:33 schrieb Bastien Nocera:
> On Tue, 2023-05-30 at 13:05 +0200, Werner Sembach wrote:
>> The old three KEY_KBDILLUM* keycodes don't reflect the current
>> situation
>> modern notebooks anymore. Especially the ones with RGB keyboards.
>>
>> e.g.
>> - Clevo NL50NU has a toggle, an up, a down and a color-cycle key
>> - TongFang PH4ARX1 doesn't have a toggle key, but one that cycles
>> through
>> off, half-brightness, and full-brightness.
>>
>> Also, on some devices these keys are already implemented in firmware.
>> It
>> would still be nice if there is a way to let userspace know when one
>> of
>> these keys is pressed to display the OSD, but don't advice it to
>> actually
>> do anything. This is the intended purpose of the KEY_KBDILLUMCHANGE
>> define.
>>
>> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
> Can you please point to the user-space patches (or issues filed) that
> would integrate the support for those keycodes, and make the key
> presses do something?
I'm sorry to say that these don't exist yet. So I guess the process is similar
to DRM uAPI additions?
https://docs.kernel.org/gpu/drm-uapi.html#open-source-userspace-requirements
>
> Has anyone tested that those keycodes are fit for purpose when mixed
> with other brightness changes that don't happen through key presses?
Color control is not yet implemented in any DE afaik, so there is not yet a
collision with the color cycle key.
For the brightness cycle key, I would assume that it functions the same as the
brightness up key unless brightness == brightness max. In this case it sets
brightness to 0. I don't see a logical collision here as brightness up and
brightness down are already implemented just fine in most DEs
>
>> ---
>> include/uapi/linux/input-event-codes.h | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/include/uapi/linux/input-event-codes.h
>> b/include/uapi/linux/input-event-codes.h
>> index 022a520e31fc2..05287bf9a77f7 100644
>> --- a/include/uapi/linux/input-event-codes.h
>> +++ b/include/uapi/linux/input-event-codes.h
>> @@ -803,6 +803,10 @@
>> #define BTN_TRIGGER_HAPPY39 0x2e6
>> #define BTN_TRIGGER_HAPPY40 0x2e7
>>
>> +#define KEY_KBDILLUMCYCLE 0x2e8
>> +#define KEY_KBDILLUMCOLORCYCLE 0x2e9
>> +#define KEY_KBDILLUMCHANGE 0x2ea
>> +
>> /* We avoid low common keys in module aliases so they don't get
>> huge. */
>> #define KEY_MIN_INTERESTING KEY_MUTE
>> #define KEY_MAX 0x2ff
^ permalink raw reply
* [PATCH 1/1] HID: logitech-hidpp: Add USB and Bluetooth IDs for the Logitech G915 TKL Keyboard
From: Stuart Hayhurst @ 2023-05-30 14:16 UTC (permalink / raw)
To: Bastien Nocera
Cc: Stuart Hayhurst, jikos, Filipe Laíns, Benjamin Tissoires,
linux-input, linux-kernel
In-Reply-To: <f395a434756b7f35336b541cdbdb61ef5b6fe0b1.camel@hadess.net>
Adds the USB and Bluetooth IDs for the Logitech G915 TKL keyboard, for device detection
For this device, this provides battery reporting on top of hid-generic
Signed-off-by: Stuart Hayhurst <stuart.a.hayhurst@gmail.com>
---
drivers/hid/hid-logitech-hidpp.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index b2cd7527de19..28761272afe5 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -4403,6 +4403,8 @@ static const struct hid_device_id hidpp_devices[] = {
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC086) },
{ /* Logitech G903 Hero Gaming Mouse over USB */
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC091) },
+ { /* Logitech G915 TKL Keyboard over USB */
+ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, 0xC343) },
{ /* Logitech G920 Wheel over USB */
HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_LOGITECH_G920_WHEEL),
.driver_data = HIDPP_QUIRK_CLASS_G920 | HIDPP_QUIRK_FORCE_OUTPUT_REPORTS},
@@ -4418,6 +4420,8 @@ static const struct hid_device_id hidpp_devices[] = {
{ /* MX5500 keyboard over Bluetooth */
HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb30b),
.driver_data = HIDPP_QUIRK_HIDPP_CONSUMER_VENDOR_KEYS },
+ { /* Logitech G915 TKL keyboard over Bluetooth */
+ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb35f) },
{ /* M-RCQ142 V470 Cordless Laser Mouse over Bluetooth */
HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb008) },
{ /* MX Master mouse over Bluetooth */
--
2.40.1.521.gf1e218fcd8
^ permalink raw reply related
* Re: Breaking change in st1232 multitouch support
From: Mark Brown @ 2023-05-30 14:02 UTC (permalink / raw)
To: Matthias Schiffer
Cc: Dmitry Torokhov, Martin Kepplinger, Henrik Rydberg, linux-input,
linux-kernel, linux
In-Reply-To: <b1ef61f5121149278b66d4cea99ba02b517fb0c9.camel@ew.tq-group.com>
[-- Attachment #1: Type: text/plain, Size: 456 bytes --]
On Tue, May 30, 2023 at 03:59:34PM +0200, Matthias Schiffer wrote:
> Adding Mark Brown to cc as a somewhat recent committer to a DTS that
> references the "sitronix,st1232" compatible (imx6qdl-udoo), in the hope
> that he has a matching display and could verify that multitouch is
> indeed broken with recent kernels.
It's sitting in a CI farm and I never physically interact with it - I
think the display is an optional extra which I don't have anyway.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Breaking change in st1232 multitouch support
From: Matthias Schiffer @ 2023-05-30 13:59 UTC (permalink / raw)
To: Dmitry Torokhov, Martin Kepplinger
Cc: Henrik Rydberg, linux-input, linux-kernel, linux, Mark Brown
Hi everyone,
I've found that something strange has happened in the ST1232 driver:
Through Martin's patch that was supposed to add support for the ST1633
(commit 351e059 "Input: st1232 - add support for st1633") and a number
of subsequent fixes (b1a402e, 95c9ea9), the driver has come to not
actually support the ST1232 anymore, as the older ST1232/ST1332 and the
newer models (ST1633, various other) seem to have incompatible register
maps.
[1] shows the original register map, which assigns 3 registers to each
finger (0x12-0x14, 0x15-0x17), while [2] describes a different map
where 4 subsequent registers are assigned to each finger.
[2] does list "ST1x32" as a supported part though, but I'm not sure if
this is not supposed to include ST1232/ST1332, or if there was a
firmware update at some point that changed the register assignment.
If this breaking change was unintended, should the change be reverted
partially, so the code matches the ST1232/ST1332 datasheet again for
the "sitronix,st1232" compatible, and the new code is only used for
"sitronix,st1633"?
Adding Mark Brown to cc as a somewhat recent committer to a DTS that
references the "sitronix,st1232" compatible (imx6qdl-udoo), in the hope
that he has a matching display and could verify that multitouch is
indeed broken with recent kernels.
[1]
https://www.displayfuture.com/Display/datasheet/controller/ST1332.pdf
[2]
https://www.crystalfontz.com/products/document/4590/Sitronix_Touch_IC_Protocol_A_V2.7.pdf
Kind regards,
Matthias
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
^ permalink raw reply
* [PATCH] HID: HP: add support for 03f0:464a HP Elite Presenter Mouse
From: Marco Morandini @ 2023-05-30 13:40 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires, linux-input
HP Elite Presenter Mouse HID Record Descriptor shows
two mouses (Repord ID 0x1 and 0x2), one keypad (Report ID 0x5),
two Consumer Controls (Report IDs 0x6 and 0x3).
Previous to this commit it registers one mouse, one keypad
and one Consumer Control, and it was usable only as a
digitl laser pointer (one of the two mouses). This patch defines
the 464a USB device ID and enables the HID_QUIRK_MULTI_INPUT
quirk for it, allowing to use the device both as a mouse
and a digital laser pointer.
Signed-off-by: Marco Morandini <marco.morandini@polimi.it>
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-quirks.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index d79e946acdcb..8afa1149cdf2 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -619,6 +619,7 @@
#define USB_DEVICE_ID_UGCI_FIGHTING 0x0030
#define USB_VENDOR_ID_HP 0x03f0
+#define USB_PRODUCT_ID_HP_ELITE_PRESENTER_MOUSE_464A 0x464a
#define USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0A4A 0x0a4a
#define USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0B4A 0x0b4a
#define USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE 0x134a
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 804fc03600cc..3983b4f282f8 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -96,6 +96,7 @@ static const struct hid_device_id hid_quirks[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_HOLTEK_ALT, USB_DEVICE_ID_HOLTEK_ALT_KEYBOARD_A096), HID_QUIRK_NO_INIT_REPORTS },
{ HID_USB_DEVICE(USB_VENDOR_ID_HOLTEK_ALT, USB_DEVICE_ID_HOLTEK_ALT_KEYBOARD_A293), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0A4A), HID_QUIRK_ALWAYS_POLL },
+ { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_ELITE_PRESENTER_MOUSE_464A), HID_QUIRK_MULTI_INPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_LOGITECH_OEM_USB_OPTICAL_MOUSE_0B4A), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_HP, USB_PRODUCT_ID_HP_PIXART_OEM_USB_OPTICAL_MOUSE_094A), HID_QUIRK_ALWAYS_POLL },
--
2.40.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox