Skip to contentSkip to conversation

arm64: dts: rockchip: enable touchpad button for rk3399-gru-kevin

PATCH In review Emil Renner Berthing 4 participants 6 messages Oct 9, 2017 – Oct 14, 2017

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 arm64: dts: rockchip: enable touchpad button for rk3399-gru-kevin

Adding the linux,gpio-keymap entry also has
the side-effect of making the driver register
the touchpad as a touchpad rather than another
touchscreen.

The index for BTN_LEFT was found by trial and error.

---
 arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 4 ++++
 1 file changed, 4 insertions(+)
arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts +4 -0
index 5c8621766908..1c58d12551f5 100644
@@ -278,6 +278,10 @@ ap_i2c_dig: &i2c2 {
 		pinctrl-0 = <&trackpad_int_l>;
 		interrupt-parent = <&gpio1>;
 		interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
+		linux,gpio-keymap = <KEY_RESERVED
+				     KEY_RESERVED
+				     KEY_RESERVED
+				     BTN_LEFT>;
 		wakeup-source;
 	};
 };
Signature · 1 line
2.14.2
maintainer
#1 lore raw

Hi Emil,

Am Montag, 9. Oktober 2017, 20:40:28 CEST schrieb Emil Renner Berthing:

Quoted 8 lines

Adding the linux,gpio-keymap entry also has
the side-effect of making the driver register
the touchpad as a touchpad rather than another
touchscreen.

The index for BTN_LEFT was found by trial and error.

looks good to me. I'll just give the ChromeOS people a chance to respond before applying [maybe they can even tell what the other keys are :-) ]

Heiko

Quoted 20 lines
---
 arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts | 4 ++++
 1 file changed, 4 insertions(+)
arch/arm64/boot/dts/rockchip/rk3399-gru-kevin.dts +4 -0
index 5c8621766908..1c58d12551f5 100644
@@ -278,6 +278,10 @@ ap_i2c_dig: &i2c2 {
 		pinctrl-0 = <&trackpad_int_l>;
 		interrupt-parent = <&gpio1>;
 		interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
+		linux,gpio-keymap = <KEY_RESERVED
+				     KEY_RESERVED
+				     KEY_RESERVED
+				     BTN_LEFT>;
 		wakeup-source;
 	};
 };
#2 lore raw
Quoted 6 lines · Heiko Stuebner

Am Montag, 9. Oktober 2017, 20:40:28 CEST schrieb Emil Renner Berthing:

Quoted 5 lines

Adding the linux,gpio-keymap entry also has
the side-effect of making the driver register
the touchpad as a touchpad rather than another
touchscreen.

Quoted 7 lines
Quoted 3 lines

The index for BTN_LEFT was found by trial and error.

looks good to me. I'll just give the ChromeOS people a chance to respond before applying [maybe they can even tell what the other keys are :-) ]

Good plan. As far as I can tell their kernel doesn't send anything but BTN_LEFT either. It's just that the controller supports multiple buttons, but not all are necessarily connected to any button. Their version of the driver has logic to detect the proper keymap whereas the mainline driver gets it from this devicetree entry.

/Emil

#3 lore raw

+ Dmitry, who can probably answer better than I can

Quoted 15 lines · Emil Renner Berthing
Quoted 6 lines · Heiko Stuebner

Am Montag, 9. Oktober 2017, 20:40:28 CEST schrieb Emil Renner Berthing:

Quoted 5 lines

Adding the linux,gpio-keymap entry also has
the side-effect of making the driver register
the touchpad as a touchpad rather than another
touchscreen.

Quoted 7 lines
Quoted 3 lines

The index for BTN_LEFT was found by trial and error.

looks good to me. I'll just give the ChromeOS people a chance to respond before applying [maybe they can even tell what the other keys are :-) ]

Quoted 5 lines

Good plan. As far as I can tell their kernel doesn't send anything but BTN_LEFT either. It's just that the controller supports multiple buttons, but not all are necessarily connected to any button. Their version of the driver has logic to detect the proper keymap whereas the mainline driver gets it from this devicetree entry.

I believe Emil is mostly correct. We only are using a BTN_LEFT in our copy of the driver, and I'm not sure the others are connected to anything. As Dmitry has explained to me (when I also wondered about "detect[ing] the proper keymap"), we don't exactly "auto"discover things; we just heuristically determine the configurations we know are used on Chrome devices.

So from the sound of it, this keymap property is reasonable. I haven't actually checked what our driver "auto" detects on gru-kevin, but if this works then I'll bet it's correct :)

IOW, I don't know enough to ACK this patch, but I'm certainly not going to NAK it.

Brian

#4 lore raw
Quoted 17 lines · Brian Norris

+ Dmitry, who can probably answer better than I can

Quoted 14 lines · Emil Renner Berthing
Quoted 13 lines · Heiko Stuebner

Am Montag, 9. Oktober 2017, 20:40:28 CEST schrieb Emil Renner Berthing:

Quoted 8 lines

Adding the linux,gpio-keymap entry also has
the side-effect of making the driver register
the touchpad as a touchpad rather than another
touchscreen.

The index for BTN_LEFT was found by trial and error.

looks good to me. I'll just give the ChromeOS people a chance to respond before applying [maybe they can even tell what the other keys are :-) ]

They are not connected.

Quoted 7 lines
Quoted 6 lines

Good plan. As far as I can tell their kernel doesn't send anything but BTN_LEFT either. It's just that the controller supports multiple buttons, but not all are necessarily connected to any button. Their version of the driver has logic to detect the proper keymap whereas the mainline driver gets it from this devicetree entry.

Quoted 6 lines

I believe Emil is mostly correct. We only are using a BTN_LEFT in our copy of the driver, and I'm not sure the others are connected to anything. As Dmitry has explained to me (when I also wondered about "detect[ing] the proper keymap"), we don't exactly "auto"discover things; we just heuristically determine the configurations we know are used on Chrome devices.

Right, we had a "legacy" GPIO/button mapping on original Pixels that used T9 multitouch reports, then we switched to a bit different mapping for newer devices that use T100 multitouch reports.

We should really have explicit map, like we have in upstream driver.

Quoted 7 lines

So from the sound of it, this keymap property is reasonable. I haven't actually checked what our driver "auto" detects on gru-kevin, but if this works then I'll bet it's correct :)

IOW, I don't know enough to ACK this patch, but I'm certainly not going to NAK it.

I think I can ACK it:

Thanks.

Signature · 1 line
Dmitry