* Re: [PATCH] dt-bindings: input: touchscreen: imagis: add missing minItems
From: Dmitry Torokhov @ 2025-09-04 14:33 UTC (permalink / raw)
To: Conor Dooley
Cc: Duje Mihanović, Markuss Broks, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Karel Balej, David Wronek,
phone-devel, ~postmarketos/upstreaming, linux-input, devicetree,
linux-kernel
In-Reply-To: <20250826-yippee-tamper-5439f104769b@spud>
On Tue, Aug 26, 2025 at 06:38:05PM +0100, Conor Dooley wrote:
> On Mon, Aug 25, 2025 at 08:57:57PM +0200, Duje Mihanović wrote:
> > On Monday, 25 August 2025 18:42:38 Central European Summer Time Conor Dooley wrote:
> > > On Sun, Aug 24, 2025 at 06:12:05PM +0200, Duje Mihanović wrote:
> > > > The binding currently expects exactly 5 keycodes, which matches the
> > > > chip's theoretical maximum but probably not the number of touch keys on
> > > > any phone using the IST3032C. Add a minItems value of 2 to prevent
> > > > dt-validate complaints.
> > >
> > > Does this mean that there are devicetrees in the wild that use < 5
> > > keycodes?
> >
> > Indeed.
>
> oke, Acked-by: Conor Dooley <conor.dooley@microchip.com>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3 7/7] Input: mc13783-pwrbutton: add OF support
From: Dmitry Torokhov @ 2025-09-04 14:16 UTC (permalink / raw)
To: Alexander Kurz
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dzmitry Sankouski, Dr. David Alan Gilbert, Heiko Stuebner,
Uwe Kleine-König, devicetree, linux-input, linux-kernel
In-Reply-To: <20250829201517.15374-8-akurz@blala.de>
Hi Alexander,
On Fri, Aug 29, 2025 at 08:15:17PM +0000, Alexander Kurz wrote:
> Add OF support for the mc13783-pwrbutton so that it can be used with
> modern DT based systems.
>
> Signed-off-by: Alexander Kurz <akurz@blala.de>
> ---
> drivers/input/misc/mc13783-pwrbutton.c | 94 +++++++++++++++++++++++---
> 1 file changed, 86 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/input/misc/mc13783-pwrbutton.c b/drivers/input/misc/mc13783-pwrbutton.c
> index c9eea57ceedd..a20236b19103 100644
> --- a/drivers/input/misc/mc13783-pwrbutton.c
> +++ b/drivers/input/misc/mc13783-pwrbutton.c
> @@ -27,6 +27,7 @@
> #include <linux/interrupt.h>
> #include <linux/platform_device.h>
> #include <linux/mfd/mc13783.h>
> +#include <linux/property.h>
> #include <linux/sched.h>
> #include <linux/slab.h>
>
> @@ -109,8 +110,82 @@ static irqreturn_t button3_irq(int irq, void *_priv)
> return button_irq(MC13783_IRQ_ONOFD3, _priv);
> }
>
> -static int mc13783_pwrbutton_probe(struct platform_device *pdev)
> +#ifdef CONFIG_OF
I do not think you need to guard this. As far as I can tell there are no
users of platform data in mainline, so just switch to using generic
device properties for configuration and get rid of struct
mc13xxx_buttons_platform_data altogether.
> +static struct mc13xxx_buttons_platform_data __init *mc13xxx_pwrbutton_probe_dt(
> + struct platform_device *pdev)
> {
> + struct mc13xxx_buttons_platform_data *pdata;
> + struct fwnode_handle *child;
> + struct device *dev = &pdev->dev;
> + struct mc13xxx_button_devtype *devtype =
> + (struct mc13xxx_button_devtype *)platform_get_device_id(pdev)->driver_data;
> +
> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + return ERR_PTR(-ENOMEM);
> +
> + struct fwnode_handle *parent __free(fwnode_handle) =
> + device_get_named_child_node(dev->parent, "buttons");
> + if (!parent)
> + return ERR_PTR(-ENODATA);
> +
> + fwnode_for_each_named_child_node(parent, child, "onkey") {
> + u32 idx;
> + u8 dbnc = MC13783_BUTTON_DBNC_30MS;
> + u16 dbnc_ms;
> +
> + if (fwnode_property_read_u32(child, "reg", &idx))
> + continue;
> +
> + if (idx > devtype->button_id_max) {
> + dev_warn(dev, "reg out of range\n");
> + continue;
> + }
> +
> + fwnode_property_read_u16(child, "debounce-delay-ms", &dbnc_ms);
> + switch (dbnc_ms) {
> + case 0:
> + dbnc = MC13783_BUTTON_DBNC_0MS;
> + break;
> + case 30:
> + dbnc = MC13783_BUTTON_DBNC_30MS;
> + break;
> + case 150:
> + dbnc = MC13783_BUTTON_DBNC_150MS;
> + break;
> + case 750:
> + dbnc = MC13783_BUTTON_DBNC_750MS;
> + break;
> + default:
> + dev_warn(dev, "invalid debounce-delay-ms value\n");
> + continue;
> + }
> +
> + if (fwnode_property_read_u32(child, "linux,code", &pdata->b_on_key[idx]))
> + continue;
> +
> + if (fwnode_property_read_bool(child, "active-low"))
> + pdata->b_on_flags[idx] |= MC13783_BUTTON_POL_INVERT;
> +
> + if (fwnode_property_read_bool(child, "fsl,enable-reset"))
> + pdata->b_on_flags[idx] |= MC13783_BUTTON_RESET_EN;
> +
> + pdata->b_on_flags[idx] |= MC13783_BUTTON_ENABLE | dbnc;
> + }
> +
> + return pdata;
> +}
> +#else
> +static inline struct mc13xxx_buttons_platform_data __init *mc13xxx_pwrbutton_probe_dt(
> + struct platform_device *pdev)
> +{
> + return ERR_PTR(-ENODEV);
> +}
> +#endif
> +
> +static int __init mc13783_pwrbutton_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> const struct mc13xxx_buttons_platform_data *pdata;
> struct mc13xxx *mc13783 = dev_get_drvdata(pdev->dev.parent);
> struct mc13xxx_button_devtype *devtype =
> @@ -121,9 +196,13 @@ static int mc13783_pwrbutton_probe(struct platform_device *pdev)
> int reg = 0;
>
> pdata = dev_get_platdata(&pdev->dev);
> - if (!pdata) {
> - dev_err(&pdev->dev, "missing platform data\n");
> - return -ENODEV;
> + if (dev->parent->of_node) {
> + pdata = mc13xxx_pwrbutton_probe_dt(pdev);
> + if (IS_ERR(pdata))
> + return PTR_ERR(pdata);
> + } else if (!pdata) {
> + dev_err(dev, "missing platform data\n");
> + return -ENODATA;
> }
>
> pwr = devm_input_allocate_device(&pdev->dev);
> @@ -290,15 +369,14 @@ static const struct platform_device_id mc13xxx_pwrbutton_idtable[] = {
> };
>
> static struct platform_driver mc13783_pwrbutton_driver = {
> - .id_table = mc13xxx_pwrbutton_idtable,
> - .probe = mc13783_pwrbutton_probe,
> - .remove = mc13783_pwrbutton_remove,
> .driver = {
> .name = "mc13783-pwrbutton",
> },
> + .id_table = mc13xxx_pwrbutton_idtable,
> + .remove = mc13783_pwrbutton_remove,
> };
>
> -module_platform_driver(mc13783_pwrbutton_driver);
> +module_platform_driver_probe(mc13783_pwrbutton_driver, mc13783_pwrbutton_probe);
Switching to module_platform_driver_probe() seems an unrelated change.
>
> MODULE_ALIAS("platform:mc13783-pwrbutton");
> MODULE_DESCRIPTION("MC13783 Power Button");
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3 2/7] Input: mc13783-pwrbutton: use managed resources
From: Dmitry Torokhov @ 2025-09-04 14:12 UTC (permalink / raw)
To: Alexander Kurz
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dzmitry Sankouski, Dr. David Alan Gilbert, Heiko Stuebner,
Uwe Kleine-König, devicetree, linux-input, linux-kernel
In-Reply-To: <20250829201517.15374-3-akurz@blala.de>
On Fri, Aug 29, 2025 at 08:15:12PM +0000, Alexander Kurz wrote:
> Use devres functionality to simplify resource freeing, dev.parent will
> be set by devm_input_allocate_device().
>
> Signed-off-by: Alexander Kurz <akurz@blala.de>
> ---
> drivers/input/misc/mc13783-pwrbutton.c | 28 ++++++++------------------
> 1 file changed, 8 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/input/misc/mc13783-pwrbutton.c b/drivers/input/misc/mc13783-pwrbutton.c
> index 4765b25bc9f6..9fd84b8d163d 100644
> --- a/drivers/input/misc/mc13783-pwrbutton.c
> +++ b/drivers/input/misc/mc13783-pwrbutton.c
> @@ -21,6 +21,7 @@
>
> #include <linux/module.h>
> #include <linux/kernel.h>
> +#include <linux/device.h>
> #include <linux/errno.h>
> #include <linux/input.h>
> #include <linux/interrupt.h>
> @@ -118,18 +119,13 @@ static int mc13783_pwrbutton_probe(struct platform_device *pdev)
> return -ENODEV;
> }
>
> - pwr = input_allocate_device();
> - if (!pwr) {
> - dev_dbg(&pdev->dev, "Can't allocate power button\n");
> + pwr = devm_input_allocate_device(&pdev->dev);
> + if (!pwr)
> return -ENOMEM;
> - }
>
> - priv = kzalloc(sizeof(*priv), GFP_KERNEL);
> - if (!priv) {
> - err = -ENOMEM;
> - dev_dbg(&pdev->dev, "Can't allocate power button\n");
> - goto free_input_dev;
> - }
> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
>
> reg |= (pdata->b1on_flags & 0x3) << MC13783_POWER_CONTROL_2_ON1BDBNC;
> reg |= (pdata->b2on_flags & 0x3) << MC13783_POWER_CONTROL_2_ON2BDBNC;
> @@ -155,7 +151,7 @@ static int mc13783_pwrbutton_probe(struct platform_device *pdev)
> button1_irq, "b1on", priv);
> if (err) {
> dev_dbg(&pdev->dev, "Can't request irq\n");
> - goto free_priv;
> + goto free_mc13xxx_lock;
> }
> }
>
> @@ -203,7 +199,6 @@ static int mc13783_pwrbutton_probe(struct platform_device *pdev)
>
> pwr->name = "mc13783_pwrbutton";
> pwr->phys = "mc13783_pwrbutton/input0";
> - pwr->dev.parent = &pdev->dev;
>
> pwr->keycode = priv->keymap;
> pwr->keycodemax = ARRAY_SIZE(priv->keymap);
> @@ -234,12 +229,8 @@ static int mc13783_pwrbutton_probe(struct platform_device *pdev)
> if (pdata->b1on_flags & MC13783_BUTTON_ENABLE)
> mc13xxx_irq_free(mc13783, MC13783_IRQ_ONOFD1, priv);
mc13xxx_irq_request() uses devm so you can drop calls to
mc13xxx_irq_free() in both error paths and in remove().
This comment is pretty much moot if you follow my suggestion of using
resources to pass interrupts to the child device.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3 1/7] Input: mc13783-pwrbutton: fix irq mixup
From: Dmitry Torokhov @ 2025-09-04 14:10 UTC (permalink / raw)
To: Alexander Kurz
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dzmitry Sankouski, Dr. David Alan Gilbert, Heiko Stuebner,
Uwe Kleine-König, devicetree, linux-input, linux-kernel
In-Reply-To: <20250829201517.15374-2-akurz@blala.de>
Hi Alexander,
On Fri, Aug 29, 2025 at 08:15:11PM +0000, Alexander Kurz wrote:
> The mfd mc13xxx interrupt handling was migrated to regmap with commit
> 10f9edaeaa30 ("mfd: mc13xxx: Use regmap irq framework for interrupts").
> As a consequence, button_irq() will get called with virtual irq instead
> of chip-internal irq now. Add wrappers for the three supported interrupts.
>
> Signed-off-by: Alexander Kurz <akurz@blala.de>
> ---
> drivers/input/misc/mc13783-pwrbutton.c | 21 ++++++++++++++++++---
> 1 file changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/input/misc/mc13783-pwrbutton.c b/drivers/input/misc/mc13783-pwrbutton.c
> index 1c7faa9b7afe..4765b25bc9f6 100644
> --- a/drivers/input/misc/mc13783-pwrbutton.c
> +++ b/drivers/input/misc/mc13783-pwrbutton.c
> @@ -88,6 +88,21 @@ static irqreturn_t button_irq(int irq, void *_priv)
> return IRQ_HANDLED;
> }
>
> +static irqreturn_t button1_irq(int irq, void *_priv)
> +{
> + return button_irq(MC13783_IRQ_ONOFD1, _priv);
> +}
> +
> +static irqreturn_t button2_irq(int irq, void *_priv)
> +{
> + return button_irq(MC13783_IRQ_ONOFD2, _priv);
> +}
> +
> +static irqreturn_t button3_irq(int irq, void *_priv)
> +{
> + return button_irq(MC13783_IRQ_ONOFD3, _priv);
> +}
> +
> static int mc13783_pwrbutton_probe(struct platform_device *pdev)
> {
> const struct mc13xxx_buttons_platform_data *pdata;
> @@ -137,7 +152,7 @@ static int mc13783_pwrbutton_probe(struct platform_device *pdev)
> reg |= MC13783_POWER_CONTROL_2_ON1BRSTEN;
>
> err = mc13xxx_irq_request(mc13783, MC13783_IRQ_ONOFD1,
> - button_irq, "b1on", priv);
> + button1_irq, "b1on", priv);
I wonder if it would not be better to have drivers/mfd/mc13xxx-core.c
use resources to describe/pass interrupts to the power button driver and
get rid of mc13xxx_irq_request() completely.
The power button driver would use platform_get_irq() to fetch virtual
interrupt numbers, store them in priv, and then compare interrupt
numbers in button_irq().
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 0/5] platform/chrome: Fix a race when probing drivers
From: Dmitry Torokhov @ 2025-09-04 14:06 UTC (permalink / raw)
To: Tzung-Bi Shih; +Cc: Benson Leung, linux-input, chrome-platform
In-Reply-To: <aLbutygmfjV4AuhZ@tzungbi-laptop>
Hi Tzung-Bi,
On Tue, Sep 02, 2025 at 09:18:47PM +0800, Tzung-Bi Shih wrote:
> On Fri, Aug 29, 2025 at 08:50:01PM +0800, Tzung-Bi Shih wrote:
> > On Fri, Aug 29, 2025 at 11:28:55AM +0000, Dmitry Torokhov wrote:
> > > On Thu, Aug 28, 2025 at 08:35:56AM +0000, Tzung-Bi Shih wrote:
> > > > A race is observed when cros_ec_lpc and cros-ec-keyb are all built as
> > > > modules. cros_ec_lpc is cros-ec-keyb's parent. However, they can be
> > > > probed at the same time.
> > > >
> > > > Example:
> > > >
> > > > + -----------------------------------------------------------------+
> > > > | Some init process (e.g. udevd) | deferred_probe_work_func worker |
> > > > + -----------------------------------------------------------------+
> > > > | Probe cros-ec-keyb. | |
> > > > | - Decide to defer[1]. | |
> > > > | | A device bound to a driver[2]. |
> > > > | Probe cros_ec_lpc. | |
> > > > | - Init the struct[3]. | |
> > > > | | Retry cros-ec-keyb from the |
> > > > | | deferred list[4]. |
> > > > | | - Won't defer again as [3]. |
> > > > | | - Access uninitialized data in |
> > > > | | the struct. |
> > > > | - Register the device. | |
> > > > + -----------------------------------------------------------------+
> > > >
> > > > [1] https://elixir.bootlin.com/linux/v6.16/source/drivers/input/keyboard/cros_ec_keyb.c#L707
> > > > [2] https://elixir.bootlin.com/linux/v6.16/source/drivers/base/dd.c#L405
> > > > [3] https://elixir.bootlin.com/linux/v6.16/source/drivers/platform/chrome/cros_ec_lpc.c#L644
> > > > [4] https://elixir.bootlin.com/linux/v6.16/source/drivers/base/dd.c#L418
> > > >
> > > > Note that the device link[5] can't help as in the observed environment,
> > > > the devices are already added via device_add()[6].
> > > >
> > > > [5] https://www.kernel.org/doc/html/latest/driver-api/device_link.html#usage
> > > > [6] https://elixir.bootlin.com/linux/v6.16/source/drivers/acpi/acpi_platform.c#L177
> > > >
> > > > The series fixes the issue by ensuring the struct is ready for accessing
> > > > before continuing to probe cros-ec-keyb.
> > >
> > > Why is the keyboard platform device instantiated before the transport
> > > (cros_ec_lpc) is done initializing? I think this is the root of the
> > > issue...
> >
> > I may misunderstand but it seems to me:
> >
> > - The ACPI bus enumerated and instantiated the platform devices[6] first.
> >
> > - The keyboard platform device was probed when `cros_ec_keyb_driver`
> > registered. It deferred as its parent's drvdata was NULL[1].
> >
> > - The transport platform device was probed when `cros_ec_lpc_driver`
> > registered. It set the drvdata[3].
> >
> > - The keyboard platform device was probed again from retrying the deferred
> > list, by another thread `deferred_probe_work_func`. The parent's drvdata
> > wasn't NULL and cros_ec_register() for the transport device weren't
> > finished. The race happened.
>
> Hi Dmitry,
>
> Does it make sense to you?
I'll have to research how MFD mixes up statically described and
DT-described platform devices and makes sure that children are not
probed before the parent is ready - I think we need to make cros_ec
behave the same way.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v4] HID: logitech-dj: Add support for a new lightspeed receiver iteration
From: Stuart @ 2025-09-04 13:12 UTC (permalink / raw)
To: Mavroudis Chatzilazaridis
Cc: jikos, linux-input, benjamin.tissoires, hadess, lains
In-Reply-To: <12899c24-a16f-4d64-bc40-a06b4c5c3e6f@protonmail.com>
> Hm. It appears I may have misunderstood how this works. Please undo the
> previous diff and apply the following on top instead:
Done, still no change :(
> I think it happens when the devices paired to it disconnect/reconnect.
Yep, that matches
> Can you also dump the HID report descriptors when the keyboard is
> plugged in directly via USB?
Sure (046d:c343):
003:007:002:DESCRIPTOR 1756991366.823468
06 00 FF 09 01 A1 01 85 10 95 06 75 08 15 00 26
FF 00 09 01 81 00 09 01 91 00 C0 06 00 FF 09 02
A1 01 85 11 95 13 75 08 15 00 26 FF 00 09 02 81
00 09 02 91 00 C0
003:007:001:DESCRIPTOR 1756991366.827464
05 01 09 02 A1 01 85 02 09 01 A1 00 95 10 75 01
15 00 25 01 05 09 19 01 29 10 81 02 95 02 75 10
16 01 80 26 FF 7F 05 01 09 30 09 31 81 06 95 01
75 08 15 81 25 7F 09 38 81 06 95 01 05 0C 0A 38
02 81 06 C0 C0 05 0C 09 01 A1 01 85 03 95 02 75
10 15 01 26 FF 02 19 01 2A FF 02 81 00 C0 05 01
09 80 A1 01 85 04 95 01 75 02 15 01 25 03 09 82
09 81 09 83 81 00 75 06 81 03 C0
003:007:000:DESCRIPTOR 1756991366.831465
05 01 09 06 A1 01 05 07 19 E0 29 E7 15 00 25 01
75 01 95 08 81 02 95 05 05 08 19 01 29 05 91 02
95 01 75 03 91 03 95 70 75 01 05 07 19 04 29 73
81 02 95 05 19 87 29 8B 81 02 95 03 19 90 29 92
81 02 C0
^ permalink raw reply
* Re: [PATCH v1 1/1] input: touchscreen: atmel_mxt_ts: add support for generic touchscreen configurations
From: Dmitry Torokhov @ 2025-09-04 12:53 UTC (permalink / raw)
To: Svyatoslav Ryhel; +Cc: Nick Dyer, Henrik Rydberg, linux-input, linux-kernel
In-Reply-To: <CAPVz0n015aKKjArWk5u+0rHU_tDZyQ1zQ92m3BbA2A=JgjAegg@mail.gmail.com>
On Thu, Sep 04, 2025 at 03:50:53PM +0300, Svyatoslav Ryhel wrote:
> чт, 4 вер. 2025 р. о 15:22 Dmitry Torokhov <dmitry.torokhov@gmail.com> пише:
> >
> > Hi Svyatoslav,
> >
> > On Wed, Sep 03, 2025 at 07:23:27PM +0300, Svyatoslav Ryhel wrote:
> > > This provides support for generic touchscreen configuration options like
> > > swapped-x-y, min-x, min-y, size-x, size-y, etc.
> >
> > This requires corresponding change to the binding document.
> >
>
> I assumed it was already included, but it seems not to be. I will add
> appropriate change to schema in v2. Do I need to add any adjustments
> to the code?
No, the code looks good.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v1 1/1] input: touchscreen: atmel_mxt_ts: add support for generic touchscreen configurations
From: Svyatoslav Ryhel @ 2025-09-04 12:50 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Nick Dyer, Henrik Rydberg, linux-input, linux-kernel
In-Reply-To: <acakhrd7m7uigyqepxnaidrzpmftvxjaeybqlns6boujmzdzwq@lter6ek2b7er>
чт, 4 вер. 2025 р. о 15:22 Dmitry Torokhov <dmitry.torokhov@gmail.com> пише:
>
> Hi Svyatoslav,
>
> On Wed, Sep 03, 2025 at 07:23:27PM +0300, Svyatoslav Ryhel wrote:
> > This provides support for generic touchscreen configuration options like
> > swapped-x-y, min-x, min-y, size-x, size-y, etc.
>
> This requires corresponding change to the binding document.
>
I assumed it was already included, but it seems not to be. I will add
appropriate change to schema in v2. Do I need to add any adjustments
to the code?
> Thanks.
>
> --
> Dmitry
^ permalink raw reply
* Re: [PATCH v1 1/2] input: rmi4: fix RMI_2D clipping
From: Svyatoslav Ryhel @ 2025-09-04 12:48 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Jonas Schwöbel, devicetree, linux-tegra,
linux-kernel, linux-input
In-Reply-To: <75wc4lutipb7uszkqfuakjl7iqsygjif4df5phosifkgi3serc@t75jpefbbbcs>
чт, 4 вер. 2025 р. о 14:58 Dmitry Torokhov <dmitry.torokhov@gmail.com> пише:
>
> Hi Svyatoslav,
>
> On Wed, Sep 03, 2025 at 07:19:45PM +0300, Svyatoslav Ryhel wrote:
> > From: Jonas Schwöbel <jonasschwoebel@yahoo.de>
> >
> > The physical max_y value was overridden with a clip_y_max value. This
> > caused problems when inverting/flipping the screen. Further it messed up
> > calculation of resolution.
> >
> > Signed-off-by: Jonas Schwöbel <jonasschwoebel@yahoo.de>
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> > drivers/input/rmi4/rmi_2d_sensor.c | 5 ++---
> > 1 file changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/input/rmi4/rmi_2d_sensor.c b/drivers/input/rmi4/rmi_2d_sensor.c
> > index b7fe6eb35a4e..b4762b3c8b24 100644
> > --- a/drivers/input/rmi4/rmi_2d_sensor.c
> > +++ b/drivers/input/rmi4/rmi_2d_sensor.c
> > @@ -56,7 +56,7 @@ void rmi_2d_sensor_abs_process(struct rmi_2d_sensor *sensor,
> > obj->x = min(sensor->max_x, obj->x);
> >
> > if (axis_align->clip_y_high)
> > - obj->y = min(sensor->max_y, obj->y);
> > + obj->y = min(axis_align->clip_y_high, obj->y);
> >
> > sensor->tracking_pos[slot].x = obj->x;
> > sensor->tracking_pos[slot].y = obj->y;
> > @@ -149,13 +149,12 @@ static void rmi_2d_sensor_set_input_params(struct rmi_2d_sensor *sensor)
> >
> > sensor->min_y = sensor->axis_align.clip_y_low;
> > if (sensor->axis_align.clip_y_high)
> > - sensor->max_y = min(sensor->max_y,
> > + max_y = min(sensor->max_y,
>
> I see that you want to have sensor->max_y to carry maximum coordinate
> the sensor is capable of reporting, so that flipping works properly. If
> this is the case you should also be deleting sensor->min_y and always
> use 0 in its place, otherwise there is inconsistency.
>
> You also need to deal with X coordinate in the similar fashion.
>
> > sensor->axis_align.clip_y_high);
> >
> > set_bit(EV_ABS, input->evbit);
> >
> > max_x = sensor->max_x;
> > - max_y = sensor->max_y;
>
> This makes max_y potentially uninitialized.
>
> > if (sensor->axis_align.swap_axes)
> > swap(max_x, max_y);
> > input_set_abs_params(input, ABS_MT_POSITION_X, 0, max_x, 0, 0);
>
> I am unconvinced that using raw sensor coordinates to calculate
> resolution is a good idea. It has potential to regress existing users.
>
> Thanks.
>
I will take a deeper look, thank you for review.
> --
> Dmitry
^ permalink raw reply
* Re: [PATCH v1] Input: xpad - add ID for Flydigi Apex 5
From: Dmitry Torokhov @ 2025-09-04 12:27 UTC (permalink / raw)
To: Antheas Kapenekakis
Cc: linux-input, linux-kernel, Brandon Lin, Sergey Belozyorcev
In-Reply-To: <20250903165114.2987905-1-lkml@antheas.dev>
On Wed, Sep 03, 2025 at 06:51:14PM +0200, Antheas Kapenekakis wrote:
> The Flydigi Apex 5 has an XInput mode. Add the vid and pid for it.
>
> Reported-by: Brandon Lin <brandon@emergence.ltd>
> Reported-by: Sergey Belozyorcev <belozyorcev@ya.ru>
> Closes: https://github.com/ublue-os/bazzite/issues/3014
> Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: iqs7222 - avoid enabling unused interrupts
From: Dmitry Torokhov @ 2025-09-04 12:27 UTC (permalink / raw)
To: Jeff LaBundy; +Cc: linux-input
In-Reply-To: <aKsvMswOOSIaCKci@nixie71>
On Sun, Aug 24, 2025 at 10:26:42AM -0500, Jeff LaBundy wrote:
> Hi Dmitry,
>
> On Sun, Aug 17, 2025 at 06:00:46PM -0700, Dmitry Torokhov wrote:
> > Hi Jeff,
> >
> > On Sun, Aug 17, 2025 at 07:20:22PM -0500, Jeff LaBundy wrote:
> > > If a proximity event node is defined so as to specify the wake-up
> > > properties of the touch surface, the proximity event interrupt is
> > > enabled unconditionally. This may result in unwanted interrupts.
> > >
> > > Solve this problem by enabling the interrupt only if the event is
> > > mapped to a key or switch code.
> >
> > Should I tag this for stable?
>
> Thank you for checking; I'm sorry for the delayed response. Yes, I
> think it's fine to tag this for stable.
>
> I didn't CC stable@ originally because I saw this patch as more of
> an optimization than a bug fix, but it's low risk enough that it's
> fine to include in stable kernels too.
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v1 1/1] input: touchscreen: atmel_mxt_ts: add support for generic touchscreen configurations
From: Dmitry Torokhov @ 2025-09-04 12:22 UTC (permalink / raw)
To: Svyatoslav Ryhel; +Cc: Nick Dyer, Henrik Rydberg, linux-input, linux-kernel
In-Reply-To: <20250903162327.109538-2-clamor95@gmail.com>
Hi Svyatoslav,
On Wed, Sep 03, 2025 at 07:23:27PM +0300, Svyatoslav Ryhel wrote:
> This provides support for generic touchscreen configuration options like
> swapped-x-y, min-x, min-y, size-x, size-y, etc.
This requires corresponding change to the binding document.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v4] HID: logitech-dj: Add support for a new lightspeed receiver iteration
From: Mavroudis Chatzilazaridis @ 2025-09-04 12:21 UTC (permalink / raw)
To: Stuart; +Cc: jikos, linux-input, benjamin.tissoires, hadess, lains
In-Reply-To: <CALTg27=vaZK6ksriDDoN71pqr0VEbvxAz7Dp1w1toG+tO71Ldg@mail.gmail.com>
On 2025-09-03 23:40, Stuart wrote:
>> Can you apply this on top of the existing changes and test again?
>
> Unfortunately, no change in behaviour
Hm. It appears I may have misunderstood how this works. Please undo the
previous diff and apply the following on top instead:
diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index 00a975b70f59..4ae67f32e78e 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -227,6 +227,7 @@ static const char kbd_lightspeed_1_3_descriptor[] = {
0x95, 0x08, /* Report Count (8) */
0x81, 0x02, /* Input (Data,Var) */
0x95, 0x05, /* Report Count (5) */
+ 0x85, 0x0E, /* Report ID (14) */
0x05, 0x08, /* Usage Page (LEDs) */
0x19, 0x01, /* Usage Minimum (Num Lock) */
0x29, 0x05, /* Usage Maximum (Kana) */
@@ -236,6 +237,7 @@ static const char kbd_lightspeed_1_3_descriptor[] = {
0x91, 0x03, /* Output (Const,Var,Abs) */
0x95, 0x70, /* Report Count (112) */
0x75, 0x01, /* Report Size (1) */
+ 0x85, 0x01, /* Report ID (1) */
0x05, 0x07, /* Usage Page (Kbrd/Keypad) */
0x19, 0x04, /* Usage Minimum (0x04) */
0x29, 0x73, /* Usage Maximum (0x73) */
> I forgot to mention in my original testing, I get a warning in my dmesg:
> logitech-hidpp-device 0003:046D:408E.0007:
> hidpp_root_get_protocol_version: received protocol error 0x08
I believe that is normal. If I recall correctly, it just means the
receiver had trouble identifying a device. I think it happens when the
devices paired to it disconnect/reconnect.
Can you also dump the HID report descriptors when the keyboard is
plugged in directly via USB?
^ permalink raw reply related
* Re: [PATCH v1 1/2] input: rmi4: fix RMI_2D clipping
From: Dmitry Torokhov @ 2025-09-04 11:58 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Jonas Schwöbel, devicetree, linux-tegra,
linux-kernel, linux-input
In-Reply-To: <20250903161947.109328-2-clamor95@gmail.com>
Hi Svyatoslav,
On Wed, Sep 03, 2025 at 07:19:45PM +0300, Svyatoslav Ryhel wrote:
> From: Jonas Schwöbel <jonasschwoebel@yahoo.de>
>
> The physical max_y value was overridden with a clip_y_max value. This
> caused problems when inverting/flipping the screen. Further it messed up
> calculation of resolution.
>
> Signed-off-by: Jonas Schwöbel <jonasschwoebel@yahoo.de>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> drivers/input/rmi4/rmi_2d_sensor.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/input/rmi4/rmi_2d_sensor.c b/drivers/input/rmi4/rmi_2d_sensor.c
> index b7fe6eb35a4e..b4762b3c8b24 100644
> --- a/drivers/input/rmi4/rmi_2d_sensor.c
> +++ b/drivers/input/rmi4/rmi_2d_sensor.c
> @@ -56,7 +56,7 @@ void rmi_2d_sensor_abs_process(struct rmi_2d_sensor *sensor,
> obj->x = min(sensor->max_x, obj->x);
>
> if (axis_align->clip_y_high)
> - obj->y = min(sensor->max_y, obj->y);
> + obj->y = min(axis_align->clip_y_high, obj->y);
>
> sensor->tracking_pos[slot].x = obj->x;
> sensor->tracking_pos[slot].y = obj->y;
> @@ -149,13 +149,12 @@ static void rmi_2d_sensor_set_input_params(struct rmi_2d_sensor *sensor)
>
> sensor->min_y = sensor->axis_align.clip_y_low;
> if (sensor->axis_align.clip_y_high)
> - sensor->max_y = min(sensor->max_y,
> + max_y = min(sensor->max_y,
I see that you want to have sensor->max_y to carry maximum coordinate
the sensor is capable of reporting, so that flipping works properly. If
this is the case you should also be deleting sensor->min_y and always
use 0 in its place, otherwise there is inconsistency.
You also need to deal with X coordinate in the similar fashion.
> sensor->axis_align.clip_y_high);
>
> set_bit(EV_ABS, input->evbit);
>
> max_x = sensor->max_x;
> - max_y = sensor->max_y;
This makes max_y potentially uninitialized.
> if (sensor->axis_align.swap_axes)
> swap(max_x, max_y);
> input_set_abs_params(input, ABS_MT_POSITION_X, 0, max_x, 0, 0);
I am unconvinced that using raw sensor coordinates to calculate
resolution is a good idea. It has potential to regress existing users.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3 00/11] HID: Implement haptic touchpad support
From: Benjamin Tissoires @ 2025-09-04 10:02 UTC (permalink / raw)
To: Dmitry Torokhov, Jonathan Denose
Cc: Jiri Kosina, Jonathan Corbet, Henrik Rydberg, linux-input,
linux-kernel, linux-doc, Angela Czubak, Sean O'Brien
In-Reply-To: <CAMCVhVOUn-un9N_Bv00RVJ7kAw1O+AHgAHOzSGM6UuMBZVdtYw@mail.gmail.com>
On Sep 02 2025, Jonathan Denose wrote:
> On Mon, Aug 18, 2025 at 6:10 PM Jonathan Denose <jdenose@google.com> wrote:
> >
> > Hello,
> >
> > This is an updated implementation of the interface for controlling haptic
> > touchpads.
> >
> > Below is an updated design proposal for the userspace and HID interfaces,
> > modified from what one of my colleagues submitted in 2019 [0].
> >
> > We would appreciate any feedback you might have.
> >
> > Thank you,
> >
> > Jonathan Denose
> > Chromium OS Team
> >
> > Background
> > ==========
> >
> > There are multiple independent projects to develop a touchpad with force sensors
> > and haptic actuators, instead of a traditional button. These haptic touchpads
> > have several advantages and potential uses; they allow clicking across the
> > entire touchpad surface, adjusting the force requirement for clicks, haptic
> > feedback initiated by UI, etc. Supporting these features will potentially
> > require two new communication channels at the kernel level:
> > * Control of haptic motor by the host
> > * Force sensor data from device to host
> >
> > This document includes two related proposals:
> > 1. HID design proposal, that hardware makers would need to implement
> > 2. Kernel design proposal
> >
> > Objective
> > ==========
> >
> > Develop a standard protocol to allow userspace applications to communicate with
> > haptic touchpads, and minimize duplicated code and effort.
> >
> > Requirements:
> > 1. Support UI-initiated haptic feedback.
> > 2. Allow userspace to control when button press and button release haptic
> > effects are triggered. (Useful when detecting a false click, changing force
> > thresholds, or sending context-dependent effects).
> > 3. Reveal force sensor readings to userspace applications.
> > 4. Only allow OS-controlled haptic feedback for those systems which support it.
> >
> > Proposal
> > ========
> >
> > In order to minimize duplicated effort, we propose standardized haptic touchpad
> > support in the linux kernel.
> >
> > HID API
> > -------
> >
> > Modes
> > .....
> >
> > The haptic touchpad should be able to operate under two different modes.
> >
> > 1. Device-controlled mode
> >
> > The haptic touchpad should start up in "device-controlled mode"
> > (HID_HAPTIC_MODE_DEVICE), meaning it acts as a normal touchpad. This means it
> > should perform the press and release haptic feedback autonomously at predefined
> > force thresholds, and send the appropriate BTN_* events.
> >
> > 2. Host-controlled mode
> >
> > Once the touchpad has been confirmed as supporting haptics (described in more
> > detail in the the "Click and release control" section below), the device should
> > enter "host-controlled mode" (HID_HAPTIC_MODE_HOST). In this mode userspace
> > should take control. From here, userspace will take control over
> > press/release haptic feedback, relying on the effects sent by the kernel.
> >
> > Multitouch
> > ..........
> >
> > The HID API for multitouch reports should follow the Microsoft precision
> > touchpad spec [1], with the following changes:
> > * A tip pressure field [2] should be used to report the force. The physical unit
> > Type (Newtons or grams), exponent, and limits should be reported in the
> > report descriptor for the force field.
> > * The device will always report the button state according to its predefined
> > force thresholds, even when not in device-controlled mode.
> > * The device must expose a "simple haptic controller" logical collection
> > alongside the touchpad collection.
> >
> > Haptic control
> > ..............
> >
> > The HID protocol described in HUTRR63[3] must be used.
> >
> > The following waveforms should be supported:
> >
> > | WAVEFORMNONE | Implicit waveforms required by protocol |
> > | WAVEFORMSTOP | |
> > | ------------------------ | ------------------------------------------------- |
> > | WAVEFORMPRESS | To be used to simulate button press. In device- |
> > | | controlled mode, it will also be used to simulate |
> > | | button release. |
> > | ------------------------ | ------------------------------------------------- |
> > | WAVEFORMRELEASE | To be used to simulate button release. |
> >
> > All waveforms will have an associated duration; continuous waveforms will be
> > ignored by the kernel.
> >
> > Triggers & Mode switching
> > .........................
> >
> > The “auto trigger waveform” should be set to WAVEFORM_PRESS by default, and the
> > button from the touchpad collection should be set as the “auto trigger
> > associated control”.
> >
> > The kernel can trigger the different modes in the following ways:
> > * Device-controlled mode can be enabled by setting the “auto trigger waveform” to
> > WAVEFORM_PRESS.
> > * Host-controlled mode can be enabled by setting the "auto trigger waveform" to
> > WAVEFORM_STOP.
> >
> > The device must also support manual triggering. If intensity modification for
> > waveforms is supported by the device, the intensity control should be included
> > in the manual trigger output report. This allows modification of the intensity
> > on a per-waveform basis. Retriggering does not need to be supported by the
> > device.
> >
> > Userspace API
> > -------------
> >
> > Multitouch protocol
> > ...................
> >
> > ABS_MT_PRESSURE will be used to report force. The resolution of ABS_MT_PRESSURE
> > should also be defined and reported in force units of grams or Newtons.
> > ABS_PRESSURE should be reported as the total force applied to the touchpad.
> > When the kernel is in host-controlled mode, it should always forward the button
> > press and release events to userspace.
> >
> > Use Force Feedback protocol to request pre-defined effects
> > ..........................................................
> >
> > The force feedback protocol [4] should be used to control predefined effects.
> >
> > Typical use of the force feedback protocol requires loading effects to the
> > driver by describing the output waveform, and then requesting those effects
> > using an ID provided by the driver. However, for haptic touchpads we do not want
> > to describe the output waveform explicitly, but use a set of predefined effects,
> > which are identified by HID usage.
> >
> > The force feedback protocol will need to be extended to allow requests for HID
> > haptic effects. This requires a new feedback effect type:
> >
> > /**
> > * struct ff_haptic_effect
> > * @hid_usage: hid_usage according to Haptics page (WAVEFORM_CLICK, etc.)
> > * @vendor_id: the waveform vendor ID if hid_usage is in the vendor-defined
> > * range
> > * @vendor_id: the vendor waveform page if hid_usage is in the vendor-defined
> > * range
> > * @intensity: strength of the effect
> > * @repeat_count: number of times to retrigger effect
> > * @retrigger_period: time before effect is retriggered (in ms)
> > */
> > struct ff_haptic_effect {
> > __u16 hid_usage;
> > __u16 vendor_id;
> > __u8 vendor_waveform_page;
> > __s16 intensity;
> > __u16 repeat_count;
> > __u16 retrigger_period;
> > }
> >
> > Since the standard waveform id namespace does not overlap with the vendor
> > waveform id namespace, the vendor id and page can be ignored for standard
> > waveforms.
> >
> > Click and release control
> > .........................
> >
> > Haptic functionality shall be gated behind the HID_MULTITOUCH_HAPTIC kernel
> > configuration option, and this kernel configuration option should only be
> > enabled if userspace will support haptic capabilities. Haptic functionality will
> > only be initialized and used if HID_MULTITOUCH_HAPTIC is enabled, and if the
> > following conditions have been met:
> > * ABS_MT_PRESSURE is defined and reporting force units of Newtons or grams.
> > * The device supports haptic effects according to the hid protocol defined in
> > HUTRR63 [3].
> > These checks will happen when the driver probes and initializes the multitouch
> > device.
> >
> > In the case when the kernel configuration option has been set and the device
> > reports pressure and haptic effects as defined above, the kernel will initialize
> > the haptic device and configure the haptic driver to signal that the touchpad is
> > haptic-compatible. To signal to userspace that the touchpad is haptic-compatible
> > the kernel will mark INPUT_PROP_HAPTIC_TOUCHPAD.
> >
> > With userspace willing and able to take control, the kernel will signal to the
> > device to exit device-controlled mode once a WAVEFORMPRESS or WAVEFORMRELEASE
> > event is uploaded. From here, userspace will take control over press/release
> > haptic feedback, relying on the effects sent by the kernel.
> >
> > In all other cases, the driver will take no action to enable haptic
> > functionality.
> >
> > Summary of normal use-case
> > 1. The kernel waits for userspace to upload WAVEFORMPRESS or
> > WAVEFORMRELEASE.
> > 2. Userspace determines when a click has been performed based on its own
> > criteria and tells the touchpad to perform a haptic effect.
> > 3. When userspace erases the WAVEFORMPRESS or WAVEFORMRELEASE effect, signal the
> > device to return to device-controlled mode.
> >
> > [0]: https://www.spinics.net/lists/linux-input/msg60938.html
> > [1]: https://learn.microsoft.com/en-us/windows-hardware/design/component-guidelines/touchpad-devices
> > [2]: Usage ID 0x30 of HID usage table 0x0D. See chapter 16:
> > https://www.usb.org/sites/default/files/documents/hut1_12v2.pdf
> > [3]: https://www.usb.org/sites/default/files/hutrr63b_-_haptics_page_redline_0.pdf
> > [4]: https://www.kernel.org/doc/html/v4.20/input/ff.html
> >
> > Signed-off-by: Jonathan Denose <jdenose@google.com>
> > ---
> > Changes in v3:
> > - Change CONFIG_HID_HAPTIC from bool to tristate
> > - Fix devm_kzalloc calls in hid-multitouch.c to use correct device
> > - Minor comment cleanup + grammar fix
> > - Link to v2: https://lore.kernel.org/r/20250818-support-forcepads-v2-0-ca2546e319d5@google.com
> >
> > Changes in v2:
> > - Rename FF_HID and ff_hid_effect to FF_HAPTIC and ff_haptic_effect
> > - Add more detail to CONFIG_HID_HAPTIC config option description
> > - Remove CONFIG_MULTITOUCH_HAPTIC config option
> > - Utilize devm api in hid-multitouch haptic functions
> > - Link to v1: https://lore.kernel.org/all/20250714-support-forcepads-v1-0-71c7c05748c9@google.com
> >
> > ---
> > Angela Czubak (11):
> > HID: add haptics page defines
> > Input: add FF_HAPTIC effect type
> > Input: add INPUT_PROP_HAPTIC_TOUCHPAD
> > HID: haptic: introduce hid_haptic_device
> > HID: input: allow mapping of haptic output
> > HID: haptic: initialize haptic device
> > HID: input: calculate resolution for pressure
> > HID: haptic: add functions handling events
> > Input: MT - add INPUT_MT_TOTAL_FORCE flags
> > HID: haptic: add hid_haptic_switch_mode
> > HID: multitouch: add haptic multitouch support
> >
> > Documentation/input/event-codes.rst | 14 +
> > drivers/hid/Kconfig | 11 +
> > drivers/hid/Makefile | 1 +
> > drivers/hid/hid-haptic.c | 580 +++++++++++++++++++++++++++++++++
> > drivers/hid/hid-haptic.h | 127 ++++++++
> > drivers/hid/hid-input.c | 18 +-
> > drivers/hid/hid-multitouch.c | 47 +++
> > drivers/input/input-mt.c | 14 +-
> > include/linux/hid.h | 29 ++
> > include/linux/input/mt.h | 1 +
> > include/uapi/linux/input-event-codes.h | 1 +
> > include/uapi/linux/input.h | 22 +-
> > 12 files changed, 858 insertions(+), 7 deletions(-)
> > ---
> > base-commit: 86731a2a651e58953fc949573895f2fa6d456841
> > change-id: 20250625-support-forcepads-0b4f74fd3d0a
> >
> > Best regards,
> > --
> > Jonathan Denose <jdenose@google.com>
> >
> Hi all,
>
> Please let me know if there is anything else needed from me.
>
Dmitry, I've just re-reviewed and tested this series. I'm fine with it.
Can you give us your ack on the input bits?
Cheers,
Benjamin
^ permalink raw reply
* Re: [PATCH] HID: steelseries: refactor probe() and remove()
From: Jeongjun Park @ 2025-09-04 4:52 UTC (permalink / raw)
To: Jiri Kosina; +Cc: bentiss, hadess, linux-input, linux-kernel
In-Reply-To: <4r8n3287-o91r-4903-0o01-5q93834sp47n@xreary.bet>
Hello Jiri,
Jiri Kosina <jikos@kernel.org> wrote:
>
> On Thu, 17 Jul 2025, Jeongjun Park wrote:
>
> > steelseries_srws1_probe() still does not use devm_kzalloc() and
> > devm_led_classdev_register(), so there is a lot of code to safely manage
> > heap, which reduces readability and may cause memory leaks due to minor
> > patch mistakes in the future.
> >
> > Therefore, it should be changed to use devm_kzalloc() and
> > devm_led_classdev_register() to easily and safely manage heap.
> >
> > Also, the current steelseries driver mainly checks sd->quriks to determine
> > which product a specific HID device is, which is not the correct way.
> >
> > remove(), unlike probe(), does not receive struct hid_device_id as an
> > argument, so it must check hdev unconditionally to know which product
> > it is.
> >
> > However, since struct steelseries_device and struct steelseries_srws1_data
> > have different structures, if SRWS1 is removed in remove(), converts
> > hdev->dev, which is initialized to struct steelseries_srws1_data,
> > to struct steelseries_device and uses it. This causes various
> > memory-related bugs as completely unexpected values exist in member
> > variables of the structure.
> >
> > Therefore, in order to modify probe() and remove() to work properly,
> > Arctis 1, 9 should be added to HID_USB_DEVICE and some functions should be
> > modified to check hdev->product when determining HID device product.
> >
> > Fixes: a0c76896c3fb ("HID: steelseries: Add support for Arctis 1 XBox")
> > Signed-off-by: Jeongjun Park <aha310510@gmail.com>
>
> Applied to hid.git#for-6.18/steelseries, thanks.
>
I think this patch should be applied to 6.17 rc, not 6.18.
This is because while this patch primarily addresses a potential memory
leak, it also addresses a memory corruption vuln that occurs when using
the SRWS1 device.
Therefore, it should be patched quickly in the rc release, and the stable
release, where this bug exists, should also receive this patch.
> --
> Jiri Kosina
> SUSE Labs
>
Regards,
Jeongjun Park
^ permalink raw reply
* Re: [PATCH V0 0/2] Fix CONFIG_HYPERV and vmbus related anamoly
From: Mukesh R @ 2025-09-04 2:16 UTC (permalink / raw)
To: Michael Kelley, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
linux-hyperv@vger.kernel.org, netdev@vger.kernel.org,
linux-pci@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-fbdev@vger.kernel.org, linux-arch@vger.kernel.org,
virtualization@lists.linux.dev
Cc: maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, airlied@gmail.com, simona@ffwll.ch,
jikos@kernel.org, bentiss@kernel.org, kys@microsoft.com,
haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com,
dmitry.torokhov@gmail.com, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
pabeni@redhat.com, bhelgaas@google.com,
James.Bottomley@HansenPartnership.com, martin.petersen@oracle.com,
gregkh@linuxfoundation.org, deller@gmx.de, arnd@arndb.de,
sgarzare@redhat.com, horms@kernel.org
In-Reply-To: <SN6PR02MB4157917D84D00DBDAF54BD69D406A@SN6PR02MB4157.namprd02.prod.outlook.com>
On 9/2/25 07:42, Michael Kelley wrote:
> From: Mukesh Rathor <mrathor@linux.microsoft.com> Sent: Wednesday, August 27, 2025 6:00 PM
>>
>> At present, drivers/Makefile will subst =m to =y for CONFIG_HYPERV for hv
>> subdir. Also, drivers/hv/Makefile replaces =m to =y to build in
>> hv_common.c that is needed for the drivers. Moreover, vmbus driver is
>> built if CONFIG_HYPER is set, either loadable or builtin.
>>
>> This is not a good approach. CONFIG_HYPERV is really an umbrella config that
>> encompasses builtin code and various other things and not a dedicated config
>> option for VMBUS. Vmbus should really have a config option just like
>> CONFIG_HYPERV_BALLOON etc. This small series introduces CONFIG_HYPERV_VMBUS
>> to build VMBUS driver and make that distinction explicit. With that
>> CONFIG_HYPERV could be changed to bool.
>
> Separating the core hypervisor support (CONFIG_HYPERV) from the VMBus
> support (CONFIG_HYPERV_VMBUS) makes sense to me. Overall the code
> is already mostly in separate source files code, though there's some
> entanglement in the handling of VMBus interrupts, which could be
> improved later.
>
> However, I have a compatibility concern. Consider this scenario:
>
> 1) Assume running in a Hyper-V VM with a current Linux kernel version
> built with CONFIG_HYPERV=m.
> 2) Grab a new version of kernel source code that contains this patch set.
> 3) Run 'make olddefconfig' to create the .config file for the new kernel.
> 4) Build the new kernel. This succeeds.
> 5) Install and run the new kernel in the Hyper-V VM. This fails.
>
> The failure occurs because CONFIG_HYPERV=m is no longer legal,
> so the .config file created in Step 3 has CONFIG_HYPERV=n. The
> newly built kernel has no Hyper-V support and won't run in a
> Hyper-V VM.
>
> As a second issue, if in Step 1 the current kernel was built with
> CONFIG_HYPERV=y, then the .config file for the new kernel will have
> CONFIG_HYPERV=y, which is better. But CONFIG_HYPERV_VMBUS
> defaults to 'n', so the new kernel doesn't have any VMBus drivers
> and won't run in a typical Hyper-V VM.
>
> The second issue could be fixed by assigning CONFIG_HYPERV_VMBUS
> a default value, such as whatever CONFIG_HYPERV is set to. But
> I'm not sure how to fix the first issue, except by continuing to
> allow CONFIG_HYPERV=m.
To certain extent, imo, users are expected to check config files
for changes when moving to new versions/releases, so it would be a
one time burden. CONFIG_HYPERV=m is just broken imo as one sees that
in .config but magically symbols in drivers/hv are in kerenel.
Thanks,
-Mukesh
> See additional minor comments in Patches 1 and 2.
>
> Michael
>
>>
>> For now, hv_common.c is left as is to reduce conflicts for upcoming patches,
>> but once merges are mostly done, that and some others should be moved to
>> virt/hyperv directory.
>>
>> Mukesh Rathor (2):
>> hyper-v: Add CONFIG_HYPERV_VMBUS option
>> hyper-v: Make CONFIG_HYPERV bool
>>
>> drivers/Makefile | 2 +-
>> drivers/gpu/drm/Kconfig | 2 +-
>> drivers/hid/Kconfig | 2 +-
>> drivers/hv/Kconfig | 14 ++++++++++----
>> drivers/hv/Makefile | 4 ++--
>> drivers/input/serio/Kconfig | 4 ++--
>> drivers/net/hyperv/Kconfig | 2 +-
>> drivers/pci/Kconfig | 2 +-
>> drivers/scsi/Kconfig | 2 +-
>> drivers/uio/Kconfig | 2 +-
>> drivers/video/fbdev/Kconfig | 2 +-
>> include/asm-generic/mshyperv.h | 8 +++++---
>> net/vmw_vsock/Kconfig | 2 +-
>> 13 files changed, 28 insertions(+), 20 deletions(-)
>>
>> --
>> 2.36.1.vfs.0.0
>>
^ permalink raw reply
* Re: [PATCH v4] HID: logitech-dj: Add support for a new lightspeed receiver iteration
From: Stuart @ 2025-09-03 20:40 UTC (permalink / raw)
To: Mavroudis Chatzilazaridis
Cc: jikos, linux-input, benjamin.tissoires, hadess, lains
In-Reply-To: <f92cda21-12d2-4e4d-ae84-666c6f8dce77@protonmail.com>
> Can you apply this on top of the existing changes and test again?
Unfortunately, no change in behaviour
I forgot to mention in my original testing, I get a warning in my dmesg:
logitech-hidpp-device 0003:046D:408E.0007:
hidpp_root_get_protocol_version: received protocol error 0x08
Thanks,
Stuart
^ permalink raw reply
* Re: [PATCH v3] HID: lg-g15 - Add support for Logitech G13.
From: Leo L. Schwab @ 2025-09-03 19:39 UTC (permalink / raw)
To: Hans de Goede
Cc: Kate Hsuan, Jiri Kosina, Benjamin Tissoires, linux-input,
linux-kernel
In-Reply-To: <2de88077-eb8d-44ad-a96a-5db889913cba@kernel.org>
For some reason, your replies aren't making it to me directly -- I
had to find and scrape your reply off the LKML web site:
On Tue, 2 Sep 2025 23:05:06 +0200, Hans de Goede wrote:
> On 2-Sep-25 22:41, Leo L. Schwab wrote:
>> This does not happen. The G13 accepts and remembers backlight color
>> settings even when the LEDs have been toggled off locally.
>> [ ... ]
>
> I see, interesting.
>
> So what happens if you turn off the backlight with the toggle button on the G13
> and then write 0 to brightness in sysfs and then press the toggle button again?
>
It's a little difficult to see, but the backlight turns back on with
minimal brightness. To my eye, it looks like it's displaying #000001.
> Right it does seem that using cdev.brightness_hw_changed is valid in
> this case.
>
> But the LED API is supposed to have the brightness attribute present
> the actual current brightness of the device.
>
> I'm not sure how upower will react if the poll() on brightness_hw_changed
> wakes upower up and then the reported brightness is unchanged...
>
> I need to think about this a bit and check the upower code, let me
> get back to you on this in a day or 2 ...
>
Certainly.
>> This prompts the question: What is the full intensity calculation
>> formula intended to be? The docs appear to be rather quiet on this point.
>> If we assume all intensity/brightness values (0-255) are essentially mapped
>> to the range [0.0, 1.0], then it seems to me the calculation is:
>>
>> out = intensity * brightness * brightness_hw_changed
>
> The way the API is intended to work is that after a hw-brightness-changes
> event brightness == brightness_hw_changed in sysfs.
> [ ... ]
> IOW the formula should always be:
>
> out = intensity * brightness
>
Then this should be written down somewhere. A quick ripgrep through
the 6.16 source tree shows brightness_hw_changed is used in *very* few
places so far, so it'd be good to get this clarified before too many other
people start having competing interpretations.
> As mentioned before I need to think a bit about how to handle
> this. [ ... ]
Fair enough. I'll hold off on spinning a v6 until I hear from you.
Schwab
^ permalink raw reply
* Re: [PATCH v4] HID: logitech-dj: Add support for a new lightspeed receiver iteration
From: Mavroudis Chatzilazaridis @ 2025-09-03 19:34 UTC (permalink / raw)
To: Stuart; +Cc: jikos, linux-input, benjamin.tissoires, hadess, lains
In-Reply-To: <CALTg27=Q6a2yJK6y3MUSzngsbnpXhv6vwtS_Y-t0LaKg1kK7Ag@mail.gmail.com>
>> Thanks for taking the time to test it.
>
> No problem, I had a go at this a few years ago and had the same issue
> with my patches.
> I did email the last Logitech contact I could find associated with the
> driver, but he seems to have moved to a different part of the company.
>
>> Is your product id the same as the one in the patch or are you modifying
>> it before compiling?
>
> No modifications, it's 046d:c547
Awesome, thanks!
>
>> Can you please dump the HID descriptors from your receiver
>> (sudo usbhid-dump -m 046d:c547) and share them?
>
> Sure (hoping this doesn't get mangled):
>
> 001:003:002:DESCRIPTOR 1756919882.495801
> 06 00 FF 09 01 A1 01 85 10 95 06 75 08 15 00 26
> FF 00 09 01 81 00 09 01 91 00 C0 06 00 FF 09 02
> A1 01 85 11 95 13 75 08 15 00 26 FF 00 09 02 81
> 00 09 02 91 00 C0
>
> 001:003:001:DESCRIPTOR 1756919882.500790
> 05 01 09 06 A1 01 85 01 05 07 19 E0 29 E7 15 00
> 25 01 75 01 95 08 81 02 95 05 05 08 19 01 29 05
> 91 02 95 01 75 03 91 03 95 70 75 01 05 07 19 04
> 29 73 81 02 95 05 19 87 29 8B 81 02 95 03 19 90
> 29 92 81 02 C0 05 0C 09 01 A1 01 85 03 95 02 75
> 10 15 01 26 FF 02 19 01 2A FF 02 81 00 C0 05 01
> 09 80 A1 01 85 04 95 01 75 02 15 01 25 03 09 82
> 09 81 09 83 81 00 75 01 15 00 25 01 09 9B 81 06
> 75 05 81 03 C0
>
> 001:003:000:DESCRIPTOR 1756919882.504793
> 05 01 09 02 A1 01 09 01 A1 00 95 10 75 01 15 00
> 25 01 05 09 19 01 29 10 81 02 95 02 75 10 16 01
> 80 26 FF 7F 05 01 09 30 09 31 81 06 95 01 75 08
> 15 81 25 7F 09 38 81 06 95 01 05 0C 0A 38 02 81
> 06 C0 06 00 FF 09 F1 75 08 95 05 15 00 26 FF 00
> 81 00 C0
Alright, the HID report descriptors are identical to mine.
I looked at the descriptors again and I noticed that the report ID for
the LEDs, which was previously 14, is now 1.
Can you apply this on top of the existing changes and test again?
diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
index 00a975b70f59..dd51492258f3 100644
--- a/drivers/hid/hid-logitech-dj.c
+++ b/drivers/hid/hid-logitech-dj.c
@@ -78,6 +78,7 @@
#define REPORT_TYPE_SYSTEM_CONTROL 0x04
#define REPORT_TYPE_MEDIA_CENTER 0x08
#define REPORT_TYPE_LEDS 0x0E
+#define REPORT_TYPE_LEDS_LIGHTSPEED 0x01
/* RF Report types bitfield */
#define STD_KEYBOARD BIT(1)
@@ -1455,8 +1456,14 @@ static int logi_dj_ll_raw_request(struct hid_device *hid,
count, report_type, reqtype);
}
- if (buf[0] != REPORT_TYPE_LEDS)
- return -EINVAL;
+ /* This Lightspeed receiver type uses a different LED report ID */
+ if (djrcv_dev->type == recvr_type_gaming_hidpp_ls_1_3) {
+ if (buf[0] != REPORT_TYPE_LEDS_LIGHTSPEED)
+ return -EINVAL;
+ } else {
+ if (buf[0] != REPORT_TYPE_LEDS)
+ return -EINVAL;
+ }
if (djrcv_dev->type != recvr_type_dj && count >= 2) {
if (!djrcv_dev->keyboard) {
^ permalink raw reply related
* Re: [PATCH v4] HID: logitech-dj: Add support for a new lightspeed receiver iteration
From: Stuart @ 2025-09-03 17:21 UTC (permalink / raw)
To: Mavroudis Chatzilazaridis
Cc: jikos, linux-input, benjamin.tissoires, hadess, lains
In-Reply-To: <20d3b05b-dbe0-4802-b724-fe4ab5e279d6@protonmail.com>
> Thanks for taking the time to test it.
No problem, I had a go at this a few years ago and had the same issue
with my patches.
I did email the last Logitech contact I could find associated with the
driver, but he seems to have moved to a different part of the company.
> Is your product id the same as the one in the patch or are you modifying
> it before compiling?
No modifications, it's 046d:c547
> Can you please dump the HID descriptors from your receiver
> (sudo usbhid-dump -m 046d:c547) and share them?
Sure (hoping this doesn't get mangled):
001:003:002:DESCRIPTOR 1756919882.495801
06 00 FF 09 01 A1 01 85 10 95 06 75 08 15 00 26
FF 00 09 01 81 00 09 01 91 00 C0 06 00 FF 09 02
A1 01 85 11 95 13 75 08 15 00 26 FF 00 09 02 81
00 09 02 91 00 C0
001:003:001:DESCRIPTOR 1756919882.500790
05 01 09 06 A1 01 85 01 05 07 19 E0 29 E7 15 00
25 01 75 01 95 08 81 02 95 05 05 08 19 01 29 05
91 02 95 01 75 03 91 03 95 70 75 01 05 07 19 04
29 73 81 02 95 05 19 87 29 8B 81 02 95 03 19 90
29 92 81 02 C0 05 0C 09 01 A1 01 85 03 95 02 75
10 15 01 26 FF 02 19 01 2A FF 02 81 00 C0 05 01
09 80 A1 01 85 04 95 01 75 02 15 01 25 03 09 82
09 81 09 83 81 00 75 01 15 00 25 01 09 9B 81 06
75 05 81 03 C0
001:003:000:DESCRIPTOR 1756919882.504793
05 01 09 02 A1 01 09 01 A1 00 95 10 75 01 15 00
25 01 05 09 19 01 29 10 81 02 95 02 75 10 16 01
80 26 FF 7F 05 01 09 30 09 31 81 06 95 01 75 08
15 81 25 7F 09 38 81 06 95 01 05 0C 0A 38 02 81
06 C0 06 00 FF 09 F1 75 08 95 05 15 00 26 FF 00
81 00 C0
^ permalink raw reply
* [PATCH v1] Input: xpad - add ID for Flydigi Apex 5
From: Antheas Kapenekakis @ 2025-09-03 16:51 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input
Cc: linux-kernel, Antheas Kapenekakis, Brandon Lin,
Sergey Belozyorcev
The Flydigi Apex 5 has an XInput mode. Add the vid and pid for it.
Reported-by: Brandon Lin <brandon@emergence.ltd>
Reported-by: Sergey Belozyorcev <belozyorcev@ya.ru>
Closes: https://github.com/ublue-os/bazzite/issues/3014
Signed-off-by: Antheas Kapenekakis <lkml@antheas.dev>
---
drivers/input/joystick/xpad.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 4c94297e17e6..d72e89c25e50 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -422,6 +422,7 @@ static const struct xpad_device {
{ 0x3537, 0x1010, "GameSir G7 SE", 0, XTYPE_XBOXONE },
{ 0x366c, 0x0005, "ByoWave Proteus Controller", MAP_SHARE_BUTTON, XTYPE_XBOXONE, FLAG_DELAY_INIT },
{ 0x3767, 0x0101, "Fanatec Speedster 3 Forceshock Wheel", 0, XTYPE_XBOX },
+ { 0x37d7, 0x2501, "Flydigi Apex 5", 0, XTYPE_XBOX360 },
{ 0x413d, 0x2104, "Black Shark Green Ghost Gamepad", 0, XTYPE_XBOX360 },
{ 0xffff, 0xffff, "Chinese-made Xbox Controller", 0, XTYPE_XBOX },
{ 0x0000, 0x0000, "Generic X-Box pad", 0, XTYPE_UNKNOWN }
@@ -578,6 +579,7 @@ static const struct usb_device_id xpad_table[] = {
XPAD_XBOX360_VENDOR(0x3537), /* GameSir Controllers */
XPAD_XBOXONE_VENDOR(0x3537), /* GameSir Controllers */
XPAD_XBOXONE_VENDOR(0x366c), /* ByoWave controllers */
+ XPAD_XBOX360_VENDOR(0x37d7), /* Flydigi Controllers */
XPAD_XBOX360_VENDOR(0x413d), /* Black Shark Green Ghost Controller */
{ }
};
base-commit: 1b237f190eb3d36f52dffe07a40b5eb210280e00
--
2.51.0
^ permalink raw reply related
* [PATCH 1/1] dt-bindings: input: exc3000: move eeti,egalax_ts from egalax-ts.txt to eeti,exc3000.yaml
From: Frank Li @ 2025-09-03 16:34 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
open list:INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN)...,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
Cc: imx
Remove legacy binding egalax-ts.txt file. And add compatible string
eeti,egalax_ts and wakeup-gpios to eeti,exc3000.yaml. "eeti,egalax_ts" is
general compatible string, which is not preferred. But it is compatible
with old devices (older than 10 years) and existing driver in
drivers/input/touchscreen/egalax_ts.c.
Fix below DTB_CHECKS warnings:
arch/arm/boot/dts/nxp/imx/imx6dl-gw52xx.dtb: /soc/bus@2100000/i2c@21a8000/egalax_ts@4: failed to match any schema with compatible: ['eeti,egalax_ts']
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
.../input/touchscreen/eeti,exc3000.yaml | 18 +++++++++++++++---
.../bindings/input/touchscreen/egalax-ts.txt | 18 ------------------
2 files changed, 15 insertions(+), 21 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/egalax-ts.txt
diff --git a/Documentation/devicetree/bindings/input/touchscreen/eeti,exc3000.yaml b/Documentation/devicetree/bindings/input/touchscreen/eeti,exc3000.yaml
index 1c7ae05a8c15e..40449ed168284 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/eeti,exc3000.yaml
+++ b/Documentation/devicetree/bindings/input/touchscreen/eeti,exc3000.yaml
@@ -9,15 +9,13 @@ title: EETI EXC3000 series touchscreen controller
maintainers:
- Dmitry Torokhov <dmitry.torokhov@gmail.com>
-allOf:
- - $ref: touchscreen.yaml#
-
properties:
compatible:
oneOf:
- const: eeti,exc3000
- const: eeti,exc80h60
- const: eeti,exc80h84
+ - const: eeti,egalax_ts # Do NOT use for new binding
- items:
- enum:
- eeti,exc81w32
@@ -28,6 +26,8 @@ properties:
maxItems: 1
reset-gpios:
maxItems: 1
+ wakeup-gpios:
+ maxItems: 1
vdd-supply:
description: Power supply regulator for the chip
touchscreen-size-x: true
@@ -45,6 +45,18 @@ required:
additionalProperties: false
+allOf:
+ - $ref: touchscreen.yaml#
+
+ - if:
+ properties:
+ compatible:
+ not:
+ const: eeti,egalax_ts
+ then:
+ properties:
+ wakeup-gpios: false
+
examples:
- |
#include "dt-bindings/interrupt-controller/irq.h"
diff --git a/Documentation/devicetree/bindings/input/touchscreen/egalax-ts.txt b/Documentation/devicetree/bindings/input/touchscreen/egalax-ts.txt
deleted file mode 100644
index ebbe938105745..0000000000000
--- a/Documentation/devicetree/bindings/input/touchscreen/egalax-ts.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-* EETI eGalax Multiple Touch Controller
-
-Required properties:
-- compatible: must be "eeti,egalax_ts"
-- reg: i2c slave address
-- interrupts: touch controller interrupt
-- wakeup-gpios: the gpio pin to be used for waking up the controller
- and also used as irq pin
-
-Example:
-
- touchscreen@4 {
- compatible = "eeti,egalax_ts";
- reg = <0x04>;
- interrupt-parent = <&gpio1>;
- interrupts = <9 IRQ_TYPE_LEVEL_LOW>;
- wakeup-gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;
- };
--
2.34.1
^ permalink raw reply related
* [PATCH v1 1/1] input: touchscreen: atmel_mxt_ts: add support for generic touchscreen configurations
From: Svyatoslav Ryhel @ 2025-09-03 16:23 UTC (permalink / raw)
To: Nick Dyer, Dmitry Torokhov, Henrik Rydberg, Svyatoslav Ryhel
Cc: linux-input, linux-kernel
In-Reply-To: <20250903162327.109538-1-clamor95@gmail.com>
This provides support for generic touchscreen configuration options like
swapped-x-y, min-x, min-y, size-x, size-y, etc.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
drivers/input/touchscreen/atmel_mxt_ts.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
index 322d5a3d40a0..fc624101147e 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -19,6 +19,7 @@
#include <linux/firmware.h>
#include <linux/i2c.h>
#include <linux/input/mt.h>
+#include <linux/input/touchscreen.h>
#include <linux/interrupt.h>
#include <linux/irq.h>
#include <linux/of.h>
@@ -355,6 +356,8 @@ struct mxt_data {
enum mxt_suspend_mode suspend_mode;
u32 wakeup_method;
+
+ struct touchscreen_properties prop;
};
struct mxt_vb2_buffer {
@@ -888,8 +891,7 @@ static void mxt_proc_t9_message(struct mxt_data *data, u8 *message)
/* Touch active */
input_mt_report_slot_state(input_dev, MT_TOOL_FINGER, 1);
- input_report_abs(input_dev, ABS_MT_POSITION_X, x);
- input_report_abs(input_dev, ABS_MT_POSITION_Y, y);
+ touchscreen_report_pos(input_dev, &data->prop, x, y, true);
input_report_abs(input_dev, ABS_MT_PRESSURE, amplitude);
input_report_abs(input_dev, ABS_MT_TOUCH_MAJOR, area);
} else {
@@ -1010,8 +1012,7 @@ static void mxt_proc_t100_message(struct mxt_data *data, u8 *message)
id, type, x, y, major, pressure, orientation);
input_mt_report_slot_state(input_dev, tool, 1);
- input_report_abs(input_dev, ABS_MT_POSITION_X, x);
- input_report_abs(input_dev, ABS_MT_POSITION_Y, y);
+ touchscreen_report_pos(input_dev, &data->prop, x, y, true);
input_report_abs(input_dev, ABS_MT_TOUCH_MAJOR, major);
input_report_abs(input_dev, ABS_MT_PRESSURE, pressure);
input_report_abs(input_dev, ABS_MT_DISTANCE, distance);
@@ -2212,6 +2213,8 @@ static int mxt_initialize_input_device(struct mxt_data *data)
0, 255, 0, 0);
}
+ touchscreen_parse_properties(input_dev, true, &data->prop);
+
/* For T15 and T97 Key Array */
if (data->T15_reportid_min || data->T97_reportid_min) {
for (i = 0; i < data->t15_num_keys; i++)
--
2.48.1
^ permalink raw reply related
* [PATCH v1 0/1] input: touchscreen: atmel_mxt_ts: add support for generic touchscreen configurations
From: Svyatoslav Ryhel @ 2025-09-03 16:23 UTC (permalink / raw)
To: Nick Dyer, Dmitry Torokhov, Henrik Rydberg, Svyatoslav Ryhel
Cc: linux-input, linux-kernel
This provides support for generic touchscreen configuration options like
swapped-x-y, min-x, min-y, size-x, size-y, etc.
Svyatoslav Ryhel (1):
input: touchscreen: atmel_mxt_ts: add support for generic touchscreen
configurations
drivers/input/touchscreen/atmel_mxt_ts.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
--
2.48.1
^ permalink raw reply
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