* Re: [PATCH] HID: core: do not allow parsing 0-sized reports
From: Jiri Kosina @ 2026-04-09 16:00 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Benjamin Tissoires, Peter Hutterer, Kees Cook, Alan Stern,
Charles Keepax, linux-input, linux-kernel
In-Reply-To: <acy1QWcu-yfd_kAu@google.com>
On Tue, 31 Mar 2026, Dmitry Torokhov wrote:
> Commit d7db259bd6df ("HID: core: factor out hid_parse_collections()")
> reworked collection parsing code and inadvertently allowed returning
> "success" when parsing 0-sized reports where old code returned -EINVAL.
Ah, good catch, I've missed that.
Applied on top, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: usbhid: refactor endpoint lookup
From: Jiri Kosina @ 2026-04-09 15:58 UTC (permalink / raw)
To: Johan Hovold; +Cc: Benjamin Tissoires, linux-usb, linux-input, linux-kernel
In-Reply-To: <20260330095034.1662231-1-johan@kernel.org>
On Mon, 30 Mar 2026, Johan Hovold wrote:
> Use the common USB helper for looking up interrupt-in endpoints instead
> of open coding.
Good catch, thanks Johan. Now applied to hid.git#for-7.1/core-v2.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: huawei: fix CD30 keyboard report descriptor issue
From: Jiri Kosina @ 2026-04-09 15:57 UTC (permalink / raw)
To: Miao Li; +Cc: bentiss, linux-input, linux-kernel, Miao Li
In-Reply-To: <20260318091249.217283-1-limiao870622@163.com>
On Wed, 18 Mar 2026, Miao Li wrote:
> From: Miao Li <limiao@kylinos.cn>
>
> When the Huawei CD30 USB keyboard undergoes 500 reboot cycles,
> initialization may fail due to a report descriptor problem.
Oh wow, that's a novelty I think.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: playstation: validate num_touch_reports in DualShock 4 reports
From: Jiri Kosina @ 2026-04-09 15:55 UTC (permalink / raw)
To: FirstName LastName
Cc: Roderick Colenbrander, Benjamin Tissoires, linux-input,
linux-kernel
In-Reply-To: <20260323124737.3223129-1-bsevens@google.com>
Dear FirstName LastName,
there seems to be a way to fix in your mail setup configuration :)
On Mon, 23 Mar 2026, FirstName LastName wrote:
> From: Beno=C3=AEt Sevens <bsevens@google.com>
>
> The DualShock 4 HID driver fails to validate the num_touch_reports field
> received from the device in both USB and Bluetooth input reports.
> A malicious device could set this field to a value larger than the
> allocated size of the touch_reports array (3 for USB, 4 for Bluetooth),
> leading to an out-of-bounds read in dualshock4_parse_report().
>
> This can result in kernel memory disclosure when processing malicious
> HID reports.
>
> Validate num_touch_reports against the array size for the respective
> connection types before processing the touch data.
>
> Signed-off-by: Beno=C3=AEt Sevens <bsevens@google.com>
Applied now to hid.git#for-7.0/upstream-fixes, thanks!
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: drop 'default !EXPERT' from tristate symbols
From: Jiri Kosina @ 2026-04-09 15:53 UTC (permalink / raw)
To: Thomas Weißschuh; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260321-hid-expert-v1-1-4a6d81b4f3ac@weissschuh.net>
On Sat, 21 Mar 2026, Thomas Weißschuh wrote:
> There is no reason to build random drivers for obscure hardware into the
> core kernel by default.
This is from the time when invididual drivers have been extracted from
monolithing hid.o, and there was a general fear that it would cause
regressions for people, because the generic driver wouldn't work any more
and they'd have to look for fixing that by enabling particular driver.
That ship has sailed ages ago though, so I agree we could just remove it.
> The usages of 'default !EXPERT' for the HID_PICOLCD suboptions are kept,
> as these make some sense, although they probably should use 'default y'.
There are very few fans of 'default y' :)
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: ft260: validate report size and payload length in raw_event
From: Jiri Kosina @ 2026-04-09 15:50 UTC (permalink / raw)
To: Sebastian Josue Alba Vives
Cc: michael.zaidman, Benjamin Tissoires, linux-i2c, linux-input,
linux-kernel, stable
In-Reply-To: <20260324201858.46591-1-sebasjosue84@gmail.com>
On Tue, 24 Mar 2026, Sebastian Josue Alba Vives wrote:
> ft260_raw_event() casts the raw data buffer to a
> ft260_i2c_input_report struct and accesses its fields without
> validating the size parameter. Since __hid_input_report() invokes
> the driver's raw_event callback before hid_report_raw_event()
> performs its own report-size validation, a device sending a
> truncated HID report can cause out-of-bounds heap reads.
>
> Additionally, even with a full-sized report, a corrupted
> xfer->length field can cause memcpy to read beyond the report
> buffer. The existing check only validates against the destination
> buffer size, not the source data available in the report.
>
> Add two checks: reject reports shorter than FT260_REPORT_MAX_LENGTH,
> and verify that xfer->length does not exceed the actual data
> available in the report. Log warnings to aid debugging.
>
> Cc: stable@vger.kernel.org
> Signed-off-by: Sebastian Josue Alba Vives <sebasjosue84@gmail.com>
> ---
> drivers/hid/hid-ft260.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/hid/hid-ft260.c b/drivers/hid/hid-ft260.c
> index 333341e80..68008a423 100644
> --- a/drivers/hid/hid-ft260.c
> +++ b/drivers/hid/hid-ft260.c
> @@ -1068,6 +1068,17 @@ static int ft260_raw_event(struct hid_device *hdev, struct hid_report *report,
> struct ft260_device *dev = hid_get_drvdata(hdev);
> struct ft260_i2c_input_report *xfer = (void *)data;
>
> + if (size < FT260_REPORT_MAX_LENGTH) {
> + hid_warn(hdev, "short report: %d\n", size);
> + return 0;
Michael, can you please confirm whether the device can never legitimately
send shorter than FT260_REPORT_MAX_LENGTH reports?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] hid: usbhid: fix deadlock in hid_post_reset()
From: Jiri Kosina @ 2026-04-09 15:48 UTC (permalink / raw)
To: Oliver Neukum; +Cc: bentiss, linux-input, linux-usb
In-Reply-To: <036cb81b-ae6e-4dcd-8f97-593e754279d1@suse.com>
On Mon, 30 Mar 2026, Oliver Neukum wrote:
> > Did you find this just by code inspection, or was this reported with a
> > real device?
>
> Pure inspection. We are looking at USB error handling
> in general right now.
OK, thanks. Now queued in hid.git.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: apple: ensure the keyboard backlight is off if suspending
From: Jiri Kosina @ 2026-04-09 15:46 UTC (permalink / raw)
To: Aditya Garg
Cc: Benjamin Tissoires, linux-input, linux-kernel, stable,
André Eikmeyer
In-Reply-To: <MAUPR01MB115467C51E492BD620ED390B6B85FA@MAUPR01MB11546.INDPRD01.PROD.OUTLOOK.COM>
On Sat, 4 Apr 2026, Aditya Garg wrote:
> Some users reported that upon suspending their keyboard backlight
> remained on. Fix this by adding the missing LED_CORE_SUSPENDRESUME flag.
>
> Cc: stable@vger.kernel.org
> Fixes: 394ba612f941 ("HID: apple: Add support for magic keyboard backlight on T2 Macs")
> Fixes: 9018eacbe623 ("HID: apple: Add support for keyboard backlight on certain T2 Macs.")
> Reported-by: André Eikmeyer <andre.eikmeyer@gmail.com>
> Tested-by: André Eikmeyer <andre.eikmeyer@gmail.com>
> Signed-off-by: Aditya Garg <gargaditya08@live.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: quirks: Set ALWAYS_POLL for LOGITECH_BOLT_RECEIVER
From: Jiri Kosina @ 2026-04-09 15:45 UTC (permalink / raw)
To: Nícolas F. R. A. Prado
Cc: Benjamin Tissoires, kernel, linux-input, linux-kernel
In-Reply-To: <20260407-logi-bolt-hid-quirk-always-poll-v1-1-4dae0fda344e@collabora.com>
On Tue, 7 Apr 2026, Nícolas F. R. A. Prado wrote:
> The Logitech Bolt receiver once connected to a wireless device will
> generate data on interface 2. If this data isn't polled, when the USB
> port it is connected to gets suspended (and if that happens within 5
> minutes of the last input from the wireless device), it will trigger a
> remote wakeup 3 seconds later, which will result in a spurious system
> wakeup if the port was suspended as part of system sleep.
>
> Set the ALWAYS_POLL quirk for this device to ensure interface 2 is
> always polled and this spurious wakeup never happens.
>
> With this change in place the system can be suspended with the receiver
> plugged in and the system can be woken up when an input is sent from the
> wireless device.
>
> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com>
> ---
> Hi,
>
> Given that the polling only needs to happen before the device goes into
> suspend, I wonder if it might make sense to introduce a new quirk type
> that only does a poll before the device goes into suspend (both for
> system sleep and runtime suspend). It would reduce the extra bit of USB
> traffic that ends up happening in this case with ALWAYS_POLL every time
> a wireless device connects to the receiver.
I don't think it's worth the hassle, but if you feel strongly about it, I
wouldn't object too strongly.
In the meantime, I am applying this one. Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: winwing: add support for URSA MINOR combat joysticks
From: Jiri Kosina @ 2026-04-09 15:43 UTC (permalink / raw)
To: René Onier; +Cc: linux-input, bentiss, ivan.gorinov
In-Reply-To: <20260404172641.195619-1-rene.onier@gmail.com>
On Sat, 4 Apr 2026, René Onier wrote:
> Add device IDs for the Winwing URSA MINOR Combat Joystick L (0xbc29)
> and R (0xbc2a). These joysticks declare 128 buttons in their HID
> report descriptor, causing the generic HID driver to reject buttons
> above KEY_MAX (767) with "Invalid code" errors.
>
> The URSA MINOR joysticks use buttons in the 33-64 range for grip
> controls including the index trigger, so map_more_buttons is set
> to 1 to enable the extended KEY_MACRO mapping.
>
> Tested with both left and right URSA MINOR joysticks on kernel 6.19.
>
> Signed-off-by: René Onier <rene.onier@gmail.com>
> ---
> hid-winwing.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/hid-winwing.c b/hid-winwing.c
> index ab65dc1..f3e6ea0 100644
> --- a/hid-winwing.c
> +++ b/hid-winwing.c
Thanks for the patch!
You seem to have generated it however without a full path, so it can't be
applied using standard patch -p1 way ... could you please fix that up and
resend?
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: alps: fix NULL pointer dereference in alps_raw_event()
From: Jiri Kosina @ 2026-04-09 15:37 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-input, linux-kernel, stable, Benjamin Tissoires, Masaki Ota
In-Reply-To: <2026040624-overjoyed-impart-6fa4@gregkh>
On Mon, 6 Apr 2026, Greg Kroah-Hartman wrote:
> Commit ecfa6f34492c ("HID: Add HID_CLAIMED_INPUT guards in raw_event
> callbacks missing them") attempted to fix up the HID drivers that had
> missed the previous fix that was done in 2ff5baa9b527 ("HID: appleir:
> Fix potential NULL dereference at raw event handle"), but the alps
> driver was missed.
>
> Fix this up by properly checking in the hid-alps driver that it had been
> claimed correctly before attempting to process the raw event.
>
> Fixes: 73196ebe134d ("HID: alps: add support for Alps T4 Touchpad device")
> Cc: stable <stable@kernel.org>
> Cc: Jiri Kosina <jikos@kernel.org>
> Cc: Benjamin Tissoires <bentiss@kernel.org>
> Cc: Masaki Ota <masaki.ota@jp.alps.com>
> Cc: linux-input@vger.kernel.org
> Assisted-by: gregkh_clanker_t1000
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2 1/2] HID: logitech-dj: Standardise hid_report_enum variable nomenclature
From: Jiri Kosina @ 2026-04-09 15:36 UTC (permalink / raw)
To: Lee Jones
Cc: Filipe Laíns, Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260407135955.GQ3795166@google.com>
On Tue, 7 Apr 2026, Lee Jones wrote:
> > Since we will need to differentiate between the two report_enum types
> > soon, let's unify the naming conventions now to save confusion and/or
> > unnecessary/unrelated changes in upcoming commits.
> >
> > {input,output}_report_enum is used in other places to let's conform.
> >
> > Signed-off-by: Lee Jones <lee@kernel.org>
> > ---
> > v1 => v2: New patch
> >
> > drivers/hid/hid-logitech-dj.c | 12 ++++++------
> > 1 file changed, 6 insertions(+), 6 deletions(-)
>
> During a previous submission you indicated that you preferred pings over
> [RESEND]s - so this is it.
>
> This submission was posted 2 weeks ago. Could someone take a look please?
Sorry for the delay. Now applied. Thanks!
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: sony: update module description
From: Jiri Kosina @ 2026-04-09 15:34 UTC (permalink / raw)
To: Rosalie Wanders; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260402155915.17745-2-rosalie@mailbox.org>
On Thu, 2 Apr 2026, Rosalie Wanders wrote:
> This commit updates the hid-sony module description to make it correct
> with the recent hid-sony changes alongside making it more consistent.
>
> Signed-off-by: Rosalie Wanders <rosalie@mailbox.org>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: logitech-hidpp: Check bounds when deleting force-feedback effects
From: Jiri Kosina @ 2026-04-09 15:27 UTC (permalink / raw)
To: Günther Noack
Cc: Filipe Laíns, Bastien Nocera, Benjamin Tissoires, Lee Jones,
linux-input, linux-kernel
In-Reply-To: <20260331074052.194064-1-gnoack@google.com>
On Tue, 31 Mar 2026, Günther Noack wrote:
> Without this bounds check, this might otherwise overwrite index -1.
>
> Triggering this condition requires action both from the USB device and from
> userspace, which reduces the scenarios in which it can be exploited.
>
> Cc: Lee Jones <lee@kernel.org>
> Signed-off-by: G=C3=BCnther Noack <gnoack@google.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: sdm845-oneplus: Update compatible to include model
From: David Heidelberg @ 2026-04-09 15:19 UTC (permalink / raw)
To: Konrad Dybcio, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jason A. Donenfeld, Matthias Schiffer,
Vincent Huang, Bjorn Andersson, Konrad Dybcio
Cc: linux-input, devicetree, linux-kernel, linux-arm-msm, phone-devel,
Krzysztof Kozlowski
In-Reply-To: <80067706-1857-46a0-a281-7f4ff3937468@oss.qualcomm.com>
On 09/04/2026 14:41, Konrad Dybcio wrote:
> On 4/8/26 7:34 PM, David Heidelberg via B4 Relay wrote:
>> From: David Heidelberg <david@ixit.cz>
>>
>> We know the driver is reporting s3706b, introduce the compatible so we
>
> via Google search AI summary:
> "Bon Chef S3706B is a black dinner fork (Roman Euro Dinner Fork)" - the
> more you know!
Oh no, that's definitely not compatible hardware! Maybe it's some fork... :P
^ permalink raw reply
* Re: [PATCH] Docs: hid: intel-ish-hid: make long URL usable
From: Jonathan Corbet @ 2026-04-09 14:42 UTC (permalink / raw)
To: Randy Dunlap, linux-kernel
Cc: Randy Dunlap, Jiri Kosina, Benjamin Tissoires,
Srinivas Pandruvada, linux-input, Shuah Khan, linux-doc
In-Reply-To: <20260321230934.435020-1-rdunlap@infradead.org>
Randy Dunlap <rdunlap@infradead.org> writes:
> The '\' line continuation character in this long URL
> doesn't help anything. There is no documentation tooling that
> handles the line continuation character to join the 2 lines
> to make a usable URL. Web browsers terminate the URL just
> before the '\' character so that the second line of the URL
> is lost. See:
> https://docs.kernel.org/hid/intel-ish-hid.html
>
> Join the 2 lines together so that the URL is usable.
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> Cc: Jiri Kosina <jikos@kernel.org>
> Cc: Benjamin Tissoires <bentiss@kernel.org>
> Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> Cc: linux-input@vger.kernel.org
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Shuah Khan <skhan@linuxfoundation.org>
> Cc: linux-doc@vger.kernel.org
>
> Documentation/hid/intel-ish-hid.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> --- linux-next-20260320.orig/Documentation/hid/intel-ish-hid.rst
> +++ linux-next-20260320/Documentation/hid/intel-ish-hid.rst
> @@ -163,8 +163,8 @@ The transport layer is a bi-directional
> - A flow control mechanism to avoid buffer overflows
>
> This protocol resembles bus messages described in the following document:
> -http://www.intel.com/content/dam/www/public/us/en/documents/technical-\
> -specifications/dcmi-hi-1-0-spec.pdf "Chapter 7: Bus Message Layer"
> +http://www.intel.com/content/dam/www/public/us/en/documents/technical-specifications/dcmi-hi-1-0-spec.pdf
> +"Chapter 7: Bus Message Layer".
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: sdm845-oneplus: Update compatible to include model
From: Konrad Dybcio @ 2026-04-09 12:41 UTC (permalink / raw)
To: david, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jason A. Donenfeld, Matthias Schiffer,
Vincent Huang, Bjorn Andersson, Konrad Dybcio
Cc: linux-input, devicetree, linux-kernel, linux-arm-msm, phone-devel,
Krzysztof Kozlowski
In-Reply-To: <20260408-synaptics-rmi4-dt-v1-2-2d32bacce673@ixit.cz>
On 4/8/26 7:34 PM, David Heidelberg via B4 Relay wrote:
> From: David Heidelberg <david@ixit.cz>
>
> We know the driver is reporting s3706b, introduce the compatible so we
via Google search AI summary:
"Bon Chef S3706B is a black dinner fork (Roman Euro Dinner Fork)" - the
more you know!
> can more easily introduce quirks for weird touchscreen replacements in
> followup series.
>
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 0/2] HID: multitouch: Add support for Dell Pro Rugged 12 Tablet RA02260
From: buingoc67 @ 2026-04-09 5:13 UTC (permalink / raw)
To: jikos; +Cc: bentiss, buingoc67, linux-input, linux-kernel
In-Reply-To: <4op5533p-s086-55sr-oso5-30qsnqpq407n@xreary.bet>
Hi, I don't understand why it take my email "buingoc67" instead
of the git user.name that I set as "hmtheboy154". Is there any way
that I can change this ? Or else I'll submit the changes under my
org email (hmtheboy154@blisslabs.org) if that's ok.
^ permalink raw reply
* Re: [PATCH v4 11/11] arm64: dts: qcom: sdm845-google: Add STM FTS touchscreen support
From: Dmitry Baryshkov @ 2026-04-08 23:56 UTC (permalink / raw)
To: david
Cc: Dmitry Torokhov, Maxime Coquelin, Alexandre Torgue, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Henrik Rydberg,
Bjorn Andersson, Konrad Dybcio, Petr Hodina, linux-input,
linux-stm32, linux-arm-kernel, linux-kernel, Krzysztof Kozlowski,
devicetree, linux-arm-msm, phone-devel, Konrad Dybcio
In-Reply-To: <20260409-stmfts5-v4-11-64fe62027db5@ixit.cz>
On Thu, Apr 09, 2026 at 12:15:54AM +0200, David Heidelberg via B4 Relay wrote:
> From: Petr Hodina <petr.hodina@protonmail.com>
>
> Basic touchscreen connected to second i2c bus.
>
> Signed-off-by: Petr Hodina <petr.hodina@protonmail.com>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Co-developed-by: David Heidelberg <david@ixit.cz>
> Signed-off-by: David Heidelberg <david@ixit.cz>
> ---
> arch/arm64/boot/dts/qcom/sdm845-google-blueline.dts | 19 ++++++++++++++++++-
> arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi | 2 +-
> 2 files changed, 19 insertions(+), 2 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2] HID: sony: add support for more instruments
From: Jiri Kosina @ 2026-04-08 22:44 UTC (permalink / raw)
To: Rosalie
Cc: Benjamin Tissoires, Sanjay Govind, Brenton Simpson, linux-input,
linux-kernel
In-Reply-To: <21996a49-6408-4fbc-b11f-0d9cc503ad10@mailbox.org>
On Thu, 9 Apr 2026, Rosalie wrote:
> It looks fine to me code wise, and it compiles! but you forgot to apply a
> patch you applied earlier to the for-7.1/sony branch, namely 'HID: sony:
> update module description'
Thanks for checking.
Yes, I am aware of that one missing for now, it's in the queue for next
time.
> Other than that, it's fine, and again I apologize for the chaos,
Np. Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: sony: add support for more instruments
From: Rosalie @ 2026-04-08 22:41 UTC (permalink / raw)
To: Jiri Kosina
Cc: Benjamin Tissoires, Sanjay Govind, Brenton Simpson, linux-input,
linux-kernel
In-Reply-To: <r803963p-778n-84p8-3046-s7118rr376pp@xreary.bet>
On 4/9/26 00:19, Jiri Kosina wrote:
> On Thu, 9 Apr 2026, Rosalie wrote:
>
>> Yes I do apologize, and I'll be mindful of either doing a series, mark
>> dependencies clearly or do a pull request.
>>
>> I didn't expect to be sending this many patches at all in the first place, but
>> one minor annoyance of the code bothers me one day and then another day
>> someone else mentions that e.g a device name is incorrect, so that kinda led
>> to this chaos.
>>
>> Apologies and I'll try preventing it in the future, and thanks for the advice,
>
> No worries. I've just update hid.git#for-7.1/sony and I believe it's now
> in proper state with all the patch dependencies correctly captured. If you
> see any issue there, please let me know.
>
> Thanks,
>
It looks fine to me code wise, and it compiles! but you forgot to apply
a patch you applied earlier to the for-7.1/sony branch, namely 'HID:
sony: update module description'
Other than that, it's fine, and again I apologize for the chaos,
Rosalie
^ permalink raw reply
* Re: [PATCH] HID: apple: Add Niz keyboard dongle to non-apple keyboards list
From: Jiri Kosina @ 2026-04-08 22:25 UTC (permalink / raw)
To: utzcoz; +Cc: Benjamin Tissoires, linux-input, linux-kernel
In-Reply-To: <20260403161806.31908-1-utzcoz@gmail.com>
On Sat, 4 Apr 2026, utzcoz wrote:
> Niz X99 uses a 2.4GHz wireless dongle (Milsky LL Dongle) that
> reports Apple's vendor and product IDs (05ac:0220), causing
> hid-apple to apply Apple function key translation. Since the
> dongle has no Apple Fn key, F1-F12 become unreachable when fnmode
> defaults to media-first behavior.
>
> Add the Milsky LL Dongle to the non_apple_keyboards list so that
> fnmode=3 (auto) correctly resolves to fnmode=2, making F1-F12 work
> as standard function keys.
>
> Signed-off-by: utzcoz <utzcoz@gmail.com>
Thanks a lot for the patches.
I know that the kernel documentation is now a little bit more liberal
about not having to use real names, but "well established identities"
being fine, but stil ... would you mind submitting this under some more
comprehensible authorship? (anonymous submissions are still not allowed,
BTW).
utzcoz doesn't really sound too well established identity to me,
unfortunately ... if it is, I'd be happy to stay corrected.
Thanks again,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 0/3] HID: apple: reinitialize T2 HID devices after resume
From: Jiri Kosina @ 2026-04-08 22:24 UTC (permalink / raw)
To: deqrocks; +Cc: benjamin.tissoires, linux-input
In-Reply-To: <20260403130620.91999-1-andre@negmaster.com>
On Fri, 3 Apr 2026, deqrocks wrote:
> This series improves suspend and resume handling for Apple T2 based Macs.
>
> On affected systems, Apple T2 HID-backed devices can disappear across suspend and resume and come back with freshly enumerated interfaces. Reusing the pre-suspend device state leaves parts of the stack non-functional after resume, especially keyboard backlight and Touch Bar related devices.
>
> This series adds the required Apple T2 HID identifiers, wires up PM handling for the relevant Apple HID path, and reworks teardown and reprobe handling so stale state is discarded and devices are initialized again after resume.
>
> Tested on: MacBookAir9,1, MacBookPro15,1, MacBookPro16,1, MacBookPro16,2, MacBookPro16,4
Thanks a lot for the patches.
I know that the kernel documentation is now a little bit more liberal
about not having to use real names, but "well established identities"
being fine, but stil ... would you mind submitting this under some more
comprehensible authorship? (anonymous submissions are still not allowed,
BTW).
deqrocks doesn't really sound too well established identity to me,
unfortunately ... if it is, I'd be happy to stay corrected.
Thanks a lot,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH v2] HID: sony: add support for more instruments
From: Jiri Kosina @ 2026-04-08 22:19 UTC (permalink / raw)
To: Rosalie
Cc: Benjamin Tissoires, Sanjay Govind, Brenton Simpson, linux-input,
linux-kernel
In-Reply-To: <cb0617fb-76b0-4241-8fba-982a5ffa4525@mailbox.org>
On Thu, 9 Apr 2026, Rosalie wrote:
> Yes I do apologize, and I'll be mindful of either doing a series, mark
> dependencies clearly or do a pull request.
>
> I didn't expect to be sending this many patches at all in the first place, but
> one minor annoyance of the code bothers me one day and then another day
> someone else mentions that e.g a device name is incorrect, so that kinda led
> to this chaos.
>
> Apologies and I'll try preventing it in the future, and thanks for the advice,
No worries. I've just update hid.git#for-7.1/sony and I believe it's now
in proper state with all the patch dependencies correctly captured. If you
see any issue there, please let me know.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [PATCH v4 11/11] arm64: dts: qcom: sdm845-google: Add STM FTS touchscreen support
From: David Heidelberg via B4 Relay @ 2026-04-08 22:15 UTC (permalink / raw)
To: Dmitry Torokhov, Maxime Coquelin, Alexandre Torgue, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Henrik Rydberg,
Bjorn Andersson, Konrad Dybcio
Cc: Petr Hodina, linux-input, linux-stm32, linux-arm-kernel,
linux-kernel, Krzysztof Kozlowski, devicetree, linux-arm-msm,
phone-devel, David Heidelberg, Konrad Dybcio
In-Reply-To: <20260409-stmfts5-v4-0-64fe62027db5@ixit.cz>
From: Petr Hodina <petr.hodina@protonmail.com>
Basic touchscreen connected to second i2c bus.
Signed-off-by: Petr Hodina <petr.hodina@protonmail.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Co-developed-by: David Heidelberg <david@ixit.cz>
Signed-off-by: David Heidelberg <david@ixit.cz>
---
arch/arm64/boot/dts/qcom/sdm845-google-blueline.dts | 19 ++++++++++++++++++-
arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi | 2 +-
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm845-google-blueline.dts b/arch/arm64/boot/dts/qcom/sdm845-google-blueline.dts
index fa89be500fb85..8fb988130b551 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-google-blueline.dts
+++ b/arch/arm64/boot/dts/qcom/sdm845-google-blueline.dts
@@ -26,7 +26,24 @@ &i2c2 {
status = "okay";
- /* ST,FTS @ 49 */
+ touchscreen@49 {
+ compatible = "st,stmfts5";
+ reg = <0x49>;
+
+ pinctrl-0 = <&touchscreen_irq_n>, <&touchscreen_reset>;
+ pinctrl-names = "default";
+
+ interrupts-extended = <&tlmm 125 IRQ_TYPE_LEVEL_LOW>;
+
+ mode-switch-gpios = <&tlmm 136 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&tlmm 99 GPIO_ACTIVE_LOW>;
+
+ avdd-supply = <&vreg_l14a_1p8>;
+ vdd-supply = <&vreg_l19a_3p3>;
+
+ touchscreen-size-x = <1080>;
+ touchscreen-size-y = <2160>;
+ };
};
&mdss_dsi0 {
diff --git a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
index 6930066857768..4653c63ec26d2 100644
--- a/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845-google-common.dtsi
@@ -466,7 +466,7 @@ touchscreen_reset: ts-reset-state {
bias-pull-up;
};
- touchscreen_pins: ts-pins-gpio-state {
+ touchscreen_irq_n: ts-irq-n-gpio-state {
pins = "gpio125";
function = "gpio";
drive-strength = <2>;
--
2.53.0
^ 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