* Re: supporting binary (near-far) proximity sensors over gpio
From: Jeff LaBundy @ 2023-11-26 4:33 UTC (permalink / raw)
To: David Lechner
Cc: Sicelo, linux-iio, maemo-leste, Ivaylo Dimitrov, linux-input
In-Reply-To: <CAMknhBE5A3w7ntdWC9cFDYSrPQNPoH7sQ5PVXKEy6MAJmZ93SA@mail.gmail.com>
Hi Sicelo and David,
On Sat, Nov 18, 2023 at 06:09:18PM -0600, David Lechner wrote:
> On Fri, Nov 17, 2023 at 12:22 PM Sicelo <absicsz@gmail.com> wrote:
> >
> > Hi
> >
> > Some phones have 1-bit proximity sensors, which simply toggle a GPIO
> > line to indicate that an object is near or far. Thresholds are set at
> > hardware level. One such sensor is OSRAM SFH 7741 [1], which is used on
> > the Nokia N900.
> >
> > It is currently exported over evdev, emitting the SW_FRONT_PROXIMITY key
> > code [2].
> >
> > So the question is: should a new, general purpose iio-gpio driver be
> > written, that would switch such a proximity sensor to the iio framework?
> > Or evdev is really the best place to support it?
> >
> > There are a couple of people who are willing to write such an iio
> > driver, if iio is the way to go.
> >
> > Regards,
> > Sicelo
> >
> > [1] https://media.digikey.com/pdf/Data%20Sheets/Osram%20PDFs/SFH_7741.pdf
> > [2] https://elixir.bootlin.com/linux/v6.6.1/source/arch/arm/boot/dts/ti/omap/omap3-n900.dts#L111
> >
> Since this is really a proximity switch (it is either on or off)
> rather than measuring a proximity value over a continuous range, it
> doesn't seem like a good fit for the iio subsystem. If the sensor is
> on a phone, then it is likely to detect human presence so the input
> subsystem does seem like the right one for that application.
>
> More at https://www.kernel.org/doc/html/latest/driver-api/iio/intro.html
>
I tend to agree; if there are only two discrete states as is the case for a
GPIO, then this is technically a switch and not a sensor. Therefore, input
seems like a better fit; that is just my $.02.
FWIW, a similar discussion came up a few years ago in [1] and again the key
differentiator was whether the output is discrete or continuous.
Kind regards,
Jeff LaBundy
[1] https://lore.kernel.org/linux-iio/9f9b0ff6-3bf1-63c4-eb36-901cecd7c4d9@redhat.com/
^ permalink raw reply
* [PATCH v1] dt-bindings: input: convert gpio-mouse to json-schema
From: Anshul Dalal @ 2023-11-26 10:30 UTC (permalink / raw)
To: linux-input, devicetree
Cc: Anshul Dalal, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Linus Walleij, linux-kernel, linux-kernel-mentees
Convert device tree binding documentation for GPIO attached mouse to
json-schema.
Signed-off-by: Anshul Dalal <anshulusr@gmail.com>
---
.../devicetree/bindings/input/gpio-mouse.txt | 32 ---------
.../devicetree/bindings/input/gpio-mouse.yaml | 68 +++++++++++++++++++
2 files changed, 68 insertions(+), 32 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/input/gpio-mouse.txt
create mode 100644 Documentation/devicetree/bindings/input/gpio-mouse.yaml
diff --git a/Documentation/devicetree/bindings/input/gpio-mouse.txt b/Documentation/devicetree/bindings/input/gpio-mouse.txt
deleted file mode 100644
index 519510a11af9..000000000000
--- a/Documentation/devicetree/bindings/input/gpio-mouse.txt
+++ /dev/null
@@ -1,32 +0,0 @@
-Device-Tree bindings for GPIO attached mice
-
-This simply uses standard GPIO handles to define a simple mouse connected
-to 5-7 GPIO lines.
-
-Required properties:
- - compatible: must be "gpio-mouse"
- - scan-interval-ms: The scanning interval in milliseconds
- - up-gpios: GPIO line phandle to the line indicating "up"
- - down-gpios: GPIO line phandle to the line indicating "down"
- - left-gpios: GPIO line phandle to the line indicating "left"
- - right-gpios: GPIO line phandle to the line indicating "right"
-
-Optional properties:
- - button-left-gpios: GPIO line handle to the left mouse button
- - button-middle-gpios: GPIO line handle to the middle mouse button
- - button-right-gpios: GPIO line handle to the right mouse button
-Example:
-
-#include <dt-bindings/gpio/gpio.h>
-
-gpio-mouse {
- compatible = "gpio-mouse";
- scan-interval-ms = <50>;
- up-gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
- down-gpios = <&gpio0 1 GPIO_ACTIVE_LOW>;
- left-gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
- right-gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
- button-left-gpios = <&gpio0 4 GPIO_ACTIVE_LOW>;
- button-middle-gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;
- button-right-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
-};
diff --git a/Documentation/devicetree/bindings/input/gpio-mouse.yaml b/Documentation/devicetree/bindings/input/gpio-mouse.yaml
new file mode 100644
index 000000000000..3928ec6aff1d
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/gpio-mouse.yaml
@@ -0,0 +1,68 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/gpio-mouse.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: GPIO attached mouse
+
+description: |
+ This simply uses standard GPIO handles to define a simple mouse connected
+ to 5-7 GPIO lines.
+
+maintainers:
+ - Anshul Dalal <anshulusr@gmail.com>
+
+properties:
+ compatible:
+ const: gpio-mouse
+
+ scan-interval-ms:
+ maxItems: 1
+
+ up-gpios:
+ maxItems: 1
+
+ down-gpios:
+ maxItems: 1
+
+ left-gpios:
+ maxItems: 1
+
+ right-gpios:
+ maxItems: 1
+
+ button-left-gpios:
+ maxItems: 1
+
+ button-middle-gpios:
+ maxItems: 1
+
+ button-right-gpios:
+ maxItems: 1
+
+required:
+ - compatible
+ - scan-interval-ms
+ - up-gpios
+ - down-gpios
+ - left-gpios
+ - right-gpios
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ gpio-mouse {
+ compatible = "gpio-mouse";
+ scan-interval-ms = <50>;
+ up-gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
+ down-gpios = <&gpio0 1 GPIO_ACTIVE_LOW>;
+ left-gpios = <&gpio0 2 GPIO_ACTIVE_LOW>;
+ right-gpios = <&gpio0 3 GPIO_ACTIVE_LOW>;
+ button-left-gpios = <&gpio0 4 GPIO_ACTIVE_LOW>;
+ button-middle-gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;
+ button-right-gpios = <&gpio0 6 GPIO_ACTIVE_LOW>;
+ };
--
2.42.1
^ permalink raw reply related
* Re: supporting binary (near-far) proximity sensors over gpio
From: Philipp Jungkamp @ 2023-11-26 10:59 UTC (permalink / raw)
To: Jeff LaBundy, David Lechner
Cc: Sicelo, linux-iio, maemo-leste, Ivaylo Dimitrov, linux-input
In-Reply-To: <ZWLKsVu/v8m9nA0U@nixie71>
Hi,
would it make sense to move the HID human presence driver at
drivers/iio/light/hid-sensor-prox.c to the input system then? This
driver only checks for the "Biometric" (0x2004b0) and "Biometric: Human
Presence" (0x2004b1) HID usages. The former has a vendor defined value
range, the latter is defined as a boolean switch. See the HID Usage
Tables, section 21.1 and 21.6.
I take from this discussion that the input subsystem would make more
sense for the "Biometric: Human Presence" usage.
I just wanted to chime in as there seems to be some older precedent for
a binary sensor in the iio subsystem. I tried to get that sensor
working for the proximity sensor on my laptop last year.
Regards,
Philipp Jungkamp
On Sat, 2023-11-25 at 22:33 -0600, Jeff LaBundy wrote:
> Hi Sicelo and David,
>
> On Sat, Nov 18, 2023 at 06:09:18PM -0600, David Lechner wrote:
> > On Fri, Nov 17, 2023 at 12:22 PM Sicelo <absicsz@gmail.com> wrote:
> > >
> > > Hi
> > >
> > > Some phones have 1-bit proximity sensors, which simply toggle a
> > > GPIO
> > > line to indicate that an object is near or far. Thresholds are
> > > set at
> > > hardware level. One such sensor is OSRAM SFH 7741 [1], which is
> > > used on
> > > the Nokia N900.
> > >
> > > It is currently exported over evdev, emitting the
> > > SW_FRONT_PROXIMITY key
> > > code [2].
> > >
> > > So the question is: should a new, general purpose iio-gpio driver
> > > be
> > > written, that would switch such a proximity sensor to the iio
> > > framework?
> > > Or evdev is really the best place to support it?
> > >
> > > There are a couple of people who are willing to write such an iio
> > > driver, if iio is the way to go.
> > >
> > > Regards,
> > > Sicelo
> > >
> > > [1]
> > > https://media.digikey.com/pdf/Data%20Sheets/Osram%20PDFs/SFH_7741.pdf
> > > [2]
> > > https://elixir.bootlin.com/linux/v6.6.1/source/arch/arm/boot/dts/ti/omap/omap3-n900.dts#L111
> > >
> > Since this is really a proximity switch (it is either on or off)
> > rather than measuring a proximity value over a continuous range, it
> > doesn't seem like a good fit for the iio subsystem. If the sensor
> > is
> > on a phone, then it is likely to detect human presence so the input
> > subsystem does seem like the right one for that application.
> >
> > More at
> > https://www.kernel.org/doc/html/latest/driver-api/iio/intro.html
> >
>
> I tend to agree; if there are only two discrete states as is the case
> for a
> GPIO, then this is technically a switch and not a sensor. Therefore,
> input
> seems like a better fit; that is just my $.02.
>
> FWIW, a similar discussion came up a few years ago in [1] and again
> the key
> differentiator was whether the output is discrete or continuous.
>
> Kind regards,
> Jeff LaBundy
>
> [1]
> https://lore.kernel.org/linux-iio/9f9b0ff6-3bf1-63c4-eb36-901cecd7c4d9@redhat.com/
>
^ permalink raw reply
* Re: [PATCH v1] dt-bindings: input: convert gpio-mouse to json-schema
From: Linus Walleij @ 2023-11-26 20:08 UTC (permalink / raw)
To: Anshul Dalal
Cc: linux-input, devicetree, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-kernel,
linux-kernel-mentees
In-Reply-To: <20231126103029.851742-1-anshulusr@gmail.com>
On Sun, Nov 26, 2023 at 11:32 AM Anshul Dalal <anshulusr@gmail.com> wrote:
> Convert device tree binding documentation for GPIO attached mouse to
> json-schema.
>
> Signed-off-by: Anshul Dalal <anshulusr@gmail.com>
Nice work! It looks flawless, making good use of default typing suffixes
-ms -gpios.
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] Input: omap4-keypad: react on keypresses if device is runtime-suspended
From: Andreas Kemnade @ 2023-11-26 19:43 UTC (permalink / raw)
To: dmitry.torokhov, tony, u.kleine-koenig, robh, Jonathan.Cameron,
andreas, frank.li, linux-input, linux-kernel
According to SWPU235AB, table 26-6, fclk is required to generate events
at least on OMAP4460, so keep fclk enabled all the time the device
is opened.
Suggested-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Andreas Kemnade <andreas@kemnade.info>
Reviewed-by: Tony Lindgren <tony@atomide.com>
---
Changes since RFC:
- add R-by:
drivers/input/keyboard/omap4-keypad.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/input/keyboard/omap4-keypad.c b/drivers/input/keyboard/omap4-keypad.c
index d3f8688fdd9c3..7d83aff95617f 100644
--- a/drivers/input/keyboard/omap4-keypad.c
+++ b/drivers/input/keyboard/omap4-keypad.c
@@ -11,6 +11,7 @@
#include <linux/module.h>
#include <linux/interrupt.h>
#include <linux/platform_device.h>
+#include <linux/clk.h>
#include <linux/errno.h>
#include <linux/io.h>
#include <linux/of.h>
@@ -83,6 +84,7 @@ struct omap4_keypad {
bool no_autorepeat;
u64 keys;
unsigned short *keymap;
+ struct clk *fck;
};
static int kbd_readl(struct omap4_keypad *keypad_data, u32 offset)
@@ -211,6 +213,8 @@ static int omap4_keypad_open(struct input_dev *input)
disable_irq(keypad_data->irq);
+ clk_prepare_enable(keypad_data->fck);
+
kbd_writel(keypad_data, OMAP4_KBD_CTRL,
OMAP4_DEF_CTRL_NOSOFTMODE |
(OMAP4_KEYPAD_PTV_DIV_128 << OMAP4_DEF_CTRL_PTV_SHIFT));
@@ -258,6 +262,7 @@ static void omap4_keypad_close(struct input_dev *input)
disable_irq(keypad_data->irq);
omap4_keypad_stop(keypad_data);
enable_irq(keypad_data->irq);
+ clk_disable_unprepare(keypad_data->fck);
pm_runtime_mark_last_busy(dev);
pm_runtime_put_autosuspend(dev);
@@ -356,6 +361,11 @@ static int omap4_keypad_probe(struct platform_device *pdev)
}
keypad_data->irq = irq;
+ keypad_data->fck = devm_clk_get(&pdev->dev, "fck");
+ if (IS_ERR(keypad_data->fck))
+ return dev_err_probe(&pdev->dev, PTR_ERR(keypad_data->fck),
+ "unable to get fck");
+
mutex_init(&keypad_data->lock);
platform_set_drvdata(pdev, keypad_data);
--
2.39.2
^ permalink raw reply related
* Re: [PATCH v1] dt-bindings: input: convert gpio-mouse to json-schema
From: Krzysztof Kozlowski @ 2023-11-27 7:13 UTC (permalink / raw)
To: Anshul Dalal, linux-input, devicetree
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Linus Walleij, linux-kernel, linux-kernel-mentees
In-Reply-To: <20231126103029.851742-1-anshulusr@gmail.com>
On 26/11/2023 11:30, Anshul Dalal wrote:
> Convert device tree binding documentation for GPIO attached mouse to
> json-schema.
>
> Signed-off-by: Anshul Dalal <anshulusr@gmail.com>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply
* [dtor-input:master] BUILD REGRESSION fedfa36d045ab78ea9a0aa2c5a3d5d74c27207d3
From: kernel test robot @ 2023-11-27 8:05 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git master
branch HEAD: fedfa36d045ab78ea9a0aa2c5a3d5d74c27207d3 Input: cap11xx - remove unnecessary IRQ parsing
Error/Warning ids grouped by kconfigs:
gcc_recent_errors
`-- powerpc-randconfig-r131-20231126
|-- arch-powerpc-kexec-core.c:sparse:sparse:incorrect-type-in-assignment-(different-base-types)-expected-unsigned-long-long-static-addressable-toplevel-usertype-crashk_base-got-restricted-__be32-usertype
|-- arch-powerpc-kexec-core.c:sparse:sparse:incorrect-type-in-assignment-(different-base-types)-expected-unsigned-long-long-static-addressable-toplevel-usertype-crashk_size-got-restricted-__be32-usertype
|-- arch-powerpc-kexec-core.c:sparse:sparse:incorrect-type-in-assignment-(different-base-types)-expected-unsigned-long-long-static-addressable-toplevel-usertype-kernel_end-got-restricted-__be32-usertype
|-- arch-powerpc-sysdev-fsl_rio.c:sparse:sparse:symbol-fsl_map_inb_mem-was-not-declared.-Should-it-be-static
|-- arch-powerpc-sysdev-fsl_rio.c:sparse:sparse:symbol-fsl_unmap_inb_mem-was-not-declared.-Should-it-be-static
`-- arch-powerpc-sysdev-fsl_rmu.c:sparse:sparse:symbol-msg_unit_error_handler-was-not-declared.-Should-it-be-static
clang_recent_errors
|-- arm-randconfig-003-20231126
| `-- bin-bash:line:Segmentation-fault-scripts-mod-modpost-m-a-w-N-W-o-Module.symvers-n-T-modules.order-vmlinux.o
|-- hexagon-randconfig-002-20231126
| |-- drivers-media-platform-mediatek-mdp3-mtk-mdp3-comp.c:warning:unused-variable-mdp_comp_dt_ids
| `-- drivers-media-platform-mediatek-mdp3-mtk-mdp3-core.c:warning:unused-variable-mdp_of_ids
|-- powerpc64-randconfig-r123-20231126
| |-- arch-powerpc-kvm-book3s_64_vio.c:sparse:sparse:cast-to-restricted-__be64
| |-- arch-powerpc-kvm-book3s_64_vio.c:sparse:sparse:function-kvm_spapr_tce_attach_iommu_group-with-external-linkage-has-definition
| `-- arch-powerpc-kvm-book3s_64_vio.c:sparse:sparse:function-kvm_spapr_tce_release_iommu_group-with-external-linkage-has-definition
`-- s390-randconfig-r121-20231126
|-- open-dice.c:(.text):undefined-reference-to-devm_memremap
|-- s39-linux-ld:irq-al-fic.c:(.init.text):undefined-reference-to-iounmap
|-- s39-linux-ld:open-dice.c:(.text):undefined-reference-to-devm_memunmap
`-- xillybus_of.c:(.text):undefined-reference-to-devm_platform_ioremap_resource
elapsed time: 1448m
configs tested: 211
configs skipped: 3
tested configs:
alpha allnoconfig gcc
alpha allyesconfig gcc
alpha defconfig gcc
arc allmodconfig gcc
arc allnoconfig gcc
arc allyesconfig gcc
arc defconfig gcc
arc randconfig-001-20231126 gcc
arc randconfig-002-20231126 gcc
arm allmodconfig gcc
arm allnoconfig gcc
arm allyesconfig gcc
arm aspeed_g5_defconfig gcc
arm defconfig clang
arm lpc18xx_defconfig gcc
arm lpc32xx_defconfig clang
arm mps2_defconfig gcc
arm mv78xx0_defconfig clang
arm orion5x_defconfig clang
arm pxa_defconfig gcc
arm randconfig-001-20231126 clang
arm randconfig-002-20231126 clang
arm randconfig-003-20231126 clang
arm randconfig-004-20231126 clang
arm spear6xx_defconfig gcc
arm versatile_defconfig clang
arm64 allmodconfig clang
arm64 allnoconfig gcc
arm64 defconfig gcc
arm64 randconfig-001-20231126 clang
arm64 randconfig-002-20231126 clang
arm64 randconfig-003-20231126 clang
arm64 randconfig-004-20231126 clang
csky allmodconfig gcc
csky allnoconfig gcc
csky allyesconfig gcc
csky defconfig gcc
csky randconfig-001-20231126 gcc
csky randconfig-002-20231126 gcc
hexagon allmodconfig clang
hexagon allnoconfig clang
hexagon allyesconfig clang
hexagon defconfig clang
hexagon randconfig-001-20231126 clang
hexagon randconfig-002-20231126 clang
i386 allmodconfig clang
i386 allnoconfig clang
i386 allyesconfig clang
i386 buildonly-randconfig-001-20231126 clang
i386 buildonly-randconfig-002-20231126 clang
i386 buildonly-randconfig-003-20231126 clang
i386 buildonly-randconfig-004-20231126 clang
i386 buildonly-randconfig-005-20231126 clang
i386 buildonly-randconfig-006-20231126 clang
i386 defconfig gcc
i386 randconfig-001-20231126 clang
i386 randconfig-002-20231126 clang
i386 randconfig-003-20231126 clang
i386 randconfig-004-20231126 clang
i386 randconfig-005-20231126 clang
i386 randconfig-006-20231126 clang
i386 randconfig-011-20231126 gcc
i386 randconfig-012-20231126 gcc
i386 randconfig-013-20231126 gcc
i386 randconfig-014-20231126 gcc
i386 randconfig-015-20231126 gcc
i386 randconfig-016-20231126 gcc
loongarch allmodconfig gcc
loongarch allnoconfig gcc
loongarch allyesconfig gcc
loongarch defconfig gcc
loongarch randconfig-001-20231126 gcc
loongarch randconfig-002-20231126 gcc
m68k allmodconfig gcc
m68k allnoconfig gcc
m68k allyesconfig gcc
m68k amiga_defconfig gcc
m68k bvme6000_defconfig gcc
m68k defconfig gcc
m68k mvme16x_defconfig gcc
m68k virt_defconfig gcc
microblaze allmodconfig gcc
microblaze allnoconfig gcc
microblaze allyesconfig gcc
microblaze defconfig gcc
mips allmodconfig gcc
mips allnoconfig clang
mips allyesconfig gcc
mips cobalt_defconfig gcc
mips cu1830-neo_defconfig clang
mips jazz_defconfig gcc
mips maltaaprp_defconfig clang
mips rb532_defconfig gcc
mips rs90_defconfig clang
mips vocore2_defconfig gcc
nios2 allmodconfig gcc
nios2 allnoconfig gcc
nios2 allyesconfig gcc
nios2 defconfig gcc
nios2 randconfig-001-20231126 gcc
nios2 randconfig-002-20231126 gcc
openrisc allmodconfig gcc
openrisc allnoconfig gcc
openrisc allyesconfig gcc
openrisc defconfig gcc
parisc allmodconfig gcc
parisc allnoconfig gcc
parisc allyesconfig gcc
parisc defconfig gcc
parisc randconfig-001-20231126 gcc
parisc randconfig-002-20231126 gcc
parisc64 defconfig gcc
powerpc allmodconfig clang
powerpc allnoconfig gcc
powerpc allyesconfig clang
powerpc asp8347_defconfig gcc
powerpc canyonlands_defconfig gcc
powerpc cm5200_defconfig gcc
powerpc eiger_defconfig gcc
powerpc ep8248e_defconfig gcc
powerpc mpc8315_rdb_defconfig clang
powerpc randconfig-001-20231126 clang
powerpc randconfig-002-20231126 clang
powerpc randconfig-003-20231126 clang
powerpc sam440ep_defconfig gcc
powerpc tqm8541_defconfig gcc
powerpc64 randconfig-001-20231126 clang
powerpc64 randconfig-002-20231126 clang
powerpc64 randconfig-003-20231126 clang
riscv allmodconfig gcc
riscv allnoconfig clang
riscv allyesconfig gcc
riscv defconfig gcc
riscv randconfig-001-20231126 clang
riscv randconfig-002-20231126 clang
riscv rv32_defconfig clang
s390 allmodconfig gcc
s390 allnoconfig gcc
s390 allyesconfig gcc
s390 defconfig gcc
s390 randconfig-001-20231126 gcc
s390 randconfig-002-20231126 gcc
sh allmodconfig gcc
sh allnoconfig gcc
sh allyesconfig gcc
sh defconfig gcc
sh kfr2r09-romimage_defconfig gcc
sh landisk_defconfig gcc
sh migor_defconfig gcc
sh randconfig-001-20231126 gcc
sh randconfig-002-20231126 gcc
sh rsk7269_defconfig gcc
sh rts7751r2d1_defconfig gcc
sh se7343_defconfig gcc
sh se7619_defconfig gcc
sh se7724_defconfig gcc
sh se7751_defconfig gcc
sh sh03_defconfig gcc
sh sh7757lcr_defconfig gcc
sparc allmodconfig gcc
sparc allyesconfig gcc
sparc64 allmodconfig gcc
sparc64 allyesconfig gcc
sparc64 defconfig gcc
sparc64 randconfig-001-20231126 gcc
sparc64 randconfig-002-20231126 gcc
um allmodconfig clang
um allnoconfig clang
um allyesconfig clang
um defconfig gcc
um i386_defconfig gcc
um randconfig-001-20231126 clang
um randconfig-002-20231126 clang
um x86_64_defconfig gcc
x86_64 allnoconfig gcc
x86_64 allyesconfig clang
x86_64 buildonly-randconfig-001-20231126 clang
x86_64 buildonly-randconfig-002-20231126 clang
x86_64 buildonly-randconfig-003-20231126 clang
x86_64 buildonly-randconfig-004-20231126 clang
x86_64 buildonly-randconfig-005-20231126 clang
x86_64 buildonly-randconfig-006-20231126 clang
x86_64 defconfig gcc
x86_64 kexec gcc
x86_64 randconfig-001-20231126 gcc
x86_64 randconfig-002-20231126 gcc
x86_64 randconfig-003-20231126 gcc
x86_64 randconfig-004-20231126 gcc
x86_64 randconfig-005-20231126 gcc
x86_64 randconfig-006-20231126 gcc
x86_64 randconfig-011-20231126 clang
x86_64 randconfig-012-20231126 clang
x86_64 randconfig-013-20231126 clang
x86_64 randconfig-014-20231126 clang
x86_64 randconfig-015-20231126 clang
x86_64 randconfig-016-20231126 clang
x86_64 randconfig-071-20231126 clang
x86_64 randconfig-072-20231126 clang
x86_64 randconfig-073-20231126 clang
x86_64 randconfig-074-20231126 clang
x86_64 randconfig-075-20231126 clang
x86_64 randconfig-076-20231126 clang
x86_64 rhel-8.3-bpf gcc
x86_64 rhel-8.3-rust clang
x86_64 rhel-8.3 gcc
xtensa allnoconfig gcc
xtensa allyesconfig gcc
xtensa generic_kc705_defconfig gcc
xtensa nommu_kc705_defconfig gcc
xtensa randconfig-001-20231126 gcc
xtensa randconfig-002-20231126 gcc
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: Implement per-key keyboard backlight as auxdisplay?
From: Werner Sembach @ 2023-11-27 10:59 UTC (permalink / raw)
To: Hans de Goede, Pavel Machek, Jani Nikula, jikos,
Jelle van der Waa
Cc: Miguel Ojeda, Lee Jones, linux-kernel,
dri-devel@lists.freedesktop.org, linux-input, ojeda, linux-leds
In-Reply-To: <4222268b-ff44-4b7d-bf11-e350594bbe24@redhat.com>
Hi Hans,
Am 22.11.23 um 19:34 schrieb Hans de Goede:
> Hi Werner,
[snip]
>>>> Another idea I want to throw in the mix:
>>>>
>>>> Maybe the kernel is not the right place to implement this at all. RGB stuff is not at all standardized and every vendor is doing completely different interfaces, which does not fit the kernel userpsace apis desire to be uniformal and fixed. e.g. Auxdisplay might fit static setting of RGB values, but it does not fit the snake-effect mode, or the raindrops mode, or the 4-different-colors-in-the-edges-breathing-and-color-cycling mode.
>>>>
>>>> So my current idea: Implement these keyboards as a single zone RGB kbd_backlight in the leds interface to have something functional out of the box, but make it runtime disable-able if something like https://gitlab.com/CalcProgrammer1/OpenRGB wants to take over more fine granular control from userspace via hidraw.
>>> That sounds like a good approach to me. We are seeing the same with game controllers where steam and wine/proton also sometimes use hidraw mode to get access to all the crazy^W interesting features.
>>>
>>> That would mean that all we need to standardize and the kernel <-> userspace API level is adding a standard way to disable the single zone RGB kbd_backlight support in the kernel.
>> I would suggest a simple "enable" entry. Default is 1. When set to 0 the kernel driver no longer does anything.
> I'm not in favor of using "enable" as sysfs attribute for this,
> I would like to see a more descriptive name, how about:
>
> "disable_kernel_kbd_backlight_support"
>
> And then maybe also have the driver actually unregister
> the LED class device ?
>
> Or just make the support inactive when writing 1 to
> this and allow re-enabling it by writing 0?
Unregistering would mean that it can't be reenabled without module reload/reboot?
I would prefer that the userspace driver could easily give back control to the
leds interface.
>
>> Questions:
>>
>> - Should the driver try to reset the settings to boot default? Or just leave the device in the current state? With the former I could see issues that they keyboard is flashing when changing from kernelspace control to userspace control. With the later the burden on bringing the device to a know state lies with the userspace driver.
> My vote would go to leave the state as is. Even if the hw
> does not support state readback, then the userspace code
> can readback the state before writing 1 to
> "disable_kernel_kbd_backlight_support"
ack
>
>> - Should this be a optional entry that only shows up on drivers supporting it, or could this implemented in a generic way affecting all current led entries?
> IMHO this should be optional. If we go with the variant
> where writing 1 to "disable_kernel_kbd_backlight_support"
> just disables support and 0 re-enables it then I guess
> we could have support for this in the LED-core, enabled
> by a flag set by the driver.
>
> If we go with unregistering the led class device,
> then this needs to be mostly handled in the driver.
>
> Either way the kernel driver should know about this even
> if it is mostly handled in the LED core so that e.g.
> it does not try to restore settings on resume from suspend.
So a generic implementation would still require all current led drivers to be
touched?
For the sake of simplicity I would then prefer the optional variant.
>
>> - I guess UPower integration for the userspace driver could be archived with https://www.kernel.org/doc/html/latest/leds/uleds.html however this limited to brightness atm, so when accent colors actually come to UPower this would also need some expansion to be able to pass a preferred color to the userspace driver (regardless of what that driver is then doing with that information).
> Using uleds is an interesting suggestion, but upower atm
> does not support LED class kbd_backlight devices getting
> hot-plugged. It only scans for them once at boot.
>
> Jelle van der Waa (a colleague of mine, added to the Cc)
> has indicated he is interested in maybe working on fixing
> this upower short-coming as a side project, once his
> current side-projects are finished.
Nice to hear.
>
>> On a different note: This approach does currently not cover the older EC controlled 3 zone keyboards from clevo. Here only the kernel has access access to the device so the kernel driver has to expose all functionality somehow. Should this be done by an arbitrarily designed platform device?
> Interesting question, this reminds there was a discussion
> about how to handle zoned keyboards using plain LED class
> APIs here:
>
> https://lore.kernel.org/linux-leds/544484b9-c0ac-2fd0-1f41-8fa94cb94d4b@redhat.com/
>
> Basically the idea discussed there is to create
> separate multi-color LED sysfs devices for each zone,
> using :rgb:kbd_zoned_backlight-xxx as postfix, e.g. :
>
> :rgb:kbd_zoned_backlight-left
> :rgb:kbd_zoned_backlight-middle
> :rgb:kbd_zoned_backlight-right
> :rgb:kbd_zoned_backlight-wasd
>
> As postfixes for the 4 per zone LED class devices
> and then teach upower to just treat this as
> a single kbd-backlight for the existing upower
> DBUS API and maybe later extend the DBUS API.
>
> Would something like this work for the Clevo
> case you are describing?
Not entirely as some concept for the special modes would still be required.
Also it would be nice to be able to set the whole keyboard with a singular file
access so that the keyboard changes at once and not zone by zone.
>
> Unfortunately this was never implemented but
> I think that for simple zoned backlighting
> this still makes sense. Where as for per key
> controllable backlighting as mention in
> $subject I do believe that just using hidraw
> access directly from userspace is best.
>
> Regards,
>
> Hans
I also stumbled across a new Problem:
We have an upcoming device that has a per-key keyboard backlight, but does the
control completely via a wmi/acpi interface. So no usable hidraw here for a
potential userspace driver implementation ...
So a quick summary for the ideas floating in this thread so far:
1. Expand leds interface allowing arbitrary modes with semi arbitrary optional
attributes:
- Pro:
- Still offers all default attributes for use with UPower
- Fairly simple to implement from the preexisting codebase
- Could be implemented for all (to me) known internal keyboard backlights
- Con:
- Violates the simplicity paradigm of the leds interface (e.g. with
this one leds entry controls possible multiple leds)
2. Implement per-key keyboards as auxdisplay
- Pro:
- Already has a concept for led positions
- Is conceptually closer to "multiple leds forming a singular entity"
- Con:
- No preexisting UPower support
- No concept for special hardware lightning modes
- No support for arbitrary led outlines yet (e.g. ISO style enter-key)
3. Implement in input subsystem
- Pro:
- Preexisting concept for keys and key purpose
- Con:
- Not in scope for subsystem
- No other preexisting light infrastructure
4. Implement a simple leds driver only supporting a small subset of the
capabilities and make it disable-able for a userspace driver to take over
- Pro:
- Most simple to implement basic support
- In scope for led subsystem simplicity paradigm
- Con:
- Not all built in keyboard backlights can be implemented in a
userspace only driver
Kind Regards,
Werner
^ permalink raw reply
* [PATCH v2 11/32] hid/picolcd_fb: Set FBINFO_VIRTFB flag
From: Thomas Zimmermann @ 2023-11-27 13:15 UTC (permalink / raw)
To: javierm, deller
Cc: linux-fbdev, dri-devel, Thomas Zimmermann, Bruno Prémont,
Jiri Kosina, Benjamin Tissoires, linux-input, Jiri Kosina
In-Reply-To: <20231127131655.4020-1-tzimmermann@suse.de>
The picolcd_fb driver operates on system memory. Mark the framebuffer
accordingly. Helpers operating on the framebuffer memory will test
for the presence of this flag.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Cc: "Bruno Prémont" <bonbons@linux-vserver.org>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: linux-input@vger.kernel.org
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Acked-by: Bruno Prémont <bonbons@linux-vserver.org>
Acked-by: Jiri Kosina <jkosina@suse.cz>
---
drivers/hid/hid-picolcd_fb.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hid/hid-picolcd_fb.c b/drivers/hid/hid-picolcd_fb.c
index a4dccdcda26fc..d7dddd99d325e 100644
--- a/drivers/hid/hid-picolcd_fb.c
+++ b/drivers/hid/hid-picolcd_fb.c
@@ -505,6 +505,7 @@ int picolcd_init_framebuffer(struct picolcd_data *data)
dev_err(dev, "can't get a free page for framebuffer\n");
goto err_nomem;
}
+ info->flags |= FBINFO_VIRTFB;
info->screen_buffer = fbdata->bitmap;
info->fix.smem_start = (unsigned long)fbdata->bitmap;
memset(fbdata->vbitmap, 0xff, PICOLCDFB_SIZE);
--
2.43.0
^ permalink raw reply related
* Re: Wrong inputs on DualSense Edge Wireless Controller
From: Roderick Colenbrander @ 2023-11-27 14:37 UTC (permalink / raw)
To: Alexander Koskovich
Cc: roderick.colenbrander@sony.com, linux-input@vger.kernel.org
In-Reply-To: <o-hu9PCGr9R5LPS2ZnqssxnR22SBfwuDa0xuSsPwr3op3vBs1lbSsyH7RZMxkw7Ro2EuEzXbekDPrbiFoJ_R2_TzDlQ1g5zDaCogEU2w0sI=@protonmail.com>
Hi Alexander,
Sorry for the late reply, but I have been out for a few days. I'm not
aware of any button/axis mapping change between Edge and regular
DualSense. The HID reports stayed the same.
I just did a quick check on my laptop also on Fedora 38 / kernel 6.5
and the mapping seems to be fine. In evtest, triangle reports
BTN_NORTH, square BTN_WEST, etcetera.
The sticks, triggers and buttons seem to be fine as well. How are you
testing this?
Thanks,
Roderick
On Wed, Nov 22, 2023 at 4:18 PM Alexander Koskovich
<AKoskovich@protonmail.com> wrote:
>
> [Resending email due to lack HTML message rejected]
>
> Hello,
>
> I am currently on Fedora 39 (6.5.12-300.fc39.x86_64) and I am noticing that the inputs for this controller are wrong primarily on the right side of the controller.
>
> playstation 0005:054C:0DF2.000C: hidraw11: BLUETOOTH HID v1.00 Gamepad [DualSense Edge Wireless Controller] on 10:3d:1c:fd:30:bc
> playstation 0005:054C:0DF2.000C: Registered DualSense controller hw_version=0x01000208 fw_version=0x01000036
>
> This is the current mapping that I'm seeing with the hid_playstation module loaded:
> "X" is actually "Square"
> "Square" is "Triangle"
> "Triangle" is "Circle"
> "Circle" is "X"
>
> Also the right joystick seems to be controlling "R2" instead of the right joystick. "L2" and "R2" triggers control the joystick instead. It's overall very weird. Has there been any similar reports to this?
>
^ permalink raw reply
* Re: Wrong inputs on DualSense Edge Wireless Controller
From: Alexander Koskovich @ 2023-11-27 14:41 UTC (permalink / raw)
To: Roderick Colenbrander
Cc: roderick.colenbrander@sony.com, linux-input@vger.kernel.org
In-Reply-To: <CAEc3jaBpdY0J8hwJ6FMBOi5JH3Z-pEPxP38RYD0Y74+9=cfUOw@mail.gmail.com>
I was testing this in the Steam controller test, Cyberpunk 2077 (through GOG, not through Steam), and SuperTuxKart. All of these have wrong mappings for the Edge controller exclusively.
For additional context I have a PS5 controller (non Edge) and it works out of the box. This just seems to be an issue with the Edge variant.
On Monday, November 27th, 2023 at 9:37 AM, Roderick Colenbrander <thunderbird2k@gmail.com> wrote:
>
>
> Hi Alexander,
>
> Sorry for the late reply, but I have been out for a few days. I'm not
> aware of any button/axis mapping change between Edge and regular
> DualSense. The HID reports stayed the same.
>
> I just did a quick check on my laptop also on Fedora 38 / kernel 6.5
> and the mapping seems to be fine. In evtest, triangle reports
> BTN_NORTH, square BTN_WEST, etcetera.
>
> The sticks, triggers and buttons seem to be fine as well. How are you
> testing this?
>
> Thanks,
> Roderick
>
> On Wed, Nov 22, 2023 at 4:18 PM Alexander Koskovich
> AKoskovich@protonmail.com wrote:
>
> > [Resending email due to lack HTML message rejected]
> >
> > Hello,
> >
> > I am currently on Fedora 39 (6.5.12-300.fc39.x86_64) and I am noticing that the inputs for this controller are wrong primarily on the right side of the controller.
> >
> > playstation 0005:054C:0DF2.000C: hidraw11: BLUETOOTH HID v1.00 Gamepad [DualSense Edge Wireless Controller] on 10:3d:1c:fd:30:bc
> > playstation 0005:054C:0DF2.000C: Registered DualSense controller hw_version=0x01000208 fw_version=0x01000036
> >
> > This is the current mapping that I'm seeing with the hid_playstation module loaded:
> > "X" is actually "Square"
> > "Square" is "Triangle"
> > "Triangle" is "Circle"
> > "Circle" is "X"
> >
> > Also the right joystick seems to be controlling "R2" instead of the right joystick. "L2" and "R2" triggers control the joystick instead. It's overall very weird. Has there been any similar reports to this?
^ permalink raw reply
* [PATCH v11 1/2] dt-bindings: input: bindings for Adafruit Seesaw Gamepad
From: Anshul Dalal @ 2023-11-27 16:11 UTC (permalink / raw)
To: linux-input, devicetree
Cc: Anshul Dalal, Conor Dooley, Dmitry Torokhov,
Thomas Weißschuh, linux-kernel, Krzysztof Kozlowski,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Jeff LaBundy,
linux-kernel-mentees
Adds bindings for the Adafruit Seesaw Gamepad.
The gamepad functions as an i2c device with the default address of 0x50
and has an IRQ pin that can be enabled in the driver to allow for a rising
edge trigger on each button press or joystick movement.
Product page:
https://www.adafruit.com/product/5743
Arduino driver:
https://github.com/adafruit/Adafruit_Seesaw
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Anshul Dalal <anshulusr@gmail.com>
---
Changes for v11:
- no updates
Changes for v10:
- Added interrupt-controller/irq.h header
Changes for v9:
- Added interrupt in example
Changes for v8:
- no updates
Changes for v7:
- no updates
Changes for v6:
- no updates
Changes for v5:
- Added link to the datasheet
Changes for v4:
- Fixed the URI for the id field
- Added `interrupts` property
Changes for v3:
- Updated id field to reflect updated file name from previous version
- Added `reg` property
Changes for v2:
- Renamed file to `adafruit,seesaw-gamepad.yaml`
- Removed quotes for `$id` and `$schema`
- Removed "Bindings for" from the description
- Changed node name to the generic name "joystick"
- Changed compatible to 'adafruit,seesaw-gamepad' instead of
'adafruit,seesaw_gamepad'
Previous versions:
v10: https://lore.kernel.org/lkml/20231121123409.2231115-1-anshulusr@gmail.com/
v9: https://lore.kernel.org/lkml/20231121101751.2189965-1-anshulusr@gmail.com/
v8: https://lore.kernel.org/lkml/20231108005337.45069-1-anshulusr@gmail.com/
v7: https://lore.kernel.org/lkml/20231106164134.114668-1-anshulusr@gmail.com/
v6: https://lore.kernel.org/lkml/20231027051819.81333-1-anshulusr@gmail.com/
v5: https://lore.kernel.org/lkml/20231017034356.1436677-1-anshulusr@gmail.com/
v4: https://lore.kernel.org/lkml/20231010184827.1213507-1-anshulusr@gmail.com/
v3: https://lore.kernel.org/linux-input/20231008185709.2448423-1-anshulusr@gmail.com/
v2: https://lore.kernel.org/linux-input/20231008172435.2391009-1-anshulusr@gmail.com/
v1: https://lore.kernel.org/linux-input/20231007144052.1535417-1-anshulusr@gmail.com/
---
.../input/adafruit,seesaw-gamepad.yaml | 63 +++++++++++++++++++
1 file changed, 63 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/adafruit,seesaw-gamepad.yaml
diff --git a/Documentation/devicetree/bindings/input/adafruit,seesaw-gamepad.yaml b/Documentation/devicetree/bindings/input/adafruit,seesaw-gamepad.yaml
new file mode 100644
index 000000000000..5e86f6de6978
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/adafruit,seesaw-gamepad.yaml
@@ -0,0 +1,63 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/input/adafruit,seesaw-gamepad.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Adafruit Mini I2C Gamepad with seesaw
+
+maintainers:
+ - Anshul Dalal <anshulusr@gmail.com>
+
+description: |
+ Adafruit Mini I2C Gamepad
+
+ +-----------------------------+
+ | ___ |
+ | / \ (X) |
+ | | S | __ __ (Y) (A) |
+ | \___/ |ST| |SE| (B) |
+ | |
+ +-----------------------------+
+
+ S -> 10-bit precision bidirectional analog joystick
+ ST -> Start
+ SE -> Select
+ X, A, B, Y -> Digital action buttons
+
+ Datasheet: https://cdn-learn.adafruit.com/downloads/pdf/gamepad-qt.pdf
+ Product page: https://www.adafruit.com/product/5743
+ Arduino Driver: https://github.com/adafruit/Adafruit_Seesaw
+
+properties:
+ compatible:
+ const: adafruit,seesaw-gamepad
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+ description:
+ The gamepad's IRQ pin triggers a rising edge if interrupts are enabled.
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ joystick@50 {
+ compatible = "adafruit,seesaw-gamepad";
+ interrupts = <18 IRQ_TYPE_EDGE_RISING>;
+ reg = <0x50>;
+ };
+ };
--
2.42.1
^ permalink raw reply related
* [PATCH v11 2/2] input: joystick: driver for Adafruit Seesaw Gamepad
From: Anshul Dalal @ 2023-11-27 16:11 UTC (permalink / raw)
To: linux-input, devicetree
Cc: Anshul Dalal, Conor Dooley, Dmitry Torokhov,
Thomas Weißschuh, linux-kernel, Krzysztof Kozlowski,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Jeff LaBundy,
linux-kernel-mentees
In-Reply-To: <20231127161158.1651716-1-anshulusr@gmail.com>
Adds a driver for a mini gamepad that communicates over i2c, the gamepad
has bidirectional thumb stick input and six buttons.
The gamepad chip utilizes the open framework from Adafruit called 'Seesaw'
to transmit the ADC data for the joystick and digital pin state for the
buttons. I have only implemented the functionality required to receive the
thumb stick and button state.
Steps in reading the gamepad state over i2c:
1. Reset the registers
2. Set the pin mode of the pins specified by the `BUTTON_MASK` to input
`BUTTON_MASK`: A bit-map for the six digital pins internally
connected to the joystick buttons.
3. Enable internal pullup resistors for the `BUTTON_MASK`
4. Bulk set the pin state HIGH for `BUTTON_MASK`
5. Poll the device for button and joystick state done by:
`seesaw_read_data(struct i2c_client *client, struct seesaw_data *data)`
Product page:
https://www.adafruit.com/product/5743
Arduino driver:
https://github.com/adafruit/Adafruit_Seesaw
Driver tested on RPi Zero 2W
Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>
Signed-off-by: Anshul Dalal <anshulusr@gmail.com>
---
Changes for v11:
- Removed `of_match_ptr` to prevent warning:
'seesaw_of_table' defined but not used
on non OF platforms
Changes for v10:
- no updates
Changes for v9:
- Added of_device_id
Changes for v8:
- Updated invalid references to `adafruit_seesaw` to `adafruit-seesaw`
Changes for v7:
adafruit-seesaw.c
- Fixed formatting for macro definitions
- Made SEESAW_BUTTON_MASK static const
- Removed __be16 type for x and y fields of seesaw_data
- Used sparse_keymap implementation instead of custom keymap
- Used i2c_msg instead of i2c_master_send and recv in
seesaw_register_read
- Use temporary variable `adc_data` to store data received from ADC
- Changed read_buf from u8[4] to __be32
- Use usleep_range instead of msleep
- Removed 'Reviewed-by: Thomas Weißschuh' due to large number of changes
since last review
Kconfig:
- Added `select INPUT_SPARSEKMAP`
Changes for v6:
- Added TODO
- Removed `clang-format` directives
- Namespaced device buttons
- Removed `char physical_path[32]` field from `struct seesaw_gamepad`
- Added `packed` attribute to `struct seesaw_data`
- Moved from having booleans per button to single `u32 button_state`
- Added `seesaw_button_description` array to directly associate device
buttons with respective keycodes
- Added wrapper functions `seesaw_register_` around `i2c_master_` API
- Ratelimited input error reporting with `dev_err_ratelimited`
- Removed `of_device_id`
Changes for v5:
- Added link to the datasheet
- Added debug log message when `seesaw_read_data` fails
Changes for v4:
- Changed `1UL << BUTTON_` to BIT(BUTTON_)
- Removed `hardware_id` field from `struct seesaw_gamepad`
- Removed redundant checks for the number of bytes written and received by
`i2c_master_send` and `i2c_master_recv`
- Used `get_unaligned_be32` to instantiate `u32 result` from `read_buf`
- Changed `result & (1UL << BUTTON_)` to
`test_bit(BUTTON_, (long *)&result)`
- Changed `KBUILD_MODNAME` in id-tables to `SEESAW_DEVICE_NAME`
- Fixed formatting issues
- Changed button reporting:
Since the gamepad had the action buttons in a non-standard layout:
(X)
(Y) (A)
(B)
Therefore moved to using generic directional action button event codes
instead of BTN_[ABXY].
Changes for v3:
- no updates
Changes for v2:
adafruit-seesaw.c:
- Renamed file from 'adafruit_seesaw.c'
- Changed device name from 'seesaw_gamepad' to 'seesaw-gamepad'
- Changed count parameter for receiving joystick x on line 118:
`2` to `sizeof(write_buf)`
- Fixed invalid buffer size on line 123 and 126:
`data->y` to `sizeof(data->y)`
- Added comment for the `mdelay(10)` on line 169
- Changed inconsistent indentation on line 271
Kconfig:
- Fixed indentation for the help text
- Updated module name
Makefile:
- Updated module object file name
MAINTAINERS:
- Updated file name for the driver and bindings
Previous versions:
v10: https://lore.kernel.org/lkml/20231121123409.2231115-2-anshulusr@gmail.com/
v9: https://lore.kernel.org/lkml/20231121101751.2189965-2-anshulusr@gmail.com/
v8: https://lore.kernel.org/lkml/20231108005337.45069-2-anshulusr@gmail.com/
v7: https://lore.kernel.org/lkml/20231106164134.114668-2-anshulusr@gmail.com/
v6: https://lore.kernel.org/lkml/20231027051819.81333-2-anshulusr@gmail.com/
v5: https://lore.kernel.org/lkml/20231017034356.1436677-2-anshulusr@gmail.com/
v4: https://lore.kernel.org/lkml/20231010184827.1213507-2-anshulusr@gmail.com/
v3: https://lore.kernel.org/linux-input/20231008185709.2448423-2-anshulusr@gmail.com/
v2: https://lore.kernel.org/linux-input/20231008172435.2391009-2-anshulusr@gmail.com/
v1: https://lore.kernel.org/linux-input/20231007144052.1535417-2-anshulusr@gmail.com/
---
MAINTAINERS | 7 +
drivers/input/joystick/Kconfig | 10 +
drivers/input/joystick/Makefile | 1 +
drivers/input/joystick/adafruit-seesaw.c | 318 +++++++++++++++++++++++
4 files changed, 336 insertions(+)
create mode 100644 drivers/input/joystick/adafruit-seesaw.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 81d5fc0bba68..b3f101edc24b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -441,6 +441,13 @@ W: http://wiki.analog.com/AD7879
W: https://ez.analog.com/linux-software-drivers
F: drivers/input/touchscreen/ad7879.c
+ADAFRUIT MINI I2C GAMEPAD
+M: Anshul Dalal <anshulusr@gmail.com>
+L: linux-input@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/input/adafruit,seesaw-gamepad.yaml
+F: drivers/input/joystick/adafruit-seesaw.c
+
ADDRESS SPACE LAYOUT RANDOMIZATION (ASLR)
M: Jiri Kosina <jikos@kernel.org>
S: Maintained
diff --git a/drivers/input/joystick/Kconfig b/drivers/input/joystick/Kconfig
index ac6925ce8366..7755e5b454d2 100644
--- a/drivers/input/joystick/Kconfig
+++ b/drivers/input/joystick/Kconfig
@@ -412,4 +412,14 @@ config JOYSTICK_SENSEHAT
To compile this driver as a module, choose M here: the
module will be called sensehat_joystick.
+config JOYSTICK_SEESAW
+ tristate "Adafruit Mini I2C Gamepad with Seesaw"
+ depends on I2C
+ select INPUT_SPARSEKMAP
+ help
+ Say Y here if you want to use the Adafruit Mini I2C Gamepad.
+
+ To compile this driver as a module, choose M here: the module will be
+ called adafruit-seesaw.
+
endif
diff --git a/drivers/input/joystick/Makefile b/drivers/input/joystick/Makefile
index 3937535f0098..9976f596a920 100644
--- a/drivers/input/joystick/Makefile
+++ b/drivers/input/joystick/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_JOYSTICK_N64) += n64joy.o
obj-$(CONFIG_JOYSTICK_PSXPAD_SPI) += psxpad-spi.o
obj-$(CONFIG_JOYSTICK_PXRC) += pxrc.o
obj-$(CONFIG_JOYSTICK_QWIIC) += qwiic-joystick.o
+obj-$(CONFIG_JOYSTICK_SEESAW) += adafruit-seesaw.o
obj-$(CONFIG_JOYSTICK_SENSEHAT) += sensehat-joystick.o
obj-$(CONFIG_JOYSTICK_SIDEWINDER) += sidewinder.o
obj-$(CONFIG_JOYSTICK_SPACEBALL) += spaceball.o
diff --git a/drivers/input/joystick/adafruit-seesaw.c b/drivers/input/joystick/adafruit-seesaw.c
new file mode 100644
index 000000000000..0f4a54c9519e
--- /dev/null
+++ b/drivers/input/joystick/adafruit-seesaw.c
@@ -0,0 +1,318 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Copyright (C) 2023 Anshul Dalal <anshulusr@gmail.com>
+ *
+ * Driver for Adafruit Mini I2C Gamepad
+ *
+ * Based on the work of:
+ * Oleh Kravchenko (Sparkfun Qwiic Joystick driver)
+ *
+ * Datasheet: https://cdn-learn.adafruit.com/downloads/pdf/gamepad-qt.pdf
+ * Product page: https://www.adafruit.com/product/5743
+ * Firmware and hardware sources: https://github.com/adafruit/Adafruit_Seesaw
+ *
+ * TODO:
+ * - Add interrupt support
+ */
+
+#include <asm/unaligned.h>
+#include <linux/bits.h>
+#include <linux/delay.h>
+#include <linux/i2c.h>
+#include <linux/input.h>
+#include <linux/input/sparse-keymap.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+
+#define SEESAW_DEVICE_NAME "seesaw-gamepad"
+
+#define SEESAW_STATUS_BASE 0x00
+#define SEESAW_GPIO_BASE 0x01
+#define SEESAW_ADC_BASE 0x09
+
+#define SEESAW_GPIO_DIRCLR_BULK 0x03
+#define SEESAW_GPIO_BULK 0x04
+#define SEESAW_GPIO_BULK_SET 0x05
+#define SEESAW_GPIO_PULLENSET 0x0b
+
+#define SEESAW_STATUS_HW_ID 0x01
+#define SEESAW_STATUS_SWRST 0x7f
+
+#define SEESAW_ADC_OFFSET 0x07
+
+#define SEESAW_BUTTON_A 0x05
+#define SEESAW_BUTTON_B 0x01
+#define SEESAW_BUTTON_X 0x06
+#define SEESAW_BUTTON_Y 0x02
+#define SEESAW_BUTTON_START 0x10
+#define SEESAW_BUTTON_SELECT 0x00
+
+#define SEESAW_ANALOG_X 0x0e
+#define SEESAW_ANALOG_Y 0x0f
+
+#define SEESAW_JOYSTICK_MAX_AXIS 1023
+#define SEESAW_JOYSTICK_FUZZ 2
+#define SEESAW_JOYSTICK_FLAT 4
+
+#define SEESAW_GAMEPAD_POLL_INTERVAL 16
+#define SEESAW_GAMEPAD_POLL_MIN 8
+#define SEESAW_GAMEPAD_POLL_MAX 32
+
+#define MSEC_PER_USEC 1000
+
+static const u32 SEESAW_BUTTON_MASK =
+ BIT(SEESAW_BUTTON_A) | BIT(SEESAW_BUTTON_B) | BIT(SEESAW_BUTTON_X) |
+ BIT(SEESAW_BUTTON_Y) | BIT(SEESAW_BUTTON_START) |
+ BIT(SEESAW_BUTTON_SELECT);
+
+struct seesaw_gamepad {
+ struct input_dev *input_dev;
+ struct i2c_client *i2c_client;
+};
+
+struct seesaw_data {
+ u16 x;
+ u16 y;
+ u32 button_state;
+};
+
+static const struct key_entry seesaw_buttons_new[] = {
+ { KE_KEY, SEESAW_BUTTON_A, .keycode = BTN_SOUTH },
+ { KE_KEY, SEESAW_BUTTON_B, .keycode = BTN_EAST },
+ { KE_KEY, SEESAW_BUTTON_X, .keycode = BTN_NORTH },
+ { KE_KEY, SEESAW_BUTTON_Y, .keycode = BTN_WEST },
+ { KE_KEY, SEESAW_BUTTON_START, .keycode = BTN_START },
+ { KE_KEY, SEESAW_BUTTON_SELECT, .keycode = BTN_SELECT },
+ { KE_END, 0 }
+};
+
+static int seesaw_register_read(struct i2c_client *client, u8 register_high,
+ u8 register_low, char *buf, int count)
+{
+ int ret;
+ u8 register_buf[2] = { register_high, register_low };
+
+ struct i2c_msg message_buf[2] = {
+ {
+ .addr = client->addr,
+ .flags = client->flags,
+ .len = sizeof(register_buf),
+ .buf = register_buf,
+ },
+ {
+ .addr = client->addr,
+ .flags = client->flags | I2C_M_RD,
+ .len = count,
+ .buf = buf,
+ },
+ };
+ ret = i2c_transfer(client->adapter, message_buf,
+ ARRAY_SIZE(message_buf));
+
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+static int seesaw_register_write_u8(struct i2c_client *client, u8 register_high,
+ u8 register_low, u8 value)
+{
+ int ret;
+ u8 write_buf[3] = { register_high, register_low, value };
+
+ ret = i2c_master_send(client, write_buf, sizeof(write_buf));
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+static int seesaw_register_write_u32(struct i2c_client *client,
+ u8 register_high, u8 register_low,
+ u32 value)
+{
+ int ret;
+ u8 write_buf[6] = { register_high, register_low };
+
+ put_unaligned_be32(value, write_buf + 2);
+ ret = i2c_master_send(client, write_buf, sizeof(write_buf));
+ if (ret < 0)
+ return ret;
+
+ return 0;
+}
+
+static int seesaw_read_data(struct i2c_client *client, struct seesaw_data *data)
+{
+ int ret;
+ __be16 adc_data;
+ __be32 read_buf;
+
+ ret = seesaw_register_read(client, SEESAW_GPIO_BASE, SEESAW_GPIO_BULK,
+ (char *)&read_buf, sizeof(read_buf));
+ if (ret)
+ return ret;
+
+ data->button_state = ~be32_to_cpu(read_buf);
+
+ ret = seesaw_register_read(client, SEESAW_ADC_BASE,
+ SEESAW_ADC_OFFSET + SEESAW_ANALOG_X,
+ (char *)&adc_data, sizeof(adc_data));
+ if (ret)
+ return ret;
+ /*
+ * ADC reads left as max and right as 0, must be reversed since kernel
+ * expects reports in opposite order.
+ */
+ data->x = SEESAW_JOYSTICK_MAX_AXIS - be16_to_cpu(adc_data);
+
+ ret = seesaw_register_read(client, SEESAW_ADC_BASE,
+ SEESAW_ADC_OFFSET + SEESAW_ANALOG_Y,
+ (char *)&adc_data, sizeof(adc_data));
+ if (ret)
+ return ret;
+ data->y = be16_to_cpu(adc_data);
+
+ return 0;
+}
+
+static void seesaw_poll(struct input_dev *input)
+{
+ int err, i;
+ struct seesaw_gamepad *private = input_get_drvdata(input);
+ struct seesaw_data data;
+
+ err = seesaw_read_data(private->i2c_client, &data);
+ if (err) {
+ dev_err_ratelimited(&input->dev,
+ "failed to read joystick state: %d\n", err);
+ return;
+ }
+
+ input_report_abs(input, ABS_X, data.x);
+ input_report_abs(input, ABS_Y, data.y);
+
+ for_each_set_bit(i, (long *)&SEESAW_BUTTON_MASK,
+ BITS_PER_TYPE(SEESAW_BUTTON_MASK)) {
+ if (!sparse_keymap_report_event(
+ input, i, data.button_state & BIT(i), false)) {
+ dev_err_ratelimited(&input->dev,
+ "failed to report keymap event");
+ };
+ }
+
+ input_sync(input);
+}
+
+static int seesaw_probe(struct i2c_client *client)
+{
+ int ret;
+ u8 hardware_id;
+ struct seesaw_gamepad *seesaw;
+
+ ret = seesaw_register_write_u8(client, SEESAW_STATUS_BASE,
+ SEESAW_STATUS_SWRST, 0xFF);
+ if (ret)
+ return ret;
+
+ /* Wait for the registers to reset before proceeding */
+ usleep_range(10 * MSEC_PER_USEC, 15 * MSEC_PER_USEC);
+
+ seesaw = devm_kzalloc(&client->dev, sizeof(*seesaw), GFP_KERNEL);
+ if (!seesaw)
+ return -ENOMEM;
+
+ ret = seesaw_register_read(client, SEESAW_STATUS_BASE,
+ SEESAW_STATUS_HW_ID, &hardware_id,
+ sizeof(hardware_id));
+ if (ret)
+ return ret;
+
+ dev_dbg(&client->dev, "Adafruit Seesaw Gamepad, Hardware ID: %02x\n",
+ hardware_id);
+
+ /* Set Pin Mode to input and enable pull-up resistors */
+ ret = seesaw_register_write_u32(client, SEESAW_GPIO_BASE,
+ SEESAW_GPIO_DIRCLR_BULK,
+ SEESAW_BUTTON_MASK);
+ if (ret)
+ return ret;
+ ret = seesaw_register_write_u32(client, SEESAW_GPIO_BASE,
+ SEESAW_GPIO_PULLENSET,
+ SEESAW_BUTTON_MASK);
+ if (ret)
+ return ret;
+ ret = seesaw_register_write_u32(client, SEESAW_GPIO_BASE,
+ SEESAW_GPIO_BULK_SET,
+ SEESAW_BUTTON_MASK);
+ if (ret)
+ return ret;
+
+ seesaw->i2c_client = client;
+ seesaw->input_dev = devm_input_allocate_device(&client->dev);
+ if (!seesaw->input_dev)
+ return -ENOMEM;
+
+ seesaw->input_dev->id.bustype = BUS_I2C;
+ seesaw->input_dev->name = "Adafruit Seesaw Gamepad";
+ seesaw->input_dev->phys = "i2c/" SEESAW_DEVICE_NAME;
+ input_set_drvdata(seesaw->input_dev, seesaw);
+ input_set_abs_params(seesaw->input_dev, ABS_X, 0,
+ SEESAW_JOYSTICK_MAX_AXIS, SEESAW_JOYSTICK_FUZZ,
+ SEESAW_JOYSTICK_FLAT);
+ input_set_abs_params(seesaw->input_dev, ABS_Y, 0,
+ SEESAW_JOYSTICK_MAX_AXIS, SEESAW_JOYSTICK_FUZZ,
+ SEESAW_JOYSTICK_FLAT);
+
+ ret = sparse_keymap_setup(seesaw->input_dev, seesaw_buttons_new, NULL);
+ if (ret) {
+ dev_err(&client->dev,
+ "failed to set up input device keymap: %d\n", ret);
+ return ret;
+ }
+
+ ret = input_setup_polling(seesaw->input_dev, seesaw_poll);
+ if (ret) {
+ dev_err(&client->dev, "failed to set up polling: %d\n", ret);
+ return ret;
+ }
+
+ input_set_poll_interval(seesaw->input_dev, SEESAW_GAMEPAD_POLL_INTERVAL);
+ input_set_max_poll_interval(seesaw->input_dev, SEESAW_GAMEPAD_POLL_MAX);
+ input_set_min_poll_interval(seesaw->input_dev, SEESAW_GAMEPAD_POLL_MIN);
+
+ ret = input_register_device(seesaw->input_dev);
+ if (ret) {
+ dev_err(&client->dev, "failed to register joystick: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static const struct i2c_device_id seesaw_id_table[] = {
+ { SEESAW_DEVICE_NAME },
+ { /* Sentinel */ }
+};
+MODULE_DEVICE_TABLE(i2c, seesaw_id_table);
+
+static const struct of_device_id seesaw_of_table[] = {
+ { .compatible = "adafruit,seesaw-gamepad"},
+ { /* Sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, seesaw_of_table);
+
+static struct i2c_driver seesaw_driver = {
+ .driver = {
+ .name = SEESAW_DEVICE_NAME,
+ .of_match_table = seesaw_of_table,
+ },
+ .id_table = seesaw_id_table,
+ .probe = seesaw_probe,
+};
+module_i2c_driver(seesaw_driver);
+
+MODULE_AUTHOR("Anshul Dalal <anshulusr@gmail.com>");
+MODULE_DESCRIPTION("Adafruit Mini I2C Gamepad driver");
+MODULE_LICENSE("GPL");
--
2.42.1
^ permalink raw reply related
* Re: [PATCH] Input: i8042 - add quirk for Lenovo ThinkPad T14 Gen 1
From: Jonathan Denose @ 2023-11-27 16:38 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input, Jonathan Denose, Hans de Goede, Huacai Chen,
Mattijs Korpershoek, Takashi Iwai, Werner Sembach, linux-kernel
In-Reply-To: <ZWF76ALANQwP_9b1@google.com>
Hi Dmitry
On Fri, Nov 24, 2023 at 10:45 PM Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
>
> Hi Jonathan,
>
> On Mon, Sep 25, 2023 at 04:33:20PM -0500, Jonathan Denose wrote:
> > The ThinkPad T14 Gen 1 touchpad works fine except that clicking
> > and dragging by tapping the touchpad or depressing the touchpad
> > do not work. Disabling PNP for controller setting discovery enables
> > click and drag without negatively impacting other touchpad features.
>
> I would like to understand more on how enabling PnP discovery for i8042
> affects the touchpad. Do you see it using different interrupt or IO
> ports? What protocol does the touchpad use with/without PnP? If the
> protocol is the same, do you see difference in the ranges (pressure,
> etc) reported by the device?
>
> Thanks.
>
> --
> Dmitry
Without PnP discovery the touchpad is using the SynPS/2 protocol, with
PnP discovery, the touchpad is using the rmi4 protocol. Since the
protocols are different, so are the ranges but let me know if you
still want to see them.
Can you tell me how to check the interrupt/IO ports? I'm not sure how
to do that.
Thanks,
Jonathan
^ permalink raw reply
* [PATCH 33/55] input: touchscreen: atmel: Stop abusing of min_buffers_needed field
From: Benjamin Gaignard @ 2023-11-27 16:54 UTC (permalink / raw)
To: hverkuil, mchehab, tfiga, m.szyprowski, matt.ranostay
Cc: linux-kernel, linux-media, linux-staging, kernel,
Benjamin Gaignard, Nick Dyer, Dmitry Torokhov, linux-input
In-Reply-To: <20231127165454.166373-1-benjamin.gaignard@collabora.com>
'min_buffers_needed' is suppose to be used to indicate the number
of buffers needed by DMA engine to start streaming.
atmel touchscreen driver doesn't use DMA engine and just want to specify
the minimum number of buffers to allocate when calling VIDIOC_REQBUFS.
That 'min_reqbufs_allocation' field purpose so use it.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
CC: Nick Dyer <nick@shmanahar.org>
CC: Dmitry Torokhov <dmitry.torokhov@gmail.com>
CC: linux-input@vger.kernel.org
---
drivers/input/touchscreen/atmel_mxt_ts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
index 20094b9899f0..47f2b3aafa4d 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -2546,7 +2546,7 @@ static const struct vb2_queue mxt_queue = {
.ops = &mxt_queue_ops,
.mem_ops = &vb2_vmalloc_memops,
.timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC,
- .min_buffers_needed = 1,
+ .min_reqbufs_allocation = 1,
};
static int mxt_vidioc_querycap(struct file *file, void *priv,
--
2.39.2
^ permalink raw reply related
* [PATCH 34/55] input: touchscreen: sur40: Stop abusing of min_buffers_needed field
From: Benjamin Gaignard @ 2023-11-27 16:54 UTC (permalink / raw)
To: hverkuil, mchehab, tfiga, m.szyprowski, matt.ranostay
Cc: linux-kernel, linux-media, linux-staging, kernel,
Benjamin Gaignard, Dmitry Torokhov, linux-input
In-Reply-To: <20231127165454.166373-1-benjamin.gaignard@collabora.com>
'min_buffers_needed' is suppose to be used to indicate the number
of buffers needed by DMA engine to start streaming.
sur40 touchscreen driver doesn't use DMA engine and just want to specify
the minimum number of buffers to allocate when calling VIDIOC_REQBUFS.
That 'min_reqbufs_allocation' field purpose so use it.
Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com>
CC: Dmitry Torokhov <dmitry.torokhov@gmail.com>
CC: linux-input@vger.kernel.org
---
drivers/input/touchscreen/sur40.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/sur40.c b/drivers/input/touchscreen/sur40.c
index e7d2a52169a0..4da3063c352e 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -1124,7 +1124,7 @@ static const struct vb2_queue sur40_queue = {
.ops = &sur40_queue_ops,
.mem_ops = &vb2_dma_sg_memops,
.timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC,
- .min_buffers_needed = 3,
+ .min_reqbufs_allocation = 3,
};
static const struct v4l2_file_operations sur40_video_fops = {
--
2.39.2
^ permalink raw reply related
* hid_logitech_dj/hidpp disable high resolution wheel scroll quirk needed
From: Kim @ 2023-11-27 18:07 UTC (permalink / raw)
To: linux-input
Reported to libinput, [Logitech G604 metal wheel unintended scroll
caused by high resolution setting enforced by kernel
drivers](https://gitlab.freedesktop.org/libinput/libinput/-/issues/949)
and isolated to kernel modules hid_logitech_dj/hid_logitech_hidpp,
though dj is for receiver setup.
The G604 exhibits extremely sensitive scroll wheel, so much so, that a
minor jolt (from lifting and bringing the mouse back down on a surface),
is enough to generate unintentional wheel scroll.
The problem is in hardware, caused by a trivial "bounce" of the metal
scroll wheel, and can be mitigated by lightly holding the wheel with one
finger. Even so, this unintended wheel scrolling doesn't occur in
Windows 10/11 or Android OS. It is suspected that the hires scroll
wheel is not enabled in those operating systems. A quirk is needed to
override and force lowres scroll wheel sensitivity.
hidpp initializes the mouse and sets the sensitivity such that it
persists through a reboot. Blacklisting hid_logitech_dj/hidpp is not
enough. The mouse must be disconnected from the USB bus, and is
reinitialized upon reconnect.
Please advise on what further information needs to be provided to
facilitate isolation and resolution.
Tested on Manjaro Linux which is rolling release the LTS Kernel 6.6.1,
details found at [Manjaro
releases](https://forum.manjaro.org/c/announcements/stable-updates/12)
Blacklisting just hid_logitech_dj (the lightspeed receiver) is enough to
clear the issue, as this effectively prevents both dj and hidpp from
being loaded.
Without hid-logitech-dj/hidpp the G604 is identified as Logitech
Wireless Mouse PID:4085 Mouse; with, it is registered as Logitech G604.
[hid-ids.h](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/drivers/hid/hid-ids.h)
[hid-logitech-hidpp](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/drivers/hid/hid-logitech-hidpp.c)
[hid-logitech-dj](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/drivers/hid/hid-logitech-dj.c)
modinfo hid-logitech-dj has alias for G604:
lsusb
Bus 001 Device 010: ID 046d:c539 Logitech, Inc. Lightspeed Receiver
modinfo hid-logitech-dj
filename:
/lib/modules/6.6.1-1-MANJARO/kernel/drivers/hid/hid-logitech-dj.ko.zst
author: nlopezcasad@logitech.com
author: Nestor Lopez Casado
author: Logitech
license: GPL
srcversion: 012CD0C907AC711AE721D02
alias: hid:b0003g*v0000046Dp0000C539
depends: usbhid
grep -i hid_logitech_ /lib/modules/$(uname -r)/modules.alias
alias hid:b0003g*v0000046Dp0000C539 hid_logitech_dj
evt=22 ; udevadm info -an /dev/input/event"$evt" |grep -B3 DRIVERS==
looking at parent device
'/devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1.1/1-5.1.1.1/1-5.1.1.1.2/1-5.1.1.1.2:1.2/0003:046D:C539.0004/0003:046D:4085.000B':
KERNELS=="0003:046D:4085.000B"
SUBSYSTEMS=="hid"
DRIVERS=="logitech-hidpp-device"
--
looking at parent device
'/devices/pci0000:00/0000:00:14.0/usb1/1-5/1-5.1/1-5.1.1/1-5.1.1.1/1-5.1.1.1.2/1-5.1.1.1.2:1.2/0003:046D:C539.0004':
KERNELS=="0003:046D:C539.0004"
SUBSYSTEMS=="hid"
DRIVERS=="logitech-djreceiver"
ID present in hid-ids.h
#define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1 0xc539
^ permalink raw reply
* [PATCH] input/vmmouse: Fix device name copies
From: Zack Rusin @ 2023-11-27 20:42 UTC (permalink / raw)
To: linux-kernel
Cc: Zack Rusin, Dmitry Torokhov, VMware Graphics Reviewers,
Arnd Bergmann, Robert Jarzmik, Raul Rangel, linux-input, stable
From: Zack Rusin <zackr@vmware.com>
Make sure vmmouse_data::phys can hold serio::phys (which is 32 bytes)
plus an extra string, extend it to 64.
Fixes gcc13 warnings:
drivers/input/mouse/vmmouse.c: In function ‘vmmouse_init’:
drivers/input/mouse/vmmouse.c:455:53: warning: ‘/input1’ directive output may be truncated writing 7 bytes into a region of size between 1 and 32 [-Wformat-truncation=]
455 | snprintf(priv->phys, sizeof(priv->phys), "%s/input1",
| ^~~~~~~
drivers/input/mouse/vmmouse.c:455:9: note: ‘snprintf’ output between 8 and 39 bytes into a destination of size 32
455 | snprintf(priv->phys, sizeof(priv->phys), "%s/input1",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
456 | psmouse->ps2dev.serio->phys);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Zack Rusin <zackr@vmware.com>
Fixes: 8b8be51b4fd3 ("Input: add vmmouse driver")
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: VMware Graphics Reviewers <linux-graphics-maintainer@vmware.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Robert Jarzmik <robert.jarzmik@free.fr>
Cc: Raul Rangel <rrangel@chromium.org>
Cc: linux-input@vger.kernel.org
Cc: <stable@vger.kernel.org> # v4.1+
---
drivers/input/mouse/vmmouse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/mouse/vmmouse.c b/drivers/input/mouse/vmmouse.c
index ea9eff7c8099..7248cada4c8c 100644
--- a/drivers/input/mouse/vmmouse.c
+++ b/drivers/input/mouse/vmmouse.c
@@ -72,7 +72,7 @@
*/
struct vmmouse_data {
struct input_dev *abs_dev;
- char phys[32];
+ char phys[64];
char dev_name[128];
};
--
2.39.2
^ permalink raw reply related
* [PATCH] HID: Add quirk for Labtec/ODDOR/aikeec handbrake
From: Sebastian Parschauer @ 2023-11-27 22:49 UTC (permalink / raw)
To: Jiri Kosina, Benjamin Tissoires; +Cc: linux-input, Sebastian Parschauer
This device needs ALWAYS_POLL quirk, otherwise it keeps reconnecting
indefinitely. It is a handbrake for sim racing detected as joystick.
Reported and tested by GitHub user N0th1ngM4tt3rs.
Link: https://github.com/sriemer/fix-linux-mouse issue 22
Signed-off-by: Sebastian Parschauer <s.parschauer@gmx.de>
---
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 f7973ccd84a2..a07afed1143c 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -744,6 +744,7 @@
#define USB_VENDOR_ID_LABTEC 0x1020
#define USB_DEVICE_ID_LABTEC_WIRELESS_KEYBOARD 0x0006
+#define USB_DEVICE_ID_LABTEC_ODDOR_HANDBRAKE 0x8888
#define USB_VENDOR_ID_LCPOWER 0x1241
#define USB_DEVICE_ID_LCPOWER_LC1000 0xf767
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 5a48fcaa32f0..d9a4f8f7bbb0 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -120,6 +120,7 @@ static const struct hid_device_id hid_quirks[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_EASYPEN_M406XE), HID_QUIRK_MULTI_INPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_MOUSEPEN_I608X_V2), HID_QUIRK_MULTI_INPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_PENSKETCH_T609A), HID_QUIRK_MULTI_INPUT },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LABTEC, USB_DEVICE_ID_LABTEC_ODDOR_HANDBRAKE), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_OPTICAL_USB_MOUSE_600E), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_608D), HID_QUIRK_ALWAYS_POLL },
{ HID_USB_DEVICE(USB_VENDOR_ID_LENOVO, USB_DEVICE_ID_LENOVO_PIXART_USB_MOUSE_6019), HID_QUIRK_ALWAYS_POLL },
--
2.35.3
^ permalink raw reply related
* Re: Wrong inputs on DualSense Edge Wireless Controller
From: Alexander Koskovich @ 2023-11-28 1:50 UTC (permalink / raw)
To: Roderick Colenbrander; +Cc: Colenbrander, Roelof, linux-input
In-Reply-To: <CAEc3jaCSUWXPZo=nvYkWhvOuJYT7xmh4QcBajmrs4GWY6u5OVw@mail.gmail.com>
I tested in evtest, and it's reporting sane results (cross south, square west, etc). So this seems to be an issue outside of the playstation driver itself?
On Monday, November 27th, 2023 at 2:40 PM, Roderick Colenbrander <thunderbird2k@gmail.com> wrote:
> This seems a little weird to me. Would you be able to test in using evtest? It would rule out some of the other middle layers which can do their own remapping.
> Thanks,
> Roderick
>
> On Mon, Nov 27, 2023, 6:42 AM Alexander Koskovich <AKoskovich@protonmail.com> wrote:
>
> > I was testing this in the Steam controller test, Cyberpunk 2077 (through GOG, not through Steam), and SuperTuxKart. All of these have wrong mappings for the Edge controller exclusively.
> > For additional context I have a PS5 controller (non Edge) and it works out of the box. This just seems to be an issue with the Edge variant.
> >
> >
> > On Monday, November 27th, 2023 at 9:37 AM, Roderick Colenbrander <thunderbird2k@gmail.com> wrote:
> >
> >
> > >
> > >
> > > Hi Alexander,
> > >
> > > Sorry for the late reply, but I have been out for a few days. I'm not
> > > aware of any button/axis mapping change between Edge and regular
> > > DualSense. The HID reports stayed the same.
> > >
> > > I just did a quick check on my laptop also on Fedora 38 / kernel 6.5
> > > and the mapping seems to be fine. In evtest, triangle reports
> > > BTN_NORTH, square BTN_WEST, etcetera.
> > >
> > > The sticks, triggers and buttons seem to be fine as well. How are you
> > > testing this?
> > >
> > > Thanks,
> > > Roderick
> > >
> > > On Wed, Nov 22, 2023 at 4:18 PM Alexander Koskovich
> > > AKoskovich@protonmail.com wrote:
> > >
> > > > [Resending email due to lack HTML message rejected]
> > > >
> > > > Hello,
> > > >
> > > > I am currently on Fedora 39 (6.5.12-300.fc39.x86_64) and I am noticing that the inputs for this controller are wrong primarily on the right side of the controller.
> > > >
> > > > playstation 0005:054C:0DF2.000C: hidraw11: BLUETOOTH HID v1.00 Gamepad [DualSense Edge Wireless Controller] on 10:3d:1c:fd:30:bc
> > > > playstation 0005:054C:0DF2.000C: Registered DualSense controller hw_version=0x01000208 fw_version=0x01000036
> > > >
> > > > This is the current mapping that I'm seeing with the hid_playstation module loaded:
> > > > "X" is actually "Square"
> > > > "Square" is "Triangle"
> > > > "Triangle" is "Circle"
> > > > "Circle" is "X"
> > > >
> > > > Also the right joystick seems to be controlling "R2" instead of the right joystick. "L2" and "R2" triggers control the joystick instead. It's overall very weird. Has there been any similar reports to this?
^ permalink raw reply
* Re: [PATCH 1/1] hid-playstation: Fix button maps for the DualSense Edge controller
From: Rahul Rameshbabu @ 2023-11-28 2:16 UTC (permalink / raw)
To: Alexander Koskovich
Cc: roderick.colenbrander, jikos, benjamin.tissoires, linux-input,
linux-kernel
In-Reply-To: <20231126001544.747151-1-akoskovich@pm.me>
On Sun, 26 Nov, 2023 00:15:49 +0000 "Alexander Koskovich" <AKoskovich@pm.me> wrote:
> This brings functionality of the DualSense Edge controller inline
> with the stock PS5 controller.
>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
Will provide a follow-up to the relevant discussion.
https://lore.kernel.org/linux-input/P8jVfYBAwiM_8MIgshN0osVVfshfBH2-oZCQuqoqh0Hy76_031zuZvYXWl0edtfTUwDOSNlc5priSRXI3G5dboVh5VPbcdxzAcEF7EvUVgo=@protonmail.com/T/#t
Since I assume this patch was not actually tested to resolve the issue
based on the evtest results, I think we should drop this patch. Will
mention some details I might have with regards to the behavior you are
seeing with Steam/Proton specifically.
--
Thanks,
Rahul Rameshbabu
^ permalink raw reply
* Re: [PATCH 1/1] hid-playstation: Fix button maps for the DualSense Edge controller
From: Alexander Koskovich @ 2023-11-28 2:19 UTC (permalink / raw)
To: Rahul Rameshbabu
Cc: roderick.colenbrander, jikos, benjamin.tissoires, linux-input,
linux-kernel
In-Reply-To: <87bkbeei6g.fsf@protonmail.com>
To clarify, I did test this patch locally on Fedora Rawhide and confirm it works with games. It does resolve the issue, and is a workaround.
It's not just Steam/Proton I'm seeing this issue in, I'm seeing it in native Linux games like SuperTuxKart.
On Monday, November 27th, 2023 at 9:16 PM, Rahul Rameshbabu <sergeantsagara@protonmail.com> wrote:
>
>
> On Sun, 26 Nov, 2023 00:15:49 +0000 "Alexander Koskovich" AKoskovich@pm.me wrote:
>
> > This brings functionality of the DualSense Edge controller inline
> > with the stock PS5 controller.
> >
> > Signed-off-by: Alexander Koskovich akoskovich@pm.me
> > ---
>
>
> Will provide a follow-up to the relevant discussion.
>
> https://lore.kernel.org/linux-input/P8jVfYBAwiM_8MIgshN0osVVfshfBH2-oZCQuqoqh0Hy76_031zuZvYXWl0edtfTUwDOSNlc5priSRXI3G5dboVh5VPbcdxzAcEF7EvUVgo=@protonmail.com/T/#t
>
> Since I assume this patch was not actually tested to resolve the issue
> based on the evtest results, I think we should drop this patch. Will
> mention some details I might have with regards to the behavior you are
> seeing with Steam/Proton specifically.
>
> --
> Thanks,
>
> Rahul Rameshbabu
^ permalink raw reply
* Re: Wrong inputs on DualSense Edge Wireless Controller
From: Rahul Rameshbabu @ 2023-11-28 2:23 UTC (permalink / raw)
To: Alexander Koskovich
Cc: Roderick Colenbrander, Colenbrander, Roelof, linux-input
In-Reply-To: <P8jVfYBAwiM_8MIgshN0osVVfshfBH2-oZCQuqoqh0Hy76_031zuZvYXWl0edtfTUwDOSNlc5priSRXI3G5dboVh5VPbcdxzAcEF7EvUVgo=@protonmail.com>
On Tue, 28 Nov, 2023 01:50:37 +0000 "Alexander Koskovich" <AKoskovich@protonmail.com> wrote:
> I tested in evtest, and it's reporting sane results (cross south, square west, etc). So this seems to be an issue outside of the playstation driver itself?
>
Right, I believe the problem stems from Proton -> Windows userspace
Xinput drivers or game/Steam controller test specific code though I am
not 100% sure.
https://github.com/ValveSoftware/Proton/blob/proton_8.0/docs/CONTROLLERS.md
A easy way to confirm would be to run the Steam controller test from
Windows (if you have access) and see if it is weird. You will see from
the diagram that the driver is bypassed by hidraw on the linux side. If
hidraw is not usable on the system, a fallback occurs SDL2's js backend
is used to map the device into a "generic" Xbox controller on the
wine/Windows land.
>
> On Monday, November 27th, 2023 at 2:40 PM, Roderick Colenbrander <thunderbird2k@gmail.com> wrote:
>
>
>> This seems a little weird to me. Would you be able to test in using evtest? It would rule out some of the other middle layers which can do their own remapping.
>> Thanks,
>> Roderick
>>
>> On Mon, Nov 27, 2023, 6:42 AM Alexander Koskovich <AKoskovich@protonmail.com> wrote:
>>
>> > I was testing this in the Steam controller test, Cyberpunk 2077 (through GOG, not through Steam), and SuperTuxKart. All of these have wrong mappings for the Edge controller exclusively.
>> > For additional context I have a PS5 controller (non Edge) and it works out of the box. This just seems to be an issue with the Edge variant.
>> >
>> >
>> > On Monday, November 27th, 2023 at 9:37 AM, Roderick Colenbrander <thunderbird2k@gmail.com> wrote:
>> >
>> >
>> > >
>> > >
>> > > Hi Alexander,
>> > >
>> > > Sorry for the late reply, but I have been out for a few days. I'm not
>> > > aware of any button/axis mapping change between Edge and regular
>> > > DualSense. The HID reports stayed the same.
>> > >
>> > > I just did a quick check on my laptop also on Fedora 38 / kernel 6.5
>> > > and the mapping seems to be fine. In evtest, triangle reports
>> > > BTN_NORTH, square BTN_WEST, etcetera.
>> > >
>> > > The sticks, triggers and buttons seem to be fine as well. How are you
>> > > testing this?
>> > >
>> > > Thanks,
>> > > Roderick
>> > >
>> > > On Wed, Nov 22, 2023 at 4:18 PM Alexander Koskovich
>> > > AKoskovich@protonmail.com wrote:
>> > >
>> > > > [Resending email due to lack HTML message rejected]
>> > > >
>> > > > Hello,
>> > > >
>> > > > I am currently on Fedora 39 (6.5.12-300.fc39.x86_64) and I am noticing that the inputs for this controller are wrong primarily on the right side of the controller.
>> > > >
>> > > > playstation 0005:054C:0DF2.000C: hidraw11: BLUETOOTH HID v1.00 Gamepad [DualSense Edge Wireless Controller] on 10:3d:1c:fd:30:bc
>> > > > playstation 0005:054C:0DF2.000C: Registered DualSense controller hw_version=0x01000208 fw_version=0x01000036
>> > > >
>> > > > This is the current mapping that I'm seeing with the hid_playstation module loaded:
>> > > > "X" is actually "Square"
>> > > > "Square" is "Triangle"
>> > > > "Triangle" is "Circle"
>> > > > "Circle" is "X"
>> > > >
>> > > > Also the right joystick seems to be controlling "R2" instead of the right joystick. "L2" and "R2" triggers control the joystick instead. It's overall very weird. Has there been any similar reports to this?
^ permalink raw reply
* Re: Wrong inputs on DualSense Edge Wireless Controller
From: Roderick Colenbrander @ 2023-11-28 2:25 UTC (permalink / raw)
To: Alexander Koskovich; +Cc: Colenbrander, Roelof, linux-input
In-Reply-To: <P8jVfYBAwiM_8MIgshN0osVVfshfBH2-oZCQuqoqh0Hy76_031zuZvYXWl0edtfTUwDOSNlc5priSRXI3G5dboVh5VPbcdxzAcEF7EvUVgo=@protonmail.com>
Hi Alexander,
Thanks for testing. This indeed confirms the kernel side mapping
(hid-playstation) is right. Different software layers e.g. SDL2 and
others tend to do their own mappings. This type of mapping seems to be
incorrect (or even missing for DualSense Edge resulting in a default
fallback).
Thanks,
Roderick
On Mon, Nov 27, 2023 at 5:50 PM Alexander Koskovich
<AKoskovich@protonmail.com> wrote:
>
> I tested in evtest, and it's reporting sane results (cross south, square west, etc). So this seems to be an issue outside of the playstation driver itself?
>
>
> On Monday, November 27th, 2023 at 2:40 PM, Roderick Colenbrander <thunderbird2k@gmail.com> wrote:
>
>
> > This seems a little weird to me. Would you be able to test in using evtest? It would rule out some of the other middle layers which can do their own remapping.
> > Thanks,
> > Roderick
> >
> > On Mon, Nov 27, 2023, 6:42 AM Alexander Koskovich <AKoskovich@protonmail.com> wrote:
> >
> > > I was testing this in the Steam controller test, Cyberpunk 2077 (through GOG, not through Steam), and SuperTuxKart. All of these have wrong mappings for the Edge controller exclusively.
> > > For additional context I have a PS5 controller (non Edge) and it works out of the box. This just seems to be an issue with the Edge variant.
> > >
> > >
> > > On Monday, November 27th, 2023 at 9:37 AM, Roderick Colenbrander <thunderbird2k@gmail.com> wrote:
> > >
> > >
> > > >
> > > >
> > > > Hi Alexander,
> > > >
> > > > Sorry for the late reply, but I have been out for a few days. I'm not
> > > > aware of any button/axis mapping change between Edge and regular
> > > > DualSense. The HID reports stayed the same.
> > > >
> > > > I just did a quick check on my laptop also on Fedora 38 / kernel 6.5
> > > > and the mapping seems to be fine. In evtest, triangle reports
> > > > BTN_NORTH, square BTN_WEST, etcetera.
> > > >
> > > > The sticks, triggers and buttons seem to be fine as well. How are you
> > > > testing this?
> > > >
> > > > Thanks,
> > > > Roderick
> > > >
> > > > On Wed, Nov 22, 2023 at 4:18 PM Alexander Koskovich
> > > > AKoskovich@protonmail.com wrote:
> > > >
> > > > > [Resending email due to lack HTML message rejected]
> > > > >
> > > > > Hello,
> > > > >
> > > > > I am currently on Fedora 39 (6.5.12-300.fc39.x86_64) and I am noticing that the inputs for this controller are wrong primarily on the right side of the controller.
> > > > >
> > > > > playstation 0005:054C:0DF2.000C: hidraw11: BLUETOOTH HID v1.00 Gamepad [DualSense Edge Wireless Controller] on 10:3d:1c:fd:30:bc
> > > > > playstation 0005:054C:0DF2.000C: Registered DualSense controller hw_version=0x01000208 fw_version=0x01000036
> > > > >
> > > > > This is the current mapping that I'm seeing with the hid_playstation module loaded:
> > > > > "X" is actually "Square"
> > > > > "Square" is "Triangle"
> > > > > "Triangle" is "Circle"
> > > > > "Circle" is "X"
> > > > >
> > > > > Also the right joystick seems to be controlling "R2" instead of the right joystick. "L2" and "R2" triggers control the joystick instead. It's overall very weird. Has there been any similar reports to this?
^ permalink raw reply
* Re: Wrong inputs on DualSense Edge Wireless Controller
From: Roderick Colenbrander @ 2023-11-28 2:30 UTC (permalink / raw)
To: Alexander Koskovich; +Cc: Colenbrander, Roelof, linux-input
In-Reply-To: <CAEc3jaCrpbBADiAgSy-kTXqOj_XLy8QuV88GxqY38=2BvG0QZw@mail.gmail.com>
Many applications use SDL2 and don't use evdev directly. Latest SDL2
from git doesn't have the mappings for dualsense edge, but only
regular dualsense. Though usually on SDL2 it would use hidraw.
Depending on what version of the library was used, it may not support
the controller.
See e.g. https://github.com/libsdl-org/SDL/blob/8d47e3bb82288321eb15a0708d1311cbd25a11d6/src/joystick/SDL_gamecontrollerdb.h#L765
On Mon, Nov 27, 2023 at 6:25 PM Roderick Colenbrander
<thunderbird2k@gmail.com> wrote:
>
> Hi Alexander,
>
> Thanks for testing. This indeed confirms the kernel side mapping
> (hid-playstation) is right. Different software layers e.g. SDL2 and
> others tend to do their own mappings. This type of mapping seems to be
> incorrect (or even missing for DualSense Edge resulting in a default
> fallback).
>
> Thanks,
> Roderick
>
> On Mon, Nov 27, 2023 at 5:50 PM Alexander Koskovich
> <AKoskovich@protonmail.com> wrote:
> >
> > I tested in evtest, and it's reporting sane results (cross south, square west, etc). So this seems to be an issue outside of the playstation driver itself?
> >
> >
> > On Monday, November 27th, 2023 at 2:40 PM, Roderick Colenbrander <thunderbird2k@gmail.com> wrote:
> >
> >
> > > This seems a little weird to me. Would you be able to test in using evtest? It would rule out some of the other middle layers which can do their own remapping.
> > > Thanks,
> > > Roderick
> > >
> > > On Mon, Nov 27, 2023, 6:42 AM Alexander Koskovich <AKoskovich@protonmail.com> wrote:
> > >
> > > > I was testing this in the Steam controller test, Cyberpunk 2077 (through GOG, not through Steam), and SuperTuxKart. All of these have wrong mappings for the Edge controller exclusively.
> > > > For additional context I have a PS5 controller (non Edge) and it works out of the box. This just seems to be an issue with the Edge variant.
> > > >
> > > >
> > > > On Monday, November 27th, 2023 at 9:37 AM, Roderick Colenbrander <thunderbird2k@gmail.com> wrote:
> > > >
> > > >
> > > > >
> > > > >
> > > > > Hi Alexander,
> > > > >
> > > > > Sorry for the late reply, but I have been out for a few days. I'm not
> > > > > aware of any button/axis mapping change between Edge and regular
> > > > > DualSense. The HID reports stayed the same.
> > > > >
> > > > > I just did a quick check on my laptop also on Fedora 38 / kernel 6.5
> > > > > and the mapping seems to be fine. In evtest, triangle reports
> > > > > BTN_NORTH, square BTN_WEST, etcetera.
> > > > >
> > > > > The sticks, triggers and buttons seem to be fine as well. How are you
> > > > > testing this?
> > > > >
> > > > > Thanks,
> > > > > Roderick
> > > > >
> > > > > On Wed, Nov 22, 2023 at 4:18 PM Alexander Koskovich
> > > > > AKoskovich@protonmail.com wrote:
> > > > >
> > > > > > [Resending email due to lack HTML message rejected]
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > I am currently on Fedora 39 (6.5.12-300.fc39.x86_64) and I am noticing that the inputs for this controller are wrong primarily on the right side of the controller.
> > > > > >
> > > > > > playstation 0005:054C:0DF2.000C: hidraw11: BLUETOOTH HID v1.00 Gamepad [DualSense Edge Wireless Controller] on 10:3d:1c:fd:30:bc
> > > > > > playstation 0005:054C:0DF2.000C: Registered DualSense controller hw_version=0x01000208 fw_version=0x01000036
> > > > > >
> > > > > > This is the current mapping that I'm seeing with the hid_playstation module loaded:
> > > > > > "X" is actually "Square"
> > > > > > "Square" is "Triangle"
> > > > > > "Triangle" is "Circle"
> > > > > > "Circle" is "X"
> > > > > >
> > > > > > Also the right joystick seems to be controlling "R2" instead of the right joystick. "L2" and "R2" triggers control the joystick instead. It's overall very weird. Has there been any similar reports to this?
^ 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