Re: [RESEND 00/25] Rid W=1 warnings from HID
On Thu, Apr 8, 2021 at 9:06 AM Lee Jones wrote: > > On Wed, 07 Apr 2021, Benjamin Tissoires wrote: > > > On Tue, Apr 6, 2021 at 10:56 AM Lee Jones wrote: > > > > > > On Fri, 26 Mar 2021, Lee Jones wrote: > > > > > > > This set is part of a larger effort attempting to clean-up W=1 > > > > kernel builds, which are currently overwhelmingly riddled with > > > > niggly little warnings. > > > > > > > > Lee Jones (25): > > > > HID: intel-ish-hid: Remove unused variable 'err' > > > > HID: ishtp-hid-client: Move variable to where it's actually used > > > > HID: intel-ish-hid: pci-ish: Remove unused variable 'ret' > > > > HID: intel-ish: Supply some missing param descriptions > > > > HID: intel-ish: Fix a naming disparity and a formatting error > > > > HID: usbhid: Repair a formatting issue in a struct description > > > > HID: intel-ish-hid: Fix a little doc-rot > > > > HID: usbhid: hid-pidff: Demote a couple kernel-doc abuses > > > > HID: hid-alps: Correct struct misnaming > > > > HID: intel-ish-hid: Fix potential copy/paste error > > > > HID: hid-core: Fix incorrect function name in header > > > > HID: intel-ish-hid: ipc: Correct fw_reset_work_fn() function name in > > > > header > > > > HID: ishtp-hid-client: Fix incorrect function name report_bad_packet() > > > > HID: hid-kye: Fix incorrect function name for kye_tablet_enable() > > > > HID: hid-picolcd_core: Remove unused variable 'ret' > > > > HID: hid-logitech-hidpp: Fix conformant kernel-doc header and demote > > > > abuses > > > > HID: hid-uclogic-rdesc: Kernel-doc is for functions and structs > > > > HID: hid-thrustmaster: Demote a bunch of kernel-doc abuses > > > > HID: hid-uclogic-params: Ensure function names are present and correct > > > > in kernel-doc headers > > > > HID: hid-sensor-custom: Remove unused variable 'ret' > > > > HID: wacom_sys: Demote kernel-doc abuse > > > > HID: hid-sensor-hub: Remove unused struct member 'quirks' > > > > HID: hid-sensor-hub: Move 'hsdev' description to correct struct > > > > definition > > > > HID: intel-ish-hid: ishtp-fw-loader: Fix a bunch of formatting issues > > > > HID: ishtp-hid-client: Fix 'suggest-attribute=format' compiler warning > > > > > > These have been on the list for a couple of weeks now. > > > > > > Is there anything I can do to help expedite their merge? > > > > > > I'm concerned since -rc6 has just been released. > > > > Sorry for the delay. > > > > I am currently queuing them locally and running a few tests on them. I > > don't expect anything to happen, but better be safe than anything. > > > > FWIW, I am splitting the series in 3: > > - 11 patches for intel ish are going to be queued in for-5.13/intel-ish > > - the thrustmaster one in for-5.13/thrustmaster > > - the rest (13 patches) will be sent in for-5.13/warnings. > > Sounds good to me. Thanks Benjamin. > After a few attempts at fixing my CI, I have now pushed this series as mentioned previously. Cheers, Benjamin
Re: [PATCH 06/25] HID: usbhid: Repair a formatting issue in a struct description
On Fri, Mar 26, 2021 at 3:35 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/hid/usbhid/usbkbd.c:66: warning: bad line: should be
> on
>
> Cc: Jiri Kosina
> Cc: Benjamin Tissoires
> Cc: message to
> Cc: linux-...@vger.kernel.org
> Cc: linux-in...@vger.kernel.org
> Signed-off-by: Lee Jones
> ---
> drivers/hid/usbhid/usbkbd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/usbhid/usbkbd.c b/drivers/hid/usbhid/usbkbd.c
> index d5b7a696a68c5..d0c640be8a885 100644
> --- a/drivers/hid/usbhid/usbkbd.c
> +++ b/drivers/hid/usbhid/usbkbd.c
> @@ -63,7 +63,7 @@ static const unsigned char usb_kbd_keycode[256] = {
> * new key is pressed or a key that was pressed is released.
> * @led: URB for sending LEDs (e.g. numlock, ...)
> * @newleds: data that will be sent with the @led URB representing which
> LEDs
> - should be on
> + * should be on
nitpick: checkpatch complains about spaces before tabs here.
I amended locally and will push the fixed version.
Cheers,
Benjamin
> * @name: Name of the keyboard. @dev's name field points to this buffer
> * @phys: Physical path of the keyboard. @dev's phys field points to
> this
> * buffer
> --
> 2.27.0
>
Re: [RESEND 00/25] Rid W=1 warnings from HID
On Tue, Apr 6, 2021 at 10:56 AM Lee Jones wrote: > > On Fri, 26 Mar 2021, Lee Jones wrote: > > > This set is part of a larger effort attempting to clean-up W=1 > > kernel builds, which are currently overwhelmingly riddled with > > niggly little warnings. > > > > Lee Jones (25): > > HID: intel-ish-hid: Remove unused variable 'err' > > HID: ishtp-hid-client: Move variable to where it's actually used > > HID: intel-ish-hid: pci-ish: Remove unused variable 'ret' > > HID: intel-ish: Supply some missing param descriptions > > HID: intel-ish: Fix a naming disparity and a formatting error > > HID: usbhid: Repair a formatting issue in a struct description > > HID: intel-ish-hid: Fix a little doc-rot > > HID: usbhid: hid-pidff: Demote a couple kernel-doc abuses > > HID: hid-alps: Correct struct misnaming > > HID: intel-ish-hid: Fix potential copy/paste error > > HID: hid-core: Fix incorrect function name in header > > HID: intel-ish-hid: ipc: Correct fw_reset_work_fn() function name in > > header > > HID: ishtp-hid-client: Fix incorrect function name report_bad_packet() > > HID: hid-kye: Fix incorrect function name for kye_tablet_enable() > > HID: hid-picolcd_core: Remove unused variable 'ret' > > HID: hid-logitech-hidpp: Fix conformant kernel-doc header and demote > > abuses > > HID: hid-uclogic-rdesc: Kernel-doc is for functions and structs > > HID: hid-thrustmaster: Demote a bunch of kernel-doc abuses > > HID: hid-uclogic-params: Ensure function names are present and correct > > in kernel-doc headers > > HID: hid-sensor-custom: Remove unused variable 'ret' > > HID: wacom_sys: Demote kernel-doc abuse > > HID: hid-sensor-hub: Remove unused struct member 'quirks' > > HID: hid-sensor-hub: Move 'hsdev' description to correct struct > > definition > > HID: intel-ish-hid: ishtp-fw-loader: Fix a bunch of formatting issues > > HID: ishtp-hid-client: Fix 'suggest-attribute=format' compiler warning > > These have been on the list for a couple of weeks now. > > Is there anything I can do to help expedite their merge? > > I'm concerned since -rc6 has just been released. Sorry for the delay. I am currently queuing them locally and running a few tests on them. I don't expect anything to happen, but better be safe than anything. FWIW, I am splitting the series in 3: - 11 patches for intel ish are going to be queued in for-5.13/intel-ish - the thrustmaster one in for-5.13/thrustmaster - the rest (13 patches) will be sent in for-5.13/warnings. Cheers, Benjamin
Re: [PATCH 0/4] Stylus-on-touchscreen device support
Hi Jiri, On Mon, Mar 8, 2021 at 11:15 AM Jiri Kosina wrote: > > On Wed, 17 Feb 2021, наб wrote: > > > This patchset adds support for stylus-on-touchscreen devices as found on > > the OneMix 3 Pro and Dell Inspiron 15 7000 2-in-1 (7591), among others; > > with it, they properly behave like a drawing tablet. > > > > Patches 2 and 4 funxionally depend on patch 1. > > Patch 4 needs patch 3 to apply. > > > > The output of this patchset and the need for a kernel, rather than > > userspace, patch was previously discussed here: > > > > https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/558#note_792834 > > > > Ahelenia Ziemiańska (4): > > HID: multitouch: require Finger field to mark Win8 reports as MT > > HID: multitouch: set Stylus suffix for Stylus-application devices, too > > HID: input: replace outdated HID numbers+comments with macros > > HID: input: work around Win8 stylus-on-touchscreen reporting > > > > drivers/hid/hid-input.c | 47 +--- > > drivers/hid/hid-multitouch.c | 18 -- > > 2 files changed, 55 insertions(+), 10 deletions(-) > > Benjamin, this patchset looks good to me; do you have any objections on > queuing it for 5.13? > Please hold on this one. I am pretty sure this should break the test suite but couldn't have the chance to get to it. Will pop this one up in TODO list. Cheers, Benjamin
Re: [PATCH 1/2] HID: logitech-dj: add support for the new lightspeed receiver iteration
On Sat, Jan 23, 2021 at 7:03 PM Filipe Laíns wrote:
>
> From: Filipe Laíns
>
> Tested with the G Pro X Superlight. libratbag sees the device, as
> expected, and input events are passing trough.
>
> https://github.com/libratbag/libratbag/pull/1122
>
> The receiver has a quirk where the moused interface doesn't have a
> report ID, I am not sure why, perhaps they forgot. All other interfaces
> have report IDs so I am left scratching my head.
> Since this driver doesn't have a quirk system, I simply implemented it
> as a different receiver type, which is true, it just wouldn't be the
> prefered approach :P
>
> Signed-off-by: Filipe Laíns
> ---
> drivers/hid/hid-ids.h | 1 +
> drivers/hid/hid-logitech-dj.c | 49 +--
> 2 files changed, 37 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index 4c5f23640f9c..8eac3c93fa38 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -803,6 +803,7 @@
> #define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1 0xc539
> #define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1_10xc53f
> #define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_POWERPLAY 0xc53a
> +#define USB_DEVICE_ID_LOGITECH_NANO_RECEIVER_LIGHTSPEED_1_20xc547
> #define USB_DEVICE_ID_SPACETRAVELLER 0xc623
> #define USB_DEVICE_ID_SPACENAVIGATOR 0xc626
> #define USB_DEVICE_ID_DINOVO_DESKTOP 0xc704
> diff --git a/drivers/hid/hid-logitech-dj.c b/drivers/hid/hid-logitech-dj.c
> index 1401ee2067ca..6596c81947a8 100644
> --- a/drivers/hid/hid-logitech-dj.c
> +++ b/drivers/hid/hid-logitech-dj.c
> @@ -114,6 +114,7 @@ enum recvr_type {
> recvr_type_dj,
> recvr_type_hidpp,
> recvr_type_gaming_hidpp,
> + recvr_type_gaming_hidpp_missing_mse_report_id, /* lightspeed
> receiver missing the mouse report ID */
> recvr_type_mouse_only,
> recvr_type_27mhz,
> recvr_type_bluetooth,
> @@ -1360,6 +1361,7 @@ static int logi_dj_ll_parse(struct hid_device *hid)
> dbg_hid("%s: sending a mouse descriptor, reports_supported:
> %llx\n",
> __func__, djdev->reports_supported);
> if (djdev->dj_receiver_dev->type == recvr_type_gaming_hidpp ||
> + djdev->dj_receiver_dev->type ==
> recvr_type_gaming_hidpp_missing_mse_report_id ||
> djdev->dj_receiver_dev->type == recvr_type_mouse_only)
> rdcat(rdesc, , mse_high_res_descriptor,
> sizeof(mse_high_res_descriptor));
> @@ -1605,19 +1607,35 @@ static int logi_dj_raw_event(struct hid_device *hdev,
> data[0] = data[1];
> data[1] = 0;
> }
> - /*
> -* Mouse-only receivers send unnumbered mouse data. The 27 MHz
> -* receiver uses 6 byte packets, the nano receiver 8 bytes.
> -*/
> - if (djrcv_dev->unnumbered_application == HID_GD_MOUSE &&
> - size <= 8) {
> - u8 mouse_report[9];
> -
> - /* Prepend report id */
> - mouse_report[0] = REPORT_TYPE_MOUSE;
> - memcpy(mouse_report + 1, data, size);
> - logi_dj_recv_forward_input_report(hdev, mouse_report,
> - size + 1);
> +
> +
> + if (djrcv_dev->unnumbered_application == HID_GD_MOUSE) {
> + /*
> +* Mouse-only receivers send unnumbered mouse data.
> The 27 MHz
> +* receiver uses 6 byte packets, the nano receiver 8
> bytes.
> +*/
> + if (size <= 8) {
> + u8 mouse_report[9];
Hmm, as stated above, the 27 MHz receiver already does the exact same thing.
Can't we just bump the array size and check above to the following:
if (size <= 16) {
u8 mouse_report[17];
The property "djrcv_dev->unnumbered_application" is based on the
report descriptor entirely, and they are just following the HID norm
here. So I think this should be enough.
Cheers,
Benjamin
> +
> + /* Prepend report id */
> + mouse_report[0] = REPORT_TYPE_MOUSE;
> + memcpy(mouse_report + 1, data, size);
> + logi_dj_recv_forward_input_report(hdev,
> mouse_report,
> + size + 1);
> +
> + /*
> +* A variant of the ligtpseed receivers is missing
> the mouse
> +* report ID.
> +*/
> + } else if (djrcv_dev->type ==
> recvr_type_gaming_hidpp_missing_mse_report_id) {
> + u8
Re: [PATCH v2 4/4] HID: i2c-hid: acpi: Drop redundant ACPI_PTR()
Hi,
On Fri, Feb 26, 2021 at 8:34 PM Andy Shevchenko
wrote:
>
> The driver depends on ACPI, ACPI_PTR() resolution is always the same.
> Otherwise a compiler may produce a warning.
>
> That said, the rule of thumb either ugly ifdeffery with ACPI_PTR or
> none should be used in a driver.
>
> Signed-off-by: Andy Shevchenko
Thanks a lot for the series. This indeed cleans things up.
For the series:
Acked-by: Benjamin Tissoires
Jiri, I wonder where we want to land this one. This is not strictly
bug fixes, but we could definitively sneak this one in 5.12-rc1.
Well, I should probably run the series on an acpi laptop here before
merging, but I'd like to know if delaying to 5.13 is OK or if we need
this in 5.12.
Cheers,
Benjamin
> ---
> v2: no changes
> drivers/hid/i2c-hid/i2c-hid-acpi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi.c
> b/drivers/hid/i2c-hid/i2c-hid-acpi.c
> index a4810f199d59..a6f0257a26de 100644
> --- a/drivers/hid/i2c-hid/i2c-hid-acpi.c
> +++ b/drivers/hid/i2c-hid/i2c-hid-acpi.c
> @@ -126,7 +126,7 @@ static struct i2c_driver i2c_hid_acpi_driver = {
> .name = "i2c_hid_acpi",
> .pm = _hid_core_pm,
> .probe_type = PROBE_PREFER_ASYNCHRONOUS,
> - .acpi_match_table = ACPI_PTR(i2c_hid_acpi_match),
> + .acpi_match_table = i2c_hid_acpi_match,
> },
>
> .probe_new = i2c_hid_acpi_probe,
> --
> 2.30.0
>
Re: [PATCH 3/5] HID: core: Export some report item parsing functions.
On Mon, Mar 1, 2021 at 3:18 PM Andy Shevchenko
wrote:
>
> On Sun, Feb 28, 2021 at 3:30 AM Ronald Tschalär wrote:
> >
> > These are useful to drivers that need to scan or parse reports
> > themselves.
>
> ...
>
> > - while ((start = fetch_item(start, end, )) != NULL)
> > + while ((start = hid_fetch_item(start, end, )) != NULL)
> > dispatch_type[item.type](parser, );
>
> > - while ((next = fetch_item(start, end, )) != NULL) {
> > + while ((next = hid_fetch_item(start, end, )) != NULL) {
> > start = next;
>
> I don't see the full picture, but perhaps you may also introduce
> for_each_hid_item() or so.
Same here, I don't see the full picture, but I would suggest to not
export those functions at all.
>From 4/5, I can see that you are using them in
appleib_find_collection(), which is only called by
appleib_add_device(), which in turn is always called with a parsed and
started HID device. Why can you not rely on the core parsing and
iterate over the already parsed hid_field?
Cheers,
Benjamin
Re: [PATCH 00/11] HID: playstation: revert LED class exposure
On Wed, Feb 17, 2021 at 6:32 PM Benjamin Tissoires wrote: > > [sending those patches on behalf of Roderick] > > There is a current thread on LED LKML which basically means that > we have to revert the LED class exposure until things are settled. > > I am sending here the full series that will end up in linux-next. > But with some git magic, the final PR to Linus will not have the > reverts in it, just the plain patches. > > I am queuing in for-5.12/playstation patches 1 to 6 immediately > (the reverts). > > I am also queuing in for-5.12/playstation-v2 patches 7 and 8 on > top of 51151098d7ab8 immediately. Those 2 patches have already > been reviewed the usual process. > > I am waiting 1 day for others to chime in regarding patches 9 to > 11 before applying them to for-5.12/playstation-v2. They are > basically the same patches that were already reviewed on the > linux-input LKML, but without the LED class bits. And I just pushed those 3 patches to for-5.12/playstation-v2. Cheers, Benjamin > > With all that, we should have more room to discuss the exposure > of the LEDs to userspace through the LED class. > > Roderick, I made small adjustments compared to the series you sent > me privately: > - added the 2 missing reverts/re-add, so I can have clean merges > for our for-next branch, > - re-ordered the `if (ds->update_rumble)` block in > `dualsense_output_worker()` to match was was in linux-next > - removed an extra new line to match the current linux-next tree. > > Cheers, > Benjamin > > Benjamin Tissoires (2): > Revert "HID: playstation: fix unused variable in > ps_battery_get_property." > Revert "HID: playstation: report DualSense hardware and firmware > version." > > Roderick Colenbrander (9): > Revert "HID: playstation: DualSense set LEDs to default player id." > Revert "HID: playstation: add DualSense player LEDs support." > Revert "HID: playstation: add microphone mute support for DualSense." > Revert "HID: playstation: add DualSense lightbar support" > HID: playstation: report DualSense hardware and firmware version. > HID: playstation: fix unused variable in ps_battery_get_property. > HID: playstation: add initial DualSense lightbar support. > HID: playstation: add microphone mute support for DualSense. > HID: playstation: add DualSense player LED support. > > drivers/hid/Kconfig | 3 - > drivers/hid/hid-playstation.c | 177 +++--- > 2 files changed, 12 insertions(+), 168 deletions(-) > > -- > 2.29.2 >
Re: [PATCH][next] HID: playstation: fix array size comparison (off-by-one)
On Mon, Feb 15, 2021 at 5:39 PM Colin King wrote:
>
> From: Colin Ian King
>
> The comparison of value with the array size ps_gamepad_hat_mapping
> appears to be off-by-one. Fix this by using >= rather than > for the
> size comparison.
>
> Addresses-Coverity: ("Out-of-bounds read")
> Fixes: bc2e15a9a022 ("HID: playstation: initial DualSense USB support.")
> Signed-off-by: Colin Ian King
> ---
Good catch.
Applied to for-5.12/playstation-v2
Cheers,
Benjamin
> drivers/hid/hid-playstation.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
> index 408b651174cf..568a3a067c88 100644
> --- a/drivers/hid/hid-playstation.c
> +++ b/drivers/hid/hid-playstation.c
> @@ -1064,7 +1064,7 @@ static int dualsense_parse_report(struct ps_device
> *ps_dev, struct hid_report *r
> input_report_abs(ds->gamepad, ABS_RZ, ds_report->rz);
>
> value = ds_report->buttons[0] & DS_BUTTONS0_HAT_SWITCH;
> - if (value > ARRAY_SIZE(ps_gamepad_hat_mapping))
> + if (value >= ARRAY_SIZE(ps_gamepad_hat_mapping))
> value = 8; /* center */
> input_report_abs(ds->gamepad, ABS_HAT0X,
> ps_gamepad_hat_mapping[value].x);
> input_report_abs(ds->gamepad, ABS_HAT0Y,
> ps_gamepad_hat_mapping[value].y);
> --
> 2.30.0
>
[PATCH 10/11] HID: playstation: add microphone mute support for DualSense.
From: Roderick Colenbrander
The DualSense controller has a built-in microphone exposed as an
audio device over USB (or HID using Bluetooth). A dedicated
button on the controller handles mute, but software has to configure
the device to mute the audio stream.
This patch captures the mute button and schedules an output report
to mute/unmute the audio stream as well as toggle the mute LED.
Signed-off-by: Roderick Colenbrander
Reviewed-by: Barnabás Pőcze
Signed-off-by: Benjamin Tissoires
---
drivers/hid/hid-playstation.c | 44 +++
1 file changed, 44 insertions(+)
diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
index b141b1be6453..04743fa0e03d 100644
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -85,6 +85,7 @@ struct ps_calibration_data {
#define DS_BUTTONS1_R3 BIT(7)
#define DS_BUTTONS2_PS_HOMEBIT(0)
#define DS_BUTTONS2_TOUCHPAD BIT(1)
+#define DS_BUTTONS2_MIC_MUTE BIT(2)
/* Status field of DualSense input report. */
#define DS_STATUS_BATTERY_CAPACITY GENMASK(3, 0)
@@ -103,9 +104,12 @@ struct ps_calibration_data {
/* Flags for DualSense output report. */
#define DS_OUTPUT_VALID_FLAG0_COMPATIBLE_VIBRATION BIT(0)
#define DS_OUTPUT_VALID_FLAG0_HAPTICS_SELECT BIT(1)
+#define DS_OUTPUT_VALID_FLAG1_MIC_MUTE_LED_CONTROL_ENABLE BIT(0)
+#define DS_OUTPUT_VALID_FLAG1_POWER_SAVE_CONTROL_ENABLE BIT(1)
#define DS_OUTPUT_VALID_FLAG1_LIGHTBAR_CONTROL_ENABLE BIT(2)
#define DS_OUTPUT_VALID_FLAG1_RELEASE_LEDS BIT(3)
#define DS_OUTPUT_VALID_FLAG2_LIGHTBAR_SETUP_CONTROL_ENABLE BIT(1)
+#define DS_OUTPUT_POWER_SAVE_CONTROL_MIC_MUTE BIT(4)
#define DS_OUTPUT_LIGHTBAR_SETUP_LIGHT_OUT BIT(1)
/* DualSense hardware limits */
@@ -142,6 +146,11 @@ struct dualsense {
uint8_t lightbar_green;
uint8_t lightbar_blue;
+ /* Microphone */
+ bool update_mic_mute;
+ bool mic_muted;
+ bool last_btn_mic_state;
+
struct work_struct output_worker;
void *output_report_dmabuf;
uint8_t output_seq; /* Sequence number for output report. */
@@ -815,6 +824,23 @@ static void dualsense_output_worker(struct work_struct
*work)
ds->update_lightbar = false;
}
+ if (ds->update_mic_mute) {
+ common->valid_flag1 |=
DS_OUTPUT_VALID_FLAG1_MIC_MUTE_LED_CONTROL_ENABLE;
+ common->mute_button_led = ds->mic_muted;
+
+ if (ds->mic_muted) {
+ /* Disable microphone */
+ common->valid_flag1 |=
DS_OUTPUT_VALID_FLAG1_POWER_SAVE_CONTROL_ENABLE;
+ common->power_save_control |=
DS_OUTPUT_POWER_SAVE_CONTROL_MIC_MUTE;
+ } else {
+ /* Enable microphone */
+ common->valid_flag1 |=
DS_OUTPUT_VALID_FLAG1_POWER_SAVE_CONTROL_ENABLE;
+ common->power_save_control &=
~DS_OUTPUT_POWER_SAVE_CONTROL_MIC_MUTE;
+ }
+
+ ds->update_mic_mute = false;
+ }
+
spin_unlock_irqrestore(>base.lock, flags);
dualsense_send_output_report(ds, );
@@ -829,6 +855,7 @@ static int dualsense_parse_report(struct ps_device *ps_dev,
struct hid_report *r
uint8_t battery_data, battery_capacity, charging_status, value;
int battery_status;
uint32_t sensor_timestamp;
+ bool btn_mic_state;
unsigned long flags;
int i;
@@ -884,6 +911,23 @@ static int dualsense_parse_report(struct ps_device
*ps_dev, struct hid_report *r
input_report_key(ds->gamepad, BTN_MODE, ds_report->buttons[2] &
DS_BUTTONS2_PS_HOME);
input_sync(ds->gamepad);
+ /*
+* The DualSense has an internal microphone, which can be muted through
a mute button
+* on the device. The driver is expected to read the button state and
program the device
+* to mute/unmute audio at the hardware level.
+*/
+ btn_mic_state = !!(ds_report->buttons[2] & DS_BUTTONS2_MIC_MUTE);
+ if (btn_mic_state && !ds->last_btn_mic_state) {
+ spin_lock_irqsave(_dev->lock, flags);
+ ds->update_mic_mute = true;
+ ds->mic_muted = !ds->mic_muted; /* toggle */
+ spin_unlock_irqrestore(_dev->lock, flags);
+
+ /* Schedule updating of microphone state at hardware level. */
+ schedule_work(>output_worker);
+ }
+ ds->last_btn_mic_state = btn_mic_state;
+
/* Parse and calibrate gyroscope data. */
for (i = 0; i < ARRAY_SIZE(ds_report->gyro); i++) {
int raw_data = (short)le16_to_cpu(ds_report->gyro[i]);
--
2.29.2
[PATCH 09/11] HID: playstation: add initial DualSense lightbar support.
From: Roderick Colenbrander
Provide initial support for the DualSense lightbar and configure it
with a default PlayStation blue color.
Signed-off-by: Roderick Colenbrander
Reviewed-by: Barnabás Pőcze
Signed-off-by: Benjamin Tissoires
---
drivers/hid/hid-playstation.c | 65 +++
1 file changed, 65 insertions(+)
diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
index f279064e74a5..b141b1be6453 100644
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -103,6 +103,10 @@ struct ps_calibration_data {
/* Flags for DualSense output report. */
#define DS_OUTPUT_VALID_FLAG0_COMPATIBLE_VIBRATION BIT(0)
#define DS_OUTPUT_VALID_FLAG0_HAPTICS_SELECT BIT(1)
+#define DS_OUTPUT_VALID_FLAG1_LIGHTBAR_CONTROL_ENABLE BIT(2)
+#define DS_OUTPUT_VALID_FLAG1_RELEASE_LEDS BIT(3)
+#define DS_OUTPUT_VALID_FLAG2_LIGHTBAR_SETUP_CONTROL_ENABLE BIT(1)
+#define DS_OUTPUT_LIGHTBAR_SETUP_LIGHT_OUT BIT(1)
/* DualSense hardware limits */
#define DS_ACC_RES_PER_G 8192
@@ -132,6 +136,12 @@ struct dualsense {
uint8_t motor_left;
uint8_t motor_right;
+ /* RGB lightbar */
+ bool update_lightbar;
+ uint8_t lightbar_red;
+ uint8_t lightbar_green;
+ uint8_t lightbar_blue;
+
struct work_struct output_worker;
void *output_report_dmabuf;
uint8_t output_seq; /* Sequence number for output report. */
@@ -796,6 +806,15 @@ static void dualsense_output_worker(struct work_struct
*work)
ds->update_rumble = false;
}
+ if (ds->update_lightbar) {
+ common->valid_flag1 |=
DS_OUTPUT_VALID_FLAG1_LIGHTBAR_CONTROL_ENABLE;
+ common->lightbar_red = ds->lightbar_red;
+ common->lightbar_green = ds->lightbar_green;
+ common->lightbar_blue = ds->lightbar_blue;
+
+ ds->update_lightbar = false;
+ }
+
spin_unlock_irqrestore(>base.lock, flags);
dualsense_send_output_report(ds, );
@@ -980,6 +999,41 @@ static int dualsense_play_effect(struct input_dev *dev,
void *data, struct ff_ef
return 0;
}
+static int dualsense_reset_leds(struct dualsense *ds)
+{
+ struct dualsense_output_report report;
+ uint8_t *buf;
+
+ buf = kzalloc(sizeof(struct dualsense_output_report_bt), GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ dualsense_init_output_report(ds, , buf);
+ /*
+* On Bluetooth the DualSense outputs an animation on the lightbar
+* during startup and maintains a color afterwards. We need to
explicitly
+* reconfigure the lightbar before we can do any programming later on.
+* In USB the lightbar is not on by default, but redoing the setup there
+* doesn't hurt.
+*/
+ report.common->valid_flag2 =
DS_OUTPUT_VALID_FLAG2_LIGHTBAR_SETUP_CONTROL_ENABLE;
+ report.common->lightbar_setup = DS_OUTPUT_LIGHTBAR_SETUP_LIGHT_OUT; /*
Fade light out. */
+ dualsense_send_output_report(ds, );
+
+ kfree(buf);
+ return 0;
+}
+
+static void dualsense_set_lightbar(struct dualsense *ds, uint8_t red, uint8_t
green, uint8_t blue)
+{
+ ds->update_lightbar = true;
+ ds->lightbar_red = red;
+ ds->lightbar_green = green;
+ ds->lightbar_blue = blue;
+
+ schedule_work(>output_worker);
+}
+
static struct ps_device *dualsense_create(struct hid_device *hdev)
{
struct dualsense *ds;
@@ -1057,6 +,17 @@ static struct ps_device *dualsense_create(struct
hid_device *hdev)
if (ret)
goto err;
+ /*
+* The hardware may have control over the LEDs (e.g. in Bluetooth on
startup).
+* Reset the LEDs (lightbar, mute, player leds), so we can control them
+* from software.
+*/
+ ret = dualsense_reset_leds(ds);
+ if (ret)
+ goto err;
+
+ dualsense_set_lightbar(ds, 0, 0, 128); /* blue */
+
/*
* Reporting hardware and firmware is important as there are frequent
updates, which
* can change behavior.
--
2.29.2
[PATCH 11/11] HID: playstation: add DualSense player LED support.
From: Roderick Colenbrander
The DualSense features 5 player LEDs below its touchpad, which are
meant as player id indications. The LEDs are configured with a
player ID determined by an ID allocator, which assign player ids
to ps_device instances.
This patch is a combination of the following original patches
minus use of LED framework APIs:
- HID: playstation: add DualSense player LEDs support.
- HID: playstation: DualSense set LEDs to default player id.
Signed-off-by: Roderick Colenbrander
Reviewed-by: Barnabás Pőcze
Signed-off-by: Benjamin Tissoires
---
drivers/hid/hid-playstation.c | 83 ++-
1 file changed, 82 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
index 04743fa0e03d..7f65d30ca77c 100644
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include
#include
@@ -20,6 +21,8 @@
static DEFINE_MUTEX(ps_devices_lock);
static LIST_HEAD(ps_devices_list);
+static DEFINE_IDA(ps_player_id_allocator);
+
#define HID_PLAYSTATION_VERSION_PATCH 0x8000
/* Base class for playstation devices. */
@@ -28,6 +31,8 @@ struct ps_device {
struct hid_device *hdev;
spinlock_t lock;
+ uint32_t player_id;
+
struct power_supply_desc battery_desc;
struct power_supply *battery;
uint8_t battery_capacity;
@@ -108,6 +113,7 @@ struct ps_calibration_data {
#define DS_OUTPUT_VALID_FLAG1_POWER_SAVE_CONTROL_ENABLE BIT(1)
#define DS_OUTPUT_VALID_FLAG1_LIGHTBAR_CONTROL_ENABLE BIT(2)
#define DS_OUTPUT_VALID_FLAG1_RELEASE_LEDS BIT(3)
+#define DS_OUTPUT_VALID_FLAG1_PLAYER_INDICATOR_CONTROL_ENABLE BIT(4)
#define DS_OUTPUT_VALID_FLAG2_LIGHTBAR_SETUP_CONTROL_ENABLE BIT(1)
#define DS_OUTPUT_POWER_SAVE_CONTROL_MIC_MUTE BIT(4)
#define DS_OUTPUT_LIGHTBAR_SETUP_LIGHT_OUT BIT(1)
@@ -151,6 +157,11 @@ struct dualsense {
bool mic_muted;
bool last_btn_mic_state;
+ /* Player leds */
+ bool update_player_leds;
+ uint8_t player_leds_state;
+ struct led_classdev player_leds[5];
+
struct work_struct output_worker;
void *output_report_dmabuf;
uint8_t output_seq; /* Sequence number for output report. */
@@ -309,6 +320,24 @@ static int ps_devices_list_remove(struct ps_device *dev)
return 0;
}
+static int ps_device_set_player_id(struct ps_device *dev)
+{
+ int ret = ida_alloc(_player_id_allocator, GFP_KERNEL);
+
+ if (ret < 0)
+ return ret;
+
+ dev->player_id = ret;
+ return 0;
+}
+
+static void ps_device_release_player_id(struct ps_device *dev)
+{
+ ida_free(_player_id_allocator, dev->player_id);
+
+ dev->player_id = U32_MAX;
+}
+
static struct input_dev *ps_allocate_input_dev(struct hid_device *hdev, const
char *name_suffix)
{
struct input_dev *input_dev;
@@ -824,6 +853,13 @@ static void dualsense_output_worker(struct work_struct
*work)
ds->update_lightbar = false;
}
+ if (ds->update_player_leds) {
+ common->valid_flag1 |=
DS_OUTPUT_VALID_FLAG1_PLAYER_INDICATOR_CONTROL_ENABLE;
+ common->player_leds = ds->player_leds_state;
+
+ ds->update_player_leds = false;
+ }
+
if (ds->update_mic_mute) {
common->valid_flag1 |=
DS_OUTPUT_VALID_FLAG1_MIC_MUTE_LED_CONTROL_ENABLE;
common->mute_button_led = ds->mic_muted;
@@ -1078,6 +1114,29 @@ static void dualsense_set_lightbar(struct dualsense *ds,
uint8_t red, uint8_t gr
schedule_work(>output_worker);
}
+static void dualsense_set_player_leds(struct dualsense *ds)
+{
+ /*
+* The DualSense controller has a row of 5 LEDs used for player ids.
+* Behavior on the PlayStation 5 console is to center the player id
+* across the LEDs, so e.g. player 1 would be "--x--" with x being 'on'.
+* Follow a similar mapping here.
+*/
+ static const int player_ids[5] = {
+ BIT(2),
+ BIT(3) | BIT(1),
+ BIT(4) | BIT(2) | BIT(0),
+ BIT(4) | BIT(3) | BIT(1) | BIT(0),
+ BIT(4) | BIT(3) | BIT(2) | BIT(1) | BIT(0)
+ };
+
+ uint8_t player_id = ds->base.player_id % ARRAY_SIZE(player_ids);
+
+ ds->update_player_leds = true;
+ ds->player_leds_state = player_ids[player_id];
+ schedule_work(>output_worker);
+}
+
static struct ps_device *dualsense_create(struct hid_device *hdev)
{
struct dualsense *ds;
@@ -1166,6 +1225,15 @@ static struct ps_device *dualsense_create(struct
hid_device *hdev)
dualsense_set_lightbar(ds, 0, 0, 128); /* blue */
+ ret = ps_device_set_player_id(ps_dev);
+ if (ret) {
+ hid_err(hdev, "Failed to assign player id for DualSense: %d\n",
ret);
+
[PATCH 08/11] HID: playstation: fix unused variable in ps_battery_get_property.
From: Roderick Colenbrander The ret variable in ps_battery_get_property is set in an error path, but never actually returned. Change the function to return ret. Reported-by: kernel test robot Signed-off-by: Roderick Colenbrander Signed-off-by: Benjamin Tissoires --- drivers/hid/hid-playstation.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c index 84f484fce1ee..f279064e74a5 100644 --- a/drivers/hid/hid-playstation.c +++ b/drivers/hid/hid-playstation.c @@ -333,7 +333,7 @@ static int ps_battery_get_property(struct power_supply *psy, uint8_t battery_capacity; int battery_status; unsigned long flags; - int ret; + int ret = 0; spin_lock_irqsave(>lock, flags); battery_capacity = dev->battery_capacity; @@ -358,7 +358,7 @@ static int ps_battery_get_property(struct power_supply *psy, break; } - return 0; + return ret; } static int ps_device_register_battery(struct ps_device *dev) -- 2.29.2
[PATCH 07/11] HID: playstation: report DualSense hardware and firmware version.
From: Roderick Colenbrander
Retrieve DualSense hardware and firmware information using a vendor
specific feature report. Report the data through sysfs and also
report using hid_info as there can be signficant differences between
versions.
Signed-off-by: Roderick Colenbrander
Reviewed-by: Barnabás Pőcze
Signed-off-by: Benjamin Tissoires
---
drivers/hid/hid-playstation.c | 81 +++
1 file changed, 81 insertions(+)
diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
index 64193fdeaa0d..84f484fce1ee 100644
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -34,6 +34,8 @@ struct ps_device {
int battery_status;
uint8_t mac_address[6]; /* Note: stored in little endian order. */
+ uint32_t hw_version;
+ uint32_t fw_version;
int (*parse_report)(struct ps_device *dev, struct hid_report *report,
u8 *data, int size);
};
@@ -64,6 +66,8 @@ struct ps_calibration_data {
#define DS_FEATURE_REPORT_CALIBRATION_SIZE 41
#define DS_FEATURE_REPORT_PAIRING_INFO 0x09
#define DS_FEATURE_REPORT_PAIRING_INFO_SIZE20
+#define DS_FEATURE_REPORT_FIRMWARE_INFO0x20
+#define DS_FEATURE_REPORT_FIRMWARE_INFO_SIZE 64
/* Button masks for DualSense input report. */
#define DS_BUTTONS0_HAT_SWITCH GENMASK(3, 0)
@@ -538,6 +542,40 @@ static struct input_dev *ps_touchpad_create(struct
hid_device *hdev, int width,
return touchpad;
}
+static ssize_t firmware_version_show(struct device *dev,
+ struct device_attribute
+ *attr, char *buf)
+{
+ struct hid_device *hdev = to_hid_device(dev);
+ struct ps_device *ps_dev = hid_get_drvdata(hdev);
+
+ return sysfs_emit(buf, "0x%08x\n", ps_dev->fw_version);
+}
+
+static DEVICE_ATTR_RO(firmware_version);
+
+static ssize_t hardware_version_show(struct device *dev,
+ struct device_attribute
+ *attr, char *buf)
+{
+ struct hid_device *hdev = to_hid_device(dev);
+ struct ps_device *ps_dev = hid_get_drvdata(hdev);
+
+ return sysfs_emit(buf, "0x%08x\n", ps_dev->hw_version);
+}
+
+static DEVICE_ATTR_RO(hardware_version);
+
+static struct attribute *ps_device_attributes[] = {
+ _attr_firmware_version.attr,
+ _attr_hardware_version.attr,
+ NULL
+};
+
+static const struct attribute_group ps_device_attribute_group = {
+ .attrs = ps_device_attributes,
+};
+
static int dualsense_get_calibration_data(struct dualsense *ds)
{
short gyro_pitch_bias, gyro_pitch_plus, gyro_pitch_minus;
@@ -628,6 +666,30 @@ static int dualsense_get_calibration_data(struct dualsense
*ds)
return ret;
}
+static int dualsense_get_firmware_info(struct dualsense *ds)
+{
+ uint8_t *buf;
+ int ret;
+
+ buf = kzalloc(DS_FEATURE_REPORT_FIRMWARE_INFO_SIZE, GFP_KERNEL);
+ if (!buf)
+ return -ENOMEM;
+
+ ret = ps_get_report(ds->base.hdev, DS_FEATURE_REPORT_FIRMWARE_INFO, buf,
+ DS_FEATURE_REPORT_FIRMWARE_INFO_SIZE);
+ if (ret) {
+ hid_err(ds->base.hdev, "Failed to retrieve DualSense firmware
info: %d\n", ret);
+ goto err_free;
+ }
+
+ ds->base.hw_version = get_unaligned_le32([24]);
+ ds->base.fw_version = get_unaligned_le32([28]);
+
+err_free:
+ kfree(buf);
+ return ret;
+}
+
static int dualsense_get_mac_address(struct dualsense *ds)
{
uint8_t *buf;
@@ -956,6 +1018,12 @@ static struct ps_device *dualsense_create(struct
hid_device *hdev)
}
snprintf(hdev->uniq, sizeof(hdev->uniq), "%pMR", ds->base.mac_address);
+ ret = dualsense_get_firmware_info(ds);
+ if (ret) {
+ hid_err(hdev, "Failed to get firmware info from DualSense\n");
+ return ERR_PTR(ret);
+ }
+
ret = ps_devices_list_add(ps_dev);
if (ret)
return ERR_PTR(ret);
@@ -989,6 +1057,13 @@ static struct ps_device *dualsense_create(struct
hid_device *hdev)
if (ret)
goto err;
+ /*
+* Reporting hardware and firmware is important as there are frequent
updates, which
+* can change behavior.
+*/
+ hid_info(hdev, "Registered DualSense controller hw_version=0x%08x
fw_version=0x%08x\n",
+ ds->base.hw_version, ds->base.fw_version);
+
return >base;
err:
@@ -1039,6 +1114,12 @@ static int ps_probe(struct hid_device *hdev, const
struct hid_device_id *id)
}
}
+ ret = devm_device_add_group(>dev, _device_attribute_group);
+ if (ret) {
+ hid_err(hdev, "Failed to register sysfs nodes.\n");
+ goto err_close;
+ }
+
return ret;
err_close:
--
2.29.2
[PATCH 03/11] Revert "HID: playstation: DualSense set LEDs to default player id."
From: Roderick Colenbrander
This reverts commit 05afe02ac24f ("HID: playstation: DualSense
set LEDs to default player id.")
There is currently an ongoing discussion on linux-leds LKML,
and so to give us more room, we need to revert those related
patches from linux-next.
This is not a big deal, they are still not pushed to Linus.
Signed-off-by: Roderick Colenbrander
Signed-off-by: Benjamin Tissoires
---
drivers/hid/hid-playstation.c | 70 +--
1 file changed, 1 insertion(+), 69 deletions(-)
diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
index 973c1fe61e8a..2d96785c397d 100644
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -9,7 +9,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -23,8 +22,6 @@
static DEFINE_MUTEX(ps_devices_lock);
static LIST_HEAD(ps_devices_list);
-static DEFINE_IDA(ps_player_id_allocator);
-
#define HID_PLAYSTATION_VERSION_PATCH 0x8000
/* Base class for playstation devices. */
@@ -33,8 +30,6 @@ struct ps_device {
struct hid_device *hdev;
spinlock_t lock;
- uint32_t player_id;
-
struct power_supply_desc battery_desc;
struct power_supply *battery;
uint8_t battery_capacity;
@@ -326,24 +321,6 @@ static int ps_devices_list_remove(struct ps_device *dev)
return 0;
}
-static int ps_device_set_player_id(struct ps_device *dev)
-{
- int ret = ida_alloc(_player_id_allocator, GFP_KERNEL);
-
- if (ret < 0)
- return ret;
-
- dev->player_id = ret;
- return 0;
-}
-
-static void ps_device_release_player_id(struct ps_device *dev)
-{
- ida_free(_player_id_allocator, dev->player_id);
-
- dev->player_id = U32_MAX;
-}
-
static struct input_dev *ps_allocate_input_dev(struct hid_device *hdev, const
char *name_suffix)
{
struct input_dev *input_dev;
@@ -1179,29 +1156,6 @@ static int dualsense_reset_leds(struct dualsense *ds)
return 0;
}
-static void dualsense_set_player_leds(struct dualsense *ds)
-{
- /*
-* The DualSense controller has a row of 5 LEDs used for player ids.
-* Behavior on the PlayStation 5 console is to center the player id
-* across the LEDs, so e.g. player 1 would be "--x--" with x being 'on'.
-* Follow a similar mapping here.
-*/
- static const int player_ids[5] = {
- BIT(2),
- BIT(3) | BIT(1),
- BIT(4) | BIT(2) | BIT(0),
- BIT(4) | BIT(3) | BIT(1) | BIT(0),
- BIT(4) | BIT(3) | BIT(2) | BIT(1) | BIT(0)
- };
-
- uint8_t player_id = ds->base.player_id % ARRAY_SIZE(player_ids);
-
- ds->update_player_leds = true;
- ds->player_leds_state = player_ids[player_id];
- schedule_work(>output_worker);
-}
-
static struct ps_device *dualsense_create(struct hid_device *hdev)
{
struct dualsense *ds;
@@ -1310,15 +1264,6 @@ static struct ps_device *dualsense_create(struct
hid_device *hdev)
goto err;
}
- ret = ps_device_set_player_id(ps_dev);
- if (ret) {
- hid_err(hdev, "Failed to assign player id for DualSense: %d\n",
ret);
- goto err;
- }
-
- /* Set player LEDs to our player id. */
- dualsense_set_player_leds(ds);
-
return >base;
err:
@@ -1383,7 +1328,6 @@ static void ps_remove(struct hid_device *hdev)
struct ps_device *dev = hid_get_drvdata(hdev);
ps_devices_list_remove(dev);
- ps_device_release_player_id(dev);
hid_hw_close(hdev);
hid_hw_stop(hdev);
@@ -1404,19 +1348,7 @@ static struct hid_driver ps_driver = {
.raw_event = ps_raw_event,
};
-static int __init ps_init(void)
-{
- return hid_register_driver(_driver);
-}
-
-static void __exit ps_exit(void)
-{
- hid_unregister_driver(_driver);
- ida_destroy(_player_id_allocator);
-}
-
-module_init(ps_init);
-module_exit(ps_exit);
+module_hid_driver(ps_driver);
MODULE_AUTHOR("Sony Interactive Entertainment");
MODULE_DESCRIPTION("HID Driver for PlayStation peripherals.");
--
2.29.2
[PATCH 02/11] Revert "HID: playstation: report DualSense hardware and firmware version."
This reverts commit 1f902f8636e4 ("HID: playstation: report DualSense
hardware and firmware version.")
There is currently an ongoing discussion on linux-leds LKML,
and so to give us more room, we need to revert those related
LEDs patches from linux-next.
To have a cleaner merge with the new version, we also revert
all patches on top of the LED ones.
This is not a big deal, they are still not pushed to Linus.
Signed-off-by: Benjamin Tissoires
---
drivers/hid/hid-playstation.c | 81 ---
1 file changed, 81 deletions(-)
diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
index cc93c16cc822..973c1fe61e8a 100644
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -41,8 +41,6 @@ struct ps_device {
int battery_status;
uint8_t mac_address[6]; /* Note: stored in little endian order. */
- uint32_t hw_version;
- uint32_t fw_version;
int (*parse_report)(struct ps_device *dev, struct hid_report *report,
u8 *data, int size);
};
@@ -79,8 +77,6 @@ struct ps_led_info {
#define DS_FEATURE_REPORT_CALIBRATION_SIZE 41
#define DS_FEATURE_REPORT_PAIRING_INFO 0x09
#define DS_FEATURE_REPORT_PAIRING_INFO_SIZE20
-#define DS_FEATURE_REPORT_FIRMWARE_INFO0x20
-#define DS_FEATURE_REPORT_FIRMWARE_INFO_SIZE 64
/* Button masks for DualSense input report. */
#define DS_BUTTONS0_HAT_SWITCH GENMASK(3, 0)
@@ -665,40 +661,6 @@ static struct input_dev *ps_touchpad_create(struct
hid_device *hdev, int width,
return touchpad;
}
-static ssize_t firmware_version_show(struct device *dev,
- struct device_attribute
- *attr, char *buf)
-{
- struct hid_device *hdev = to_hid_device(dev);
- struct ps_device *ps_dev = hid_get_drvdata(hdev);
-
- return sysfs_emit(buf, "0x%08x\n", ps_dev->fw_version);
-}
-
-static DEVICE_ATTR_RO(firmware_version);
-
-static ssize_t hardware_version_show(struct device *dev,
- struct device_attribute
- *attr, char *buf)
-{
- struct hid_device *hdev = to_hid_device(dev);
- struct ps_device *ps_dev = hid_get_drvdata(hdev);
-
- return sysfs_emit(buf, "0x%08x\n", ps_dev->hw_version);
-}
-
-static DEVICE_ATTR_RO(hardware_version);
-
-static struct attribute *ps_device_attributes[] = {
- _attr_firmware_version.attr,
- _attr_hardware_version.attr,
- NULL
-};
-
-static const struct attribute_group ps_device_attribute_group = {
- .attrs = ps_device_attributes,
-};
-
static int dualsense_get_calibration_data(struct dualsense *ds)
{
short gyro_pitch_bias, gyro_pitch_plus, gyro_pitch_minus;
@@ -789,30 +751,6 @@ static int dualsense_get_calibration_data(struct dualsense
*ds)
return ret;
}
-static int dualsense_get_firmware_info(struct dualsense *ds)
-{
- uint8_t *buf;
- int ret;
-
- buf = kzalloc(DS_FEATURE_REPORT_FIRMWARE_INFO_SIZE, GFP_KERNEL);
- if (!buf)
- return -ENOMEM;
-
- ret = ps_get_report(ds->base.hdev, DS_FEATURE_REPORT_FIRMWARE_INFO, buf,
- DS_FEATURE_REPORT_FIRMWARE_INFO_SIZE);
- if (ret) {
- hid_err(ds->base.hdev, "Failed to retrieve DualSense firmware
info: %d\n", ret);
- goto err_free;
- }
-
- ds->base.hw_version = get_unaligned_le32([24]);
- ds->base.fw_version = get_unaligned_le32([28]);
-
-err_free:
- kfree(buf);
- return ret;
-}
-
static int dualsense_get_mac_address(struct dualsense *ds)
{
uint8_t *buf;
@@ -1314,12 +1252,6 @@ static struct ps_device *dualsense_create(struct
hid_device *hdev)
}
snprintf(hdev->uniq, sizeof(hdev->uniq), "%pMR", ds->base.mac_address);
- ret = dualsense_get_firmware_info(ds);
- if (ret) {
- hid_err(hdev, "Failed to get firmware info from DualSense\n");
- return ERR_PTR(ret);
- }
-
ret = ps_devices_list_add(ps_dev);
if (ret)
return ERR_PTR(ret);
@@ -1387,13 +1319,6 @@ static struct ps_device *dualsense_create(struct
hid_device *hdev)
/* Set player LEDs to our player id. */
dualsense_set_player_leds(ds);
- /*
-* Reporting hardware and firmware is important as there are frequent
updates, which
-* can change behavior.
-*/
- hid_info(hdev, "Registered DualSense controller hw_version=0x%08x
fw_version=0x%08x\n",
- ds->base.hw_version, ds->base.fw_version);
-
return >base;
err:
@@ -1444,12 +1369,6 @@ static int ps_probe(struct hid_device *hdev, const
struct hid_device_id *id)
}
}
- ret = devm_device_add_group(>dev, _device_attribute_group);
-
[PATCH 06/11] Revert "HID: playstation: add DualSense lightbar support"
From: Roderick Colenbrander
This reverts commit ebbe998a4a52 ("HID: playstation: add
DualSense lightbar support")
There is currently an ongoing discussion on linux-leds LKML,
and so to give us more room, we need to revert those related
patches from linux-next.
This is not a big deal, they are still not pushed to Linus.
Signed-off-by: Roderick Colenbrander
Signed-off-by: Benjamin Tissoires
---
drivers/hid/Kconfig | 1 -
drivers/hid/hid-playstation.c | 118 --
2 files changed, 119 deletions(-)
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index e7f17e78ff14..7ae9eef6ca64 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -857,7 +857,6 @@ config HID_PLAYSTATION
tristate "PlayStation HID Driver"
depends on HID
select CRC32
- select LEDS_CLASS_MULTICOLOR
select POWER_SUPPLY
help
Provides support for Sony PS5 controllers including support for
diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
index 97c1118ba78f..64193fdeaa0d 100644
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -10,7 +10,6 @@
#include
#include
#include
-#include
#include
#include
@@ -100,10 +99,6 @@ struct ps_calibration_data {
/* Flags for DualSense output report. */
#define DS_OUTPUT_VALID_FLAG0_COMPATIBLE_VIBRATION BIT(0)
#define DS_OUTPUT_VALID_FLAG0_HAPTICS_SELECT BIT(1)
-#define DS_OUTPUT_VALID_FLAG1_LIGHTBAR_CONTROL_ENABLE BIT(2)
-#define DS_OUTPUT_VALID_FLAG1_RELEASE_LEDS BIT(3)
-#define DS_OUTPUT_VALID_FLAG2_LIGHTBAR_SETUP_CONTROL_ENABLE BIT(1)
-#define DS_OUTPUT_LIGHTBAR_SETUP_LIGHT_OUT BIT(1)
/* DualSense hardware limits */
#define DS_ACC_RES_PER_G 8192
@@ -133,13 +128,6 @@ struct dualsense {
uint8_t motor_left;
uint8_t motor_right;
- /* RGB lightbar */
- struct led_classdev_mc lightbar;
- bool update_lightbar;
- uint8_t lightbar_red;
- uint8_t lightbar_green;
- uint8_t lightbar_blue;
-
struct work_struct output_worker;
void *output_report_dmabuf;
uint8_t output_seq; /* Sequence number for output report. */
@@ -485,45 +473,6 @@ static int ps_get_report(struct hid_device *hdev, uint8_t
report_id, uint8_t *bu
return 0;
}
-/* Register a DualSense/DualShock4 RGB lightbar represented by a multicolor
LED. */
-static int ps_lightbar_register(struct ps_device *ps_dev, struct
led_classdev_mc *lightbar_mc_dev,
- int (*brightness_set)(struct led_classdev *, enum led_brightness))
-{
- struct hid_device *hdev = ps_dev->hdev;
- struct mc_subled *mc_led_info;
- struct led_classdev *led_cdev;
- int ret;
-
- mc_led_info = devm_kmalloc_array(>dev, 3, sizeof(*mc_led_info),
-GFP_KERNEL | __GFP_ZERO);
- if (!mc_led_info)
- return -ENOMEM;
-
- mc_led_info[0].color_index = LED_COLOR_ID_RED;
- mc_led_info[1].color_index = LED_COLOR_ID_GREEN;
- mc_led_info[2].color_index = LED_COLOR_ID_BLUE;
-
- lightbar_mc_dev->subled_info = mc_led_info;
- lightbar_mc_dev->num_colors = 3;
-
- led_cdev = _mc_dev->led_cdev;
- led_cdev->name = devm_kasprintf(>dev, GFP_KERNEL,
"playstation::%pMR::rgb",
- ps_dev->mac_address);
- if (!led_cdev->name)
- return -ENOMEM;
- led_cdev->brightness = 255;
- led_cdev->max_brightness = 255;
- led_cdev->brightness_set_blocking = brightness_set;
-
- ret = devm_led_classdev_multicolor_register(>dev,
lightbar_mc_dev);
- if (ret < 0) {
- hid_err(hdev, "Cannot register multicolor LED device\n");
- return ret;
- }
-
- return 0;
-}
-
static struct input_dev *ps_sensors_create(struct hid_device *hdev, int
accel_range, int accel_res,
int gyro_range, int gyro_res)
{
@@ -702,26 +651,6 @@ static int dualsense_get_mac_address(struct dualsense *ds)
return ret;
}
-static int dualsense_lightbar_set_brightness(struct led_classdev *cdev,
- enum led_brightness brightness)
-{
- struct led_classdev_mc *mc_cdev = lcdev_to_mccdev(cdev);
- struct dualsense *ds = container_of(mc_cdev, struct dualsense,
lightbar);
- unsigned long flags;
-
- led_mc_calc_color_components(mc_cdev, brightness);
-
- spin_lock_irqsave(>base.lock, flags);
- ds->update_lightbar = true;
- ds->lightbar_red = mc_cdev->subled_info[0].brightness;
- ds->lightbar_green = mc_cdev->subled_info[1].brightness;
- ds->lightbar_blue = mc_cdev->subled_info[2].brightness;
- spin_unlock_irqrestore(>base.lock, flags);
-
- schedule_work(>output_worker);
- return 0;
-}
-
static void dualsense_init_output_report(struct dualsense *ds, struct
dualsense_
[PATCH 04/11] Revert "HID: playstation: add DualSense player LEDs support."
From: Roderick Colenbrander
This reverts commit c240f0cb88ec ("HID: playstation: add
DualSense player LEDs support.")
There is currently an ongoing discussion on linux-leds LKML,
and so to give us more room, we need to revert those related
patches from linux-next.
This is not a big deal, they are still not pushed to Linus.
Signed-off-by: Roderick Colenbrander
Signed-off-by: Benjamin Tissoires
---
drivers/hid/hid-playstation.c | 60 +--
1 file changed, 1 insertion(+), 59 deletions(-)
diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
index 2d96785c397d..c436ac8f7a6f 100644
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -112,7 +112,6 @@ struct ps_led_info {
#define DS_OUTPUT_VALID_FLAG1_POWER_SAVE_CONTROL_ENABLE BIT(1)
#define DS_OUTPUT_VALID_FLAG1_LIGHTBAR_CONTROL_ENABLE BIT(2)
#define DS_OUTPUT_VALID_FLAG1_RELEASE_LEDS BIT(3)
-#define DS_OUTPUT_VALID_FLAG1_PLAYER_INDICATOR_CONTROL_ENABLE BIT(4)
#define DS_OUTPUT_VALID_FLAG2_LIGHTBAR_SETUP_CONTROL_ENABLE BIT(1)
#define DS_OUTPUT_POWER_SAVE_CONTROL_MIC_MUTE BIT(4)
#define DS_OUTPUT_LIGHTBAR_SETUP_LIGHT_OUT BIT(1)
@@ -158,11 +157,6 @@ struct dualsense {
bool last_btn_mic_state;
struct led_classdev mute_led;
- /* Player leds */
- bool update_player_leds;
- uint8_t player_leds_state;
- struct led_classdev player_leds[5];
-
struct work_struct output_worker;
void *output_report_dmabuf;
uint8_t output_seq; /* Sequence number for output report. */
@@ -784,35 +778,6 @@ static void dualsense_mute_led_set_brightness(struct
led_classdev *led, enum led
}
-static enum led_brightness dualsense_player_led_get_brightness(struct
led_classdev *led)
-{
- struct hid_device *hdev = to_hid_device(led->dev->parent);
- struct dualsense *ds = hid_get_drvdata(hdev);
-
- return !!(ds->player_leds_state & BIT(led - ds->player_leds));
-}
-
-static void dualsense_player_led_set_brightness(struct led_classdev *led, enum
led_brightness value)
-{
- struct hid_device *hdev = to_hid_device(led->dev->parent);
- struct dualsense *ds = hid_get_drvdata(hdev);
- unsigned long flags;
- unsigned int led_index;
-
- spin_lock_irqsave(>base.lock, flags);
-
- led_index = led - ds->player_leds;
- if (value == LED_OFF)
- ds->player_leds_state &= ~BIT(led_index);
- else
- ds->player_leds_state |= BIT(led_index);
-
- ds->update_player_leds = true;
- spin_unlock_irqrestore(>base.lock, flags);
-
- schedule_work(>output_worker);
-}
-
static void dualsense_init_output_report(struct dualsense *ds, struct
dualsense_output_report *rp,
void *buf)
{
@@ -905,13 +870,6 @@ static void dualsense_output_worker(struct work_struct
*work)
ds->update_lightbar = false;
}
- if (ds->update_player_leds) {
- common->valid_flag1 |=
DS_OUTPUT_VALID_FLAG1_PLAYER_INDICATOR_CONTROL_ENABLE;
- common->player_leds = ds->player_leds_state;
-
- ds->update_player_leds = false;
- }
-
if (ds->update_mic_mute) {
common->valid_flag1 |=
DS_OUTPUT_VALID_FLAG1_MIC_MUTE_LED_CONTROL_ENABLE;
common->mute_button_led = ds->mic_muted;
@@ -1161,20 +1119,12 @@ static struct ps_device *dualsense_create(struct
hid_device *hdev)
struct dualsense *ds;
struct ps_device *ps_dev;
uint8_t max_output_report_size;
- int i, ret;
+ int ret;
static const struct ps_led_info mute_led_info = {
"micmute", dualsense_mute_led_get_brightness,
dualsense_mute_led_set_brightness
};
- static const struct ps_led_info player_leds_info[] = {
- { "led1", dualsense_player_led_get_brightness,
dualsense_player_led_set_brightness },
- { "led2", dualsense_player_led_get_brightness,
dualsense_player_led_set_brightness },
- { "led3", dualsense_player_led_get_brightness,
dualsense_player_led_set_brightness },
- { "led4", dualsense_player_led_get_brightness,
dualsense_player_led_set_brightness },
- { "led5", dualsense_player_led_get_brightness,
dualsense_player_led_set_brightness }
- };
-
ds = devm_kzalloc(>dev, sizeof(*ds), GFP_KERNEL);
if (!ds)
return ERR_PTR(-ENOMEM);
@@ -1256,14 +1206,6 @@ static struct ps_device *dualsense_create(struct
hid_device *hdev)
if (ret)
goto err;
- for (i = 0; i < ARRAY_SIZE(player_leds_info); i++) {
- const struct ps_led_info *led_info = _leds_info[i];
-
- ret = ps_led_register(ps_dev, >player_leds[i], led_info);
- if (ret < 0)
- goto err;
- }
-
return >base;
err:
--
2.29.2
[PATCH 05/11] Revert "HID: playstation: add microphone mute support for DualSense."
From: Roderick Colenbrander
This reverts commit d5f7af85a537 ("HID: playstation: add microphone
mute support for DualSense.")
There is currently an ongoing discussion on linux-leds LKML,
and so to give us more room, we need to revert those related
patches from linux-next.
This is not a big deal, they are still not pushed to Linus.
Signed-off-by: Roderick Colenbrander
Signed-off-by: Benjamin Tissoires
---
drivers/hid/Kconfig | 2 -
drivers/hid/hid-playstation.c | 99 ---
2 files changed, 101 deletions(-)
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index aee51d776b4f..e7f17e78ff14 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -857,8 +857,6 @@ config HID_PLAYSTATION
tristate "PlayStation HID Driver"
depends on HID
select CRC32
- select NEW_LEDS
- select LEDS_CLASS
select LEDS_CLASS_MULTICOLOR
select POWER_SUPPLY
help
diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
index c436ac8f7a6f..97c1118ba78f 100644
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -10,7 +10,6 @@
#include
#include
#include
-#include
#include
#include
@@ -48,12 +47,6 @@ struct ps_calibration_data {
int sens_denom;
};
-struct ps_led_info {
- const char *name;
- enum led_brightness (*brightness_get)(struct led_classdev *cdev);
- void (*brightness_set)(struct led_classdev *cdev, enum led_brightness);
-};
-
/* Seed values for DualShock4 / DualSense CRC32 for different report types. */
#define PS_INPUT_CRC32_SEED0xA1
#define PS_OUTPUT_CRC32_SEED 0xA2
@@ -89,7 +82,6 @@ struct ps_led_info {
#define DS_BUTTONS1_R3 BIT(7)
#define DS_BUTTONS2_PS_HOMEBIT(0)
#define DS_BUTTONS2_TOUCHPAD BIT(1)
-#define DS_BUTTONS2_MIC_MUTE BIT(2)
/* Status field of DualSense input report. */
#define DS_STATUS_BATTERY_CAPACITY GENMASK(3, 0)
@@ -108,12 +100,9 @@ struct ps_led_info {
/* Flags for DualSense output report. */
#define DS_OUTPUT_VALID_FLAG0_COMPATIBLE_VIBRATION BIT(0)
#define DS_OUTPUT_VALID_FLAG0_HAPTICS_SELECT BIT(1)
-#define DS_OUTPUT_VALID_FLAG1_MIC_MUTE_LED_CONTROL_ENABLE BIT(0)
-#define DS_OUTPUT_VALID_FLAG1_POWER_SAVE_CONTROL_ENABLE BIT(1)
#define DS_OUTPUT_VALID_FLAG1_LIGHTBAR_CONTROL_ENABLE BIT(2)
#define DS_OUTPUT_VALID_FLAG1_RELEASE_LEDS BIT(3)
#define DS_OUTPUT_VALID_FLAG2_LIGHTBAR_SETUP_CONTROL_ENABLE BIT(1)
-#define DS_OUTPUT_POWER_SAVE_CONTROL_MIC_MUTE BIT(4)
#define DS_OUTPUT_LIGHTBAR_SETUP_LIGHT_OUT BIT(1)
/* DualSense hardware limits */
@@ -151,12 +140,6 @@ struct dualsense {
uint8_t lightbar_green;
uint8_t lightbar_blue;
- /* Microphone */
- bool update_mic_mute;
- bool mic_muted;
- bool last_btn_mic_state;
- struct led_classdev mute_led;
-
struct work_struct output_worker;
void *output_report_dmabuf;
uint8_t output_seq; /* Sequence number for output report. */
@@ -502,32 +485,6 @@ static int ps_get_report(struct hid_device *hdev, uint8_t
report_id, uint8_t *bu
return 0;
}
-static int ps_led_register(struct ps_device *ps_dev, struct led_classdev *led,
- const struct ps_led_info *led_info)
-{
- int ret;
-
- led->name = devm_kasprintf(_dev->hdev->dev, GFP_KERNEL,
- "playstation::%pMR::%s", ps_dev->mac_address,
led_info->name);
-
- if (!led->name)
- return -ENOMEM;
-
- led->brightness = 0;
- led->max_brightness = 1;
- led->flags = LED_CORE_SUSPENDRESUME;
- led->brightness_get = led_info->brightness_get;
- led->brightness_set = led_info->brightness_set;
-
- ret = devm_led_classdev_register(_dev->hdev->dev, led);
- if (ret) {
- hid_err(ps_dev->hdev, "Failed to register LED %s: %d\n",
led_info->name, ret);
- return ret;
- }
-
- return 0;
-}
-
/* Register a DualSense/DualShock4 RGB lightbar represented by a multicolor
LED. */
static int ps_lightbar_register(struct ps_device *ps_dev, struct
led_classdev_mc *lightbar_mc_dev,
int (*brightness_set)(struct led_classdev *, enum led_brightness))
@@ -765,19 +722,6 @@ static int dualsense_lightbar_set_brightness(struct
led_classdev *cdev,
return 0;
}
-static enum led_brightness dualsense_mute_led_get_brightness(struct
led_classdev *led)
-{
- struct dualsense *ds = container_of(led, struct dualsense, mute_led);
-
- return ds->mic_muted;
-}
-
-/* The mute LED is treated as read-only. This set call prevents ENOTSUP errors
e.g. on unload. */
-static void dualsense_mute_led_set_brightness(struct led_classdev *led, enum
led_brightness value)
-{
-
-}
-
static void dualsense_init_output_report(struct dualsense *ds, struct
dualsense_output_report *rp,
vo
[PATCH 01/11] Revert "HID: playstation: fix unused variable in ps_battery_get_property."
This reverts commit 3847d15b41ce ("HID: playstation: fix unused variable
in ps_battery_get_property.")
There is currently an ongoing discussion on linux-leds LKML,
and so to give us more room, we need to revert those related
LEDs patches from linux-next.
To have a cleaner merge with the new version, we also revert
all patches on top of the LED ones.
This is not a big deal, they are still not pushed to Linus.
Signed-off-by: Benjamin Tissoires
---
drivers/hid/hid-playstation.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-playstation.c b/drivers/hid/hid-playstation.c
index 408b651174cf..cc93c16cc822 100644
--- a/drivers/hid/hid-playstation.c
+++ b/drivers/hid/hid-playstation.c
@@ -391,7 +391,7 @@ static int ps_battery_get_property(struct power_supply *psy,
uint8_t battery_capacity;
int battery_status;
unsigned long flags;
- int ret = 0;
+ int ret;
spin_lock_irqsave(>lock, flags);
battery_capacity = dev->battery_capacity;
@@ -416,7 +416,7 @@ static int ps_battery_get_property(struct power_supply *psy,
break;
}
- return ret;
+ return 0;
}
static int ps_device_register_battery(struct ps_device *dev)
--
2.29.2
[PATCH 00/11] HID: playstation: revert LED class exposure
[sending those patches on behalf of Roderick] There is a current thread on LED LKML which basically means that we have to revert the LED class exposure until things are settled. I am sending here the full series that will end up in linux-next. But with some git magic, the final PR to Linus will not have the reverts in it, just the plain patches. I am queuing in for-5.12/playstation patches 1 to 6 immediately (the reverts). I am also queuing in for-5.12/playstation-v2 patches 7 and 8 on top of 51151098d7ab8 immediately. Those 2 patches have already been reviewed the usual process. I am waiting 1 day for others to chime in regarding patches 9 to 11 before applying them to for-5.12/playstation-v2. They are basically the same patches that were already reviewed on the linux-input LKML, but without the LED class bits. With all that, we should have more room to discuss the exposure of the LEDs to userspace through the LED class. Roderick, I made small adjustments compared to the series you sent me privately: - added the 2 missing reverts/re-add, so I can have clean merges for our for-next branch, - re-ordered the `if (ds->update_rumble)` block in `dualsense_output_worker()` to match was was in linux-next - removed an extra new line to match the current linux-next tree. Cheers, Benjamin Benjamin Tissoires (2): Revert "HID: playstation: fix unused variable in ps_battery_get_property." Revert "HID: playstation: report DualSense hardware and firmware version." Roderick Colenbrander (9): Revert "HID: playstation: DualSense set LEDs to default player id." Revert "HID: playstation: add DualSense player LEDs support." Revert "HID: playstation: add microphone mute support for DualSense." Revert "HID: playstation: add DualSense lightbar support" HID: playstation: report DualSense hardware and firmware version. HID: playstation: fix unused variable in ps_battery_get_property. HID: playstation: add initial DualSense lightbar support. HID: playstation: add microphone mute support for DualSense. HID: playstation: add DualSense player LED support. drivers/hid/Kconfig | 3 - drivers/hid/hid-playstation.c | 177 +++--- 2 files changed, 12 insertions(+), 168 deletions(-) -- 2.29.2
Re: [PATCH] Input: elantech - add LEN2146 to SMBus blacklist for ThinkPad L13 Gen2
Hi Nikolai,
On Mon, Feb 8, 2021 at 9:01 AM Nikolai Kostrigin wrote:
>
> ThinkPad L13 Gen2 has both touchpad and trackpoint.
> PNP: LEN2146 PNP0f13
> With the default protocol (elantech-smbus) trackpoint is not operating,
> while touchpad does. Changing to elantech renders both operational.
>
> Signed-off-by: Nikolai Kostrigin
Instead of downgrading the capabilities of the touchpad, couldn't we
fix the trackpoint issues?
I am surprised elantech doesn't work with the trackpoint, because I am
pretty sure I wrote patches in that regard. Which kernel version have
you been testing?
Cheers,
Benjamin
> ---
> drivers/input/mouse/elantech.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
> index 90f8765f9efc..c4c3fa5828d8 100644
> --- a/drivers/input/mouse/elantech.c
> +++ b/drivers/input/mouse/elantech.c
> @@ -1776,6 +1776,7 @@ static const char * const i2c_blacklist_pnp_ids[] = {
> * These are known to not be working properly as bits are missing
> * in elan_i2c.
> */
> + "LEN2146", /* ThinkPad L13 Gen2 */
> NULL
> };
>
> --
> 2.29.2
>
Re: [PATCH] HID: multitouch: Apply MT_QUIRK_CONFIDENCE quirk for multi-input devices
On Mon, Jan 18, 2021 at 2:45 PM Kai-Heng Feng
wrote:
>
> Palm ejection stops working on some Elan and Synaptics touchpad after
> commit 40d5bb87377a ("HID: multitouch: enable multi-input as a quirk for
> some devices").
>
> The commit changes the mt_class from MT_CLS_WIN_8 to
> MT_CLS_WIN_8_FORCE_MULTI_INPUT, so MT_QUIRK_CONFIDENCE isn't applied
> anymore.
>
> So also apply the quirk since MT_CLS_WIN_8_FORCE_MULTI_INPUT is
> essentially MT_CLS_WIN_8.
>
> Fixes: 40d5bb87377a ("HID: multitouch: enable multi-input as a quirk for some
> devices")
> Signed-off-by: Kai-Heng Feng
> ---
Thanks for the patch, and for the hid-tools MR.
I have now added the "Cc: sta...@vger.kernel.org" tag and pushed to
for-5.11/upstream-fixes.
Cheers,
Benjamin
> drivers/hid/hid-multitouch.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 0743ef51d3b2..8429ebe7097e 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -758,7 +758,8 @@ static int mt_touch_input_mapping(struct hid_device
> *hdev, struct hid_input *hi,
> MT_STORE_FIELD(inrange_state);
> return 1;
> case HID_DG_CONFIDENCE:
> - if (cls->name == MT_CLS_WIN_8 &&
> + if ((cls->name == MT_CLS_WIN_8 ||
> +cls->name == MT_CLS_WIN_8_FORCE_MULTI_INPUT) &&
> (field->application == HID_DG_TOUCHPAD ||
> field->application == HID_DG_TOUCHSCREEN))
> app->quirks |= MT_QUIRK_CONFIDENCE;
> --
> 2.29.2
>
Re: [PATCH v9 0/4] HID: i2c-hid: Reorganize to allow supporting goodix,gt7375p
On Fri, Jan 15, 2021 at 6:07 PM Douglas Anderson wrote:
>
>
> The goal of this series is to support the Goodix GT7375P touchscreen.
> This touchscreen is special because it has power sequencing
> requirements that necessitate driving a reset GPIO.
>
> To do this, we totally rejigger the way i2c-hid is organized so that
> it's easier to jam the Goodix support in there.
>
> This series was:
> - Tested on a device that uses normal i2c-hid.
> - Tested on a device that has a Goodix i2c-hid device.
> - Tested on an ACPI device, but an earlier version of the series.
>
> I believe the plan is for Benjamin to land the whole series. Will
> said this about the arm64 defconfig change (and provided his Ack):
> > ...there are a few things I really care about
> > in defconfig (e.g. things like page size!), generally speaking we don't
> > need to Ack everything that changes in there.
> >
> > That said, might be worth checking whether arm-soc have any defconfig
> > changes queued in -next so you don't end up with conflicts.
>
> Changes in v9:
> - 120 ms delay => 180 ms delay
> - Local variable in ACPI code "ihid_of" => "ihid_acpi".
> - Squash Benjamin's change for ACPI power on.
>
> Changes in v8:
> - Mark suspend/resume as static as per patches robot.
>
> Changes in v7:
> - Rebase atop commit afdd34c5fa40 ("HID: i2c-hid: show the error ...")
>
> Changes in v6:
> - ACPI probe function should have been "static"
> - Don't export suspend/resume, just export dev_pm_ops from core.
> - Fixed crash in ACPI module (missing init of "client")
> - No need for regulator include in the core.
> - Removed i2c_device_id table from ACPI module.
> - Suspend/resume are no longer exported from the core.
>
> Changes in v5:
> - Add shutdown_tail op and use it in ACPI.
> - Added mention of i2c-hid in the yaml itself as per Rob.
> - Adjusted subject as per Rob.
> - i2chid_subclass_data => i2chid_ops.
> - power_up_device => power_up (same with power_down).
> - subclass => ops.
>
> Changes in v4:
> - ("arm64: defconfig: Update config names for i2c-hid rejigger") new for v4.
> - Fully rejigger so ACPI and OF are full subclasses.
> - Totally redid based on the new subclass system.
>
> Changes in v3:
> - Fixed compatible in example.
> - Removed Benjamin as a maintainer.
> - Rework to use subclassing.
> - Updated description.
>
> Changes in v2:
> - ("dt-bindings: HID: i2c-hid: Introduce bindings for the Goodix GT7375P")
> new in v2.
> - Get timings based on the compatible string.
> - Use a separate compatible string for this new touchscreen.
>
> Douglas Anderson (4):
> HID: i2c-hid: Reorganize so ACPI and OF are separate modules
> arm64: defconfig: Update config names for i2c-hid rejigger
> dt-bindings: input: HID: i2c-hid: Introduce bindings for the Goodix
> GT7375P
> HID: i2c-hid: Introduce goodix-i2c-hid using i2c-hid core
>
> .../bindings/input/goodix,gt7375p.yaml| 65 +
> arch/arm64/configs/defconfig | 3 +-
> drivers/hid/Makefile | 2 +-
> drivers/hid/i2c-hid/Kconfig | 47 +++-
> drivers/hid/i2c-hid/Makefile | 6 +-
> drivers/hid/i2c-hid/i2c-hid-acpi.c| 143 ++
> drivers/hid/i2c-hid/i2c-hid-core.c| 252 +++---
> drivers/hid/i2c-hid/i2c-hid-of-goodix.c | 116
> drivers/hid/i2c-hid/i2c-hid-of.c | 143 ++
> drivers/hid/i2c-hid/i2c-hid.h | 22 ++
> include/linux/platform_data/i2c-hid.h | 41 ---
> 11 files changed, 578 insertions(+), 262 deletions(-)
> create mode 100644
> Documentation/devicetree/bindings/input/goodix,gt7375p.yaml
> create mode 100644 drivers/hid/i2c-hid/i2c-hid-acpi.c
> create mode 100644 drivers/hid/i2c-hid/i2c-hid-of-goodix.c
> create mode 100644 drivers/hid/i2c-hid/i2c-hid-of.c
> delete mode 100644 include/linux/platform_data/i2c-hid.h
>
Many thanks for the wait. I have now scheduled this series in for-5.12/i2c-hid.
Cheers,
Benjamin
Re: [PATCH] HID: multitouch: Apply MT_QUIRK_CONFIDENCE quirk for multi-input devices
Hi,
On Mon, Jan 18, 2021 at 2:45 PM Kai-Heng Feng
wrote:
>
> Palm ejection stops working on some Elan and Synaptics touchpad after
> commit 40d5bb87377a ("HID: multitouch: enable multi-input as a quirk for
> some devices").
>
> The commit changes the mt_class from MT_CLS_WIN_8 to
> MT_CLS_WIN_8_FORCE_MULTI_INPUT, so MT_QUIRK_CONFIDENCE isn't applied
> anymore.
>
> So also apply the quirk since MT_CLS_WIN_8_FORCE_MULTI_INPUT is
> essentially MT_CLS_WIN_8.
>
> Fixes: 40d5bb87377a ("HID: multitouch: enable multi-input as a quirk for some
> devices")
> Signed-off-by: Kai-Heng Feng
Thanks for the patch.
IIt seems I was too lazy to write a regression test for it, and this
strikes back.
Can you also work on a regression test for this at
https://gitlab.freedesktop.org/libevdev/hid-tools ?
Cheers,
Benjamin
> ---
> drivers/hid/hid-multitouch.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 0743ef51d3b2..8429ebe7097e 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -758,7 +758,8 @@ static int mt_touch_input_mapping(struct hid_device
> *hdev, struct hid_input *hi,
> MT_STORE_FIELD(inrange_state);
> return 1;
> case HID_DG_CONFIDENCE:
> - if (cls->name == MT_CLS_WIN_8 &&
> + if ((cls->name == MT_CLS_WIN_8 ||
> +cls->name == MT_CLS_WIN_8_FORCE_MULTI_INPUT) &&
> (field->application == HID_DG_TOUCHPAD ||
> field->application == HID_DG_TOUCHSCREEN))
> app->quirks |= MT_QUIRK_CONFIDENCE;
> --
> 2.29.2
>
Re: [PATCH v8 0/4] HID: i2c-hid: Reorganize to allow supporting goodix,gt7375p
Hi,
On Wed, Jan 13, 2021 at 8:35 PM Benjamin Tissoires
wrote:
On Wed, Jan 13, 2021 at 5:05 PM Doug Anderson wrote:
>
> Hi,
>
> On Wed, Jan 13, 2021 at 7:09 AM Benjamin Tissoires
> wrote:
> >
> > > I wanted to apply the series yesterday, but for these kinds of changes
> > > I like giving it a spin on actual hardware. Turns out that my XPS-13
> > > can not boot to v5.11-rc2, which makes testing the new branch slightly
> > > more difficult.
> > >
> > > I'll give it a spin next week, but I think I should be able to land it
for 5.12.
> > >
> > > Regarding the defconfig conflict, no worries, we can handle it with
> > > Stephen and Linus.
> > >
> >
> > After 2 full kernel bisects (I messed up the first because I am an
> > idiot and inverted good and bad after the first reboot), I found my
> > culprit, and I was able to test the series today.
> >
> > The series works fine regarding enumeration and removing of devices,
> > but it prevents my system from being suspended. If I rmmod
> > i2c-hid-acpi, suspend works fine, but if it is present, it immediately
> > comes back, which makes me think that something must be wrong.
> >
> > I also just reverted the series and confirmed that suspend/resume now
> > works, meaning that patch 1/4 needs to be checked.
>
> Can you give me any hints about what type of failure you're seeing?
> Any logs? I don't have an ACPI system to test with...
I don't have any logs, just that the system comes back up. There is a
chance we are not powering the device down correctly, which triggers
an IRQ and which puts the system back on.
>
> Is there any chance that some type of userspace / udev rule is getting
> tripped up by the driver being renamed? We ran into something like
> this recently on Chrome OS where we had a tool that was hardcoded to
> look for "i2c-hid" and needed to be adapted to account for the new
> driver name. Often userspace tweaks with wakeup rules based on driver
> name...
I don't think there is anything like that on a regular desktop.
>
> I'll go stare at the code now and see if anything jumps out.
>
Thanks, but don't spend too much time on it, unless something really
jumps out. I'll debug that tomorrow. It's much easier with an actual
device than by just looking at the code.
Well, that's weird. Now suspend resume works reliably even with your
series. It could just have been that the lid sensor was too close to a
magnet or something like that. Though while testing the old version of
i2c-hid, it was working... Such a mystery :)
Anyway, while trying to dig up that now-non-issue, I got the following patch
that you likely want to squash into 1/4:
---
diff --git a/drivers/hid/i2c-hid/i2c-hid-acpi.c
b/drivers/hid/i2c-hid/i2c-hid-acpi.c
index 0f86060f01b4..dd6d9f74e7e7 100644
--- a/drivers/hid/i2c-hid/i2c-hid-acpi.c
+++ b/drivers/hid/i2c-hid/i2c-hid-acpi.c
@@ -31,7 +31,6 @@
struct i2c_hid_acpi {
struct i2chid_ops ops;
struct i2c_client *client;
- bool power_fixed;
};
static const struct acpi_device_id i2c_hid_acpi_blacklist[] = {
@@ -75,25 +74,6 @@ static int i2c_hid_acpi_get_descriptor(struct i2c_client
*client)
return hid_descriptor_address;
}
-static int i2c_hid_acpi_power_up(struct i2chid_ops *ops)
-{
- struct i2c_hid_acpi *ihid_of =
- container_of(ops, struct i2c_hid_acpi, ops);
- struct device *dev = _of->client->dev;
- struct acpi_device *adev;
-
- /* Only need to call acpi_device_fix_up_power() the first time */
- if (ihid_of->power_fixed)
- return 0;
- ihid_of->power_fixed = true;
-
- adev = ACPI_COMPANION(dev);
- if (adev)
- acpi_device_fix_up_power(adev);
-
- return 0;
-}
-
static void i2c_hid_acpi_shutdown_tail(struct i2chid_ops *ops)
{
struct i2c_hid_acpi *ihid_of =
@@ -107,6 +87,7 @@ static int i2c_hid_acpi_probe(struct i2c_client *client,
{
struct device *dev = >dev;
struct i2c_hid_acpi *ihid_acpi;
+ struct acpi_device *adev;
u16 hid_descriptor_address;
int ret;
@@ -115,7 +96,6 @@ static int i2c_hid_acpi_probe(struct i2c_client *client,
return -ENOMEM;
ihid_acpi->client = client;
- ihid_acpi->ops.power_up = i2c_hid_acpi_power_up;
ihid_acpi->ops.shutdown_tail = i2c_hid_acpi_shutdown_tail;
ret = i2c_hid_acpi_get_descriptor(client);
@@ -123,6 +103,10 @@ static int i2c_hid_acpi_probe(struct i2c_client *client,
return ret;
hid_descriptor_address = ret;
+ adev = ACPI_COMPANION(dev);
+ if (adev)
+ acpi_device_fix_up_power(adev);
+
if (acpi_gbl_FADT.flags & ACPI_FADT_LOW_POWER_S0) {
devic
Re: [PATCH 4/5] input: touchscreen: surface3_spi: Remove set but unused variable 'timestamp'
On Thu, Jan 14, 2021 at 4:23 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/input/touchscreen/surface3_spi.c: In function
> ‘surface3_spi_process_touch’:
> drivers/input/touchscreen/surface3_spi.c:97:6: warning: variable ‘timestamp’
> set but not used [-Wunused-but-set-variable]
>
> Cc: Dmitry Torokhov
> Cc: Henrik Rydberg
> Cc: Benjamin Tissoires
> Cc: linux-in...@vger.kernel.org
> Signed-off-by: Lee Jones
Reviewed-by: Benjamin Tissoires
Thanks for the cleanup :)
Cheers,
Benjamin
> ---
> drivers/input/touchscreen/surface3_spi.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/input/touchscreen/surface3_spi.c
> b/drivers/input/touchscreen/surface3_spi.c
> index 731454599fcee..1da23e5585a0d 100644
> --- a/drivers/input/touchscreen/surface3_spi.c
> +++ b/drivers/input/touchscreen/surface3_spi.c
> @@ -94,9 +94,7 @@ static void surface3_spi_report_touch(struct
> surface3_ts_data *ts_data,
>
> static void surface3_spi_process_touch(struct surface3_ts_data *ts_data, u8
> *data)
> {
> - u16 timestamp;
> unsigned int i;
> - timestamp = get_unaligned_le16([15]);
>
> for (i = 0; i < 13; i++) {
> struct surface3_ts_data_finger *finger;
> --
> 2.25.1
>
Re: [PATCH] HID: hid-input: avoid splitting keyboard, system and consumer controls
Hi Dmitry,
On Thu, Jan 14, 2021 at 7:24 AM Dmitry Torokhov
wrote:
>
> A typical USB keyboard usually splits its keys into several reports:
>
> - one for the basic alphanumeric keys, modifier keys, F keys, six pack
> keys and keypad. This report's application is normally listed as
> GenericDesktop.Keyboard
> - a GenericDesktop.SystemControl report for the system control keys, such
> as power and sleep
> - Consumer.ConsumerControl report for multimedia (forward, rewind,
> play/pause, mute, etc) and other extended keys.
> - additional output, vendor specific, and feature reports
>
> Splitting each report into a separate input device is wasteful and even
> hurts userspace as it makes it harder to determine the true capabilities
> (set of available keys) of a keyboard, so let's adjust application
> matching to merge system control and consumer control reports with
> keyboard report, if one has already been processed.
>
> Signed-off-by: Dmitry Torokhov
> ---
> drivers/hid/hid-input.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index f797659cb9d9..df45d8d07dc2 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -1851,6 +1851,16 @@ static struct hid_input
> *hidinput_match_application(struct hid_report *report)
> list_for_each_entry(hidinput, >inputs, list) {
> if (hidinput->application == report->application)
> return hidinput;
> +
> + /*
> +* Keep SystemControl and ConsumerControl applications
> together
> +* with the main keyboard, if present.
> +*/
> + if ((report->application == HID_GD_SYSTEM_CONTROL ||
> +report->application == HID_CP_CONSUMER_CONTROL) &&
> + hidinput->application == HID_GD_KEYBOARD) {
I am not fundamentally against the patch, but I think that if the
device exposes first a HID_CP_CONSUMER_CONTROL and then a
HID_GD_KEYBOARD we will end up with 2 different input nodes. We likely
need to "convert" HID_GD_SYSTEM_CONTROL and HID_CP_CONSUMER_CONTROL to
HID_GD_KEYBOARD when creating the hidinput.
Cheers,
Benjamin
> + return hidinput;
> + }
> }
>
> return NULL;
> --
> 2.30.0.284.gd98b1dd5eaa7-goog
>
>
> --
> Dmitry
>
Re: [PATCH v8 0/4] HID: i2c-hid: Reorganize to allow supporting goodix,gt7375p
On Wed, Jan 13, 2021 at 5:05 PM Doug Anderson wrote: > > Hi, > > On Wed, Jan 13, 2021 at 7:09 AM Benjamin Tissoires > wrote: > > > > > I wanted to apply the series yesterday, but for these kinds of changes > > > I like giving it a spin on actual hardware. Turns out that my XPS-13 > > > can not boot to v5.11-rc2, which makes testing the new branch slightly > > > more difficult. > > > > > > I'll give it a spin next week, but I think I should be able to land it > > > for 5.12. > > > > > > Regarding the defconfig conflict, no worries, we can handle it with > > > Stephen and Linus. > > > > > > > After 2 full kernel bisects (I messed up the first because I am an > > idiot and inverted good and bad after the first reboot), I found my > > culprit, and I was able to test the series today. > > > > The series works fine regarding enumeration and removing of devices, > > but it prevents my system from being suspended. If I rmmod > > i2c-hid-acpi, suspend works fine, but if it is present, it immediately > > comes back, which makes me think that something must be wrong. > > > > I also just reverted the series and confirmed that suspend/resume now > > works, meaning that patch 1/4 needs to be checked. > > Can you give me any hints about what type of failure you're seeing? > Any logs? I don't have an ACPI system to test with... I don't have any logs, just that the system comes back up. There is a chance we are not powering the device down correctly, which triggers an IRQ and which puts the system back on. > > Is there any chance that some type of userspace / udev rule is getting > tripped up by the driver being renamed? We ran into something like > this recently on Chrome OS where we had a tool that was hardcoded to > look for "i2c-hid" and needed to be adapted to account for the new > driver name. Often userspace tweaks with wakeup rules based on driver > name... I don't think there is anything like that on a regular desktop. > > I'll go stare at the code now and see if anything jumps out. > Thanks, but don't spend too much time on it, unless something really jumps out. I'll debug that tomorrow. It's much easier with an actual device than by just looking at the code. Cheers, Benjamin > -Doug >
Re: [PATCH v8 0/4] HID: i2c-hid: Reorganize to allow supporting goodix,gt7375p
On Fri, Jan 8, 2021 at 6:52 PM Benjamin Tissoires
wrote:
>
> Hi Doug,
>
> On Wed, Jan 6, 2021 at 2:35 AM Doug Anderson wrote:
> >
> > Benjamin,
> >
> > On Fri, Dec 11, 2020 at 2:24 PM Douglas Anderson
> > wrote:
> > >
> > > The goal of this series is to support the Goodix GT7375P touchscreen.
> > > This touchscreen is special because it has power sequencing
> > > requirements that necessitate driving a reset GPIO.
> > >
> > > To do this, we totally rejigger the way i2c-hid is organized so that
> > > it's easier to jam the Goodix support in there.
> > >
> > > This series was:
> > > - Tested on a device that uses normal i2c-hid.
> > > - Tested on a device that has a Goodix i2c-hid device.
> > > - Tested on an ACPI device, but an earlier version of the series.
> > >
> > > I believe the plan is for Benjamin to land the whole series. Will
> > > said this about the arm64 defconfig change (and provided his Ack):
> > > > ...there are a few things I really care about
> > > > in defconfig (e.g. things like page size!), generally speaking we don't
> > > > need to Ack everything that changes in there.
> > > >
> > > > That said, might be worth checking whether arm-soc have any defconfig
> > > > changes queued in -next so you don't end up with conflicts.
> > >
> > > Changes in v8:
> > > - Mark suspend/resume as static as per patches robot.
> > >
> > > Changes in v7:
> > > - Rebase atop commit afdd34c5fa40 ("HID: i2c-hid: show the error ...")
> > >
> > > Changes in v6:
> > > - ACPI probe function should have been "static"
> > > - Don't export suspend/resume, just export dev_pm_ops from core.
> > > - Fixed crash in ACPI module (missing init of "client")
> > > - No need for regulator include in the core.
> > > - Removed i2c_device_id table from ACPI module.
> > > - Suspend/resume are no longer exported from the core.
> > >
> > > Changes in v5:
> > > - Add shutdown_tail op and use it in ACPI.
> > > - Added mention of i2c-hid in the yaml itself as per Rob.
> > > - Adjusted subject as per Rob.
> > > - i2chid_subclass_data => i2chid_ops.
> > > - power_up_device => power_up (same with power_down).
> > > - subclass => ops.
> > >
> > > Changes in v4:
> > > - ("arm64: defconfig: Update config names for i2c-hid rejigger") new for
> > > v4.
> > > - Fully rejigger so ACPI and OF are full subclasses.
> > > - Totally redid based on the new subclass system.
> > >
> > > Changes in v3:
> > > - Fixed compatible in example.
> > > - Removed Benjamin as a maintainer.
> > > - Rework to use subclassing.
> > > - Updated description.
> > >
> > > Changes in v2:
> > > - ("dt-bindings: HID: i2c-hid: Introduce bindings for the Goodix
> > > GT7375P") new in v2.
> > > - Get timings based on the compatible string.
> > > - Use a separate compatible string for this new touchscreen.
> > >
> > > Douglas Anderson (4):
> > > HID: i2c-hid: Reorganize so ACPI and OF are separate modules
> > > arm64: defconfig: Update config names for i2c-hid rejigger
> > > dt-bindings: input: HID: i2c-hid: Introduce bindings for the Goodix
> > > GT7375P
> > > HID: i2c-hid: Introduce goodix-i2c-hid using i2c-hid core
> >
> > I think this series is ready to land. The "defconfig" has a trivial
> > conflict with commit 74b87103b3d0 ("arm64: defconfig: Enable HID
> > multitouch") against linuxnext, but it's so simple that hopefully
> > folks will be OK with that when it lands.
> >
> > Please let me know if there's anything else you need me to do. :-)
> >
>
> I wanted to apply the series yesterday, but for these kinds of changes
> I like giving it a spin on actual hardware. Turns out that my XPS-13
> can not boot to v5.11-rc2, which makes testing the new branch slightly
> more difficult.
>
> I'll give it a spin next week, but I think I should be able to land it for
> 5.12.
>
> Regarding the defconfig conflict, no worries, we can handle it with
> Stephen and Linus.
>
After 2 full kernel bisects (I messed up the first because I am an
idiot and inverted good and bad after the first reboot), I found my
culprit, and I was able to test the series today.
The series works fine regarding enumeration and removing of devices,
but it prevents my system from being suspended. If I rmmod
i2c-hid-acpi, suspend works fine, but if it is present, it immediately
comes back, which makes me think that something must be wrong.
I also just reverted the series and confirmed that suspend/resume now
works, meaning that patch 1/4 needs to be checked.
Cheers,
Benjamin
Re: [PATCH] Documentation: input: define ABS_PRESSURE/ABS_MT_PRESSURE resolution as grams
On Wed, Jan 13, 2021 at 12:03 AM Peter Hutterer
wrote:
>
> ABS_PRESSURE and ABS_MT_PRESSURE on touch devices usually represent
> contact size (as a finger flattens with higher pressure the contact size
> increases) and userspace translates the kernel pressure value back into
> contact size. For example, libinput has pressure thresholds when a touch is
> considered a palm (palm == large contact area -> high pressure). The values
> themselves are on an arbitrary scale and device-specific.
>
> On pressurepads however, the pressure axis may represent the real physical
> pressure. Pressurepads are touchpads without a hinge but an actual pressure
> sensor underneath the device instead, for example the Lenovo Yoga 9i.
>
> A high-enough pressure is converted to a button click by the firmware.
> Microsoft does not require a pressure axis to be present, see [1], so as seen
> from userspace most pressurepads are identical to clickpads - one button and
> INPUT_PROP_BUTTONPAD set.
>
> However, pressurepads that export the pressure axis break userspace because
> that axis no longer represents contact size, resulting in inconsistent touch
> tracking, e.g. [2]. Userspace needs to know when a pressure axis represents
> real pressure and the best way to do so is to define what the resolution
> field means. Userspace can then treat data with a pressure resolution as
> true pressure.
>
> This patch documents that the pressure resolution is in units/gram. This
> allows for fine-grained detail and tops out at roughly ~2000t, enough for the
> devices we're dealing with. Grams is not a scientific pressure unit but the
> alternative is:
> - Pascal: defined as force per area and area is unreliable on many devices and
> seems like the wrong option here anyway, especially for devices with a
> single pressure sensor only.
> - Newton: defined as mass * distance/acceleration and for the purposes of a
> pressure axis, the distance is tricky to interpret and we get the data to
> calculate acceleration from event timestamps anyway.
>
> For the purposes of touch devices and digitizers, grams seems the best choice
> and the easiest to interpret.
>
> Bonus side effect: we can use the existing hwdb infrastructure in userspace to
> fix devices that advertise false pressure.
>
> [1]
> https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/windows-precision-touchpad-required-hid-top-level-collections#windows-precision-touchpad-input-reports
> [2] https://gitlab.freedesktop.org/libinput/libinput/-/issues/562
>
> Signed-off-by: Peter Hutterer
FWIW, and because I was involved in the initial discussion:
Acked-by: Benjamin Tissoires
Cheers,
Benjamin
> ---
> Documentation/input/event-codes.rst | 15 +++
> Documentation/input/multi-touch-protocol.rst | 4
> 2 files changed, 19 insertions(+)
>
> diff --git a/Documentation/input/event-codes.rst
> b/Documentation/input/event-codes.rst
> index b24b5343f5eb..3118fc1c1e26 100644
> --- a/Documentation/input/event-codes.rst
> +++ b/Documentation/input/event-codes.rst
> @@ -236,6 +236,21 @@ A few EV_ABS codes have special meanings:
>- Used to describe multitouch input events. Please see
> multi-touch-protocol.txt for details.
>
> +* ABS_PRESSURE/ABS_MT_PRESSURE:
> +
> + - For touch devices, many devices converted contact size into pressure.
> + A finger flattens with pressure, causing a larger contact area and thus
> + pressure and contact size are directly related. This is not the case
> + for other devices, for example digitizers and touchpads with a true
> + pressure sensor ("pressure pads").
> +
> + A device should set the resolution of the axis to indicate whether the
> + pressure is in measurable units. If the resolution is zero, the
> + pressure data is in arbitrary units. If the resolution is nonzero, the
> + pressure data is in units/gram. For example, a value of 10 with a
> + resolution of 1 represents 10 gram, a value of 10 with a resolution on
> + 1000 represents 10 microgram.
> +
> EV_SW
> -
>
> diff --git a/Documentation/input/multi-touch-protocol.rst
> b/Documentation/input/multi-touch-protocol.rst
> index 307fe22d9668..21c1e6a22888 100644
> --- a/Documentation/input/multi-touch-protocol.rst
> +++ b/Documentation/input/multi-touch-protocol.rst
> @@ -260,6 +260,10 @@ ABS_MT_PRESSURE
> of TOUCH and WIDTH for pressure-based devices or any device with a
> spatial
> signal intensity distribution.
>
> +If the resolution is zero, the pressure data is in arbitrary units.
> +If the resolution is nonzero, the pressure data is in units/gram. See
> +:ref:`input-event-codes` for details.
> +
> ABS_MT_DISTANCE
> The distance, in surface units, between the contact and the surface. Zero
> distance means the contact is touching the surface. A positive number
> means
> --
> 2.29.2
>
Re: [PATCH v8 0/4] HID: i2c-hid: Reorganize to allow supporting goodix,gt7375p
Hi Doug,
On Wed, Jan 6, 2021 at 2:35 AM Doug Anderson wrote:
>
> Benjamin,
>
> On Fri, Dec 11, 2020 at 2:24 PM Douglas Anderson
> wrote:
> >
> > The goal of this series is to support the Goodix GT7375P touchscreen.
> > This touchscreen is special because it has power sequencing
> > requirements that necessitate driving a reset GPIO.
> >
> > To do this, we totally rejigger the way i2c-hid is organized so that
> > it's easier to jam the Goodix support in there.
> >
> > This series was:
> > - Tested on a device that uses normal i2c-hid.
> > - Tested on a device that has a Goodix i2c-hid device.
> > - Tested on an ACPI device, but an earlier version of the series.
> >
> > I believe the plan is for Benjamin to land the whole series. Will
> > said this about the arm64 defconfig change (and provided his Ack):
> > > ...there are a few things I really care about
> > > in defconfig (e.g. things like page size!), generally speaking we don't
> > > need to Ack everything that changes in there.
> > >
> > > That said, might be worth checking whether arm-soc have any defconfig
> > > changes queued in -next so you don't end up with conflicts.
> >
> > Changes in v8:
> > - Mark suspend/resume as static as per patches robot.
> >
> > Changes in v7:
> > - Rebase atop commit afdd34c5fa40 ("HID: i2c-hid: show the error ...")
> >
> > Changes in v6:
> > - ACPI probe function should have been "static"
> > - Don't export suspend/resume, just export dev_pm_ops from core.
> > - Fixed crash in ACPI module (missing init of "client")
> > - No need for regulator include in the core.
> > - Removed i2c_device_id table from ACPI module.
> > - Suspend/resume are no longer exported from the core.
> >
> > Changes in v5:
> > - Add shutdown_tail op and use it in ACPI.
> > - Added mention of i2c-hid in the yaml itself as per Rob.
> > - Adjusted subject as per Rob.
> > - i2chid_subclass_data => i2chid_ops.
> > - power_up_device => power_up (same with power_down).
> > - subclass => ops.
> >
> > Changes in v4:
> > - ("arm64: defconfig: Update config names for i2c-hid rejigger") new for v4.
> > - Fully rejigger so ACPI and OF are full subclasses.
> > - Totally redid based on the new subclass system.
> >
> > Changes in v3:
> > - Fixed compatible in example.
> > - Removed Benjamin as a maintainer.
> > - Rework to use subclassing.
> > - Updated description.
> >
> > Changes in v2:
> > - ("dt-bindings: HID: i2c-hid: Introduce bindings for the Goodix GT7375P")
> > new in v2.
> > - Get timings based on the compatible string.
> > - Use a separate compatible string for this new touchscreen.
> >
> > Douglas Anderson (4):
> > HID: i2c-hid: Reorganize so ACPI and OF are separate modules
> > arm64: defconfig: Update config names for i2c-hid rejigger
> > dt-bindings: input: HID: i2c-hid: Introduce bindings for the Goodix
> > GT7375P
> > HID: i2c-hid: Introduce goodix-i2c-hid using i2c-hid core
>
> I think this series is ready to land. The "defconfig" has a trivial
> conflict with commit 74b87103b3d0 ("arm64: defconfig: Enable HID
> multitouch") against linuxnext, but it's so simple that hopefully
> folks will be OK with that when it lands.
>
> Please let me know if there's anything else you need me to do. :-)
>
I wanted to apply the series yesterday, but for these kinds of changes
I like giving it a spin on actual hardware. Turns out that my XPS-13
can not boot to v5.11-rc2, which makes testing the new branch slightly
more difficult.
I'll give it a spin next week, but I think I should be able to land it for 5.12.
Regarding the defconfig conflict, no worries, we can handle it with
Stephen and Linus.
Cheers,
Benjamin
Re: [PATCH v6 0/4] HID: i2c-hid: Reorganize to allow supporting goodix,gt7375p
Hi Doug,
On Tue, Dec 1, 2020 at 10:12 PM Doug Anderson wrote:
>
> Hi,
>
> On Wed, Nov 11, 2020 at 4:41 PM Douglas Anderson
> wrote:
> >
> > The goal of this series is to support the Goodix GT7375P touchscreen.
> > This touchscreen is special because it has power sequencing
> > requirements that necessitate driving a reset GPIO.
> >
> > To do this, we totally rejigger the way i2c-hid is organized so that
> > it's easier to jam the Goodix support in there.
> >
> > This series was:
> > - Tested on a device that uses normal i2c-hid.
> > - Tested on a device that has a Goodix i2c-hid device.
> > - Tested on an ACPI device, but an earlier version of the series.
> >
> > Changes in v6:
> > - ACPI probe function should have been "static"
> > - Don't export suspend/resume, just export dev_pm_ops from core.
> > - Fixed crash in ACPI module (missing init of "client")
> > - No need for regulator include in the core.
> > - Removed i2c_device_id table from ACPI module.
> > - Suspend/resume are no longer exported from the core.
> >
> > Changes in v5:
> > - Add shutdown_tail op and use it in ACPI.
> > - Added mention of i2c-hid in the yaml itself as per Rob.
> > - Adjusted subject as per Rob.
> > - i2chid_subclass_data => i2chid_ops.
> > - power_up_device => power_up (same with power_down).
> > - subclass => ops.
> >
> > Changes in v4:
> > - ("arm64: defconfig: Update config names for i2c-hid rejigger") new for v4.
> > - Fully rejigger so ACPI and OF are full subclasses.
> > - Totally redid based on the new subclass system.
> >
> > Changes in v3:
> > - Fixed compatible in example.
> > - Removed Benjamin as a maintainer.
> > - Rework to use subclassing.
> > - Updated description.
> >
> > Changes in v2:
> > - ("dt-bindings: HID: i2c-hid: Introduce bindings for the Goodix GT7375P")
> > new in v2.
> > - Get timings based on the compatible string.
> > - Use a separate compatible string for this new touchscreen.
> >
> > Douglas Anderson (4):
> > HID: i2c-hid: Reorganize so ACPI and OF are separate modules
> > arm64: defconfig: Update config names for i2c-hid rejigger
> > dt-bindings: input: HID: i2c-hid: Introduce bindings for the Goodix
> > GT7375P
> > HID: i2c-hid: Introduce goodix-i2c-hid using i2c-hid core
> >
> > .../bindings/input/goodix,gt7375p.yaml| 65 +
> > arch/arm64/configs/defconfig | 3 +-
> > drivers/hid/Makefile | 2 +-
> > drivers/hid/i2c-hid/Kconfig | 47 +++-
> > drivers/hid/i2c-hid/Makefile | 6 +-
> > drivers/hid/i2c-hid/i2c-hid-acpi.c| 159 +++
> > drivers/hid/i2c-hid/i2c-hid-core.c| 254 +++---
> > drivers/hid/i2c-hid/i2c-hid-of-goodix.c | 116
> > drivers/hid/i2c-hid/i2c-hid-of.c | 143 ++
> > drivers/hid/i2c-hid/i2c-hid.h | 22 ++
> > include/linux/platform_data/i2c-hid.h | 41 ---
> > 11 files changed, 596 insertions(+), 262 deletions(-)
> > create mode 100644
> > Documentation/devicetree/bindings/input/goodix,gt7375p.yaml
> > create mode 100644 drivers/hid/i2c-hid/i2c-hid-acpi.c
> > create mode 100644 drivers/hid/i2c-hid/i2c-hid-of-goodix.c
> > create mode 100644 drivers/hid/i2c-hid/i2c-hid-of.c
> > delete mode 100644 include/linux/platform_data/i2c-hid.h
>
> Are there any additional changes that folks would like with this
> series? It's not crazy urgent to get it in, but it touches enough
> lines of code that it'd be nice to get it in before other patches land
> and it gets merge conflicts.
Sorry for the delay. I was having an internal deadline last week. I
just re-read the code, and I am quite happy with it. I also just
tested it on the i2c-hid w/ acpi machine I have here, and it seems OK.
So other than that, do we need to have approvals for patch 2/4
(arch/arm64/configs/defconfig)? I can easily take that in the HID
tree, but I prefer having the approval from the maintainers first.
Catalin, Will?
>
> Hrm, I just checked and there actually is already one merge conflict
> with commit afdd34c5fa40 ("HID: i2c-hid: show the error when failing
> to fetch the HID descriptor") but that commit (and thus the
> resolution) is trivial. If there are no other comments I can re-post
> atop that patch. ...or I'm also happy if a maintainer is OK w/
> resolving when landing my series. Just let me know!
If I can quickly get the approval from the arm64/config maintainers, I
can try to apply it. Though, I wouldn't be against you sending a clean
and conflict-free series :)
>
> ...or, if you want me to just shut up for a while and wait until your
> tryptophan hangover wears off, that's fine too--just let me know.
>
Heh. Sorry, I have a tendency to have my inbox flooded, and some time
gets distracted to do other important work I am paid for (too). I
don't mind a gentle nudge from time to time, that helps figuring out
the priorities :)
Cheers,
Benjamin
Re: [PATCH 08/15] input: touchscreen: surface3_spi: Remove set but unused variable 'timestamp'
On Fri, Nov 13, 2020 at 8:40 AM Dmitry Torokhov
wrote:
>
> On Thu, Nov 12, 2020 at 11:01:57AM +, Lee Jones wrote:
> > Fixes the following W=1 kernel build warning(s):
> >
> > drivers/input/touchscreen/surface3_spi.c: In function
> > ‘surface3_spi_process_touch’:
> > drivers/input/touchscreen/surface3_spi.c:97:6: warning: variable
> > ‘timestamp’ set but not used [-Wunused-but-set-variable]
> >
> > Cc: Dmitry Torokhov
> > Cc: Henrik Rydberg
> > Cc: Benjamin Tissoires
> > Cc: linux-in...@vger.kernel.org
> > Signed-off-by: Lee Jones
> > ---
> > drivers/input/touchscreen/surface3_spi.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/drivers/input/touchscreen/surface3_spi.c
> > b/drivers/input/touchscreen/surface3_spi.c
> > index ce4828b1415a8..72dc4c562a4e1 100644
> > --- a/drivers/input/touchscreen/surface3_spi.c
> > +++ b/drivers/input/touchscreen/surface3_spi.c
> > @@ -94,9 +94,7 @@ static void surface3_spi_report_touch(struct
> > surface3_ts_data *ts_data,
> >
> > static void surface3_spi_process_touch(struct surface3_ts_data *ts_data,
> > u8 *data)
> > {
> > - u16 timestamp;
> > unsigned int i;
> > - timestamp = get_unaligned_le16([15]);
>
> Benjamin, should we pass timing data on to userspace instead?
Last time I checked, libinput was not using the HW timestamp. So I
don't mind dropping it.
Not sure if chrome/android uses it.
Cheers,
Benjamin
>
> >
> > for (i = 0; i < 13; i++) {
> > struct surface3_ts_data_finger *finger;
> > --
> > 2.25.1
> >
>
> Thanks.
>
> --
> Dmitry
Re: [PATCH v4 1/4] HID: i2c-hid: Reorganize so ACPI and OF are subclasses
chid_subclass_data *subclass;
> >>> };
> >>
> >> Personally, I would do things a bit differently here:
> >>
> >> 1. Just add the
> >>
> >> int (*power_up_device)(struct i2chid_subclass_data *subclass);
> >> void (*power_down_device)(struct i2chid_subclass_data *subclass);
> >>
> >> members which you put in the subclass struct here.
> >>
> >> 2. Move the declaration of this complete struct to
> >> drivers/hid/i2c-hid/i2c-hid.h
> >> and use this as the base-class which I described before (and store the
> >> client
> >> pointer here).
> >>
> >> 3. And then kzalloc both this baseclass struct + the subclass-data
> >> (only the bool "power_fixed" in the ACPI case) in one go in the subclass
> >> code
> >> replacing 2 kzallocs (+ error checking with one, simplifying the code and
> >> reducing memory fragmentation (by a tiny sliver).
> >
> > Sure, I'll do that if Benjamin likes moving the structure to the header.
> >
> >
> >> About the power_*_device callbacks, I wonder if it would not be more
> >> consistent
> >> to also have a shutdown callback and make i2c_driver.shutdown point to
> >> a (modified) i2c_hid_core_shutdown() function.
> >
> > Personally this doesn't seem cleaner to me, but I'm happy to do it if
> > folks like it better. Coming up with a name for the callback would be
> > a bit awkward, which is a sign that this isn't quite ideal? For the
> > power_up()/power_down() those are sane concepts to abstract out. Here
> > we'd be abstracting out "subclass_shutdown_tail()" or something?
> > ...and if a subclass needs something at the head of shutdown, we'd
> > need to add a "subclass_shutdown_head()"?
>
> I have no real preference here either way.
If we are using i2chid_ops, we could just have `shutdown_tail()`.
Basically drop any "device" or "subclass" in the op name.
This would lead to better code IMO: "ihid->dev_ops->shutdown()" for example
Cheers,
Benjamin
>
> >> You may also want to consider pointing that shutdown callback to the
> >> power_off
> >> function in the of case (in a separate commit as that is a behavioral
> >> change).
> >
> > I don't think this is the point of shutdown, but I could be corrected.
> > Shutdown isn't really supposed to be the same as driver remove or
> > anything. IIUC the main point of shutdown is to support kexec and the
> > goal is to quiesce DMA transactions. Turning off power has never been
> > a requirement that I was aware of. We don't want to jam too much
> > stuff in shutdown or else "shutdown" becomes as slow as boot for no
> > good reason, right?
>
> This sorta depends on if the regulators for the HID device are part of the
> PMIC or not. If they are part of the PMIC then on shutdown they will
> typically be turned off by the PMIC. But if they are separate they may
> stay enabled on shutdown.
>
> Anyways I again have no real preference here...
>
> Regards,
>
> Hans
>
>
>
>
>
>
> >
> >
> >>> diff --git a/drivers/hid/i2c-hid/i2c-hid-of.c
> >>> b/drivers/hid/i2c-hid/i2c-hid-of.c
> >>> new file mode 100644
> >>> index ..e1838cdef0aa
> >>> --- /dev/null
> >>> +++ b/drivers/hid/i2c-hid/i2c-hid-of.c
> >>> @@ -0,0 +1,149 @@
> >>> +/*
> >>> + * HID over I2C Open Firmware Subclass
> >>> + *
> >>> + * Copyright (c) 2012 Benjamin Tissoires
> >>> + * Copyright (c) 2012 Ecole Nationale de l'Aviation Civile, France
> >>> + * Copyright (c) 2012 Red Hat, Inc
> >>
> >>
> >>
> >>> +MODULE_DESCRIPTION("HID over I2C OF driver");
> >>> +MODULE_AUTHOR("Benjamin Tissoires ");
> >>
> >> In case Benjamin misses this during his own review: I'm not sure if he
> >> will want to be set as AUTHOR of this, given that part of the plan is
> >> for someone else to be the primary point of contact for the of bits.
> >
> > I can stick myself in as the author if needed. I'll wait for
> > Benjamin's feedback here.
> >
> >
> > -Doug
> >
>
Re: [PATCH v2] Input: Fix the HID usage of DPAD input event generation.
um(255) >Physical Minimum(0) >Physical Maximum(255) >Report Size(8) >Report Count(2) >Report Offset(80) >Flags( Variable Absolute ) >FEATURE[FEATURE] > Field(0) >Application(GenericDesktop.GamePad) >Usage(8) > ff00.0080 > ff00.0080 > ff00.0080 > ff00.0080 > ff00.0080 > ff00.0080 > ff00.0080 > ff00.0080 >Logical Minimum(0) >Logical Maximum(255) >Physical Minimum(0) >Physical Maximum(255) >Report Size(8) >Report Count(8) >Report Offset(0) >Flags( Variable Absolute ) > > GenericDesktop.X ---> Absolute.X > GenericDesktop.Y ---> Absolute.Y > GenericDesktop.Z ---> Absolute.Z > GenericDesktop.Rz ---> Absolute.Rz > GenericDesktop.HatSwitch ---> Absolute.Hat0X > GenericDesktop.HatSwitch ---> Absolute.Hat0Y It took me a while to realize that you were needing https://patchwork.kernel.org/project/linux-input/patch/20201101193452.678628-1-l...@google.com/ for that. But the weird part is that Hat switch are usually used as a single variable, with values being mapped to Hat0X and Hat0Y. So I still haven't manage to understand how the hid-input driver would map the axis to a regular one between 1 and 255... > Keyboard.004f ---> Key.Right > Keyboard.0050 ---> Key.Left > Keyboard.0051 ---> Key.Down > Keyboard.0052 ---> Key.Up > GenericDesktop.D-PadUp ---> Absolute.Hat1X > GenericDesktop.D-PadDown ---> Sync.Report > GenericDesktop.D-PadRight ---> Sync.Report > GenericDesktop.D-PadLeft ---> Sync.Report > Button.0001 ---> Key.BtnA > Button.0002 ---> Key.BtnB > Button.0003 ---> Key.BtnC > Button.0004 ---> Key.BtnX > Button.0005 ---> Key.BtnY > Button.0006 ---> Key.BtnZ > Button.0007 ---> Key.BtnTL > Button.0008 ---> Key.BtnTR > Button.0009 ---> Key.BtnTL2 > Button.000a ---> Key.BtnTR2 > Button.000b ---> Key.BtnSelect > Button.000c ---> Key.BtnStart > Button.000d ---> Key.BtnMode > Button.000e ---> Key.BtnThumbL > Button.000f ---> Key.BtnThumbR > Button.0010 ---> Key.? > ff02.0004 ---> Key.Btn0 > Consumer.0224 ---> Key.Back > Simulation.00c4 ---> Absolute.Gas > Simulation.00c5 ---> Absolute.Brake > > So you can see the device has D-Up, D-Down,D-Right,D-Left usages, and > D-up is mapped to Hat1X. OK, now I am starting to understand the problem better. > > Also if you can send HID report from hid-tool, you will see there are > always intail events on Hat1X/Hat1Y as the HatDir is 0, even no DPAD > buttons pressed. When you send HID report with D-DPAD buttons with > different state, it doesn't generate any axis events because the HatDir > internally is still 0 regardless the report value of the 4 DPAD usages. That's the part I am a little bit stuck. I can emulate events for X,Y, buttons,... but I am not sure how the gamepad sends the events for the Hat switch and the D-Pad together. Again, before we merge anything, I'd like to have the proper tests written for it, on top of https://gitlab.freedesktop.org/bentiss/hid-tools/-/commits/wip/gamevice so we can ensure there is no regression for it, and that we will not regress on it later on. Cheers, Benjamin > > > Thanks! > > Chris > > > On 11/2/20 12:16 AM, Benjamin Tissoires wrote: > > Hi Chris, > > > > > > On Sun, Nov 1, 2020 at 8:35 PM Chris Ye wrote: > >> Generic Desktop DPAD usage is mapped by hid-input, that only the first > >> DPAD usage maps to usage type EV_ABS and code of an axis. If HID > >> descriptor has DPAD UP/DOWN/LEFT/RIGHT HID usages and each of usage size > >> is 1 bit, then only the first one will generate input event, the rest of > >> the HID usages will be assigned to hat direction only. > >> The hid input event should check the HID report value and generate > >> HID event for its hat direction. > >> > >> Test: Connect HID device with Generic Desktop DPAD usage and press the > >> DPAD to generate input events. > > Thanks for the patch, but I would rather have a proper tests added to > > https://gitlab.freedesktop.org/libevdev/hid-tools > > > > We already have gamepads tests, and it would be very nice to have this > > patch reflected as a test as well. This would also allow me to better > > understand the problem. I am not sure I follow the whole logic of this > > patch without seeing the 2 variants of report descriptors. > > > > Cheers, > > Benjamin > > > >> Signed-off-by: Chris Ye > >> --- > >> drivers/hid/hid-input.c | 16
Re: [PATCH v3 2/3] HID: i2c-hid: Allow subclasses of i2c-hid for power sequencing
Hi,
On Tue, Nov 3, 2020 at 10:09 AM Hans de Goede wrote:
>
> Hi,
>
> On 11/3/20 2:46 AM, Rob Herring wrote:
> > On Mon, Nov 2, 2020 at 6:13 PM Douglas Anderson
> > wrote:
> >>
> >> This exports some things from i2c-hid so that we can have a driver
> >> that's effectively a subclass of it and that can do its own power
> >> sequencing.
> >>
> >> Signed-off-by: Douglas Anderson
> >> ---
> >>
> >> Changes in v3:
> >> - Rework to use subclassing.
> >>
> >> Changes in v2:
> >> - Use a separate compatible string for this new touchscreen.
> >> - Get timings based on the compatible string.
> >>
> >> drivers/hid/i2c-hid/i2c-hid-core.c| 78 +--
> >> include/linux/input/i2c-hid-core.h| 19 +++
> >> include/linux/platform_data/i2c-hid.h | 9
> >> 3 files changed, 79 insertions(+), 27 deletions(-)
> >> create mode 100644 include/linux/input/i2c-hid-core.h
> >>
> >> diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c
> >> b/drivers/hid/i2c-hid/i2c-hid-core.c
> >> index 786e3e9af1c9..910e9089fcf8 100644
> >> --- a/drivers/hid/i2c-hid/i2c-hid-core.c
> >> +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
> >> @@ -22,6 +22,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include
> >> #include
> >> #include
> >> @@ -1007,8 +1008,33 @@ static void i2c_hid_fwnode_probe(struct i2c_client
> >> *client,
> >> pdata->post_power_delay_ms = val;
> >> }
> >>
> >> -static int i2c_hid_probe(struct i2c_client *client,
> >> -const struct i2c_device_id *dev_id)
> >> +static int i2c_hid_power_up_device(struct i2c_hid_platform_data *pdata)
> >> +{
> >> + struct i2c_hid *ihid = container_of(pdata, struct i2c_hid, pdata);
> >> + struct hid_device *hid = ihid->hid;
> >> + int ret;
> >> +
> >> + ret = regulator_bulk_enable(ARRAY_SIZE(pdata->supplies),
> >> + pdata->supplies);
> >> + if (ret) {
> >> + if (hid)
> >> + hid_warn(hid, "Failed to enable supplies: %d\n",
> >> ret);
> >> + return ret;
> >> + }
> >> +
> >> + if (pdata->post_power_delay_ms)
> >> + msleep(pdata->post_power_delay_ms);
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static void i2c_hid_power_down_device(struct i2c_hid_platform_data *pdata)
> >> +{
> >> + regulator_bulk_disable(ARRAY_SIZE(pdata->supplies),
> >> pdata->supplies);
> >> +}
> >> +
> >> +int i2c_hid_probe(struct i2c_client *client,
> >> + const struct i2c_device_id *dev_id)
> >> {
> >> int ret;
> >> struct i2c_hid *ihid;
> >> @@ -1035,6 +1061,9 @@ static int i2c_hid_probe(struct i2c_client *client,
> >> if (!ihid)
> >> return -ENOMEM;
> >>
> >> + if (platform_data)
> >> + ihid->pdata = *platform_data;
> >> +
> >> if (client->dev.of_node) {
> >> ret = i2c_hid_of_probe(client, >pdata);
> >> if (ret)
> >> @@ -1043,13 +1072,16 @@ static int i2c_hid_probe(struct i2c_client *client,
> >> ret = i2c_hid_acpi_pdata(client, >pdata);
> >> if (ret)
> >> return ret;
> >> - } else {
> >> - ihid->pdata = *platform_data;
> >> }
> >>
> >> /* Parse platform agnostic common properties from ACPI / device
> >> tree */
> >> i2c_hid_fwnode_probe(client, >pdata);
> >>
> >> + if (!ihid->pdata.power_up_device)
> >> + ihid->pdata.power_up_device = i2c_hid_power_up_device;
> >> + if (!ihid->pdata.power_down_device)
> >> + ihid->pdata.power_down_device = i2c_hid_power_down_device;
> >> +
> >> ihid->pdata.supplies[0].supply = "vdd";
> >> ihid->pdata.supplies[1].supply = "vddl";
> >>
> >> @@ -1059,14 +1091,10 @@ static int i2c_hid_probe(struct i2c_client *client,
> >> if (ret)
> >> return ret;
> >>
> >> - ret = regulator_bulk_enable(ARRAY_SIZE(ihid->pdata.supplies),
> >> - ihid->pdata.supplies);
> >> - if (ret < 0)
> >> + ret = ihid->pdata.power_up_device(>pdata);
> >> + if (ret)
> >
> > This is an odd driver structure IMO. I guess platform data is already
> > there, but that's not what we'd use for any new driver.
> >
> > Why not export i2c_hid_probe, i2c_hid_remove, etc. and then just call
> > them from the goodix driver and possibly make it handle all DT
> > platforms?
> >
> > Who else needs regulators besides DT platforms? I thought with ACPI
> > it's all wonderfully abstracted away?
>
> Right with ACPI we do not need the regulators, actually not checking
> for them with ACPI would be preferable, if only to suppress kernel
> messages like these:
>
> [3.515658] i2c_hid i2c-SYNA8007:00: supply vdd not found, using dummy
> regulator
> [3.515848] i2c_hid i2c-SYNA8007:00: supply vddl not found, using dummy
> regulator
>
> To be
Re: [PATCH v2] Input: Fix the HID usage of DPAD input event generation.
Hi Chris,
On Sun, Nov 1, 2020 at 8:35 PM Chris Ye wrote:
>
> Generic Desktop DPAD usage is mapped by hid-input, that only the first
> DPAD usage maps to usage type EV_ABS and code of an axis. If HID
> descriptor has DPAD UP/DOWN/LEFT/RIGHT HID usages and each of usage size
> is 1 bit, then only the first one will generate input event, the rest of
> the HID usages will be assigned to hat direction only.
> The hid input event should check the HID report value and generate
> HID event for its hat direction.
>
> Test: Connect HID device with Generic Desktop DPAD usage and press the
> DPAD to generate input events.
Thanks for the patch, but I would rather have a proper tests added to
https://gitlab.freedesktop.org/libevdev/hid-tools
We already have gamepads tests, and it would be very nice to have this
patch reflected as a test as well. This would also allow me to better
understand the problem. I am not sure I follow the whole logic of this
patch without seeing the 2 variants of report descriptors.
Cheers,
Benjamin
>
> Signed-off-by: Chris Ye
> ---
> drivers/hid/hid-input.c | 16
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index 9770db624bfa..6c1007de3409 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -1269,7 +1269,7 @@ void hidinput_hid_event(struct hid_device *hid, struct
> hid_field *field, struct
> struct input_dev *input;
> unsigned *quirks = >quirks;
>
> - if (!usage->type)
> + if (!usage->type && !field->dpad)
> return;
>
> if (usage->type == EV_PWR) {
> @@ -1286,9 +1286,17 @@ void hidinput_hid_event(struct hid_device *hid, struct
> hid_field *field, struct
> int hat_dir = usage->hat_dir;
> if (!hat_dir)
> hat_dir = (value - usage->hat_min) * 8 /
> (usage->hat_max - usage->hat_min + 1) + 1;
> - if (hat_dir < 0 || hat_dir > 8) hat_dir = 0;
> - input_event(input, usage->type, usage->code,
> hid_hat_to_axis[hat_dir].x);
> - input_event(input, usage->type, usage->code + 1,
> hid_hat_to_axis[hat_dir].y);
> + if (hat_dir < 0 || hat_dir > 8 || value == 0)
> + hat_dir = 0;
> + if (field->dpad) {
> + input_event(input, EV_ABS, field->dpad,
> hid_hat_to_axis[hat_dir].x);
> + input_event(input, EV_ABS, field->dpad + 1,
> hid_hat_to_axis[hat_dir].y);
> + } else {
> + input_event(input, usage->type, usage->code,
> + hid_hat_to_axis[hat_dir].x);
> + input_event(input, usage->type, usage->code + 1,
> + hid_hat_to_axis[hat_dir].y);
> + }
> return;
> }
>
> --
> 2.29.1.341.ge80a0c044ae-goog
>
Re: [PATCH v2 1/3] dt-bindings: HID: i2c-hid: Label this binding as deprecated
On Fri, Oct 30, 2020 at 7:00 PM Rob Herring wrote: > > On Fri, Oct 30, 2020 at 11:51:53AM +0100, Benjamin Tissoires wrote: > > Hi Doug, > > > > Foreword: I was about to say "yeah, whatever" to please Rob for once. > > Read my other reply first... I think we mostly agree. > > > But after re-reading this and more specifically patch 3 of the series, > > that won't do. More comments inlined. > > > > On Sat, Oct 24, 2020 at 1:23 AM Douglas Anderson > > wrote: > > > > > > As pointed out by Rob Herring [1], we should have a device-specific > > > compatible string. This means people shouldn't be using the > > > "i2c-over-hid" compatible string anymore, or at least not without a > > > more specific compatible string before it. Specifically: > > > > > > 1. For newly added devices we should just have the device-specific > > >device string (no "hid-over-i2c" fallback) and infer the timings > > >and hid-descr-addr from there. > > > > And that's a big NACK from a maintainer point of view. I know in the > > device tree world these strings are important so that people can just > > say "I have a device compatible with X", and go on, but in the HID > > world that means we will have to implement one compatible struct per > > vendor/device, which is not something I want to do. > > It's not really any different than PCI and USB VID/PIDs. Well, it is, because in the USB (HID) world, there is a specification that provides all of the entry points a device needs. In the i2c-hid case, the only entry point a device needs, in the ACPI world is one register address, and this is provided by ACPI itself. So in the ACPI world, for i2c-hid devices, we don't need to recompile the driver to support any current or new devices. > > > You can think of it as if you are suddenly saying that because it > > would be easier for a few particular USB devices that need a quirk, > > you "just" need to add the list of *all* USB HID devices that are > > around. i2c-hid should be a driver that doesn't change unless 2 things > > happen: > > - there is a change in the spec > > - there is a specific quirk required for a device that doesn't follow the > > spec. > > Or does something outside of what the spec covers. This is solved in the ACPI case by running ACPI callbacks, and I am more and more thinking we should mimic that for DT devices. > > > So if having device tree support for these means we suddenly need to > > add every single device around in the compatible table, I would be > > tempted to just drop the support for those new devices. > > > > Again, you (or anyone else) have to understand that the descriptor > > address is just a parameter which is known at the manufacturing time, > > but that can vary with different vendors and or products. In the ACPI > > world, this parameter is provided in the DSDT, and there is no reason > > for it to not be provided in the DT. > > Whether that makes sense as a standard 'hid-over-i2c' property is a > separate discussion. Seems like it might be. Actually it is not TBH. The spec doesn't mention that sleep time (or the reset line FWIW), so it shouldn't even be seen by i2c-hid. But I accepted maybe too much parametrization on i2c-hid, and now is probably the time we take a step back and rewrite the code that goes out of spec. > > It's trying to parameterize power sequencing to be generic and a never > ending stream of quirk property additions that I'm against. That's based > on the mistake of accepting those to some point in the past. > hid-over-i2c is not special here. Ack > > If we wanted to parameterize power control/sequences in DT, then we'd > need to handle any number of controls (GPIO, regulators, clocks, power > domains, register poking, firmware loading, etc.) in any order and > amounts of time in between. What we'd end up needing is some programming > language in DT (Forth anyone?). Understood, and we are hitting the exact same problem here. The only difference is that i2c-hid is already generic for anything but power/reset, and this is what we are vehemently agreeing here :P > > > The last thing I want to see is people using device tree having to > > recompile i2c-hid to register their own device. > > That's fine if they don't need extra things like power control... > > > If this part of the Device Tree binding is so important for the DT > > world, then we should split up the DT bindings from i2c-hid, and have > > some platform driver that would handle a conversion between devicetree > > and platform data. But this driver won't be maintained by me
Re: [PATCH v2 3/3] HID: i2c-hid: Support the Goodix GT7375P touchscreen
Hi Doug,
On Sat, Oct 24, 2020 at 1:23 AM Douglas Anderson wrote:
>
> The Goodix GT7375P touchscreen uses i2c-hid so we can support it with
> just a few changes to the i2c-hid driver. Specifically this
> touchscreen needs to control a reset GPIO during its power sequencing.
>
> The Goodix timing diagram shows this:
>
> +--
> |
> AVDD +
>+--
> | (a) |
> RESET -+
> +-
>| (b) |
> I2C comm OK -+
>
> Where (a) is 10 ms and (b) is 120 ms.
These timing issues always bother me. Is there any hint that this
particular touchscreen model is "certified" for a Windows usage?
Because if so, then we might as well mimic the timings the Windows
driver is doing instead of adding parameters for every single device.
>
> While we could just add some properties and specify this generically
> in the device tree, the guidance from the device tree maintainer is
> that it's better to list the specific model and infer everything from
> there. Thus that's what this patch implements.
>
> Signed-off-by: Douglas Anderson
> ---
>
> Changes in v2:
> - Use a separate compatible string for this new touchscreen.
> - Get timings based on the compatible string.
>
> drivers/hid/i2c-hid/i2c-hid-core.c| 50 ++-
> include/linux/platform_data/i2c-hid.h | 5 +++
> 2 files changed, 54 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c
> b/drivers/hid/i2c-hid/i2c-hid-core.c
> index 786e3e9af1c9..0b2cd78b05e1 100644
> --- a/drivers/hid/i2c-hid/i2c-hid-core.c
> +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
> @@ -71,6 +71,12 @@ do {
> \
> dev_printk(KERN_DEBUG, &(ihid)->client->dev, fmt, ##arg); \
> } while (0)
>
> +struct i2c_hid_match_data {
> + u16 hid_descriptor_address;
> + int post_power_delay_ms;
> + int post_gpio_reset_delay_ms;
> +};
> +
> struct i2c_hid_desc {
> __le16 wHIDDescLength;
> __le16 bcdVersion;
> @@ -962,6 +968,21 @@ static inline void i2c_hid_acpi_enable_wakeup(struct
> device *dev) {}
> #endif
>
> #ifdef CONFIG_OF
> +static bool i2c_hid_init_from_of_match(struct device *dev,
> + struct i2c_hid_platform_data *pdata)
> +{
> + const struct i2c_hid_match_data *match_data =
> device_get_match_data(dev);
> +
> + if (!match_data)
> + return false;
> +
> + pdata->hid_descriptor_address = match_data->hid_descriptor_address;
> + pdata->post_power_delay_ms = match_data->post_power_delay_ms;
> + pdata->post_gpio_reset_delay_ms =
> match_data->post_gpio_reset_delay_ms;
> +
> + return true;
> +}
> +
> static int i2c_hid_of_probe(struct i2c_client *client,
> struct i2c_hid_platform_data *pdata)
> {
> @@ -969,6 +990,11 @@ static int i2c_hid_of_probe(struct i2c_client *client,
> u32 val;
> int ret;
>
> + /* Try getting everything based on the compatible string first */
> + if (i2c_hid_init_from_of_match(>dev, pdata))
> + return 0;
> +
> + /* Fallback to getting hid-descr-addr from a property */
> ret = of_property_read_u32(dev->of_node, "hid-descr-addr", );
> if (ret) {
> dev_err(>dev, "HID register address not provided\n");
> @@ -984,8 +1010,15 @@ static int i2c_hid_of_probe(struct i2c_client *client,
> return 0;
> }
>
> +static const struct i2c_hid_match_data goodix_gt7375p_match_data = {
> + .hid_descriptor_address = 0x0001,
Nah, please don't. See 1/3 of this series.
> + .post_power_delay_ms = 10,
> + .post_gpio_reset_delay_ms = 120,
> +};
> +
> static const struct of_device_id i2c_hid_of_match[] = {
> - { .compatible = "hid-over-i2c" },
> + { .compatible = "goodix,gt7375p", .data = _gt7375p_match_data
> },
> + { .compatible = "hid-over-i2c" }, /* Deprecated */
> {},
> };
> MODULE_DEVICE_TABLE(of, i2c_hid_of_match);
> @@ -1053,6 +1086,12 @@ static int i2c_hid_probe(struct i2c_client *client,
> ihid->pdata.supplies[0].supply = "vdd";
> ihid->pdata.supplies[1].supply = "vddl";
>
> + /* Start out with reset asserted */
> + ihid->pdata.reset_gpio =
> + devm_gpiod_get_optional(>dev, "reset",
> GPIOD_OUT_HIGH);
> + if (IS_ERR(ihid->pdata.reset_gpio))
> + return PTR_ERR(ihid->pdata.reset_gpio);
> +
That gpio change should go into its own commit. The commit briefly
mentioned this, but we could get more information on it, because this
is modifying the common probe path.
[... re-reading, thinking later ...]
Well, the whole point of this patch is for that specific GPIO. And I
am really not happy having that merged here:
what if suddenly we have another device that has a reset line that
requires a
Re: [PATCH v2 2/3] dt-bindings: HID: i2c-hid: Introduce bindings for the Goodix GT7375P
Hi Doug,
On Sat, Oct 24, 2020 at 1:23 AM Douglas Anderson wrote:
>
> This adds new bindings for the Goodix GT7375P touchscreen. While this
> touchscreen works with generic "i2c-over-hid", the current advice is
> to give it its own compatible string. The cleanest way to do this is
> to give it its own bindings.
>
> Among other things, this has the advantage that we can list the two
> possible i2c addresses for this device, which gives extra checking.
>
> Signed-off-by: Douglas Anderson
> ---
>
> Changes in v2:
> - ("dt-bindings: HID: i2c-hid: Introduce bindings for the Goodix GT7375P")
> new in v2.
>
> .../bindings/input/goodix,gt7375p.yaml| 64 +++
> 1 file changed, 64 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/input/goodix,gt7375p.yaml
>
> diff --git a/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml
> b/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml
> new file mode 100644
> index ..b5008f89e26c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/goodix,gt7375p.yaml
> @@ -0,0 +1,64 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/input/goodix,gt7375p.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Goodix GT7375P touchscreen
> +
> +maintainers:
> + - Benjamin Tissoires
Given my answer in patch 1, I am not very happy being added as a
maintainer here.
Cheers,
Benjamin
> + - Douglas Anderson
> +
> +description:
> + Supports the Goodix GT7375P touchscreen.
> +
> +properties:
> + compatible:
> +items:
> + - const: goodix,gt7375p
> +
> + reg:
> +enum:
> + - 0x5d
> + - 0x14
> +
> + interrupts:
> +maxItems: 1
> +
> + reset-gpios:
> +true
> +
> + vdd-supply:
> +description: The 3.3V supply to the touchscreen.
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - reset-gpios
> + - vdd-supply
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +#include
> +#include
> +#include
> +
> +i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + ap_ts: touchscreen@5d {
> +compatible = "hid-over-i2c";
> +reg = <0x5d>;
> +
> +interrupt-parent = <>;
> +interrupts = <9 IRQ_TYPE_LEVEL_LOW>;
> +
> +reset-gpios = < 8 GPIO_ACTIVE_LOW>;
> +vdd-supply = <_ts>;
> + };
> +};
> --
> 2.29.0.rc1.297.gfa9743e501-goog
>
Re: [PATCH v2 1/3] dt-bindings: HID: i2c-hid: Label this binding as deprecated
Hi Doug,
Foreword: I was about to say "yeah, whatever" to please Rob for once.
But after re-reading this and more specifically patch 3 of the series,
that won't do. More comments inlined.
On Sat, Oct 24, 2020 at 1:23 AM Douglas Anderson wrote:
>
> As pointed out by Rob Herring [1], we should have a device-specific
> compatible string. This means people shouldn't be using the
> "i2c-over-hid" compatible string anymore, or at least not without a
> more specific compatible string before it. Specifically:
>
> 1. For newly added devices we should just have the device-specific
>device string (no "hid-over-i2c" fallback) and infer the timings
>and hid-descr-addr from there.
And that's a big NACK from a maintainer point of view. I know in the
device tree world these strings are important so that people can just
say "I have a device compatible with X", and go on, but in the HID
world that means we will have to implement one compatible struct per
vendor/device, which is not something I want to do.
You can think of it as if you are suddenly saying that because it
would be easier for a few particular USB devices that need a quirk,
you "just" need to add the list of *all* USB HID devices that are
around. i2c-hid should be a driver that doesn't change unless 2 things
happen:
- there is a change in the spec
- there is a specific quirk required for a device that doesn't follow the spec.
So if having device tree support for these means we suddenly need to
add every single device around in the compatible table, I would be
tempted to just drop the support for those new devices.
Again, you (or anyone else) have to understand that the descriptor
address is just a parameter which is known at the manufacturing time,
but that can vary with different vendors and or products. In the ACPI
world, this parameter is provided in the DSDT, and there is no reason
for it to not be provided in the DT.
The last thing I want to see is people using device tree having to
recompile i2c-hid to register their own device.
If this part of the Device Tree binding is so important for the DT
world, then we should split up the DT bindings from i2c-hid, and have
some platform driver that would handle a conversion between devicetree
and platform data. But this driver won't be maintained by me.
I agree adding the various sleep parameters in the platform data is
not good, but I prefer that over having to maintain an endless table
of parameters for every single i2c-hid device out there.
Cheers,
Benjamin
>
> 2. If there's a need for a device tree to be backward compatible, we
>should list the device-specific compatible string and add the
>"hid-over-i2c" fallback and the various timings.
>
> [1] https://lore.kernel.org/r/20201019211036.GA3595039@bogus
>
> Signed-off-by: Douglas Anderson
> ---
>
> Changes in v2:
> - ("dt-bindings: HID: i2c-hid: Label this binding as deprecated") new in v2.
>
> Documentation/devicetree/bindings/input/hid-over-i2c.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/hid-over-i2c.txt
> b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
> index c76bafaf98d2..733a5f053280 100644
> --- a/Documentation/devicetree/bindings/input/hid-over-i2c.txt
> +++ b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
> @@ -1,5 +1,8 @@
> * HID over I2C Device-Tree bindings
>
> +WARNING: this binding is deprecated. Instead of using this, create specific
> +bindings for each hid-over-i2c device.
> +
> HID over I2C provides support for various Human Interface Devices over the
> I2C bus. These devices can be for example touchpads, keyboards, touch screens
> or sensors.
> --
> 2.29.0.rc1.297.gfa9743e501-goog
>
[PATCH] input - elantech: force query XY range after absolute mode
For some v3 hw versions, if the ETP_FW_ID_QUERY command is
issued before the call to set_absolute_mode(), the returned
values are wrong.
Force an other ETP_FW_ID_QUERY after set_absolute_mode()
to get correct values.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=209027
Cc: sta...@vger.kernel.org # 5.3+
Signed-off-by: Benjamin Tissoires
---
drivers/input/mouse/elantech.c | 161 +++--
1 file changed, 91 insertions(+), 70 deletions(-)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index 90f8765f9efc..ff8e5fb61dab 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -1593,80 +1593,12 @@ static int elantech_set_properties(struct
elantech_device_info *info)
return 0;
}
-static int elantech_query_info(struct psmouse *psmouse,
- struct elantech_device_info *info)
+static int elantech_get_range(struct psmouse *psmouse,
+ struct elantech_device_info *info)
{
unsigned char param[3];
unsigned char traces;
- memset(info, 0, sizeof(*info));
-
- /*
-* Do the version query again so we can store the result
-*/
- if (synaptics_send_cmd(psmouse, ETP_FW_VERSION_QUERY, param)) {
- psmouse_err(psmouse, "failed to query firmware version.\n");
- return -EINVAL;
- }
- info->fw_version = (param[0] << 16) | (param[1] << 8) | param[2];
-
- if (elantech_set_properties(info)) {
- psmouse_err(psmouse, "unknown hardware version, aborting...\n");
- return -EINVAL;
- }
- psmouse_info(psmouse,
-"assuming hardware version %d (with firmware version
0x%02x%02x%02x)\n",
-info->hw_version, param[0], param[1], param[2]);
-
- if (info->send_cmd(psmouse, ETP_CAPABILITIES_QUERY,
- info->capabilities)) {
- psmouse_err(psmouse, "failed to query capabilities.\n");
- return -EINVAL;
- }
- psmouse_info(psmouse,
-"Synaptics capabilities query result 0x%02x, 0x%02x,
0x%02x.\n",
-info->capabilities[0], info->capabilities[1],
-info->capabilities[2]);
-
- if (info->hw_version != 1) {
- if (info->send_cmd(psmouse, ETP_SAMPLE_QUERY, info->samples)) {
- psmouse_err(psmouse, "failed to query sample data\n");
- return -EINVAL;
- }
- psmouse_info(psmouse,
-"Elan sample query result %02x, %02x, %02x\n",
-info->samples[0],
-info->samples[1],
-info->samples[2]);
- }
-
- if (info->samples[1] == 0x74 && info->hw_version == 0x03) {
- /*
-* This module has a bug which makes absolute mode
-* unusable, so let's abort so we'll be using standard
-* PS/2 protocol.
-*/
- psmouse_info(psmouse,
-"absolute mode broken, forcing standard PS/2
protocol\n");
- return -ENODEV;
- }
-
- /* The MSB indicates the presence of the trackpoint */
- info->has_trackpoint = (info->capabilities[0] & 0x80) == 0x80;
-
- info->x_res = 31;
- info->y_res = 31;
- if (info->hw_version == 4) {
- if (elantech_get_resolution_v4(psmouse,
- >x_res,
- >y_res,
- >bus)) {
- psmouse_warn(psmouse,
-"failed to query resolution data.\n");
- }
- }
-
- /* query range information */
switch (info->hw_version) {
case 1:
info->x_min = ETP_XMIN_V1;
@@ -1745,6 +1677,87 @@ static int elantech_query_info(struct psmouse *psmouse,
break;
}
+ return 0;
+}
+
+static int elantech_query_info(struct psmouse *psmouse,
+ struct elantech_device_info *info)
+{
+ unsigned char param[3];
+ int error;
+
+ memset(info, 0, sizeof(*info));
+
+ /*
+* Do the version query again so we can store the result
+*/
+ if (synaptics_send_cmd(psmouse, ETP_FW_VERSION_QUERY, param)) {
+ psmouse_err(psmouse, "failed to query firmware version.\n");
+ return -EINVAL;
+ }
+ info->fw_version = (param[0] << 16) | (param[1] << 8) | param[2];
+
+ if (elantech_set_properties(info)) {
+ psmouse_
Re: [PATCH v4] HID: core: Sanitize event code and type when mapping input
On Tue, Sep 1, 2020 at 11:52 AM Marc Zyngier wrote:
>
> When calling into hid_map_usage(), the passed event code is
> blindly stored as is, even if it doesn't fit in the associated bitmap.
>
> This event code can come from a variety of sources, including devices
> masquerading as input devices, only a bit more "programmable".
>
> Instead of taking the event code at face value, check that it actually
> fits the corresponding bitmap, and if it doesn't:
> - spit out a warning so that we know which device is acting up
> - NULLify the bitmap pointer so that we catch unexpected uses
>
> Code paths that can make use of untrusted inputs can now check
> that the mapping was indeed correct and bail out if not.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Marc Zyngier
> ---
Pushed to for-5.9/upstream-fixes
Cheers,
Benjamin
> * From v3:
> - Drop totally unrelated mfd/syscon change from the patch
>
> * From v2:
> - Don't prematurely narrow the event code so that hid_map_usage()
> catches illegal values beyond the 16bit limit.
>
> * From v1:
> - Dropped the input.c changes, and turned hid_map_usage() into
> the validation primitive.
> - Handle mapping failures in hidinput_configure_usage() and
> mt_touch_input_mapping() (on top of hid_map_usage_clear() which
> was already handled)
>
> drivers/hid/hid-input.c | 4
> drivers/hid/hid-multitouch.c | 2 ++
> include/linux/hid.h | 42 +---
> 3 files changed, 35 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index b8eabf206e74..88e19996427e 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -1132,6 +1132,10 @@ static void hidinput_configure_usage(struct hid_input
> *hidinput, struct hid_fiel
> }
>
> mapped:
> + /* Mapping failed, bail out */
> + if (!bit)
> + return;
> +
> if (device->driver->input_mapped &&
> device->driver->input_mapped(device, hidinput, field, usage,
> , ) < 0) {
> diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> index 3f94b4954225..e3152155c4b8 100644
> --- a/drivers/hid/hid-multitouch.c
> +++ b/drivers/hid/hid-multitouch.c
> @@ -856,6 +856,8 @@ static int mt_touch_input_mapping(struct hid_device
> *hdev, struct hid_input *hi,
> code = BTN_0 + ((usage->hid - 1) & HID_USAGE);
>
> hid_map_usage(hi, usage, bit, max, EV_KEY, code);
> + if (!*bit)
> + return -1;
> input_set_capability(hi->input, EV_KEY, code);
> return 1;
>
> diff --git a/include/linux/hid.h b/include/linux/hid.h
> index 875f71132b14..c7044a14200e 100644
> --- a/include/linux/hid.h
> +++ b/include/linux/hid.h
> @@ -959,34 +959,49 @@ static inline void hid_device_io_stop(struct hid_device
> *hid) {
> * @max: maximal valid usage->code to consider later (out parameter)
> * @type: input event type (EV_KEY, EV_REL, ...)
> * @c: code which corresponds to this usage and type
> + *
> + * The value pointed to by @bit will be set to NULL if either @type is
> + * an unhandled event type, or if @c is out of range for @type. This
> + * can be used as an error condition.
> */
> static inline void hid_map_usage(struct hid_input *hidinput,
> struct hid_usage *usage, unsigned long **bit, int *max,
> - __u8 type, __u16 c)
> + __u8 type, unsigned int c)
> {
> struct input_dev *input = hidinput->input;
> -
> - usage->type = type;
> - usage->code = c;
> + unsigned long *bmap = NULL;
> + unsigned int limit = 0;
>
> switch (type) {
> case EV_ABS:
> - *bit = input->absbit;
> - *max = ABS_MAX;
> + bmap = input->absbit;
> + limit = ABS_MAX;
> break;
> case EV_REL:
> - *bit = input->relbit;
> - *max = REL_MAX;
> + bmap = input->relbit;
> + limit = REL_MAX;
> break;
> case EV_KEY:
> - *bit = input->keybit;
> - *max = KEY_MAX;
> + bmap = input->keybit;
> + limit = KEY_MAX;
> break;
> case EV_LED:
> - *bit = input->ledbit;
> - *max = LED_MAX;
> + bmap = input->ledbit;
> + limit = LED_MAX;
> break;
> }
> +
> + if (unlikely(c > limit || !bmap)) {
> + pr_warn_ratelimited("%s: Invalid code %d type %d\n",
> + input->name, c, type);
> + *bit = NULL;
> + return;
> + }
> +
> + usage->type = type;
> + usage->code = c;
> + *max = limit;
> + *bit = bmap;
> }
>
> /**
> @@ -1000,7 +1015,8 @@ static inline void
Re: [PATCH v2] HID: core: Sanitize event code and type when mapping input
On Thu, Aug 27, 2020 at 11:33 AM Jiri Kosina wrote: > > On Wed, 26 Aug 2020, Marc Zyngier wrote: > > > When calling into hid_map_usage(), the passed event code is > > blindly stored as is, even if it doesn't fit in the associated bitmap. > > > > This event code can come from a variety of sources, including devices > > masquerading as input devices, only a bit more "programmable". > > > > Instead of taking the event code at face value, check that it actually > > fits the corresponding bitmap, and if it doesn't: > > - spit out a warning so that we know which device is acting up > > - NULLify the bitmap pointer so that we catch unexpected uses > > > > Code paths that can make use of untrusted inputs can now check > > that the mapping was indeed correct and bail out if not. > > > > Cc: sta...@vger.kernel.org > > Signed-off-by: Marc Zyngier > > --- > > * From v1: > > - Dropped the input.c changes, and turned hid_map_usage() into > > the validation primitive. > > - Handle mapping failures in hidinput_configure_usage() and > > mt_touch_input_mapping() (on top of hid_map_usage_clear() which > > was already handled) > > Benjamin, could you please run this through your regression testing > machinery? > > It's a non-trivial core change, at the same time I'd like not to postpone > it for 5.10 due to its nature. OK, just passed the v4 to the testsuite, and this seems good. It won't break touchscreens nor keyboards/mice that needed to be added in the past. So this is a go for me. Cheers, Benjamin > > Thanks, > > -- > Jiri Kosina > SUSE Labs >
Re: [PATCH] HID: core: Correctly handle ReportSize being zero
On Tue, Sep 1, 2020 at 10:14 AM Jiri Kosina wrote: > > On Sat, 29 Aug 2020, Marc Zyngier wrote: > > > It appears that a ReportSize value of zero is legal, even if a bit > > non-sensical. Most of the HID code seems to handle that gracefully, > > except when computing the total size in bytes. When fed as input to > > memset, this leads to some funky outcomes. > > > > Detect the corner case and correctly compute the size. > > > > Cc: sta...@vger.kernel.org > > Signed-off-by: Marc Zyngier > > Thanks Marc; Benjamin will be pushing this patch through his regression > testing machinery, and if all is good, I'll push it for 5.9-rc still. Test results were good. I have now pushed this patch to for-5.9/upstream-fixes Cheers, Benjamin > > -- > Jiri Kosina > SUSE Labs >
Re: [PATCH v7] hwmon: add Corsair Commander Pro driver
On Tue, Jul 7, 2020 at 12:20 PM Jiri Kosina wrote: > > On Mon, 29 Jun 2020, Guenter Roeck wrote: > > > On Fri, Jun 26, 2020 at 07:59:36AM +0200, Marius Zachmann wrote: > > > This is v7 of a driver for the Corsair Commander Pro. > > > It provides sysfs attributes for: > > > - Reading fan speed > > > - Reading temp sensors > > > - Reading voltage values > > > - Writing pwm and reading last written pwm > > > - Reading fan and temp connection status > > > > > > It is an usb driver, so it needs to be ignored by usbhid. > > > The Corsair Commander Pro is a fan controller and provides > > > no means for user interaction. > > > The two device numbers are there, because there is a slightly > > > different version of the same device. (Only difference > > > seem to be in some presets.) > > > > > > This is based on the staging/hwmon tree. > > > > > > Signed-off-by: Marius Zachmann > > > > For my reference: > > > > Reviewed-by: Guenter Roeck > > > > Waiting for Ack from HID maintainer. > > Acked-by: Jiri Kosina Sorry I missed this too: Acked-by: Benjamin Tissoires for the HID hunk too. Cheers, Benjamin > > for the drivers/hid/hid-quirks.c hunk. Thanks, > > -- > Jiri Kosina > SUSE Labs >
Re: [PATCH v4 1/3] input: add to hid_ignore_list
Hi Marius,
On Wed, Jun 24, 2020 at 10:16 AM Marius Zachmann wrote:
>
> Signed-off-by: Marius Zachmann
I wasn't Cc-ed on the cover letter (0/3) if any, but there are a few
things to improve here (not code wise, I haven't reviewed the series,
but on the form).
Every commit needs a commit message. And here, this particular commit
just disables 2 device IDs from HID, which, without explanation seems
like you decided to remove support for 2 keyboards from the kernel. So
please add commit messages explaining *why* you are introducing a new
driver/change in the code.
Then, it would be much better to have a single commit that disables
the HID support and add the hwmon driver in one go. Leave the
synchronisation between the trees to the maintainers, and keep it
simple: you can squash your 3 commits together, so it's one semantic
action. This way, if there is a need to bisect or revert this patch,
we won't have side effects and can revert just one patch. Think also
that if someone needs that to be backported in a stable or a
distribution kernel, it would make everyone's life simpler.
That being said, if you squash the 3 patches and provide a good enough
explanation on the series, from a HID point of view, there should not
be any reasons for us to not give an Ack.
Cheers,
Benjamin
> ---
> drivers/hid/hid-quirks.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
> index ca8b5c261c7c..7b7bc7737c53 100644
> --- a/drivers/hid/hid-quirks.c
> +++ b/drivers/hid/hid-quirks.c
> @@ -699,6 +699,8 @@ static const struct hid_device_id hid_ignore_list[] = {
> { HID_USB_DEVICE(USB_VENDOR_ID_AXENTIA,
> USB_DEVICE_ID_AXENTIA_FM_RADIO) },
> { HID_USB_DEVICE(USB_VENDOR_ID_BERKSHIRE,
> USB_DEVICE_ID_BERKSHIRE_PCWD) },
> { HID_USB_DEVICE(USB_VENDOR_ID_CIDC, 0x0103) },
> + { HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR, 0x0c10) },
> + { HID_USB_DEVICE(USB_VENDOR_ID_CORSAIR, 0x1d00) },
> { HID_USB_DEVICE(USB_VENDOR_ID_CYGNAL,
> USB_DEVICE_ID_CYGNAL_RADIO_SI470X) },
> { HID_USB_DEVICE(USB_VENDOR_ID_CYGNAL,
> USB_DEVICE_ID_CYGNAL_RADIO_SI4713) },
> { HID_USB_DEVICE(USB_VENDOR_ID_CMEDIA, USB_DEVICE_ID_CM109) },
> --
> 2.27.0
>
Re: linux-next: build failures after merge of the hid tree
[adding Cristian, the author of the patch]
On Tue, Jun 23, 2020 at 2:37 AM Stephen Rothwell wrote:
>
> Hi all,
>
> On Sun, 21 Jun 2020 14:04:21 +1000 Stephen Rothwell
> wrote:
> >
> > After merging the hid tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> >
> > drivers/hid/intel-ish-hid/ipc/ipc.c:12:10: fatal error: client.h: No such
> > file or directory
> >12 | #include "client.h"
> > | ^~
> > drivers/hid/intel-ish-hid/ipc/pci-ish.c:22:10: fatal error: ishtp-dev.h: No
> > such file or directory
> >22 | #include "ishtp-dev.h"
> > | ^
> >
> > I don't know what caused it, but commit
> >
> > 470376737e88 ("HID: allow building hid.ko as an external module")
I am under the impression that this patch is causing the issue.
I am tempted to revert it (and force push the branch hid/for-5.9/core)
given that the 0-day bot also complained.
> >
> > did not fix it. BTW, I build with "make O=...".
> >
> > I have used the hid tree from next-20200618 for today.
> >
> > BTW, the hid tree really needs cleaning up, it contains merge commits dating
> > back to April 2018 :-(
We are carefully not force pushing the hid/for-next branch, and all
the merges you are seeing there are the various merges we do after
including a patch that will be sent to linus later. Our for-next
branch never gets merged into for-linus, we handle that separately.
I always thought you prefer not having forced push on the for-next
branch. But if you rather us overwriting the tip of the branch at
every commit, we can do it for sure.
For reference, the way we handle branches are:
- master branch follows Linus' when there is an upstream merge of the
hid/for-linus branch
- every single commit goes into a branch named
for-/
- those branches are created on top of current master and are never rebased
- every time we add a patch (series) on top of a feature branch, we
merge that into hid/for-next
- when we need to send a pull request to Linus, we merge the matching
"for-/*" branches into hid/for-linus
This allows to keep a clear view of what is scheduled to be sent. But
the counterpart is that the hid/for-next branch never gets merged back
into hid/for-linus.
Cheers,
Benjamin
> >
> > $ git rev-list --count origin/master..hid/for-next
> > 301
> > $ git rev-list --no-merges --count origin/master..hid/for-next
> > 12
>
> I am still getting this failure.
>
> --
> Cheers,
> Stephen Rothwell
Re: [PATCH] HID: usbhid: do not sleep when opening device
On Mon, Jun 1, 2020 at 7:13 PM Jiri Kosina wrote:
>
> On Fri, 29 May 2020, Dmitry Torokhov wrote:
>
> > > > > > > usbhid tries to give the device 50 milliseconds to drain its
> > > > > > > queues
> > > > > > > when opening the device, but does it naively by simply sleeping
> > > > > > > in open
> > > > > > > handler, which slows down device probing (and thus may affect
> > > > > > > overall
> > > > > > > boot time).
> > > > > > >
> > > > > > > However we do not need to sleep as we can instead mark a point of
> > > > > > > time
> > > > > > > in the future when we should start processing the events.
> > > > > > >
> > > > > > > Reported-by: Nicolas Boichat
> > > > > > > Signed-off-by: Dmitry Torokhov
> > > > > > > ---
> > > > > > > drivers/hid/usbhid/hid-core.c | 27 +++
> > > > > > > drivers/hid/usbhid/usbhid.h | 1 +
> > > > > > > 2 files changed, 16 insertions(+), 12 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/hid/usbhid/hid-core.c
> > > > > > > b/drivers/hid/usbhid/hid-core.c
> > > > > > > index c7bc9db5b192..e69992e945b2 100644
> > > > > > > --- a/drivers/hid/usbhid/hid-core.c
> > > > > > > +++ b/drivers/hid/usbhid/hid-core.c
> > > > > > > @@ -95,6 +95,19 @@ static int hid_start_in(struct hid_device *hid)
> > > > > > > set_bit(HID_NO_BANDWIDTH,
> > > > > > > >iofl);
> > > > > > > } else {
> > > > > > > clear_bit(HID_NO_BANDWIDTH,
> > > > > > > >iofl);
> > > > > > > +
> > > > > > > + if (test_and_clear_bit(HID_RESUME_RUNNING,
> > > > > > > + >iofl)) {
> > > > > > > + /*
> > > > > > > +* In case events are generated
> > > > > > > while nobody was
> > > > > > > +* listening, some are released
> > > > > > > when the device
> > > > > > > +* is re-opened. Wait 50 msec for
> > > > > > > the queue to
> > > > > > > +* empty before allowing events
> > > > > > > to go through
> > > > > > > +* hid.
> > > > > > > +*/
> > > > > > > + usbhid->input_start_time =
> > > > > > > jiffies +
> > > > > > > +
> > > > > > > msecs_to_jiffies(50);
> > > > > > > + }
> > > > > > > }
> > > > > > > }
> > > > > > > spin_unlock_irqrestore(>lock, flags);
> > > > > > > @@ -280,7 +293,8 @@ static void hid_irq_in(struct urb *urb)
> > > > > > > if (!test_bit(HID_OPENED, >iofl))
> > > > > > > break;
> > > > > > > usbhid_mark_busy(usbhid);
> > > > > > > - if (!test_bit(HID_RESUME_RUNNING, >iofl))
> > > > > > > {
> > > > > > > + if (!test_bit(HID_RESUME_RUNNING, >iofl)
> > > > > > > &&
> > > > > > > + time_after(jiffies,
> > > > > > > usbhid->input_start_time)) {
> > > > > >
> > > > > > Are we worried about jiffies overflowing (32-bit@1000Hz is "only"
> > > > > > 49.7 days...)
> > > > > >
> > > > >
> > > > > time_after() is overflow-safe. That is why it is used and jiffies is
> > > > > not compared directly.
> > > >
> > > > Well, it is overflow safe, but still can not measure more than 50 days,
> > > > so if you have a device open for 50+ days there will be a 50msec gap
> > > > where it may lose events.
> > > >
> > >
> > > Or you could explicitly use 64-bit jiffies.
> >
> > Indeed.
> >
> > Jiri, Benjamin, do you have preference between jiffies64 and ktime_t? I
> > guess jiffies64 is a tiny bit less expensive.
>
> If I would be writing the code, I'd use ktime_t, because I personally like
> that abstraction more :) But either variant works for me.
I don't have a strong opinion on either variant. Feel free to use
whatever you like the most.
Cheers,
Benjamin
>
> Thanks!
>
> --
> Jiri Kosina
> SUSE Labs
>
Re: [PATCH] HID: multitouch: Remove MT_CLS_WIN_8_DUAL
On Wed, May 27, 2020 at 11:24 AM Benjamin Tissoires
wrote:
>
> On Wed, May 27, 2020 at 8:19 AM Kai-Heng Feng
> wrote:
> >
> >
> >
> > > On May 26, 2020, at 16:43, Benjamin Tissoires
> > > wrote:
> > >
> > > On Tue, May 26, 2020 at 10:24 AM Jiri Kosina wrote:
> > >>
> > >> On Tue, 14 Apr 2020, Kai-Heng Feng wrote:
> > >>
> > >>> After commit c23e2043d5f7 ("HID: multitouch: do not filter mice nodes"),
> > >>> MT_CLS_WIN_8 also supports mouse nodes, hence make MT_CLS_WIN_8_DUAL
> > >>> redundant.
> > >>>
> > >>> Remove MT_CLS_WIN_8_DUAL accordingly.
> > >>
> > >> Benjamin, can I get your Ack on this one please?
> > >
> > > Heh, funny enough I was trying to fix
> > > https://bugzilla.kernel.org/show_bug.cgi?id=207235 and was pondering
> > > this one too.
> > >
> > > To fix #207235, I'll likely need to add a new class and quirk in
> > > hid-multitouch. I can't really find a generic solution for now, and we
> > > better have a local quirk for the 2 devices we currently have and
> > > backport those to stable. However, this patch will likely conflict
> > > (trivially), with the new quirks, so I was thinking:
> > > - submitting my quick and dirty quirk and mark it to stable
> > > - apply this one on top of it (this one really doesn't need to go to
> > > stable)
> > >
> > > How does that sound?
> >
> > Sounds good. I'll resend this patch once your patch lands in the tree.
>
> Great, thanks. Though I should be able to rebase it and push it
> directly. I'll notify you if I can't get to it today.
Alright, rebased and pushed to for-5.8/multitouch.
Thanks a lot.
Cheers,
Benjamin
>
> Cheers,
> Benjamin
>
> >
> > Kai-Heng
> >
> > >
> > > Cheers,
> > > Benjamin
> > >
> > >>
> > >> Thanks,
> > >>
> > >> --
> > >> Jiri Kosina
> > >> SUSE Labs
> > >>
> > >
> >
Re: [PATCH] HID: multitouch: enable multi-input as a quirk for some devices
On Wed, May 27, 2020 at 11:22 AM Benjamin Tissoires
wrote:
>
> On Wed, May 27, 2020 at 8:18 AM Kai-Heng Feng
> wrote:
> >
> >
> >
> > > On May 26, 2020, at 23:07, Benjamin Tissoires
> > > wrote:
> > >
> > > Two touchpad/trackstick combos are currently not behaving properly.
> > > They define a mouse emulation collection, as per Win8 requirements,
> > > but also define a separate mouse collection for the trackstick.
> > >
> > > The way the kernel currently treat the collections is that it
> > > merges both in one device. However, given that the first mouse
> > > collection already defines X,Y and left, right buttons, when
> > > mapping the events from the second mouse collection, hid-multitouch
> > > sees that these events are already mapped, and simply ignores them.
> > >
> > > To be able to report events from the tracktick, add a new quirked
> > > class for it, and manually add the 2 devices we know about.
> > >
> > > Link: https://bugzilla.kernel.org/show_bug.cgi?id=207235
> > > Cc: sta...@vger.kernel.org
> > > Signed-off-by: Benjamin Tissoires
> >
> > Tested-by: Kai-Heng Feng
>
> Thanks for the very fast testing :)
>
> Pushed to for-5.8/multitouch given that we already are at 5.7-rc7, we
> might as well postpone it for one week.
>
Apologies for the inconvenience, I hadn't noticed my master branch was
not up to date with origin. I forced push the branch to have a better
history.
Cheers,
Benjamin
> Cheers,
> Benjamin
>
> >
> > > ---
> > > drivers/hid/hid-multitouch.c | 26 ++
> > > 1 file changed, 26 insertions(+)
> > >
> > > diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> > > index 03c720b47306..39e4da7468e1 100644
> > > --- a/drivers/hid/hid-multitouch.c
> > > +++ b/drivers/hid/hid-multitouch.c
> > > @@ -69,6 +69,7 @@ MODULE_LICENSE("GPL");
> > > #define MT_QUIRK_ASUS_CUSTOM_UP BIT(17)
> > > #define MT_QUIRK_WIN8_PTP_BUTTONS BIT(18)
> > > #define MT_QUIRK_SEPARATE_APP_REPORT BIT(19)
> > > +#define MT_QUIRK_FORCE_MULTI_INPUT BIT(20)
> > >
> > > #define MT_INPUTMODE_TOUCHSCREEN 0x02
> > > #define MT_INPUTMODE_TOUCHPAD 0x03
> > > @@ -189,6 +190,7 @@ static void mt_post_parse(struct mt_device *td,
> > > struct mt_application *app);
> > > #define MT_CLS_WIN_8 0x0012
> > > #define MT_CLS_EXPORT_ALL_INPUTS 0x0013
> > > #define MT_CLS_WIN_8_DUAL 0x0014
> > > +#define MT_CLS_WIN_8_FORCE_MULTI_INPUT 0x0015
> > >
> > > /* vendor specific classes */
> > > #define MT_CLS_3M 0x0101
> > > @@ -279,6 +281,15 @@ static const struct mt_class mt_classes[] = {
> > > MT_QUIRK_CONTACT_CNT_ACCURATE |
> > > MT_QUIRK_WIN8_PTP_BUTTONS,
> > > .export_all_inputs = true },
> > > + { .name = MT_CLS_WIN_8_FORCE_MULTI_INPUT,
> > > + .quirks = MT_QUIRK_ALWAYS_VALID |
> > > + MT_QUIRK_IGNORE_DUPLICATES |
> > > + MT_QUIRK_HOVERING |
> > > + MT_QUIRK_CONTACT_CNT_ACCURATE |
> > > + MT_QUIRK_STICKY_FINGERS |
> > > + MT_QUIRK_WIN8_PTP_BUTTONS |
> > > + MT_QUIRK_FORCE_MULTI_INPUT,
> > > + .export_all_inputs = true },
> > >
> > > /*
> > >* vendor specific classes
> > > @@ -1714,6 +1725,11 @@ static int mt_probe(struct hid_device *hdev, const
> > > struct hid_device_id *id)
> > > if (id->group != HID_GROUP_MULTITOUCH_WIN_8)
> > > hdev->quirks |= HID_QUIRK_MULTI_INPUT;
> > >
> > > + if (mtclass->quirks & MT_QUIRK_FORCE_MULTI_INPUT) {
> > > + hdev->quirks &= ~HID_QUIRK_INPUT_PER_APP;
> > > + hdev->quirks |= HID_QUIRK_MULTI_INPUT;
> > > + }
> > > +
> > > timer_setup(>release_timer, mt_expired_timeout, 0);
> > >
> > > ret = hid_parse(hdev);
> > > @@ -1926,6 +1942,11 @@ static const struct hid_device_id mt_devices[] = {
> > > MT_USB_DEVICE(USB_VENDOR_ID_DWAV,
> > > USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_C002) },
> > >
> > > + /* Elan de
Re: [PATCH] HID: multitouch: Remove MT_CLS_WIN_8_DUAL
On Wed, May 27, 2020 at 8:19 AM Kai-Heng Feng
wrote:
>
>
>
> > On May 26, 2020, at 16:43, Benjamin Tissoires
> > wrote:
> >
> > On Tue, May 26, 2020 at 10:24 AM Jiri Kosina wrote:
> >>
> >> On Tue, 14 Apr 2020, Kai-Heng Feng wrote:
> >>
> >>> After commit c23e2043d5f7 ("HID: multitouch: do not filter mice nodes"),
> >>> MT_CLS_WIN_8 also supports mouse nodes, hence make MT_CLS_WIN_8_DUAL
> >>> redundant.
> >>>
> >>> Remove MT_CLS_WIN_8_DUAL accordingly.
> >>
> >> Benjamin, can I get your Ack on this one please?
> >
> > Heh, funny enough I was trying to fix
> > https://bugzilla.kernel.org/show_bug.cgi?id=207235 and was pondering
> > this one too.
> >
> > To fix #207235, I'll likely need to add a new class and quirk in
> > hid-multitouch. I can't really find a generic solution for now, and we
> > better have a local quirk for the 2 devices we currently have and
> > backport those to stable. However, this patch will likely conflict
> > (trivially), with the new quirks, so I was thinking:
> > - submitting my quick and dirty quirk and mark it to stable
> > - apply this one on top of it (this one really doesn't need to go to stable)
> >
> > How does that sound?
>
> Sounds good. I'll resend this patch once your patch lands in the tree.
Great, thanks. Though I should be able to rebase it and push it
directly. I'll notify you if I can't get to it today.
Cheers,
Benjamin
>
> Kai-Heng
>
> >
> > Cheers,
> > Benjamin
> >
> >>
> >> Thanks,
> >>
> >> --
> >> Jiri Kosina
> >> SUSE Labs
> >>
> >
>
Re: [PATCH] HID: multitouch: enable multi-input as a quirk for some devices
On Wed, May 27, 2020 at 8:18 AM Kai-Heng Feng
wrote:
>
>
>
> > On May 26, 2020, at 23:07, Benjamin Tissoires
> > wrote:
> >
> > Two touchpad/trackstick combos are currently not behaving properly.
> > They define a mouse emulation collection, as per Win8 requirements,
> > but also define a separate mouse collection for the trackstick.
> >
> > The way the kernel currently treat the collections is that it
> > merges both in one device. However, given that the first mouse
> > collection already defines X,Y and left, right buttons, when
> > mapping the events from the second mouse collection, hid-multitouch
> > sees that these events are already mapped, and simply ignores them.
> >
> > To be able to report events from the tracktick, add a new quirked
> > class for it, and manually add the 2 devices we know about.
> >
> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=207235
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Benjamin Tissoires
>
> Tested-by: Kai-Heng Feng
Thanks for the very fast testing :)
Pushed to for-5.8/multitouch given that we already are at 5.7-rc7, we
might as well postpone it for one week.
Cheers,
Benjamin
>
> > ---
> > drivers/hid/hid-multitouch.c | 26 ++
> > 1 file changed, 26 insertions(+)
> >
> > diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
> > index 03c720b47306..39e4da7468e1 100644
> > --- a/drivers/hid/hid-multitouch.c
> > +++ b/drivers/hid/hid-multitouch.c
> > @@ -69,6 +69,7 @@ MODULE_LICENSE("GPL");
> > #define MT_QUIRK_ASUS_CUSTOM_UP BIT(17)
> > #define MT_QUIRK_WIN8_PTP_BUTTONS BIT(18)
> > #define MT_QUIRK_SEPARATE_APP_REPORT BIT(19)
> > +#define MT_QUIRK_FORCE_MULTI_INPUT BIT(20)
> >
> > #define MT_INPUTMODE_TOUCHSCREEN 0x02
> > #define MT_INPUTMODE_TOUCHPAD 0x03
> > @@ -189,6 +190,7 @@ static void mt_post_parse(struct mt_device *td, struct
> > mt_application *app);
> > #define MT_CLS_WIN_8 0x0012
> > #define MT_CLS_EXPORT_ALL_INPUTS 0x0013
> > #define MT_CLS_WIN_8_DUAL 0x0014
> > +#define MT_CLS_WIN_8_FORCE_MULTI_INPUT 0x0015
> >
> > /* vendor specific classes */
> > #define MT_CLS_3M 0x0101
> > @@ -279,6 +281,15 @@ static const struct mt_class mt_classes[] = {
> > MT_QUIRK_CONTACT_CNT_ACCURATE |
> > MT_QUIRK_WIN8_PTP_BUTTONS,
> > .export_all_inputs = true },
> > + { .name = MT_CLS_WIN_8_FORCE_MULTI_INPUT,
> > + .quirks = MT_QUIRK_ALWAYS_VALID |
> > + MT_QUIRK_IGNORE_DUPLICATES |
> > + MT_QUIRK_HOVERING |
> > + MT_QUIRK_CONTACT_CNT_ACCURATE |
> > + MT_QUIRK_STICKY_FINGERS |
> > + MT_QUIRK_WIN8_PTP_BUTTONS |
> > + MT_QUIRK_FORCE_MULTI_INPUT,
> > + .export_all_inputs = true },
> >
> > /*
> >* vendor specific classes
> > @@ -1714,6 +1725,11 @@ static int mt_probe(struct hid_device *hdev, const
> > struct hid_device_id *id)
> > if (id->group != HID_GROUP_MULTITOUCH_WIN_8)
> > hdev->quirks |= HID_QUIRK_MULTI_INPUT;
> >
> > + if (mtclass->quirks & MT_QUIRK_FORCE_MULTI_INPUT) {
> > + hdev->quirks &= ~HID_QUIRK_INPUT_PER_APP;
> > + hdev->quirks |= HID_QUIRK_MULTI_INPUT;
> > + }
> > +
> > timer_setup(>release_timer, mt_expired_timeout, 0);
> >
> > ret = hid_parse(hdev);
> > @@ -1926,6 +1942,11 @@ static const struct hid_device_id mt_devices[] = {
> > MT_USB_DEVICE(USB_VENDOR_ID_DWAV,
> > USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_C002) },
> >
> > + /* Elan devices */
> > + { .driver_data = MT_CLS_WIN_8_FORCE_MULTI_INPUT,
> > + HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
> > + USB_VENDOR_ID_ELAN, 0x313a) },
> > +
> > /* Elitegroup panel */
> > { .driver_data = MT_CLS_SERIAL,
> > MT_USB_DEVICE(USB_VENDOR_ID_ELITEGROUP,
> > @@ -2056,6 +2077,11 @@ static const struct hid_device_id mt_devices[] = {
> > MT_USB_DEVICE(USB_VENDOR_ID_STANTUM_STM,
> > USB_DEVICE_ID_MTP_STM)},
> >
> > + /* Synaptics devices */
> > + { .driver_data = MT_CLS_WIN_8_FORCE_MULTI_INPUT,
> > + HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
> > + USB_VENDOR_ID_SYNAPTICS, 0xce08) },
> > +
> > /* TopSeed panels */
> > { .driver_data = MT_CLS_TOPSEED,
> > MT_USB_DEVICE(USB_VENDOR_ID_TOPSEED2,
> > --
> > 2.25.1
> >
>
[PATCH] HID: multitouch: enable multi-input as a quirk for some devices
Two touchpad/trackstick combos are currently not behaving properly.
They define a mouse emulation collection, as per Win8 requirements,
but also define a separate mouse collection for the trackstick.
The way the kernel currently treat the collections is that it
merges both in one device. However, given that the first mouse
collection already defines X,Y and left, right buttons, when
mapping the events from the second mouse collection, hid-multitouch
sees that these events are already mapped, and simply ignores them.
To be able to report events from the tracktick, add a new quirked
class for it, and manually add the 2 devices we know about.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=207235
Cc: sta...@vger.kernel.org
Signed-off-by: Benjamin Tissoires
---
drivers/hid/hid-multitouch.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index 03c720b47306..39e4da7468e1 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -69,6 +69,7 @@ MODULE_LICENSE("GPL");
#define MT_QUIRK_ASUS_CUSTOM_UPBIT(17)
#define MT_QUIRK_WIN8_PTP_BUTTONS BIT(18)
#define MT_QUIRK_SEPARATE_APP_REPORT BIT(19)
+#define MT_QUIRK_FORCE_MULTI_INPUT BIT(20)
#define MT_INPUTMODE_TOUCHSCREEN 0x02
#define MT_INPUTMODE_TOUCHPAD 0x03
@@ -189,6 +190,7 @@ static void mt_post_parse(struct mt_device *td, struct
mt_application *app);
#define MT_CLS_WIN_8 0x0012
#define MT_CLS_EXPORT_ALL_INPUTS 0x0013
#define MT_CLS_WIN_8_DUAL 0x0014
+#define MT_CLS_WIN_8_FORCE_MULTI_INPUT 0x0015
/* vendor specific classes */
#define MT_CLS_3M 0x0101
@@ -279,6 +281,15 @@ static const struct mt_class mt_classes[] = {
MT_QUIRK_CONTACT_CNT_ACCURATE |
MT_QUIRK_WIN8_PTP_BUTTONS,
.export_all_inputs = true },
+ { .name = MT_CLS_WIN_8_FORCE_MULTI_INPUT,
+ .quirks = MT_QUIRK_ALWAYS_VALID |
+ MT_QUIRK_IGNORE_DUPLICATES |
+ MT_QUIRK_HOVERING |
+ MT_QUIRK_CONTACT_CNT_ACCURATE |
+ MT_QUIRK_STICKY_FINGERS |
+ MT_QUIRK_WIN8_PTP_BUTTONS |
+ MT_QUIRK_FORCE_MULTI_INPUT,
+ .export_all_inputs = true },
/*
* vendor specific classes
@@ -1714,6 +1725,11 @@ static int mt_probe(struct hid_device *hdev, const
struct hid_device_id *id)
if (id->group != HID_GROUP_MULTITOUCH_WIN_8)
hdev->quirks |= HID_QUIRK_MULTI_INPUT;
+ if (mtclass->quirks & MT_QUIRK_FORCE_MULTI_INPUT) {
+ hdev->quirks &= ~HID_QUIRK_INPUT_PER_APP;
+ hdev->quirks |= HID_QUIRK_MULTI_INPUT;
+ }
+
timer_setup(>release_timer, mt_expired_timeout, 0);
ret = hid_parse(hdev);
@@ -1926,6 +1942,11 @@ static const struct hid_device_id mt_devices[] = {
MT_USB_DEVICE(USB_VENDOR_ID_DWAV,
USB_DEVICE_ID_DWAV_EGALAX_MULTITOUCH_C002) },
+ /* Elan devices */
+ { .driver_data = MT_CLS_WIN_8_FORCE_MULTI_INPUT,
+ HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
+ USB_VENDOR_ID_ELAN, 0x313a) },
+
/* Elitegroup panel */
{ .driver_data = MT_CLS_SERIAL,
MT_USB_DEVICE(USB_VENDOR_ID_ELITEGROUP,
@@ -2056,6 +2077,11 @@ static const struct hid_device_id mt_devices[] = {
MT_USB_DEVICE(USB_VENDOR_ID_STANTUM_STM,
USB_DEVICE_ID_MTP_STM)},
+ /* Synaptics devices */
+ { .driver_data = MT_CLS_WIN_8_FORCE_MULTI_INPUT,
+ HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
+ USB_VENDOR_ID_SYNAPTICS, 0xce08) },
+
/* TopSeed panels */
{ .driver_data = MT_CLS_TOPSEED,
MT_USB_DEVICE(USB_VENDOR_ID_TOPSEED2,
--
2.25.1
Re: [PATCH] HID: multitouch: Remove MT_CLS_WIN_8_DUAL
On Tue, May 26, 2020 at 10:24 AM Jiri Kosina wrote:
>
> On Tue, 14 Apr 2020, Kai-Heng Feng wrote:
>
> > After commit c23e2043d5f7 ("HID: multitouch: do not filter mice nodes"),
> > MT_CLS_WIN_8 also supports mouse nodes, hence make MT_CLS_WIN_8_DUAL
> > redundant.
> >
> > Remove MT_CLS_WIN_8_DUAL accordingly.
>
> Benjamin, can I get your Ack on this one please?
Heh, funny enough I was trying to fix
https://bugzilla.kernel.org/show_bug.cgi?id=207235 and was pondering
this one too.
To fix #207235, I'll likely need to add a new class and quirk in
hid-multitouch. I can't really find a generic solution for now, and we
better have a local quirk for the 2 devices we currently have and
backport those to stable. However, this patch will likely conflict
(trivially), with the new quirks, so I was thinking:
- submitting my quick and dirty quirk and mark it to stable
- apply this one on top of it (this one really doesn't need to go to stable)
How does that sound?
Cheers,
Benjamin
>
> Thanks,
>
> --
> Jiri Kosina
> SUSE Labs
>
Re: [PATCH v7 3/3] HID: logitech-hidpp: Support WirelessDeviceStatus connect events
Hi Mazin
On Sun, Oct 20, 2019 at 6:43 AM Mazin Rezk wrote:
>
> This patch allows hidpp_report_is_connect_event to support
> WirelessDeviceStatus connect events.
>
> The WirelessDeviceStatus feature index is stored in hidpp_device when
> probed. The connect event's fap feature_index is compared against it if the
> device supports it.
>
> Thanks,
> Mazin
huh, this "Thanks" bit should be after the first "---", because we
don't want it in the final commit :)
BTW, I haven't been able to trigger this one yet. Patch looks good,
but I'd rather be sure it works on many Logitech devices before we
include it.
Cheers,
Benjamin
>
> Signed-off-by: Mazin Rezk
> ---
> drivers/hid/hid-logitech-hidpp.c | 39
> 1 file changed, 35 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hid/hid-logitech-hidpp.c
> b/drivers/hid/hid-logitech-hidpp.c
> index 19b315e4e91b..c8b23568d0b1 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -191,6 +191,8 @@ struct hidpp_device {
>
> struct hidpp_battery battery;
> struct hidpp_scroll_counter vertical_wheel_counter;
> +
> + u8 wireless_feature_index;
> };
>
> /* HID++ 1.0 error codes */
> @@ -403,10 +405,13 @@ static inline bool hidpp_match_error(struct
> hidpp_report *question,
> (answer->fap.params[0] == question->fap.funcindex_clientid);
> }
>
> -static inline bool hidpp_report_is_connect_event(struct hidpp_report *report)
> +static inline bool hidpp_report_is_connect_event(struct hidpp_device *hidpp,
> + struct hidpp_report *report)
> {
> - return (report->report_id == REPORT_ID_HIDPP_SHORT) &&
> - (report->rap.sub_id == 0x41);
> + return (hidpp->wireless_feature_index &&
> + (report->fap.feature_index == hidpp->wireless_feature_index))
> ||
> + ((report->report_id == REPORT_ID_HIDPP_SHORT) &&
> + (report->rap.sub_id == 0x41));
> }
>
> /**
> @@ -1283,6 +1288,24 @@ static int hidpp_battery_get_property(struct
> power_supply *psy,
> return ret;
> }
>
> +/*
> -- */
> +/* 0x1d4b: Wireless device status
> */
> +/*
> -- */
> +#define HIDPP_PAGE_WIRELESS_DEVICE_STATUS 0x1d4b
> +
> +static int hidpp_set_wireless_feature_index(struct hidpp_device *hidpp)
> +{
> + u8 feature_type;
> + int ret;
> +
> + ret = hidpp_root_get_feature(hidpp,
> +HIDPP_PAGE_WIRELESS_DEVICE_STATUS,
> +>wireless_feature_index,
> +_type);
> +
> + return ret;
> +}
> +
> /*
> -- */
> /* 0x2120: Hi-resolution scrolling
> */
> /*
> -- */
> @@ -3078,7 +3101,7 @@ static int hidpp_raw_hidpp_event(struct hidpp_device
> *hidpp, u8 *data,
> }
> }
>
> - if (unlikely(hidpp_report_is_connect_event(report))) {
> + if (unlikely(hidpp_report_is_connect_event(hidpp, report))) {
> atomic_set(>connected,
> !(report->rap.params[0] & (1 << 6)));
> if (schedule_work(>work) == 0)
> @@ -3628,6 +3651,14 @@ static int hidpp_probe(struct hid_device *hdev, const
> struct hid_device_id *id)
> hidpp_overwrite_name(hdev);
> }
>
> + if (connected && hidpp->protocol_major >= 2) {
> + ret = hidpp_set_wireless_feature_index(hidpp);
> + if (ret == -ENOENT)
> + hidpp->wireless_feature_index = 0;
> + else if (ret)
> + goto hid_hw_init_fail;
> + }
> +
> if (connected && (hidpp->quirks & HIDPP_QUIRK_CLASS_WTP)) {
> ret = wtp_get_config(hidpp);
> if (ret)
> --
> 2.23.0
>
Re: [PATCH v7 1/3] HID: logitech-hidpp: Support translations from short to long reports
Hi Mazin,
On Sun, Oct 20, 2019 at 6:41 AM Mazin Rezk wrote:
>
> This patch allows short reports to be translated into long reports.
>
> hidpp_validate_device now returns a u8 instead of a bool which represents
> the supported reports. The corresponding bits (i.e.
> HIDPP_REPORT_*_SUPPORTED) are set if an HID++ report is supported.
>
> If a short report is being sent and the device does not support it, it is
> instead sent as a long report.
>
> Thanks,
> Mazin
>
> Signed-off-by: Mazin Rezk
> ---
Yep, I like this patch much better.
I also tested the 0xb012 MX Master, and it now works like a charm :)
nitpick: can you squash the next patch into this one? Because to be
useful, this patch really need one or 2 supported devices.
Cheers,
Benjamin
> drivers/hid/hid-logitech-hidpp.c | 25 +++--
> 1 file changed, 19 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/hid/hid-logitech-hidpp.c
> b/drivers/hid/hid-logitech-hidpp.c
> index e9bba282f9c1..ee604b17514f 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -49,6 +49,10 @@ MODULE_PARM_DESC(disable_tap_to_click,
> #define HIDPP_REPORT_LONG_LENGTH 20
> #define HIDPP_REPORT_VERY_LONG_MAX_LENGTH 64
>
> +#define HIDPP_REPORT_SHORT_SUPPORTED BIT(0)
> +#define HIDPP_REPORT_LONG_SUPPORTEDBIT(1)
> +#define HIDPP_REPORT_VERY_LONG_SUPPORTED BIT(2)
> +
> #define HIDPP_SUB_ID_CONSUMER_VENDOR_KEYS 0x03
> #define HIDPP_SUB_ID_ROLLER0x05
> #define HIDPP_SUB_ID_MOUSE_EXTRA_BTNS 0x06
> @@ -183,6 +187,7 @@ struct hidpp_device {
>
> unsigned long quirks;
> unsigned long capabilities;
> + u8 supported_reports;
>
> struct hidpp_battery battery;
> struct hidpp_scroll_counter vertical_wheel_counter;
> @@ -340,6 +345,11 @@ static int hidpp_send_rap_command_sync(struct
> hidpp_device *hidpp_dev,
> struct hidpp_report *message;
> int ret, max_count;
>
> + /* Send as long report if short reports are not supported. */
> + if (report_id == REPORT_ID_HIDPP_SHORT &&
> + !(hidpp_dev->supported_reports & HIDPP_REPORT_SHORT_SUPPORTED))
> + report_id = REPORT_ID_HIDPP_LONG;
> +
> switch (report_id) {
> case REPORT_ID_HIDPP_SHORT:
> max_count = HIDPP_REPORT_SHORT_LENGTH - 4;
> @@ -3458,10 +3468,11 @@ static int hidpp_get_report_length(struct hid_device
> *hdev, int id)
> return report->field[0]->report_count + 1;
> }
>
> -static bool hidpp_validate_device(struct hid_device *hdev)
> +static u8 hidpp_validate_device(struct hid_device *hdev)
> {
> struct hidpp_device *hidpp = hid_get_drvdata(hdev);
> - int id, report_length, supported_reports = 0;
> + int id, report_length;
> + u8 supported_reports = 0;
>
> id = REPORT_ID_HIDPP_SHORT;
> report_length = hidpp_get_report_length(hdev, id);
> @@ -3469,7 +3480,7 @@ static bool hidpp_validate_device(struct hid_device
> *hdev)
> if (report_length < HIDPP_REPORT_SHORT_LENGTH)
> goto bad_device;
>
> - supported_reports++;
> + supported_reports |= HIDPP_REPORT_SHORT_SUPPORTED;
> }
>
> id = REPORT_ID_HIDPP_LONG;
> @@ -3478,7 +3489,7 @@ static bool hidpp_validate_device(struct hid_device
> *hdev)
> if (report_length < HIDPP_REPORT_LONG_LENGTH)
> goto bad_device;
>
> - supported_reports++;
> + supported_reports |= HIDPP_REPORT_LONG_SUPPORTED;
> }
>
> id = REPORT_ID_HIDPP_VERY_LONG;
> @@ -3488,7 +3499,7 @@ static bool hidpp_validate_device(struct hid_device
> *hdev)
> report_length > HIDPP_REPORT_VERY_LONG_MAX_LENGTH)
> goto bad_device;
>
> - supported_reports++;
> + supported_reports |= HIDPP_REPORT_VERY_LONG_SUPPORTED;
> hidpp->very_long_report_length = report_length;
> }
>
> @@ -3536,7 +3547,9 @@ static int hidpp_probe(struct hid_device *hdev, const
> struct hid_device_id *id)
> /*
> * Make sure the device is HID++ capable, otherwise treat as generic
> HID
> */
> - if (!hidpp_validate_device(hdev)) {
> + hidpp->supported_reports = hidpp_validate_device(hdev);
> +
> + if (!hidpp->supported_reports) {
> hid_set_drvdata(hdev, NULL);
> devm_kfree(>dev, hidpp);
> return hid_hw_start(hdev, HID_CONNECT_DEFAULT);
> --
> 2.23.0
>
Re: [PATCH v3] HID: core: check whether usage page item is after usage id item
Hi Candle,
On Mon, Oct 21, 2019 at 9:54 AM Candle Sun wrote:
>
> Hi,
>
>
> On Mon, Oct 21, 2019 at 3:38 PM Candle Sun wrote:
> >
> > From: Candle Sun
> >
> > Upstream commit 58e75155009c ("HID: core: move Usage Page concatenation
> > to Main item") adds support for Usage Page item after Usage ID items
> > (such as keyboards manufactured by Primax).
> >
> > Usage Page concatenation in Main item works well for following report
> > descriptor patterns:
> >
> > USAGE_PAGE (Keyboard) 05 07
> > USAGE_MINIMUM (Keyboard LeftControl)19 E0
> > USAGE_MAXIMUM (Keyboard Right GUI) 29 E7
> > LOGICAL_MINIMUM (0) 15 00
> > LOGICAL_MAXIMUM (1) 25 01
> > REPORT_SIZE (1) 75 01
> > REPORT_COUNT (8)95 08
> > INPUT (Data,Var,Abs)81 02
> >
> > -
> >
> > USAGE_MINIMUM (Keyboard LeftControl)19 E0
> > USAGE_MAXIMUM (Keyboard Right GUI) 29 E7
> > LOGICAL_MINIMUM (0) 15 00
> > LOGICAL_MAXIMUM (1) 25 01
> > REPORT_SIZE (1) 75 01
> > REPORT_COUNT (8)95 08
> > USAGE_PAGE (Keyboard) 05 07
> > INPUT (Data,Var,Abs)81 02
> >
> > But it makes the parser act wrong for the following report
> > descriptor pattern(such as some Gamepads):
> >
> > USAGE_PAGE (Button) 05 09
> > USAGE (Button 1)09 01
> > USAGE (Button 2)09 02
> > USAGE (Button 4)09 04
> > USAGE (Button 5)09 05
> > USAGE (Button 7)09 07
> > USAGE (Button 8)09 08
> > USAGE (Button 14) 09 0E
> > USAGE (Button 15) 09 0F
> > USAGE (Button 13) 09 0D
> > USAGE_PAGE (Consumer Devices) 05 0C
> > USAGE (Back)0a 24 02
> > USAGE (HomePage)0a 23 02
> > LOGICAL_MINIMUM (0) 15 00
> > LOGICAL_MAXIMUM (1) 25 01
> > REPORT_SIZE (1) 75 01
> > REPORT_COUNT (11) 95 0B
> > INPUT (Data,Var,Abs)81 02
> >
> > With Usage Page concatenation in Main item, parser recognizes all the
> > 11 Usages as consumer keys, it is not the HID device's real intention.
> >
> > This patch adds usage_page_last to flag whether Usage Page is after
> > Usage ID items. usage_page_last is false default, it is set as true
> > once Usage Page item is encountered and is reverted by next Usage ID
> > item.
> >
> > Usage Page concatenation on the currently defined Usage Page will do
> > firstly in Local parsing when Usage ID items encountered.
> >
> > When Main item is parsing, concatenation will do again with last
> > defined Usage Page if usage_page_last flag is true.
> >
> > Signed-off-by: Candle Sun
> > Signed-off-by: Nianfu Bai
> > ---
> > Changes in v3:
> > - Rework the GET_COMPLETE_USAGE macro as static complete_usage()
> > function
> > - Add some code comments for usage_page_last
> >
> > Changes in v2:
> > - Update patch title
> > - Add GET_COMPLETE_USAGE macro
> > - Change the logic of checking whether to concatenate usage page again
> > in main parsing
> > ---
> > drivers/hid/hid-core.c | 42 +-
> > include/linux/hid.h| 1 +
> > 2 files changed, 38 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> > index 3eaee2c37931..779b7798dae8 100644
> > --- a/drivers/hid/hid-core.c
> > +++ b/drivers/hid/hid-core.c
> > @@ -211,6 +211,18 @@ static unsigned hid_lookup_collection(struct
> > hid_parser *parser, unsigned type)
> > return 0; /* we know nothing about this usage type */
> > }
> >
> > +/*
> > + * Concatenate usage which defines 16 bits or less with the
> > + * currently defined usage page to form a 32 bit usage
> > + */
> > +
> > +static void complete_usage(struct hid_parser *parser, unsigned int index)
> > +{
> > + parser->local.usage[index] &= 0x;
> > + parser->local.usage[index] |=
> > + (parser->global.usage_page & 0x) << 16;
> > +}
> > +
> > /*
> > * Add a usage to the temporary parser table.
> > */
> > @@ -221,7 +233,18 @@ static int hid_add_usage(struct hid_parser *parser,
> > unsigned usage, u8 size)
> > hid_err(parser->device, "usage index exceeded\n");
> > return -1;
> > }
> > - parser->local.usage[parser->local.usage_index] = usage;
This broke my CI, and it turns out that installing the patch on an
actual laptop, the touchpad, touchscreen were not present, nor any HID
devices plugged in.
Basically, complete_usage()
Re: [PATCH v6 2/2] HID: logitech: Support WirelessDeviceStatus connect events
On Mon, Oct 14, 2019 at 8:36 PM Mazin Rezk wrote:
>
> This patch allows WirelessDeviceStatus (0x1d4b) events to be detected as
> connection events in the hid-logitech-hidpp module.
>
> Devices with HIDPP_QUIRK_WIRELESS_DEVICE_STATUS use WirelessDeviceStatus
> instead of traditional connect events. Since all Bluetooth LE devices seem
> to act this way, HIDPP_QUIRK_CLASS_BLUETOOTH_LE aliases this quirk.
>
> Signed-off-by: Mazin Rezk
> ---
> drivers/hid/hid-logitech-hidpp.c | 42
> 1 file changed, 37 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/hid/hid-logitech-hidpp.c
> b/drivers/hid/hid-logitech-hidpp.c
> index 997b1056850a..9b3df57ca857 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -60,6 +60,7 @@ MODULE_PARM_DESC(disable_tap_to_click,
> #define HIDPP_QUIRK_CLASS_K750 BIT(4)
>
> /* bits 2..15 are reserved for classes */
> +#define HIDPP_QUIRK_WIRELESS_DEVICE_STATUS BIT(19)
> #define HIDPP_QUIRK_MISSING_SHORT_REPORTS BIT(20)
> /* #define HIDPP_QUIRK_CONNECT_EVENTS BIT(21) disabled */
> #define HIDPP_QUIRK_WTP_PHYSICAL_BUTTONS BIT(22)
> @@ -82,7 +83,8 @@ MODULE_PARM_DESC(disable_tap_to_click,
> HIDPP_QUIRK_HI_RES_SCROLL_X2120 | \
> HIDPP_QUIRK_HI_RES_SCROLL_X2121)
>
> -#define HIDPP_QUIRK_CLASS_BLUETOOTH_LE HIDPP_QUIRK_MISSING_SHORT_REPORTS
> +#define HIDPP_QUIRK_CLASS_BLUETOOTH_LE (HIDPP_QUIRK_MISSING_SHORT_REPORTS | \
> +HIDPP_QUIRK_WIRELESS_DEVICE_STATUS)
>
> #define HIDPP_QUIRK_DELAYED_INIT HIDPP_QUIRK_NO_HIDINPUT
>
> @@ -189,6 +191,8 @@ struct hidpp_device {
>
> struct hidpp_battery battery;
> struct hidpp_scroll_counter vertical_wheel_counter;
> +
> + u8 wireless_feature_index;
> };
>
> /* HID++ 1.0 error codes */
> @@ -402,10 +406,14 @@ static inline bool hidpp_match_error(struct
> hidpp_report *question,
> (answer->fap.params[0] == question->fap.funcindex_clientid);
> }
>
> -static inline bool hidpp_report_is_connect_event(struct hidpp_report *report)
> +static inline bool hidpp_report_is_connect_event(struct hidpp_device *hidpp,
> +struct hidpp_report *report)
> {
> - return (report->report_id == REPORT_ID_HIDPP_SHORT) &&
> - (report->rap.sub_id == 0x41);
> + return ((hidpp->quirks & HIDPP_QUIRK_WIRELESS_DEVICE_STATUS) &&
> + (report->fap.feature_index == hidpp->wireless_feature_index))
> ||
> + (((report->report_id == REPORT_ID_HIDPP_SHORT) ||
> + (hidpp->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS)) &&
> + (report->rap.sub_id == 0x41));
I wonder if we need a quirk after all: if
hidpp->wireless_feature_index is non null, that means that we have the
quirk.
Unless the feature is present for non BLE devices, in which case, we
might want to enable them one by one, for now.
Cheers,
Benjamin
> }
>
> /**
> @@ -1282,6 +1290,24 @@ static int hidpp_battery_get_property(struct
> power_supply *psy,
> return ret;
> }
>
> +/*
> -- */
> +/* 0x1d4b: Wireless device status
> */
> +/*
> -- */
> +#define HIDPP_PAGE_WIRELESS_DEVICE_STATUS 0x1d4b
> +
> +static int hidpp_set_wireless_feature_index(struct hidpp_device *hidpp)
> +{
> + u8 feature_type;
> + int ret;
> +
> + ret = hidpp_root_get_feature(hidpp,
> +HIDPP_PAGE_WIRELESS_DEVICE_STATUS,
> +>wireless_feature_index,
> +_type);
> +
> + return ret;
> +}
> +
> /*
> -- */
> /* 0x2120: Hi-resolution scrolling
> */
> /*
> -- */
> @@ -3077,7 +3103,7 @@ static int hidpp_raw_hidpp_event(struct hidpp_device
> *hidpp, u8 *data,
> }
> }
>
> - if (unlikely(hidpp_report_is_connect_event(report))) {
> + if (unlikely(hidpp_report_is_connect_event(hidpp, report))) {
> atomic_set(>connected,
> !(report->rap.params[0] & (1 << 6)));
> if (schedule_work(>work) == 0)
> @@ -3624,6 +3650,12 @@ static int hidpp_probe(struct hid_device *hdev, const
> struct hid_device_id *id)
> hidpp_overwrite_name(hdev);
> }
>
> + if (connected && (hidpp->quirks &
> HIDPP_QUIRK_WIRELESS_DEVICE_STATUS)) {
> + ret = hidpp_set_wireless_feature_index(hidpp);
> + if (ret)
> +
Re: [PATCH v6 1/2] HID: logitech: Add MX Master over Bluetooth
Hi Mazin,
On Mon, Oct 14, 2019 at 8:36 PM Mazin Rezk wrote:
>
> This patch adds support for the MX Master (b01e and b012) and also adds
> foundational code for other Bluetooth LE HID++ devices to be added.
>
> Some devices do not support short reports and thus have a quirk
> (HIDPP_QUIRK_MISSING_SHORT_REPORTS) that forces short reports to be sent as
> long reports. Since all Bluetooth LE HID++ devices seem to act this way,
> HIDPP_QUIRK_CLASS_BLUETOOTH_LE aliases this quirk.
>
> To allow for some space for future quirks, I changed the comment that
> defines the bits reserved for classes from 2...20 to 2..15.
>
> Signed-off-by: Mazin Rezk
> ---
> drivers/hid/hid-logitech-hidpp.c | 24 +++-
> 1 file changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hid/hid-logitech-hidpp.c
> b/drivers/hid/hid-logitech-hidpp.c
> index 0179f7ed77e5..997b1056850a 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -59,7 +59,8 @@ MODULE_PARM_DESC(disable_tap_to_click,
> #define HIDPP_QUIRK_CLASS_G920 BIT(3)
> #define HIDPP_QUIRK_CLASS_K750 BIT(4)
>
> -/* bits 2..20 are reserved for classes */
> +/* bits 2..15 are reserved for classes */
> +#define HIDPP_QUIRK_MISSING_SHORT_REPORTS BIT(20)
> /* #define HIDPP_QUIRK_CONNECT_EVENTS BIT(21) disabled */
> #define HIDPP_QUIRK_WTP_PHYSICAL_BUTTONS BIT(22)
> #define HIDPP_QUIRK_NO_HIDINPUTBIT(23)
> @@ -81,6 +82,8 @@ MODULE_PARM_DESC(disable_tap_to_click,
> HIDPP_QUIRK_HI_RES_SCROLL_X2120 | \
> HIDPP_QUIRK_HI_RES_SCROLL_X2121)
>
> +#define HIDPP_QUIRK_CLASS_BLUETOOTH_LE HIDPP_QUIRK_MISSING_SHORT_REPORTS
> +
> #define HIDPP_QUIRK_DELAYED_INIT HIDPP_QUIRK_NO_HIDINPUT
>
> #define HIDPP_CAPABILITY_HIDPP10_BATTERY BIT(0)
> @@ -340,6 +343,12 @@ static int hidpp_send_rap_command_sync(struct
> hidpp_device *hidpp_dev,
> struct hidpp_report *message;
> int ret, max_count;
>
> + /* Force long reports on devices that do not support short reports */
> + if (hidpp_dev->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS &&
> + report_id == REPORT_ID_HIDPP_SHORT)
> + report_id = REPORT_ID_HIDPP_LONG;
Wouldn't it be faster to just store which report needs to be put here
in struct hidpp_device?
> +
> +
> switch (report_id) {
> case REPORT_ID_HIDPP_SHORT:
> max_count = HIDPP_REPORT_SHORT_LENGTH - 4;
> @@ -3482,6 +3491,12 @@ static bool hidpp_validate_report(struct hid_device
> *hdev, int id,
>
> static bool hidpp_validate_device(struct hid_device *hdev)
> {
> + struct hidpp_device *hidpp = hid_get_drvdata(hdev);
> + /* Skip the short report check if the device does not support it */
> + if (hidpp->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS)
> + return hidpp_validate_report(hdev, REPORT_ID_HIDPP_LONG,
> +HIDPP_REPORT_LONG_LENGTH, false);
> +
I just merged Andrey's report detection, which means you will need to
update this hunk:
https://git.kernel.org/pub/scm/linux/kernel/git/hid/hid.git/commit/?h=for-5.4/upstream-fixes=905d754c53a522aacf806ea1d3e7c929148c1910
The good thing, is that now you can simply auto-detect if the short
report is missing. If the returned report_length is null, you know
that the report is missing (and thus you can remember to set the
quirk/which report id is needed).
Cheers,
Benjamin
> return hidpp_validate_report(hdev, REPORT_ID_HIDPP_SHORT,
> HIDPP_REPORT_SHORT_LENGTH, false) &&
>hidpp_validate_report(hdev, REPORT_ID_HIDPP_LONG,
> @@ -3773,6 +3788,13 @@ static const struct hid_device_id hidpp_devices[] = {
> { /* MX5500 keyboard over Bluetooth */
> HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb30b),
> .driver_data = HIDPP_QUIRK_HIDPP_CONSUMER_VENDOR_KEYS },
> + { /* MX Master mouse over Bluetooth */
> + HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb012),
> + .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 |
> +HIDPP_QUIRK_CLASS_BLUETOOTH_LE },
> + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb01e),
> + .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 |
> +HIDPP_QUIRK_CLASS_BLUETOOTH_LE },
> {}
> };
>
> --
> 2.23.0
>
Re: [PATCH v2] HID: i2c-hid: Remove runtime power management
On Wed, Oct 16, 2019 at 5:12 PM Kai-Heng Feng
wrote:
>
> Runtime power management in i2c-hid brings lots of issues, such as:
> - When transitioning from display manager to desktop session, i2c-hid
> was closed and opened, so the device was set to SLEEP and ON in a short
> period. Vendors confirmed that their devices can't handle fast ON/SLEEP
> command because Windows doesn't have this behavior.
>
> - When rebooting, i2c-hid was closed, and the driver core put the device
> back to full power before shutdown. This behavior also triggers a quick
> SLEEP and ON commands that some devices can't handle, renders an
> unusable touchpad after reboot.
>
> - Most importantly, my power meter reports little to none energy saving
> when i2c-hid is runtime suspended.
>
> So let's remove runtime power management since there is no actual
> benefit.
>
> Signed-off-by: Kai-Heng Feng
> ---
> v2:
> - Remove unused label and wording change.
Thanks!
v2 now applied to for-5.4/upstream-fixes
(with Hans' acked-by from the v1 kept)
Cheers,
Benjamin
>
> drivers/hid/i2c-hid/i2c-hid-core.c | 118 ++---
> 1 file changed, 7 insertions(+), 111 deletions(-)
>
> diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c
> b/drivers/hid/i2c-hid/i2c-hid-core.c
> index 2a7c6e33bb1c..d9c55e30f986 100644
> --- a/drivers/hid/i2c-hid/i2c-hid-core.c
> +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
> @@ -26,7 +26,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -48,8 +47,6 @@
> /* quirks to control the device */
> #define I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV BIT(0)
> #define I2C_HID_QUIRK_NO_IRQ_AFTER_RESET BIT(1)
> -#define I2C_HID_QUIRK_NO_RUNTIME_PMBIT(2)
> -#define I2C_HID_QUIRK_DELAY_AFTER_SLEEPBIT(3)
> #define I2C_HID_QUIRK_BOGUS_IRQBIT(4)
>
> /* flags */
> @@ -172,14 +169,7 @@ static const struct i2c_hid_quirks {
> { USB_VENDOR_ID_WEIDA, HID_ANY_ID,
> I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV },
> { I2C_VENDOR_ID_HANTICK, I2C_PRODUCT_ID_HANTICK_5288,
> - I2C_HID_QUIRK_NO_IRQ_AFTER_RESET |
> - I2C_HID_QUIRK_NO_RUNTIME_PM },
> - { I2C_VENDOR_ID_RAYDIUM, I2C_PRODUCT_ID_RAYDIUM_4B33,
> - I2C_HID_QUIRK_DELAY_AFTER_SLEEP },
> - { USB_VENDOR_ID_LG, I2C_DEVICE_ID_LG_8001,
> - I2C_HID_QUIRK_NO_RUNTIME_PM },
> - { I2C_VENDOR_ID_GOODIX, I2C_DEVICE_ID_GOODIX_01F0,
> - I2C_HID_QUIRK_NO_RUNTIME_PM },
> + I2C_HID_QUIRK_NO_IRQ_AFTER_RESET },
> { USB_VENDOR_ID_ELAN, HID_ANY_ID,
> I2C_HID_QUIRK_BOGUS_IRQ },
> { 0, 0 }
> @@ -397,7 +387,6 @@ static int i2c_hid_set_power(struct i2c_client *client,
> int power_state)
> {
> struct i2c_hid *ihid = i2c_get_clientdata(client);
> int ret;
> - unsigned long now, delay;
>
> i2c_hid_dbg(ihid, "%s\n", __func__);
>
> @@ -415,22 +404,9 @@ static int i2c_hid_set_power(struct i2c_client *client,
> int power_state)
> goto set_pwr_exit;
> }
>
> - if (ihid->quirks & I2C_HID_QUIRK_DELAY_AFTER_SLEEP &&
> - power_state == I2C_HID_PWR_ON) {
> - now = jiffies;
> - if (time_after(ihid->sleep_delay, now)) {
> - delay = jiffies_to_usecs(ihid->sleep_delay - now);
> - usleep_range(delay, delay + 1);
> - }
> - }
> -
> ret = __i2c_hid_command(client, _set_power_cmd, power_state,
> 0, NULL, 0, NULL, 0);
>
> - if (ihid->quirks & I2C_HID_QUIRK_DELAY_AFTER_SLEEP &&
> - power_state == I2C_HID_PWR_SLEEP)
> - ihid->sleep_delay = jiffies + msecs_to_jiffies(20);
> -
> if (ret)
> dev_err(>dev, "failed to change power setting.\n");
>
> @@ -791,11 +767,6 @@ static int i2c_hid_open(struct hid_device *hid)
> {
> struct i2c_client *client = hid->driver_data;
> struct i2c_hid *ihid = i2c_get_clientdata(client);
> - int ret = 0;
> -
> - ret = pm_runtime_get_sync(>dev);
> - if (ret < 0)
> - return ret;
>
> set_bit(I2C_HID_STARTED, >flags);
> return 0;
> @@ -807,27 +778,6 @@ static void i2c_hid_close(struct hid_device *hid)
> struct i2c_hid *ihid = i2c_get_clientdata(client);
>
> clear_bit(I2C_HID_STARTED, >flags);
> -
> - /* Save some power */
> - pm_runtime_put(>dev);
> -}
> -
> -static int i2c_hid_power(struct hid_device *hid, int lvl)
> -{
> - struct i2c_client *client = hid->driver_data;
> - struct i2c_hid *ihid = i2c_get_clientdata(client);
> -
> - i2c_hid_dbg(ihid, "%s lvl:%d\n", __func__, lvl);
> -
> - switch (lvl) {
> - case PM_HINT_FULLON:
> - pm_runtime_get_sync(>dev);
> - break;
> - case PM_HINT_NORMAL:
> - pm_runtime_put(>dev);
> -
Re: [PATCH v3 0/3] Logitech G920 fixes
On Fri, Oct 18, 2019 at 6:45 AM Andrey Smirnov wrote:
>
> Everyone:
>
> This series contains patches to fix a couple of regressions in G920
> wheel support by hid-logitech-hidpp driver. Without the patches the
> wheel remains stuck in autocentering mode ("resisting" any attempt to
> trun) as well as missing support for any FF action.
>
> Thanks,
> Andrey Smirnov
>
> Changes since [v2]:
>
> - Fixes a buggy validity check "HID: logitech-hidpp: rework
> device validation" as pointed out by Benjamin Tissoires
>
> - Marked "HID: logitech-hidpp: do all FF cleanup in
>hidpp_ff_destroy()" as 5.2+ for stable
>
> Changes since [v1]:
>
> - "HID: logitech-hidpp: split g920_get_config()" is changed to
>not rely on devres and be a self contained patch
>
> - Quirk driven behaviour of "HID: logitech-hidpp: add G920 device
>validation quirk" is replaced with generic validation algorithm
>of "HID: logitech-hidpp: rework device validation"
>
> - Fix for a poteintial race condition is added in
>"HID: logitech-hidpp: do all FF cleanup in hidpp_ff_destroy()"
>as per suggestion by Benjamin Tissoires
>
> - Collected Tested-by from Sam Bazely for "HID: logitech-hidpp:
>split g920_get_config()" since that patch didn't change
>significantly since [v1]
>
> - Specified stable kernel versions I think the patches should
>apply to (hopefully I got that right)
>
> [v2] lore.kernel.org/lkml/20191016182935.5616-1-andrew.smir...@gmail.com
> [v1] lore.kernel.org/lkml/20191007051240.4410-1-andrew.smir...@gmail.com
>
> Andrey Smirnov (3):
> HID: logitech-hidpp: split g920_get_config()
> HID: logitech-hidpp: rework device validation
> HID: logitech-hidpp: do all FF cleanup in hidpp_ff_destroy()
>
> drivers/hid/hid-logitech-hidpp.c | 237 +--
> 1 file changed, 131 insertions(+), 106 deletions(-)
>
Thanks a lot for the work on this series.
I gave a slight test of the series with a bunch of devices handled by
hid-logitech-hidpp without regressions.
Applied to for-5.4/upstream-fixes
Cheers,
Benjamin
> --
> 2.21.0
>
Re: [PATCH v2 2/3] HID: logitech-hidpp: rework device validation
On Wed, Oct 16, 2019 at 9:38 PM Andrey Smirnov wrote:
>
> On Wed, Oct 16, 2019 at 12:24 PM Benjamin Tissoires
> wrote:
> >
> > Hi Andrey,
> >
> > On Wed, Oct 16, 2019 at 8:30 PM Andrey Smirnov
> > wrote:
> > >
> > > G920 device only advertises REPORT_ID_HIDPP_LONG and
> > > REPORT_ID_HIDPP_VERY_LONG in its HID report descriptor, so querying
> > > for REPORT_ID_HIDPP_SHORT with optional=false will always fail and
> > > prevent G920 to be recognized as a valid HID++ device.
> > >
> > > To fix this and improve some other aspects, modify
> > > hidpp_validate_device() as follows:
> > >
> > > - Inline the code of hidpp_validate_report() to simplify
> > > distingushing between non-present and invalid report descriptors
> > >
> > > - Drop the check for id >= HID_MAX_IDS || id < 0 since all of our
> > > IDs are static and known to satisfy that at compile time
> > >
> > > - Change the algorithms to check all possible report
> > > types (including very long report) and deem the device as a valid
> > > HID++ device if it supports at least one
> > >
> > > - Treat invalid report length as a hard stop for the validation
> > > algorithm, meaning that if any of the supported reports has
> > > invalid length we assume the worst and treat the device as a
> > > generic HID device.
> > >
> > > - Fold initialization of hidpp->very_long_report_length into
> > > hidpp_validate_device() since it already fetches very long report
> > > length and validates its value
> > >
> > > Fixes: fe3ee1ec007b ("HID: logitech-hidpp: allow non HID++ devices to be
> > > handled by this module")
> > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204191
> > > Reported-by: Sam Bazely
> > > Signed-off-by: Andrey Smirnov
> > > Cc: Jiri Kosina
> > > Cc: Benjamin Tissoires
> > > Cc: Henrik Rydberg
> > > Cc: Pierre-Loup A. Griffais
> > > Cc: Austin Palmer
> > > Cc: linux-in...@vger.kernel.org
> > > Cc: linux-kernel@vger.kernel.org
> > > Cc: sta...@vger.kernel.org # 5.2+
> > > ---
> > > drivers/hid/hid-logitech-hidpp.c | 54 ++--
> > > 1 file changed, 30 insertions(+), 24 deletions(-)
> > >
> > > diff --git a/drivers/hid/hid-logitech-hidpp.c
> > > b/drivers/hid/hid-logitech-hidpp.c
> > > index 85911586b3b6..8c4be991f387 100644
> > > --- a/drivers/hid/hid-logitech-hidpp.c
> > > +++ b/drivers/hid/hid-logitech-hidpp.c
> > > @@ -3498,34 +3498,45 @@ static int hidpp_get_report_length(struct
> > > hid_device *hdev, int id)
> > > return report->field[0]->report_count + 1;
> > > }
> > >
> > > -static bool hidpp_validate_report(struct hid_device *hdev, int id,
> > > - int expected_length, bool optional)
> > > +static bool hidpp_validate_device(struct hid_device *hdev)
> > > {
> > > - int report_length;
> > > + struct hidpp_device *hidpp = hid_get_drvdata(hdev);
> > > + int id, report_length, supported_reports = 0;
> > > +
> > > + id = REPORT_ID_HIDPP_SHORT;
> > > + report_length = hidpp_get_report_length(hdev, id);
> > > + if (report_length) {
> > > + if (report_length < HIDPP_REPORT_SHORT_LENGTH)
> > > + goto bad_device;
> > >
> > > - if (id >= HID_MAX_IDS || id < 0) {
> > > - hid_err(hdev, "invalid HID report id %u\n", id);
> > > - return false;
> > > + supported_reports++;
> > > }
> > >
> > > + id = REPORT_ID_HIDPP_LONG;
> > > report_length = hidpp_get_report_length(hdev, id);
> > > - if (!report_length)
> > > - return optional;
> > > + if (report_length) {
> > > + if (report_length < HIDPP_REPORT_LONG_LENGTH)
> > > + goto bad_device;
> > >
> > > - if (report_length < expected_length) {
> > > - hid_warn(hdev, "not enough values in hidpp report %d\n",
> > > id);
> > > - return false;
> > > + supported_reports++;
> > > }
> > >
> > > - return true;
> > > -}
> > > + id = REPORT_ID_HIDPP_VERY_LONG;
> > > + report_length = hidpp_get_report_length(hdev, id);
> > > + if (report_length) {
> > > + if (report_length > HIDPP_REPORT_LONG_LENGTH &&
> > > + report_length < HIDPP_REPORT_VERY_LONG_MAX_LENGTH)
> >
> > Can you double check the conditions here?
> > It's late, but I think you inverted the tests as we expect the report
> > length to be between HIDPP_REPORT_LONG_LENGTH and
> > HIDPP_REPORT_VERY_LONG_MAX_LENGTH inclusive, while here this creates a
> > bad_device.
>
> Hmm, I think you are right. Not sure why I didn't catch it on G920
> since it support very long reports AFAIR. Will re-spin and double
> check in v3. Sorry about that.
>
Oh, the issue is that the very long HID++ reports on the G920 are
HIDPP_REPORT_VERY_LONG_MAX_LENGTH long, which means the test will fail
for those.
Cheers,
Benjamin
Re: [PATCH v2 2/3] HID: logitech-hidpp: rework device validation
Hi Andrey,
On Wed, Oct 16, 2019 at 8:30 PM Andrey Smirnov wrote:
>
> G920 device only advertises REPORT_ID_HIDPP_LONG and
> REPORT_ID_HIDPP_VERY_LONG in its HID report descriptor, so querying
> for REPORT_ID_HIDPP_SHORT with optional=false will always fail and
> prevent G920 to be recognized as a valid HID++ device.
>
> To fix this and improve some other aspects, modify
> hidpp_validate_device() as follows:
>
> - Inline the code of hidpp_validate_report() to simplify
> distingushing between non-present and invalid report descriptors
>
> - Drop the check for id >= HID_MAX_IDS || id < 0 since all of our
> IDs are static and known to satisfy that at compile time
>
> - Change the algorithms to check all possible report
> types (including very long report) and deem the device as a valid
> HID++ device if it supports at least one
>
> - Treat invalid report length as a hard stop for the validation
> algorithm, meaning that if any of the supported reports has
> invalid length we assume the worst and treat the device as a
> generic HID device.
>
> - Fold initialization of hidpp->very_long_report_length into
> hidpp_validate_device() since it already fetches very long report
> length and validates its value
>
> Fixes: fe3ee1ec007b ("HID: logitech-hidpp: allow non HID++ devices to be
> handled by this module")
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204191
> Reported-by: Sam Bazely
> Signed-off-by: Andrey Smirnov
> Cc: Jiri Kosina
> Cc: Benjamin Tissoires
> Cc: Henrik Rydberg
> Cc: Pierre-Loup A. Griffais
> Cc: Austin Palmer
> Cc: linux-in...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: sta...@vger.kernel.org # 5.2+
> ---
> drivers/hid/hid-logitech-hidpp.c | 54 ++--
> 1 file changed, 30 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/hid/hid-logitech-hidpp.c
> b/drivers/hid/hid-logitech-hidpp.c
> index 85911586b3b6..8c4be991f387 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -3498,34 +3498,45 @@ static int hidpp_get_report_length(struct hid_device
> *hdev, int id)
> return report->field[0]->report_count + 1;
> }
>
> -static bool hidpp_validate_report(struct hid_device *hdev, int id,
> - int expected_length, bool optional)
> +static bool hidpp_validate_device(struct hid_device *hdev)
> {
> - int report_length;
> + struct hidpp_device *hidpp = hid_get_drvdata(hdev);
> + int id, report_length, supported_reports = 0;
> +
> + id = REPORT_ID_HIDPP_SHORT;
> + report_length = hidpp_get_report_length(hdev, id);
> + if (report_length) {
> + if (report_length < HIDPP_REPORT_SHORT_LENGTH)
> + goto bad_device;
>
> - if (id >= HID_MAX_IDS || id < 0) {
> - hid_err(hdev, "invalid HID report id %u\n", id);
> - return false;
> + supported_reports++;
> }
>
> + id = REPORT_ID_HIDPP_LONG;
> report_length = hidpp_get_report_length(hdev, id);
> - if (!report_length)
> - return optional;
> + if (report_length) {
> + if (report_length < HIDPP_REPORT_LONG_LENGTH)
> + goto bad_device;
>
> - if (report_length < expected_length) {
> - hid_warn(hdev, "not enough values in hidpp report %d\n", id);
> - return false;
> + supported_reports++;
> }
>
> - return true;
> -}
> + id = REPORT_ID_HIDPP_VERY_LONG;
> + report_length = hidpp_get_report_length(hdev, id);
> + if (report_length) {
> + if (report_length > HIDPP_REPORT_LONG_LENGTH &&
> + report_length < HIDPP_REPORT_VERY_LONG_MAX_LENGTH)
Can you double check the conditions here?
It's late, but I think you inverted the tests as we expect the report
length to be between HIDPP_REPORT_LONG_LENGTH and
HIDPP_REPORT_VERY_LONG_MAX_LENGTH inclusive, while here this creates a
bad_device.
Other than that, I really like the series.
Cheers,
Benjamin
> + goto bad_device;
>
> -static bool hidpp_validate_device(struct hid_device *hdev)
> -{
> - return hidpp_validate_report(hdev, REPORT_ID_HIDPP_SHORT,
> -HIDPP_REPORT_SHORT_LENGTH, false) &&
> - hidpp_validate_report(hdev, REPORT_ID_HIDPP_LONG,
> -HIDPP_REPORT_LONG_LENGTH, true);
> + supported_reports++;
> +
Re: [PATCH 3/3] HID: logitech-hidpp: add G920 device validation quirk
On Sat, Oct 12, 2019 at 1:33 AM Andrey Smirnov wrote:
>
> On Fri, Oct 11, 2019 at 3:33 PM Benjamin Tissoires
> wrote:
> >
> > On Fri, Oct 11, 2019 at 9:39 PM Andrey Smirnov
> > wrote:
> > >
> > > On Fri, Oct 11, 2019 at 7:56 AM Benjamin Tissoires
> > > wrote:
> > > >
> > > > On Mon, Oct 7, 2019 at 7:13 AM Andrey Smirnov
> > > > wrote:
> > > > >
> > > > > G920 device only advertises REPORT_ID_HIDPP_LONG and
> > > > > REPORT_ID_HIDPP_VERY_LONG in its HID report descriptor, so querying
> > > > > for REPORT_ID_HIDPP_SHORT with optional=false will always fail and
> > > > > prevent G920 to be recognized as a valid HID++ device.
> > > > >
> > > > > Modify hidpp_validate_device() to check only REPORT_ID_HIDPP_LONG with
> > > > > optional=false on G920 to fix this.
> > > > >
> > > > > Fixes: fe3ee1ec007b ("HID: logitech-hidpp: allow non HID++ devices to
> > > > > be handled by this module")
> > > > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204191
> > > > > Reported-by: Sam Bazely
> > > > > Signed-off-by: Andrey Smirnov
> > > > > Cc: Jiri Kosina
> > > > > Cc: Benjamin Tissoires
> > > > > Cc: Henrik Rydberg
> > > > > Cc: Sam Bazely
> > > > > Cc: Pierre-Loup A. Griffais
> > > > > Cc: Austin Palmer
> > > > > Cc: linux-in...@vger.kernel.org
> > > > > Cc: linux-kernel@vger.kernel.org
> > > > > Cc: sta...@vger.kernel.org
> > > > > ---
> > > > > drivers/hid/hid-logitech-hidpp.c | 6 ++
> > > > > 1 file changed, 6 insertions(+)
> > > > >
> > > > > diff --git a/drivers/hid/hid-logitech-hidpp.c
> > > > > b/drivers/hid/hid-logitech-hidpp.c
> > > > > index cadf36d6c6f3..f415bf398e17 100644
> > > > > --- a/drivers/hid/hid-logitech-hidpp.c
> > > > > +++ b/drivers/hid/hid-logitech-hidpp.c
> > > > > @@ -3511,6 +3511,12 @@ static bool hidpp_validate_report(struct
> > > > > hid_device *hdev, int id,
> > > > >
> > > > > static bool hidpp_validate_device(struct hid_device *hdev)
> > > > > {
> > > > > + struct hidpp_device *hidpp = hid_get_drvdata(hdev);
> > > > > +
> > > > > + if (hidpp->quirks & HIDPP_QUIRK_CLASS_G920)
> > > > > + return hidpp_validate_report(hdev,
> > > > > REPORT_ID_HIDPP_LONG,
> > > > > +
> > > > > HIDPP_REPORT_SHORT_LENGTH, false);
> > > > > +
> > > >
> > > > with https://patchwork.kernel.org/patch/11184749/ we also have a need
> > > > for such a trick for BLE mice.
> > > >
> > > > I wonder if we should not have a more common way of validating the
> > > > devices
> > > >
> > >
> > > What about just checking for:
> > >
> > > hidpp_validate_report(REPORT_ID_HIDPP_SHORT,
> > > HIDPP_REPORT_SHORT_LENGTH, true) ||
> > > hidpp_validate_report(hdev, REPORT_ID_HIDPP_LONG,
> > > HIDPP_REPORT_LONG_LENGTH, true);
> > >
> > > and probably dropping the "optional" argument for
> > > hidpp_validate_report()? Original code allows there to be devices
> > > supporting shorts reports only, but it seems that devices that support
> > > only long reports are legitimate too, so maybe the only "invalid"
> > > combination is if both are invalid length or missing?
> >
> > Well, the problem is we also want to detect 2 things:
> > - devices that do not have any of the HID++ collections, and handle
> > them as generic ones (the second mouse/keyboard collection in the
> > gaming mice should still be exported by the driver, or this will kill
> > the macros / rebinding capabilities
> > - malicious devices that pretends to have a HID++ collection but want
> > to trigger a buffer overflow by having a shorter than expected report
> > length
> >
> > Point 2 above should still be fine, but point 1 is why we have the
> > enforcement of the HID++ short report in the first place.
> >
>
> It sounds like the result of hidpp_validate_report() can't really be
> contained in a bool. If we modify it to
Re: [PATCH 1/3] HID: logitech-hidpp: use devres to manage FF private data
On Sat, Oct 12, 2019 at 1:24 AM Dmitry Torokhov wrote: > > On Sat, Oct 12, 2019 at 12:48:42AM +0200, Benjamin Tissoires wrote: > > On Fri, Oct 11, 2019 at 11:34 PM Dmitry Torokhov > > wrote: > > > > > > On Fri, Oct 11, 2019 at 01:35:09PM -0700, Dmitry Torokhov wrote: > > > > On Fri, Oct 11, 2019 at 01:33:03PM -0700, Dmitry Torokhov wrote: > > > > > On Fri, Oct 11, 2019 at 09:25:52PM +0200, Benjamin Tissoires wrote: > > > > > > On Fri, Oct 11, 2019 at 8:26 PM Dmitry Torokhov > > > > > > wrote: > > > > > > > > > > > > > > On Fri, Oct 11, 2019 at 04:52:04PM +0200, Benjamin Tissoires > > > > > > > wrote: > > > > > > > > Hi Andrey, > > > > > > > > > > > > > > > > On Mon, Oct 7, 2019 at 7:13 AM Andrey Smirnov > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > To simplify resource management in commit that follows as > > > > > > > > > well as to > > > > > > > > > save a couple of extra kfree()s and simplify > > > > > > > > > hidpp_ff_deinit() switch > > > > > > > > > driver code to use devres to manage the life-cycle of FF > > > > > > > > > private data. > > > > > > > > > > > > > > > > > > Signed-off-by: Andrey Smirnov > > > > > > > > > Cc: Jiri Kosina > > > > > > > > > Cc: Benjamin Tissoires > > > > > > > > > Cc: Henrik Rydberg > > > > > > > > > Cc: Sam Bazely > > > > > > > > > Cc: Pierre-Loup A. Griffais > > > > > > > > > Cc: Austin Palmer > > > > > > > > > Cc: linux-in...@vger.kernel.org > > > > > > > > > Cc: linux-kernel@vger.kernel.org > > > > > > > > > Cc: sta...@vger.kernel.org > > > > > > > > > > > > > > > > This patch doesn't seem to fix any error, is there a reason to > > > > > > > > send it > > > > > > > > to stable? (besides as a dependency of the rest of the series). > > > > > > > > > > > > > > > > > --- > > > > > > > > > drivers/hid/hid-logitech-hidpp.c | 53 > > > > > > > > > +--- > > > > > > > > > 1 file changed, 29 insertions(+), 24 deletions(-) > > > > > > > > > > > > > > > > > > diff --git a/drivers/hid/hid-logitech-hidpp.c > > > > > > > > > b/drivers/hid/hid-logitech-hidpp.c > > > > > > > > > index 0179f7ed77e5..58eb928224e5 100644 > > > > > > > > > --- a/drivers/hid/hid-logitech-hidpp.c > > > > > > > > > +++ b/drivers/hid/hid-logitech-hidpp.c > > > > > > > > > @@ -2079,6 +2079,11 @@ static void hidpp_ff_destroy(struct > > > > > > > > > ff_device *ff) > > > > > > > > > struct hidpp_ff_private_data *data = ff->private; > > > > > > > > > > > > > > > > > > kfree(data->effect_ids); > > > > > > > > > > > > > > > > Is there any reasons we can not also devm alloc > > > > > > > > data->effect_ids? > > > > > > > > > > > > > > > > > + /* > > > > > > > > > +* Set private to NULL to prevent input_ff_destroy() > > > > > > > > > from > > > > > > > > > +* freeing our devres allocated memory > > > > > > > > > > > > > > > > Ouch. There is something wrong here: input_ff_destroy() calls > > > > > > > > kfree(ff->private), when the data has not been allocated by > > > > > > > > input_ff_create(). This seems to lack a little bit of symmetry. > > > > > > > > > > > > > > Yeah, ff and ff-memless essentially take over the private data > > > > > > > assigned > > > > > > > to them. They were done before devm and the lifetime of the > > > > > > > "private&
Re: [PATCH v5 1/2] HID: logitech: Add MX Master over Bluetooth
^~~ > > > > > > drivers/hid/hid-logitech-hidpp.c:85:40: note: in expansion of macro > > 'HIDPP_QUIRK_MISSING_SHORT_REPORTS' > > #define HIDPP_QUIRK_CLASS_BLUETOOTH_LE HIDPP_QUIRK_MISSING_SHORT_REPORTS > > ^ > > drivers/hid/hid-logitech-hidpp.c:3797:5: note: in expansion of macro > > 'HIDPP_QUIRK_CLASS_BLUETOOTH_LE' > > HIDPP_QUIRK_CLASS_BLUETOOTH_LE }, > > ^~ > > > > -- > > > > In file included from include/linux/ioport.h:15:0, > > from include/linux/device.h:15, > > from drivers//hid/hid-logitech-hidpp.c:13: > > drivers//hid/hid-logitech-hidpp.c: In function > > 'hidpp_send_rap_command_sync': > > > > > > include/linux/bits.h:8:26: warning: left shift count >= width of type > > > > [-Wshift-count-overflow] > > > > #define BIT(nr) (UL(1) << (nr)) > > ^ > > > > > > drivers//hid/hid-logitech-hidpp.c:74:43: note: in expansion of macro 'BIT' > > #define HIDPP_QUIRK_MISSING_SHORT_REPORTS BIT(32) > > ^~~ > > drivers//hid/hid-logitech-hidpp.c:347:26: note: in expansion of macro > > 'HIDPP_QUIRK_MISSING_SHORT_REPORTS' > > if (hidpp_dev->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS && > > > > ^ > > > > > > drivers//hid/hid-logitech-hidpp.c: In function 'hidpp_validate_device': > > > > > > include/linux/bits.h:8:26: warning: left shift count >= width of type > > > > [-Wshift-count-overflow] > > > > #define BIT(nr) (UL(1) << (nr)) > > ^ > > > > > > drivers//hid/hid-logitech-hidpp.c:74:43: note: in expansion of macro 'BIT' > > #define HIDPP_QUIRK_MISSING_SHORT_REPORTS BIT(32) > > ^~~ > > drivers//hid/hid-logitech-hidpp.c:3496:22: note: in expansion of macro > > 'HIDPP_QUIRK_MISSING_SHORT_REPORTS' > > if (hidpp->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS) > > > > ^ > > > > > > drivers//hid/hid-logitech-hidpp.c: At top level: > > > > > > include/linux/bits.h:8:26: warning: left shift count >= width of type > > > > [-Wshift-count-overflow] > > > > #define BIT(nr) (UL(1) << (nr)) > > ^ > > > > > > drivers//hid/hid-logitech-hidpp.c:74:43: note: in expansion of macro 'BIT' > > #define HIDPP_QUIRK_MISSING_SHORT_REPORTS BIT(32) > > ^~~ > > drivers//hid/hid-logitech-hidpp.c:85:40: note: in expansion of macro > > 'HIDPP_QUIRK_MISSING_SHORT_REPORTS' > > #define HIDPP_QUIRK_CLASS_BLUETOOTH_LE HIDPP_QUIRK_MISSING_SHORT_REPORTS > > ^ > > drivers//hid/hid-logitech-hidpp.c:3794:5: note: in expansion of macro > > 'HIDPP_QUIRK_CLASS_BLUETOOTH_LE' > > HIDPP_QUIRK_CLASS_BLUETOOTH_LE }, > > ^~ > > > > > > include/linux/bits.h:8:26: warning: left shift count >= width of type > > > > [-Wshift-count-overflow] > > > > #define BIT(nr) (UL(1) << (nr)) > > ^ > > > > > > drivers//hid/hid-logitech-hidpp.c:74:43: note: in expansion of macro 'BIT' > > #define HIDPP_QUIRK_MISSING_SHORT_REPORTS BIT(32) > > ^~~ > > drivers//hid/hid-logitech-hidpp.c:85:40: note: in expansion of macro > > 'HIDPP_QUIRK_MISSING_SHORT_REPORTS' > > #define HIDPP_QUIRK_CLASS_BLUETOOTH_LE HIDPP_QUIRK_MISSING_SHORT_REPORTS > > ^ > > drivers//hid/hid-logitech-hidpp.c:3797:5: note: in expansion of macro > > 'HIDPP_QUIRK_CLASS_BLUETOOTH_LE' > > HIDPP_QUIRK_CLASS_BLUETOOTH_LE }, > > ^~ > > > > vim +/BIT +74 drivers/hid/hid-logitech-hidpp.c > > > > 12 > > > > > 13 #include > > > > 14#include > > > > 15#include > > > > 16#include > > > > 17#include > > > > 18#include > > > > 19#include > > > > 20#include > > > > 21#in
Re: [PATCH 1/3] HID: logitech-hidpp: use devres to manage FF private data
On Fri, Oct 11, 2019 at 11:34 PM Dmitry Torokhov wrote: > > On Fri, Oct 11, 2019 at 01:35:09PM -0700, Dmitry Torokhov wrote: > > On Fri, Oct 11, 2019 at 01:33:03PM -0700, Dmitry Torokhov wrote: > > > On Fri, Oct 11, 2019 at 09:25:52PM +0200, Benjamin Tissoires wrote: > > > > On Fri, Oct 11, 2019 at 8:26 PM Dmitry Torokhov > > > > wrote: > > > > > > > > > > On Fri, Oct 11, 2019 at 04:52:04PM +0200, Benjamin Tissoires wrote: > > > > > > Hi Andrey, > > > > > > > > > > > > On Mon, Oct 7, 2019 at 7:13 AM Andrey Smirnov > > > > > > wrote: > > > > > > > > > > > > > > To simplify resource management in commit that follows as well as > > > > > > > to > > > > > > > save a couple of extra kfree()s and simplify hidpp_ff_deinit() > > > > > > > switch > > > > > > > driver code to use devres to manage the life-cycle of FF private > > > > > > > data. > > > > > > > > > > > > > > Signed-off-by: Andrey Smirnov > > > > > > > Cc: Jiri Kosina > > > > > > > Cc: Benjamin Tissoires > > > > > > > Cc: Henrik Rydberg > > > > > > > Cc: Sam Bazely > > > > > > > Cc: Pierre-Loup A. Griffais > > > > > > > Cc: Austin Palmer > > > > > > > Cc: linux-in...@vger.kernel.org > > > > > > > Cc: linux-kernel@vger.kernel.org > > > > > > > Cc: sta...@vger.kernel.org > > > > > > > > > > > > This patch doesn't seem to fix any error, is there a reason to send > > > > > > it > > > > > > to stable? (besides as a dependency of the rest of the series). > > > > > > > > > > > > > --- > > > > > > > drivers/hid/hid-logitech-hidpp.c | 53 > > > > > > > +--- > > > > > > > 1 file changed, 29 insertions(+), 24 deletions(-) > > > > > > > > > > > > > > diff --git a/drivers/hid/hid-logitech-hidpp.c > > > > > > > b/drivers/hid/hid-logitech-hidpp.c > > > > > > > index 0179f7ed77e5..58eb928224e5 100644 > > > > > > > --- a/drivers/hid/hid-logitech-hidpp.c > > > > > > > +++ b/drivers/hid/hid-logitech-hidpp.c > > > > > > > @@ -2079,6 +2079,11 @@ static void hidpp_ff_destroy(struct > > > > > > > ff_device *ff) > > > > > > > struct hidpp_ff_private_data *data = ff->private; > > > > > > > > > > > > > > kfree(data->effect_ids); > > > > > > > > > > > > Is there any reasons we can not also devm alloc data->effect_ids? > > > > > > > > > > > > > + /* > > > > > > > +* Set private to NULL to prevent input_ff_destroy() from > > > > > > > +* freeing our devres allocated memory > > > > > > > > > > > > Ouch. There is something wrong here: input_ff_destroy() calls > > > > > > kfree(ff->private), when the data has not been allocated by > > > > > > input_ff_create(). This seems to lack a little bit of symmetry. > > > > > > > > > > Yeah, ff and ff-memless essentially take over the private data > > > > > assigned > > > > > to them. They were done before devm and the lifetime of the "private" > > > > > data pieces was tied to the lifetime of the input device to simplify > > > > > error handling and teardown. > > > > > > > > Yeah, that stealing of the pointer is not good :) > > > > But OTOH, it helps > > > > > > > > > > > > > > Maybe we should clean it up a bit... I'm open to suggestions. > > > > > > > > The problem I had when doing the review was that there is no easy way > > > > to have a "devm_input_ff_create_()", because the way it's built is > > > > already "devres-compatible": the destroy gets called by input core. > > > > > > I do not think we want devm_input_ff_create() explicitly, I think the > > > fact that you can "build up" an input device by allocating it, then > > > adding slots, poller, ff support,
Re: [PATCH 1/3] HID: logitech-hidpp: use devres to manage FF private data
On Fri, Oct 11, 2019 at 10:33 PM Dmitry Torokhov wrote: > > On Fri, Oct 11, 2019 at 09:25:52PM +0200, Benjamin Tissoires wrote: > > On Fri, Oct 11, 2019 at 8:26 PM Dmitry Torokhov > > wrote: > > > > > > On Fri, Oct 11, 2019 at 04:52:04PM +0200, Benjamin Tissoires wrote: > > > > Hi Andrey, > > > > > > > > On Mon, Oct 7, 2019 at 7:13 AM Andrey Smirnov > > > > wrote: > > > > > > > > > > To simplify resource management in commit that follows as well as to > > > > > save a couple of extra kfree()s and simplify hidpp_ff_deinit() switch > > > > > driver code to use devres to manage the life-cycle of FF private data. > > > > > > > > > > Signed-off-by: Andrey Smirnov > > > > > Cc: Jiri Kosina > > > > > Cc: Benjamin Tissoires > > > > > Cc: Henrik Rydberg > > > > > Cc: Sam Bazely > > > > > Cc: Pierre-Loup A. Griffais > > > > > Cc: Austin Palmer > > > > > Cc: linux-in...@vger.kernel.org > > > > > Cc: linux-kernel@vger.kernel.org > > > > > Cc: sta...@vger.kernel.org > > > > > > > > This patch doesn't seem to fix any error, is there a reason to send it > > > > to stable? (besides as a dependency of the rest of the series). > > > > > > > > > --- > > > > > drivers/hid/hid-logitech-hidpp.c | 53 > > > > > +--- > > > > > 1 file changed, 29 insertions(+), 24 deletions(-) > > > > > > > > > > diff --git a/drivers/hid/hid-logitech-hidpp.c > > > > > b/drivers/hid/hid-logitech-hidpp.c > > > > > index 0179f7ed77e5..58eb928224e5 100644 > > > > > --- a/drivers/hid/hid-logitech-hidpp.c > > > > > +++ b/drivers/hid/hid-logitech-hidpp.c > > > > > @@ -2079,6 +2079,11 @@ static void hidpp_ff_destroy(struct ff_device > > > > > *ff) > > > > > struct hidpp_ff_private_data *data = ff->private; > > > > > > > > > > kfree(data->effect_ids); > > > > > > > > Is there any reasons we can not also devm alloc data->effect_ids? > > > > > > > > > + /* > > > > > +* Set private to NULL to prevent input_ff_destroy() from > > > > > +* freeing our devres allocated memory > > > > > > > > Ouch. There is something wrong here: input_ff_destroy() calls > > > > kfree(ff->private), when the data has not been allocated by > > > > input_ff_create(). This seems to lack a little bit of symmetry. > > > > > > Yeah, ff and ff-memless essentially take over the private data assigned > > > to them. They were done before devm and the lifetime of the "private" > > > data pieces was tied to the lifetime of the input device to simplify > > > error handling and teardown. > > > > Yeah, that stealing of the pointer is not good :) > > But OTOH, it helps > > > > > > > > Maybe we should clean it up a bit... I'm open to suggestions. > > > > The problem I had when doing the review was that there is no easy way > > to have a "devm_input_ff_create_()", because the way it's built is > > already "devres-compatible": the destroy gets called by input core. > > I do not think we want devm_input_ff_create() explicitly, I think the > fact that you can "build up" an input device by allocating it, then > adding slots, poller, ff support, etc, and input core cleans it up is > all good. It is just the ownership if the driver-private data block is > not very obvious and is not compatible with allocating via devm. Yep, that's what I meant: input_ff_create() already handles its cleanup, so there is no point in devm_input_ff_create() as the input core should clean it up for us. Cheers, Benjamin > > > > > So I don't have a good answer to simplify in a transparent manner > > without breaking the API. > > > > > > > > In this case maybe best way is to get rid of hidpp_ff_destroy() and not > > > set ff->private and rely on devm to free the buffers. One can get to > > > device private data from ff methods via input_get_drvdata() since they > > > all (except destroy) are passed input device pointer. > > > > Sounds like a good idea. However, it seems there might be a race when > > removing the workqueue: > > the workqueue gets deleted in hidpp_remove, when the input node will > > be freed by devres, so after the call of hidpp_remove. > > Yeah, well, that is a common issue with mixing devm and normal resources > (and workqueue here is that "normal" resource), and we should either: > > - not use devm > - use devm_add_action_or_reset() to work in custom actions that work > freeing of non-managed resources into devm flow. > > Thanks. > > -- > Dmitry
Re: [PATCH 3/3] HID: logitech-hidpp: add G920 device validation quirk
On Fri, Oct 11, 2019 at 9:39 PM Andrey Smirnov wrote:
>
> On Fri, Oct 11, 2019 at 7:56 AM Benjamin Tissoires
> wrote:
> >
> > On Mon, Oct 7, 2019 at 7:13 AM Andrey Smirnov
> > wrote:
> > >
> > > G920 device only advertises REPORT_ID_HIDPP_LONG and
> > > REPORT_ID_HIDPP_VERY_LONG in its HID report descriptor, so querying
> > > for REPORT_ID_HIDPP_SHORT with optional=false will always fail and
> > > prevent G920 to be recognized as a valid HID++ device.
> > >
> > > Modify hidpp_validate_device() to check only REPORT_ID_HIDPP_LONG with
> > > optional=false on G920 to fix this.
> > >
> > > Fixes: fe3ee1ec007b ("HID: logitech-hidpp: allow non HID++ devices to be
> > > handled by this module")
> > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204191
> > > Reported-by: Sam Bazely
> > > Signed-off-by: Andrey Smirnov
> > > Cc: Jiri Kosina
> > > Cc: Benjamin Tissoires
> > > Cc: Henrik Rydberg
> > > Cc: Sam Bazely
> > > Cc: Pierre-Loup A. Griffais
> > > Cc: Austin Palmer
> > > Cc: linux-in...@vger.kernel.org
> > > Cc: linux-kernel@vger.kernel.org
> > > Cc: sta...@vger.kernel.org
> > > ---
> > > drivers/hid/hid-logitech-hidpp.c | 6 ++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/drivers/hid/hid-logitech-hidpp.c
> > > b/drivers/hid/hid-logitech-hidpp.c
> > > index cadf36d6c6f3..f415bf398e17 100644
> > > --- a/drivers/hid/hid-logitech-hidpp.c
> > > +++ b/drivers/hid/hid-logitech-hidpp.c
> > > @@ -3511,6 +3511,12 @@ static bool hidpp_validate_report(struct
> > > hid_device *hdev, int id,
> > >
> > > static bool hidpp_validate_device(struct hid_device *hdev)
> > > {
> > > + struct hidpp_device *hidpp = hid_get_drvdata(hdev);
> > > +
> > > + if (hidpp->quirks & HIDPP_QUIRK_CLASS_G920)
> > > + return hidpp_validate_report(hdev, REPORT_ID_HIDPP_LONG,
> > > +HIDPP_REPORT_SHORT_LENGTH,
> > > false);
> > > +
> >
> > with https://patchwork.kernel.org/patch/11184749/ we also have a need
> > for such a trick for BLE mice.
> >
> > I wonder if we should not have a more common way of validating the devices
> >
>
> What about just checking for:
>
> hidpp_validate_report(REPORT_ID_HIDPP_SHORT,
> HIDPP_REPORT_SHORT_LENGTH, true) ||
> hidpp_validate_report(hdev, REPORT_ID_HIDPP_LONG,
> HIDPP_REPORT_LONG_LENGTH, true);
>
> and probably dropping the "optional" argument for
> hidpp_validate_report()? Original code allows there to be devices
> supporting shorts reports only, but it seems that devices that support
> only long reports are legitimate too, so maybe the only "invalid"
> combination is if both are invalid length or missing?
Well, the problem is we also want to detect 2 things:
- devices that do not have any of the HID++ collections, and handle
them as generic ones (the second mouse/keyboard collection in the
gaming mice should still be exported by the driver, or this will kill
the macros / rebinding capabilities
- malicious devices that pretends to have a HID++ collection but want
to trigger a buffer overflow by having a shorter than expected report
length
Point 2 above should still be fine, but point 1 is why we have the
enforcement of the HID++ short report in the first place.
Cheers,
Benjamin
>
> Thanks,
> Andrey Smirnov
Re: [PATCH 1/3] HID: logitech-hidpp: use devres to manage FF private data
On Fri, Oct 11, 2019 at 8:26 PM Dmitry Torokhov wrote: > > On Fri, Oct 11, 2019 at 04:52:04PM +0200, Benjamin Tissoires wrote: > > Hi Andrey, > > > > On Mon, Oct 7, 2019 at 7:13 AM Andrey Smirnov > > wrote: > > > > > > To simplify resource management in commit that follows as well as to > > > save a couple of extra kfree()s and simplify hidpp_ff_deinit() switch > > > driver code to use devres to manage the life-cycle of FF private data. > > > > > > Signed-off-by: Andrey Smirnov > > > Cc: Jiri Kosina > > > Cc: Benjamin Tissoires > > > Cc: Henrik Rydberg > > > Cc: Sam Bazely > > > Cc: Pierre-Loup A. Griffais > > > Cc: Austin Palmer > > > Cc: linux-in...@vger.kernel.org > > > Cc: linux-kernel@vger.kernel.org > > > Cc: sta...@vger.kernel.org > > > > This patch doesn't seem to fix any error, is there a reason to send it > > to stable? (besides as a dependency of the rest of the series). > > > > > --- > > > drivers/hid/hid-logitech-hidpp.c | 53 +--- > > > 1 file changed, 29 insertions(+), 24 deletions(-) > > > > > > diff --git a/drivers/hid/hid-logitech-hidpp.c > > > b/drivers/hid/hid-logitech-hidpp.c > > > index 0179f7ed77e5..58eb928224e5 100644 > > > --- a/drivers/hid/hid-logitech-hidpp.c > > > +++ b/drivers/hid/hid-logitech-hidpp.c > > > @@ -2079,6 +2079,11 @@ static void hidpp_ff_destroy(struct ff_device *ff) > > > struct hidpp_ff_private_data *data = ff->private; > > > > > > kfree(data->effect_ids); > > > > Is there any reasons we can not also devm alloc data->effect_ids? > > > > > + /* > > > +* Set private to NULL to prevent input_ff_destroy() from > > > +* freeing our devres allocated memory > > > > Ouch. There is something wrong here: input_ff_destroy() calls > > kfree(ff->private), when the data has not been allocated by > > input_ff_create(). This seems to lack a little bit of symmetry. > > Yeah, ff and ff-memless essentially take over the private data assigned > to them. They were done before devm and the lifetime of the "private" > data pieces was tied to the lifetime of the input device to simplify > error handling and teardown. Yeah, that stealing of the pointer is not good :) But OTOH, it helps > > Maybe we should clean it up a bit... I'm open to suggestions. The problem I had when doing the review was that there is no easy way to have a "devm_input_ff_create_()", because the way it's built is already "devres-compatible": the destroy gets called by input core. So I don't have a good answer to simplify in a transparent manner without breaking the API. > > In this case maybe best way is to get rid of hidpp_ff_destroy() and not > set ff->private and rely on devm to free the buffers. One can get to > device private data from ff methods via input_get_drvdata() since they > all (except destroy) are passed input device pointer. Sounds like a good idea. However, it seems there might be a race when removing the workqueue: the workqueue gets deleted in hidpp_remove, when the input node will be freed by devres, so after the call of hidpp_remove. So we should probably keep hidpp_ff_destroy() to clean up the ff bits, and instead move the content of hidpp_ff_deinit() into hidpp_ff_destroy() so we ensure proper ordering. Andrey, note that ensuring the workqueue gets freed after the call of input_destroy_device is something that should definitively go into stable as this is a potential race problem. Cheers, Benjamin
Re: [PATCH 1/3] HID: logitech-hidpp: use devres to manage FF private data
Hi Andrey, On Fri, Oct 11, 2019 at 8:19 PM Andrey Smirnov wrote: > > On Fri, Oct 11, 2019 at 7:52 AM Benjamin Tissoires > wrote: > > > > Hi Andrey, > > > > On Mon, Oct 7, 2019 at 7:13 AM Andrey Smirnov > > wrote: > > > > > > To simplify resource management in commit that follows as well as to > > > save a couple of extra kfree()s and simplify hidpp_ff_deinit() switch > > > driver code to use devres to manage the life-cycle of FF private data. > > > > > > Signed-off-by: Andrey Smirnov > > > Cc: Jiri Kosina > > > Cc: Benjamin Tissoires > > > Cc: Henrik Rydberg > > > Cc: Sam Bazely > > > Cc: Pierre-Loup A. Griffais > > > Cc: Austin Palmer > > > Cc: linux-in...@vger.kernel.org > > > Cc: linux-kernel@vger.kernel.org > > > Cc: sta...@vger.kernel.org > > > > This patch doesn't seem to fix any error, is there a reason to send it > > to stable? (besides as a dependency of the rest of the series). > > > > Dependency is the only reason for this patch, but it is a pretty big > reason. Prior to patches 1/3 and 2/3 FF private data was both > allocated and passed off to FF layer via ff->private = data in a span > of a few lines of code within hidpp_ff_init()/g920_get_config(). > After, said pair is effectively split into two different functions, > both needing access to FF private data, but called quite far apart in > hidpp_probe(). Alternatives to patch 1/3 would be to either make sure > that every error path in hidpp_prob() after the call to > g920_allocate() is aware of allocated FF data, which seems like a > nightmare, or, to create a temporary FF data, fill it in > g920_get_config() and memdup() it in hidpp_ff_init(). Is that (the > latter) the path that you prefer to take? Hmm, I don't have a strong opinion on that. The point I don't like with the devres version is that it seems like a half-backed solution, as part of the driver would use devres while parts for the same purpose will not. I do not consider your code untrusted, but this is usually a reasonable source of leakages, so as a rule a thumb, devres should be used in a all or nothing fashion. Basically, both alternative solutions would be OK with me, as long as the scope of each patch is reduced to the minimum (and having more than one is OK too). > > > > --- > > > drivers/hid/hid-logitech-hidpp.c | 53 +--- > > > 1 file changed, 29 insertions(+), 24 deletions(-) > > > > > > diff --git a/drivers/hid/hid-logitech-hidpp.c > > > b/drivers/hid/hid-logitech-hidpp.c > > > index 0179f7ed77e5..58eb928224e5 100644 > > > --- a/drivers/hid/hid-logitech-hidpp.c > > > +++ b/drivers/hid/hid-logitech-hidpp.c > > > @@ -2079,6 +2079,11 @@ static void hidpp_ff_destroy(struct ff_device *ff) > > > struct hidpp_ff_private_data *data = ff->private; > > > > > > kfree(data->effect_ids); > > > > Is there any reasons we can not also devm alloc data->effect_ids? > > No, but I was trying to limit the scope of this patch. > > > > > > + /* > > > +* Set private to NULL to prevent input_ff_destroy() from > > > +* freeing our devres allocated memory > > > > Ouch. There is something wrong here: input_ff_destroy() calls > > kfree(ff->private), when the data has not been allocated by > > input_ff_create(). This seems to lack a little bit of symmetry. > > > > I agree, I think it's a wart in FF API design. Yep, see Dmitry's answer for ideas :) > > > > +*/ > > > + ff->private = NULL; > > > } > > > > > > static int hidpp_ff_init(struct hidpp_device *hidpp, u8 feature_index) > > > @@ -2090,7 +2095,7 @@ static int hidpp_ff_init(struct hidpp_device > > > *hidpp, u8 feature_index) > > > const u16 bcdDevice = le16_to_cpu(udesc->bcdDevice); > > > struct ff_device *ff; > > > struct hidpp_report response; > > > - struct hidpp_ff_private_data *data; > > > + struct hidpp_ff_private_data *data = hidpp->private_data; > > > int error, j, num_slots; > > > u8 version; > > > > > > @@ -2129,18 +2134,13 @@ static int hidpp_ff_init(struct hidpp_device > > > *hidpp, u8 feature_index) > > > return error; > > > } > > > > > > - data = kzalloc(sizeof(*data), GFP_KERNEL); > > > - if (!data) > > > - return -ENOMEM; > > > d
Re: [PATCH] Revert "Input: elantech - enable SMBus on new (2018+) systems"
Hi Kai-Heng,
On Tue, Oct 1, 2019 at 9:09 AM Kai-Heng Feng
wrote:
>
> This reverts commit 883a2a80f79ca5c0c105605fafabd1f3df99b34c.
>
> Apparently use dmi_get_bios_year() as manufacturing date isn't accurate
> and this breaks older laptops with new BIOS update.
>
> So let's revert this patch.
>
> There are still new HP laptops still need to use SMBus to support all
> features, but it'll be enabled via a whitelist.
>
You might want to add here:
Link: https://bugzilla.kernel.org/show_bug.cgi?id=204771
> Signed-off-by: Kai-Heng Feng
Oops, seems like you are missing my acked by:
Acked-by: Benjamin Tissoires
Also, don't we want to send this one to stable as well? I can't
remember if we reverted it in all the released kernels.
Cheers,
Benjamin
> ---
> drivers/input/mouse/elantech.c | 55 ++
> 1 file changed, 29 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
> index 04fe43440a3c..2d8434b7b623 100644
> --- a/drivers/input/mouse/elantech.c
> +++ b/drivers/input/mouse/elantech.c
> @@ -1827,31 +1827,6 @@ static int elantech_create_smbus(struct psmouse
> *psmouse,
> leave_breadcrumbs);
> }
>
> -static bool elantech_use_host_notify(struct psmouse *psmouse,
> -struct elantech_device_info *info)
> -{
> - if (ETP_NEW_IC_SMBUS_HOST_NOTIFY(info->fw_version))
> - return true;
> -
> - switch (info->bus) {
> - case ETP_BUS_PS2_ONLY:
> - /* expected case */
> - break;
> - case ETP_BUS_SMB_HST_NTFY_ONLY:
> - case ETP_BUS_PS2_SMB_HST_NTFY:
> - /* SMbus implementation is stable since 2018 */
> - if (dmi_get_bios_year() >= 2018)
> - return true;
> - /* fall through */
> - default:
> - psmouse_dbg(psmouse,
> - "Ignoring SMBus bus provider %d\n", info->bus);
> - break;
> - }
> -
> - return false;
> -}
> -
> /**
> * elantech_setup_smbus - called once the PS/2 devices are enumerated
> * and decides to instantiate a SMBus InterTouch device.
> @@ -1871,7 +1846,7 @@ static int elantech_setup_smbus(struct psmouse *psmouse,
> * i2c_blacklist_pnp_ids.
> * Old ICs are up to the user to decide.
> */
> - if (!elantech_use_host_notify(psmouse, info) ||
> + if (!ETP_NEW_IC_SMBUS_HOST_NOTIFY(info->fw_version) ||
> psmouse_matches_pnp_id(psmouse, i2c_blacklist_pnp_ids))
> return -ENXIO;
> }
> @@ -1891,6 +1866,34 @@ static int elantech_setup_smbus(struct psmouse
> *psmouse,
> return 0;
> }
>
> +static bool elantech_use_host_notify(struct psmouse *psmouse,
> +struct elantech_device_info *info)
> +{
> + if (ETP_NEW_IC_SMBUS_HOST_NOTIFY(info->fw_version))
> + return true;
> +
> + switch (info->bus) {
> + case ETP_BUS_PS2_ONLY:
> + /* expected case */
> + break;
> + case ETP_BUS_SMB_ALERT_ONLY:
> + /* fall-through */
> + case ETP_BUS_PS2_SMB_ALERT:
> + psmouse_dbg(psmouse, "Ignoring SMBus provider through alert
> protocol.\n");
> + break;
> + case ETP_BUS_SMB_HST_NTFY_ONLY:
> + /* fall-through */
> + case ETP_BUS_PS2_SMB_HST_NTFY:
> + return true;
> + default:
> + psmouse_dbg(psmouse,
> + "Ignoring SMBus bus provider %d.\n",
> + info->bus);
> + }
> +
> + return false;
> +}
> +
> int elantech_init_smbus(struct psmouse *psmouse)
> {
> struct elantech_device_info info;
> --
> 2.17.1
>
Re: [PATCH 3/3] HID: logitech-hidpp: add G920 device validation quirk
On Mon, Oct 7, 2019 at 7:13 AM Andrey Smirnov wrote:
>
> G920 device only advertises REPORT_ID_HIDPP_LONG and
> REPORT_ID_HIDPP_VERY_LONG in its HID report descriptor, so querying
> for REPORT_ID_HIDPP_SHORT with optional=false will always fail and
> prevent G920 to be recognized as a valid HID++ device.
>
> Modify hidpp_validate_device() to check only REPORT_ID_HIDPP_LONG with
> optional=false on G920 to fix this.
>
> Fixes: fe3ee1ec007b ("HID: logitech-hidpp: allow non HID++ devices to be
> handled by this module")
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204191
> Reported-by: Sam Bazely
> Signed-off-by: Andrey Smirnov
> Cc: Jiri Kosina
> Cc: Benjamin Tissoires
> Cc: Henrik Rydberg
> Cc: Sam Bazely
> Cc: Pierre-Loup A. Griffais
> Cc: Austin Palmer
> Cc: linux-in...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: sta...@vger.kernel.org
> ---
> drivers/hid/hid-logitech-hidpp.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/hid/hid-logitech-hidpp.c
> b/drivers/hid/hid-logitech-hidpp.c
> index cadf36d6c6f3..f415bf398e17 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -3511,6 +3511,12 @@ static bool hidpp_validate_report(struct hid_device
> *hdev, int id,
>
> static bool hidpp_validate_device(struct hid_device *hdev)
> {
> + struct hidpp_device *hidpp = hid_get_drvdata(hdev);
> +
> + if (hidpp->quirks & HIDPP_QUIRK_CLASS_G920)
> + return hidpp_validate_report(hdev, REPORT_ID_HIDPP_LONG,
> +HIDPP_REPORT_SHORT_LENGTH,
> false);
> +
with https://patchwork.kernel.org/patch/11184749/ we also have a need
for such a trick for BLE mice.
I wonder if we should not have a more common way of validating the devices
This can probably be handled later, as your patch fixes the current devices.
Cheers,
Benjamin
> return hidpp_validate_report(hdev, REPORT_ID_HIDPP_SHORT,
> HIDPP_REPORT_SHORT_LENGTH, false) &&
>hidpp_validate_report(hdev, REPORT_ID_HIDPP_LONG,
> --
> 2.21.0
>
Re: [PATCH 0/3] Logitech G920 fixes
Hi,
Finally, someone who takes care of the G920!
Note that when I sent my first initial version that Hans reused, I
surely broke it (looking at your patch 3/3), but no one cared to test
it :(
On Mon, Oct 7, 2019 at 7:13 AM Andrey Smirnov wrote:
>
> Everyone:
>
> This series contains patches to fix a couple of regressions in G920
> wheel support by hid-logitech-hidpp driver. Without the patches the
> wheel remains stuck in autocentering mode ("resisting" any attempt to
> trun) as well as missing support for any FF action.
So, you are talking about regressions, and for that I would like to be
able to push the patches to stable.
However, I would need more information:
- patch 3/3 seems simple enough to go in stable, and is clearly a
regression from the recent series. Can you put it in first and add
sta...@vger.kernel.org in a CC field (and possibly with a Fixes tag as
well)?
- I am not sure which patch fixes the wheel remains stuck in
autocentering mode. Is it patch 2/3?
- was the "wheel remains stuck in autocentering mode" bug present from
on of the recent patch or was it always there since we introduced
support in hid-logitech-hidpp, but the game would need to unlock the
wheel first?
So all in all, can you:
- drop the first patch and push it in a later series
- re-order the patches: 3/3 then 2/3
- tell me when the wheel is not stuck when the series is applied
(after 3/3 or 2/3), and make a note in the commit message with that
information
- take into account my comments in the first patch you submitted (that
I just sent).
Cheers,
Benjamin
>
> Thanks,
> Andrey Smirnov
>
> Andrey Smirnov (3):
> HID: logitech-hidpp: use devres to manage FF private data
> HID: logitech-hidpp: split g920_get_config()
> HID: logitech-hidpp: add G920 device validation quirk
>
> drivers/hid/hid-logitech-hidpp.c | 193 +++
> 1 file changed, 120 insertions(+), 73 deletions(-)
>
> --
> 2.21.0
>
Re: [PATCH 1/3] HID: logitech-hidpp: use devres to manage FF private data
Hi Andrey,
On Mon, Oct 7, 2019 at 7:13 AM Andrey Smirnov wrote:
>
> To simplify resource management in commit that follows as well as to
> save a couple of extra kfree()s and simplify hidpp_ff_deinit() switch
> driver code to use devres to manage the life-cycle of FF private data.
>
> Signed-off-by: Andrey Smirnov
> Cc: Jiri Kosina
> Cc: Benjamin Tissoires
> Cc: Henrik Rydberg
> Cc: Sam Bazely
> Cc: Pierre-Loup A. Griffais
> Cc: Austin Palmer
> Cc: linux-in...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: sta...@vger.kernel.org
This patch doesn't seem to fix any error, is there a reason to send it
to stable? (besides as a dependency of the rest of the series).
> ---
> drivers/hid/hid-logitech-hidpp.c | 53 +---
> 1 file changed, 29 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/hid/hid-logitech-hidpp.c
> b/drivers/hid/hid-logitech-hidpp.c
> index 0179f7ed77e5..58eb928224e5 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -2079,6 +2079,11 @@ static void hidpp_ff_destroy(struct ff_device *ff)
> struct hidpp_ff_private_data *data = ff->private;
>
> kfree(data->effect_ids);
Is there any reasons we can not also devm alloc data->effect_ids?
> + /*
> +* Set private to NULL to prevent input_ff_destroy() from
> +* freeing our devres allocated memory
Ouch. There is something wrong here: input_ff_destroy() calls
kfree(ff->private), when the data has not been allocated by
input_ff_create(). This seems to lack a little bit of symmetry.
> +*/
> + ff->private = NULL;
> }
>
> static int hidpp_ff_init(struct hidpp_device *hidpp, u8 feature_index)
> @@ -2090,7 +2095,7 @@ static int hidpp_ff_init(struct hidpp_device *hidpp, u8
> feature_index)
> const u16 bcdDevice = le16_to_cpu(udesc->bcdDevice);
> struct ff_device *ff;
> struct hidpp_report response;
> - struct hidpp_ff_private_data *data;
> + struct hidpp_ff_private_data *data = hidpp->private_data;
> int error, j, num_slots;
> u8 version;
>
> @@ -2129,18 +2134,13 @@ static int hidpp_ff_init(struct hidpp_device *hidpp,
> u8 feature_index)
> return error;
> }
>
> - data = kzalloc(sizeof(*data), GFP_KERNEL);
> - if (!data)
> - return -ENOMEM;
> data->effect_ids = kcalloc(num_slots, sizeof(int), GFP_KERNEL);
> - if (!data->effect_ids) {
> - kfree(data);
> + if (!data->effect_ids)
> return -ENOMEM;
> - }
> +
> data->wq = create_singlethread_workqueue("hidpp-ff-sendqueue");
> if (!data->wq) {
> kfree(data->effect_ids);
> - kfree(data);
> return -ENOMEM;
> }
>
> @@ -2199,28 +2199,15 @@ static int hidpp_ff_init(struct hidpp_device *hidpp,
> u8 feature_index)
> return 0;
> }
>
> -static int hidpp_ff_deinit(struct hid_device *hid)
> +static void hidpp_ff_deinit(struct hid_device *hid)
> {
> - struct hid_input *hidinput = list_entry(hid->inputs.next, struct
> hid_input, list);
> - struct input_dev *dev = hidinput->input;
> - struct hidpp_ff_private_data *data;
> -
> - if (!dev) {
> - hid_err(hid, "Struct input_dev not found!\n");
> - return -EINVAL;
> - }
> + struct hidpp_device *hidpp = hid_get_drvdata(hid);
> + struct hidpp_ff_private_data *data = hidpp->private_data;
>
> hid_info(hid, "Unloading HID++ force feedback.\n");
> - data = dev->ff->private;
> - if (!data) {
I am pretty sure we might need to keep a test on data not being null.
> - hid_err(hid, "Private data not found!\n");
> - return -EINVAL;
> - }
>
> destroy_workqueue(data->wq);
> device_remove_file(>dev, _attr_range);
> -
> - return 0;
> }
This whole hunk seems unrelated to the devm change.
Can you extract a patch that just stores hidpp_ff_private_data in
hidpp->private_data and then cleans up hidpp_ff_deinit() before
switching it to devm? (or maybe not, see below)
After a few more thoughts, I don't think this mixing of devm and non
devm is a good idea:
we could say that the hidpp_ff_private_data and its effect_ids are
both children of the input_dev, not the hid_device. And we would
expect the whole thing to simplify with devm, but it's not, because ff
is not supposed to be used with devm.
I have a feeling the whole ff logic is wrong in term of where things
should be clean
Re: [PATCH] HID: i2c-hid: Remove runtime power management
Hi,
[Adding Mika, who introduced runpm in i2c-hid]
few questions, remarks:
On Tue, Oct 8, 2019 at 10:26 PM Hans de Goede wrote:
>
> Hi,
>
> On 08-10-2019 17:38, Kai-Heng Feng wrote:
> > Runtime power management in i2c-hid brings lots of issues, such as:
> > - When transitioning from display manager to desktop session, i2c-hid
> > was closed and opened, so the device was set to SLEEP and ON in a short
> > period. Vendors confirmed that their devices can't handle fast ON/SLEEP
> > command because Windows doesn't have this behavior.
> >
> > - When rebooting, i2c-hid was closed, and the driver core put the device
> > back to full power before shutdown. This behavior also triggers a quick
> > SLEEP and ON commands that some devices can't handle, renders an
> > unusable touchpad after reboot.
> >
> > - Runtime power management is only useful when i2c-hid isn't opened,
> > i.e. a laptop without desktop session, which isn't that common.
There is also one GPM-like driver that uses libinput (can't remember
from the top of my head), but you can have the i2c-hid device opened
on a vt too (with 2 finger gestures for scrolling and what not) :)
And there is also the use case of a 2-in-1 when the laptop is in
tablet mode. In some cases, the compositor will close the inputs to
ignore the touchpad events.
Anyway, Mika, is there any drawbacks of not having runpm on i2c-hid
devices? Maybe at the IRQ level?
> >
> > - Most importantly, my power meter reports little to none energy saving
> > when i2c-hid is runtime suspended.
Heh, that was the whole point of HID over I2C: the bus doesn't drain
power when not in used, so we can have always on devices with little
to no consumption of energy.
Do you have any numbers, or is it in the noise range?
> >
> > So let's remove runtime power management since there is no actual
> > benefit.
> >
> > Signed-off-by: Kai-Heng Feng
Thanks for the patch (one nitpick down below though).
>
> Given all the problems we've been seeing related to runtime pm I agree
> that this is probably the best approach:
>
> Acked-by: Hans de Goede
Thanks Hans.
You-Sheng, does this solve your issue with your touchpad? Do I have
your acked-by or tested-by?
Cheers,
Benjamin
>
> Regards,
>
> Hans
>
>
>
> > ---
> > drivers/hid/i2c-hid/i2c-hid-core.c | 111 ++---
> > 1 file changed, 4 insertions(+), 107 deletions(-)
> >
> > diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c
> > b/drivers/hid/i2c-hid/i2c-hid-core.c
> > index 2a7c6e33bb1c..5ab4982b3a7b 100644
> > --- a/drivers/hid/i2c-hid/i2c-hid-core.c
> > +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
> > @@ -26,7 +26,6 @@
> > #include
> > #include
> > #include
> > -#include
> > #include
> > #include
> > #include
> > @@ -48,8 +47,6 @@
> > /* quirks to control the device */
> > #define I2C_HID_QUIRK_SET_PWR_WAKEUP_DEVBIT(0)
> > #define I2C_HID_QUIRK_NO_IRQ_AFTER_RESETBIT(1)
> > -#define I2C_HID_QUIRK_NO_RUNTIME_PM BIT(2)
> > -#define I2C_HID_QUIRK_DELAY_AFTER_SLEEP BIT(3)
> > #define I2C_HID_QUIRK_BOGUS_IRQ BIT(4)
> >
> > /* flags */
> > @@ -172,14 +169,7 @@ static const struct i2c_hid_quirks {
> > { USB_VENDOR_ID_WEIDA, HID_ANY_ID,
> > I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV },
> > { I2C_VENDOR_ID_HANTICK, I2C_PRODUCT_ID_HANTICK_5288,
> > - I2C_HID_QUIRK_NO_IRQ_AFTER_RESET |
> > - I2C_HID_QUIRK_NO_RUNTIME_PM },
> > - { I2C_VENDOR_ID_RAYDIUM, I2C_PRODUCT_ID_RAYDIUM_4B33,
> > - I2C_HID_QUIRK_DELAY_AFTER_SLEEP },
> > - { USB_VENDOR_ID_LG, I2C_DEVICE_ID_LG_8001,
> > - I2C_HID_QUIRK_NO_RUNTIME_PM },
> > - { I2C_VENDOR_ID_GOODIX, I2C_DEVICE_ID_GOODIX_01F0,
> > - I2C_HID_QUIRK_NO_RUNTIME_PM },
> > + I2C_HID_QUIRK_NO_IRQ_AFTER_RESET },
> > { USB_VENDOR_ID_ELAN, HID_ANY_ID,
> >I2C_HID_QUIRK_BOGUS_IRQ },
> > { 0, 0 }
> > @@ -397,7 +387,6 @@ static int i2c_hid_set_power(struct i2c_client *client,
> > int power_state)
> > {
> > struct i2c_hid *ihid = i2c_get_clientdata(client);
> > int ret;
> > - unsigned long now, delay;
> >
> > i2c_hid_dbg(ihid, "%s\n", __func__);
> >
> > @@ -415,22 +404,9 @@ static int i2c_hid_set_power(struct i2c_client
> > *client, int power_state)
> > goto set_pwr_exit;
> > }
> >
> > - if (ihid->quirks & I2C_HID_QUIRK_DELAY_AFTER_SLEEP &&
> > - power_state == I2C_HID_PWR_ON) {
> > - now = jiffies;
> > - if (time_after(ihid->sleep_delay, now)) {
> > - delay = jiffies_to_usecs(ihid->sleep_delay - now);
> > - usleep_range(delay, delay + 1);
> > - }
> > - }
> > -
> > ret = __i2c_hid_command(client, _set_power_cmd, power_state,
> > 0, NULL, 0, NULL, 0);
> >
> > - if (ihid->quirks & I2C_HID_QUIRK_DELAY_AFTER_SLEEP &&
> > - power_state ==
Re: [PATCH v4 1/4] HID: logitech: Add MX Mice over Bluetooth
On Fri, Oct 11, 2019 at 10:49 AM Filipe Laíns wrote:
>
> On Fri, 2019-10-11 at 00:57 +, Mazin Rezk wrote:
> > On Saturday, October 5, 2019 9:04 PM, Mazin Rezk <
> > mn...@protonmail.com> wrote:
> >
> > > This patch adds support for several MX mice over Bluetooth. The
> > > device IDs
> > > have been copied from the libratbag device database and their
> > > features
> > > have been based on their DJ device counterparts.
> >
> > No changes have been made to this patch in v4. However, it should be
> > noted
> > that the only device that has been thoroughly tested in this patch is
> > the
> > MX Master (b01e). Further testing for the other devices may be
> > required.
> >
> > Signed-off-by: Mazin Rezk
> > ---
> > drivers/hid/hid-logitech-hidpp.c | 18 ++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-
> > logitech-hidpp.c
> > index 0179f7ed77e5..85fd0c17cc2f 100644
> > --- a/drivers/hid/hid-logitech-hidpp.c
> > +++ b/drivers/hid/hid-logitech-hidpp.c
> > @@ -3773,6 +3773,24 @@ static const struct hid_device_id
> > hidpp_devices[] = {
> > { /* MX5500 keyboard over Bluetooth */
> > HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb30b),
> > .driver_data = HIDPP_QUIRK_HIDPP_CONSUMER_VENDOR_KEYS },
> > + { /* MX Anywhere 2 mouse over Bluetooth */
> > + HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb013),
> > + .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> > + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb018),
> > + .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> > + { /* MX Anywhere 2S mouse over Bluetooth */
> > + HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb01a),
> > + .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> > + { /* MX Master mouse over Bluetooth */
> > + HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb012),
> > + .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> > + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb017),
> > + .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> > + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb01e),
> > + .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> > + { /* MX Master 2S mouse over Bluetooth */
> > + HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb019),
> > + .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> > {}
> > };
> >
> > --
> > 2.23.0
> >
>
> The series now looks great, thanks!
>
> Benjamin, I can confirm that up to now all BLE devices don't have short
> reports. I am not sure if you still want to only enable tested devices
> but from an architectural standpoint everything here should be fine.
Unfortunately yes, we need actual device tests:
- this series enable 0x2121 on all of those devices (is it correct?)
- we are not shielded from a FW error and something that goes wrong
when enabling one of those mice with hid-logitech-hidpp.c. All of
those mice works fine with hid-generic, and if we oversee one tiny
bit, we'll regress for no good reasons.
Cheers,
Benjamin
>
> Mazin, you can have my
>
> Reviewed-by: Filipe Laíns
>
> for the series.
>
> Thank you,
> Filipe Laíns
Re: [PATCH v4 4/4] HID: logitech: Support WirelessDeviceStatus connect events
On Fri, Oct 11, 2019 at 2:58 AM Mazin Rezk wrote:
>
> On Saturday, October 5, 2019 9:05 PM, Mazin Rezk wrote:
>
> > This patch makes WirelessDeviceStatus (0x1d4b) events get detected as
> > connection events on devices with HIDPP_QUIRK_WIRELESS_DEVICE_STATUS.
> >
> > This quirk is currently an alias for HIDPP_QUIRK_CLASS_BLUETOOTH since
> > the added Bluetooth devices do not support regular connect events.
>
> No changes have been made to this patch in v4.
>
> Signed-off-by: Mazin Rezk
> ---
> drivers/hid/hid-logitech-hidpp.c | 20 +---
> 1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/hid/hid-logitech-hidpp.c
> b/drivers/hid/hid-logitech-hidpp.c
> index 2062be922c08..b2b5fe2c74db 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -84,6 +84,7 @@ MODULE_PARM_DESC(disable_tap_to_click,
>
> /* Just an alias for now, may possibly be a catch-all in the future */
> #define HIDPP_QUIRK_MISSING_SHORT_REPORTS HIDPP_QUIRK_CLASS_BLUETOOTH
> +#define HIDPP_QUIRK_WIRELESS_DEVICE_STATUS HIDPP_QUIRK_CLASS_BLUETOOTH
Hmm, I don't like the idea of aliasing quirks on a class. Either it's
a class of devices, and you use it as such in the code, either you
want to use individual quirks, and so each one of those needs its own
bit definition.
If you take my advice in 2/4, please assign a new bit for
HIDPP_QUIRK_WIRELESS_DEVICE_STATUS (0x1f IIRC), and logically and it
on the HIDPP_QUIRK_CLASS_BLUETOOTH here.
>
> #define HIDPP_QUIRK_DELAYED_INIT HIDPP_QUIRK_NO_HIDINPUT
>
> @@ -406,9 +407,22 @@ static inline bool hidpp_match_error(struct hidpp_report
> *question,
> (answer->fap.params[0] == question->fap.funcindex_clientid);
> }
>
> -static inline bool hidpp_report_is_connect_event(struct hidpp_report *report)
> +#define HIDPP_PAGE_WIRELESS_DEVICE_STATUS 0x1d4b
> +
> +static inline bool hidpp_report_is_connect_event(struct hidpp_device *hidpp,
> +struct hidpp_report *report)
> {
> - return (report->report_id == REPORT_ID_HIDPP_SHORT) &&
> + if (hidpp->quirks & HIDPP_QUIRK_WIRELESS_DEVICE_STATUS) {
> + /* If feature is invalid, skip array check */
> + if (report->fap.feature_index > hidpp->feature_count)
> + return false;
This should probably be merged with the next return (if bool0, return
false else return bool1 can easily be transformed into return !bool0
&& bool1)
> +
> + return (hidpp->features[report->fap.feature_index] ==
> +HIDPP_PAGE_WIRELESS_DEVICE_STATUS);
Oh, so that's why you need the feature enumeration.
Though, it's a costly operation when you could simply:
- add a wireless_feature_index in struct hidpp_device,
- gets this feature index at probe with a single call to
hidpp_root_get_feature()
- and check here if this feature index of the report is not null and
equal to wireless_feature_index.
Cheers,
Benjamin
> + }
> +
> + return ((report->report_id == REPORT_ID_HIDPP_SHORT) ||
> + (hidpp->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS)) &&
> (report->rap.sub_id == 0x41);
> }
>
> @@ -3157,7 +3171,7 @@ static int hidpp_raw_hidpp_event(struct hidpp_device
> *hidpp, u8 *data,
> }
> }
>
> - if (unlikely(hidpp_report_is_connect_event(report))) {
> + if (unlikely(hidpp_report_is_connect_event(hidpp, report))) {
> atomic_set(>connected,
> !(report->rap.params[0] & (1 << 6)));
> if (schedule_work(>work) == 0)
> --
> 2.23.0
Re: [PATCH v4 3/4] HID: logitech: Add feature 0x0001: FeatureSet
On Fri, Oct 11, 2019 at 10:33 AM Benjamin Tissoires wrote: > > On Fri, Oct 11, 2019 at 2:57 AM Mazin Rezk wrote: > > > > On Saturday, October 5, 2019 9:04 PM, Mazin Rezk > > wrote: > > > > > This patch adds support for the 0x0001 (FeatureSet) feature. This feature > > > is used to look up the feature ID of a feature index on a device and list > > > the total count of features on the device. > > > > > > I also added the hidpp20_get_features function which iterates through all > > > feature indexes on the device and stores a map of them in features an > > > hidpp_device struct. This function runs when an HID++ 2.0 device is > > > probed. > > > > Changes in the version: > > - Renamed hidpp20_featureset_get_feature to > >hidpp20_featureset_get_feature_id. > > > > - Re-ordered hidpp20_featureset_get_count and > >hidpp20_featureset_get_feature_id based on their command IDs. > > > > - Made feature_count initialize to 0 before running hidpp20_get_features. > > I still need to decide whether or not we need to take this one. We > historically did not do this to mimic the Windows driver at the time. > However, the driver is full of quirks that could be detected instead > of hardcoded thanks to this functions. So we might want to switch to > auto-detection of those quirks so we can keep 'quirks' for actual > defects that can't be auto-detected. > > But, if we want to go this route, we need to actually make use of it. > So this patch should be part of a series where we use it, not added by > its own. > > Can you drop it from the series? > And maybe possibly work on a cleanup of some of the auto detection, > like the HIDPP_QUIRK_HI_RES_SCROLL_X2121 which you can easily test? > But this would need to happen in a second series, once this one gets > merged in. While reviewing 4/4, I realized why you need this one. See my comments in 4/4, I still believe the case is not strong enough to spend some time to enable the feature for barely no gain. Cheers, Benjamin
Re: [PATCH v4 3/4] HID: logitech: Add feature 0x0001: FeatureSet
On Fri, Oct 11, 2019 at 2:57 AM Mazin Rezk wrote:
>
> On Saturday, October 5, 2019 9:04 PM, Mazin Rezk wrote:
>
> > This patch adds support for the 0x0001 (FeatureSet) feature. This feature
> > is used to look up the feature ID of a feature index on a device and list
> > the total count of features on the device.
> >
> > I also added the hidpp20_get_features function which iterates through all
> > feature indexes on the device and stores a map of them in features an
> > hidpp_device struct. This function runs when an HID++ 2.0 device is probed.
>
> Changes in the version:
> - Renamed hidpp20_featureset_get_feature to
>hidpp20_featureset_get_feature_id.
>
> - Re-ordered hidpp20_featureset_get_count and
>hidpp20_featureset_get_feature_id based on their command IDs.
>
> - Made feature_count initialize to 0 before running hidpp20_get_features.
I still need to decide whether or not we need to take this one. We
historically did not do this to mimic the Windows driver at the time.
However, the driver is full of quirks that could be detected instead
of hardcoded thanks to this functions. So we might want to switch to
auto-detection of those quirks so we can keep 'quirks' for actual
defects that can't be auto-detected.
But, if we want to go this route, we need to actually make use of it.
So this patch should be part of a series where we use it, not added by
its own.
Can you drop it from the series?
And maybe possibly work on a cleanup of some of the auto detection,
like the HIDPP_QUIRK_HI_RES_SCROLL_X2121 which you can easily test?
But this would need to happen in a second series, once this one gets
merged in.
Cheers,
Benjamin
>
> Signed-off-by: Mazin Rezk
> ---
> drivers/hid/hid-logitech-hidpp.c | 90
> 1 file changed, 90 insertions(+)
>
> diff --git a/drivers/hid/hid-logitech-hidpp.c
> b/drivers/hid/hid-logitech-hidpp.c
> index a0efa8a43213..2062be922c08 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -190,6 +190,9 @@ struct hidpp_device {
>
> struct hidpp_battery battery;
> struct hidpp_scroll_counter vertical_wheel_counter;
> +
> + u16 *features;
> + u8 feature_count;
> };
>
> /* HID++ 1.0 error codes */
> @@ -911,6 +914,82 @@ static int hidpp_root_get_protocol_version(struct
> hidpp_device *hidpp)
> return 0;
> }
>
> +/*
> -- */
> +/* 0x0001: FeatureSet
> */
> +/*
> -- */
> +
> +#define HIDPP_PAGE_FEATURESET 0x0001
> +
> +#define CMD_FEATURESET_GET_COUNT 0x00
> +#define CMD_FEATURESET_GET_FEATURE 0x11
> +
> +static int hidpp20_featureset_get_count(struct hidpp_device *hidpp,
> + u8 feature_index, u8 *count)
> +{
> + struct hidpp_report response;
> + int ret;
> +
> + ret = hidpp_send_fap_command_sync(hidpp, feature_index,
> + CMD_FEATURESET_GET_COUNT, NULL, 0, );
> +
> + if (ret)
> + return ret;
> +
> + *count = response.fap.params[0];
> +
> + return ret;
> +}
> +
> +static int hidpp20_featureset_get_feature_id(struct hidpp_device *hidpp,
> + u8 featureset_index, u8 feature_index, u16 *feature_id)
> +{
> + struct hidpp_report response;
> + int ret;
> +
> + ret = hidpp_send_fap_command_sync(hidpp, featureset_index,
> + CMD_FEATURESET_GET_FEATURE, _index, 1, );
> +
> + if (ret)
> + return ret;
> +
> + *feature_id = (response.fap.params[0] << 8) | response.fap.params[1];
> +
> + return ret;
> +}
> +
> +static int hidpp20_get_features(struct hidpp_device *hidpp)
> +{
> + int ret;
> + u8 featureset_index, featureset_type;
> + u8 i;
> +
> + ret = hidpp_root_get_feature(hidpp, HIDPP_PAGE_FEATURESET,
> +_index, _type);
> +
> + if (ret == -ENOENT) {
> + hid_warn(hidpp->hid_dev, "Unable to retrieve feature set.");
> + return 0;
> + }
> +
> + if (ret)
> + return ret;
> +
> + ret = hidpp20_featureset_get_count(hidpp, featureset_index,
> + >feature_count);
> +
> + if (ret)
> + return ret;
> +
> + hidpp->features = devm_kzalloc(>hid_dev->dev,
> + hidpp->feature_count * sizeof(u16), GFP_KERNEL);
> +
> + for (i = 0; i < hidpp->feature_count && !ret; i++)
> + ret = hidpp20_featureset_get_feature_id(hidpp,
> featureset_index,
> + i, &(hidpp->features[i]));
> +
> + return ret;
> +}
> +
> /*
> -- */
> /* 0x0005: GetDeviceNameType
Re: [PATCH v4 2/4] HID: logitech: Support HID++ devices without short reports
On Fri, Oct 11, 2019 at 2:57 AM Mazin Rezk wrote:
>
> On Saturday, October 5, 2019 9:04 PM, Mazin Rezk wrote:
>
> > This patch allows the hid-logitech-hidpp module to support devices that do
> > not have support for Short HID++ reports. So far, it seems that Bluetooth
> > HID++ 2.0 devices are missing short reports.
>
> > This has been tested and confirmed with the MX Master and MX Master 2S and
> > is therefore likely the case with the other Bluetooth devices.
>
> No changes have been made to this patch in v4.
>
> Signed-off-by: Mazin Rezk
> ---
> drivers/hid/hid-logitech-hidpp.c | 37 ++--
> 1 file changed, 30 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/hid/hid-logitech-hidpp.c
> b/drivers/hid/hid-logitech-hidpp.c
> index 85fd0c17cc2f..a0efa8a43213 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -71,6 +71,7 @@ MODULE_PARM_DESC(disable_tap_to_click,
> #define HIDPP_QUIRK_HIDPP_WHEELS BIT(29)
> #define HIDPP_QUIRK_HIDPP_EXTRA_MOUSE_BTNS BIT(30)
> #define HIDPP_QUIRK_HIDPP_CONSUMER_VENDOR_KEYS BIT(31)
> +#define HIDPP_QUIRK_CLASS_BLUETOOTHBIT(5)
Quirks should be kept in order.
>
> /* These are just aliases for now */
> #define HIDPP_QUIRK_KBD_SCROLL_WHEEL HIDPP_QUIRK_HIDPP_WHEELS
> @@ -81,6 +82,9 @@ MODULE_PARM_DESC(disable_tap_to_click,
> HIDPP_QUIRK_HI_RES_SCROLL_X2120 | \
> HIDPP_QUIRK_HI_RES_SCROLL_X2121)
>
> +/* Just an alias for now, may possibly be a catch-all in the future */
> +#define HIDPP_QUIRK_MISSING_SHORT_REPORTS HIDPP_QUIRK_CLASS_BLUETOOTH
I would rather have the other way around: define
HIDPP_QUIRK_MISSING_SHORT_REPORTS as BIT(20) (change the comment while
defining it), and have a class definition that aliases
HIDPP_QUIRK_MISSING_SHORT_REPORTS instead. This way, we can add an
other quirk like you do in one of the next patches without
conflicting.
> +
> #define HIDPP_QUIRK_DELAYED_INIT HIDPP_QUIRK_NO_HIDINPUT
>
> #define HIDPP_CAPABILITY_HIDPP10_BATTERY BIT(0)
> @@ -340,6 +344,12 @@ static int hidpp_send_rap_command_sync(struct
> hidpp_device *hidpp_dev,
> struct hidpp_report *message;
> int ret, max_count;
>
> + /* Force long reports on devices that do not support short reports */
> + if (hidpp_dev->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS &&
> + report_id == REPORT_ID_HIDPP_SHORT)
> + report_id = REPORT_ID_HIDPP_LONG;
> +
> +
nitpick: one extra carriage return.
> switch (report_id) {
> case REPORT_ID_HIDPP_SHORT:
> max_count = HIDPP_REPORT_SHORT_LENGTH - 4;
> @@ -3482,6 +3492,12 @@ static bool hidpp_validate_report(struct hid_device
> *hdev, int id,
>
> static bool hidpp_validate_device(struct hid_device *hdev)
> {
> + struct hidpp_device *hidpp = hid_get_drvdata(hdev);
nitpick: empty line missing.
> + /* Skip the short report check if the device does not support it */
> + if (hidpp->quirks & HIDPP_QUIRK_MISSING_SHORT_REPORTS)
> + return hidpp_validate_report(hdev, REPORT_ID_HIDPP_LONG,
> +HIDPP_REPORT_LONG_LENGTH, false);
> +
> return hidpp_validate_report(hdev, REPORT_ID_HIDPP_SHORT,
> HIDPP_REPORT_SHORT_LENGTH, false) &&
>hidpp_validate_report(hdev, REPORT_ID_HIDPP_LONG,
> @@ -3775,22 +3791,29 @@ static const struct hid_device_id hidpp_devices[] = {
> .driver_data = HIDPP_QUIRK_HIDPP_CONSUMER_VENDOR_KEYS },
> { /* MX Anywhere 2 mouse over Bluetooth */
> HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb013),
> - .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> + .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 |
> +HIDPP_QUIRK_CLASS_BLUETOOTH },
As mentioned in 1/4:
- please only add devices you know have been tested
- squash the previous one into this one to preserve bisectability.
Cheers,
Benjamin
> { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb018),
> - .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> + .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 |
> +HIDPP_QUIRK_CLASS_BLUETOOTH },
> { /* MX Anywhere 2S mouse over Bluetooth */
> HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb01a),
> - .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> + .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 |
> +HIDPP_QUIRK_CLASS_BLUETOOTH },
> { /* MX Master mouse over Bluetooth */
> HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb012),
> - .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> + .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 |
> +HIDPP_QUIRK_CLASS_BLUETOOTH },
> {
Re: [PATCH v4 1/4] HID: logitech: Add MX Mice over Bluetooth
Hi Mazin,
On Fri, Oct 11, 2019 at 2:57 AM Mazin Rezk wrote:
>
> On Saturday, October 5, 2019 9:04 PM, Mazin Rezk wrote:
>
> > This patch adds support for several MX mice over Bluetooth. The device IDs
> > have been copied from the libratbag device database and their features
> > have been based on their DJ device counterparts.
>
> No changes have been made to this patch in v4. However, it should be noted
> that the only device that has been thoroughly tested in this patch is the
> MX Master (b01e). Further testing for the other devices may be required.
Thanks a lot for the series, but please amend your format-patch process:
- The commit message should not contain the leading `>` characters,
and checkpath.pl then complains about Possible unwrapped commit
description (prefer a maximum 75 chars per line)
- this description of the changes is very useful, but it should go
after the first `---` so that we do not pull it while applying the
patch.
Also, this patch introduces a breakage in the bisectability of the
devices it adds. If we were to bisect a breakage in one of those
devices, the device will fail to work, and we could not detect where
the error comes from.
So please squash this patch with the next one.
Last, if we need "Further testing for the other devices may be
required", then I'd rather enable those device one by one when ewe get
the confirmation they are working. Adding a new device costs, but not
as much than breaking an existing one, especially when it gets
detected later, when the kernel gets shipped in distributions.
Note that I have the MX Master 0xB012, so you can safely keep that one
on the list, I'll test it myself.
Cheers,
Benjamin
>
> Signed-off-by: Mazin Rezk
> ---
> drivers/hid/hid-logitech-hidpp.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/hid/hid-logitech-hidpp.c
> b/drivers/hid/hid-logitech-hidpp.c
> index 0179f7ed77e5..85fd0c17cc2f 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -3773,6 +3773,24 @@ static const struct hid_device_id hidpp_devices[] = {
> { /* MX5500 keyboard over Bluetooth */
> HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb30b),
> .driver_data = HIDPP_QUIRK_HIDPP_CONSUMER_VENDOR_KEYS },
> + { /* MX Anywhere 2 mouse over Bluetooth */
> + HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb013),
> + .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb018),
> + .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> + { /* MX Anywhere 2S mouse over Bluetooth */
> + HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb01a),
> + .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> + { /* MX Master mouse over Bluetooth */
> + HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb012),
> + .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb017),
> + .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> + { HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb01e),
> + .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> + { /* MX Master 2S mouse over Bluetooth */
> + HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_LOGITECH, 0xb019),
> + .driver_data = HIDPP_QUIRK_HI_RES_SCROLL_X2121 },
> {}
> };
>
> --
> 2.23.0
>
Re: [PATCH v2] HID: core: check whether usage page item is after usage id item
On Wed, Oct 9, 2019 at 2:54 PM Candle Sun wrote:
>
> From: Candle Sun
>
> Upstream commit 58e75155009c ("HID: core: move Usage Page concatenation
> to Main item") adds support for Usage Page item after Usage ID items
> (such as keyboards manufactured by Primax).
>
> Usage Page concatenation in Main item works well for following report
> descriptor patterns:
>
> USAGE_PAGE (Keyboard) 05 07
> USAGE_MINIMUM (Keyboard LeftControl)19 E0
> USAGE_MAXIMUM (Keyboard Right GUI) 29 E7
> LOGICAL_MINIMUM (0) 15 00
> LOGICAL_MAXIMUM (1) 25 01
> REPORT_SIZE (1) 75 01
> REPORT_COUNT (8)95 08
> INPUT (Data,Var,Abs)81 02
>
> -
>
> USAGE_MINIMUM (Keyboard LeftControl)19 E0
> USAGE_MAXIMUM (Keyboard Right GUI) 29 E7
> LOGICAL_MINIMUM (0) 15 00
> LOGICAL_MAXIMUM (1) 25 01
> REPORT_SIZE (1) 75 01
> REPORT_COUNT (8)95 08
> USAGE_PAGE (Keyboard) 05 07
> INPUT (Data,Var,Abs)81 02
>
> But it makes the parser act wrong for the following report
> descriptor pattern(such as some Gamepads):
>
> USAGE_PAGE (Button) 05 09
> USAGE (Button 1)09 01
> USAGE (Button 2)09 02
> USAGE (Button 4)09 04
> USAGE (Button 5)09 05
> USAGE (Button 7)09 07
> USAGE (Button 8)09 08
> USAGE (Button 14) 09 0E
> USAGE (Button 15) 09 0F
> USAGE (Button 13) 09 0D
> USAGE_PAGE (Consumer Devices) 05 0C
> USAGE (Back)0a 24 02
> USAGE (HomePage)0a 23 02
> LOGICAL_MINIMUM (0) 15 00
> LOGICAL_MAXIMUM (1) 25 01
> REPORT_SIZE (1) 75 01
> REPORT_COUNT (11) 95 0B
> INPUT (Data,Var,Abs)81 02
>
> With Usage Page concatenation in Main item, parser recognizes all the
> 11 Usages as consumer keys, it is not the HID device's real intention.
>
> This patch adds usage_page_last to flag whether Usage Page is after
> Usage ID items. usage_page_last is false default, it is set as true
> once Usage Page item is encountered and is reverted by next Usage ID
> item.
>
> Usage Page concatenation on the currently defined Usage Page will do
> firstly in Local parsing when Usage ID items encountered.
>
> When Main item is parsing, concatenation will do again with last
> defined Usage Page if usage_page_last flag is true.
>
> Signed-off-by: Candle Sun
> Signed-off-by: Nianfu Bai
> ---
> Changes in v2:
> - Update patch title
> - Add GET_COMPLETE_USAGE macro
> - Change the logic of checking whether to concatenate usage page again
> in main parsing
> ---
> drivers/hid/hid-core.c | 31 +--
> include/linux/hid.h| 1 +
> 2 files changed, 26 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 3eaee2c..3394222 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -35,6 +35,8 @@
>
> #include "hid-ids.h"
>
> +#define GET_COMPLETE_USAGE(page, id) (((page) << 16) + ((id) & 0x))
> +
> /*
> * Version Information
> */
> @@ -221,7 +223,15 @@ static int hid_add_usage(struct hid_parser *parser,
> unsigned usage, u8 size)
> hid_err(parser->device, "usage index exceeded\n");
> return -1;
> }
> - parser->local.usage[parser->local.usage_index] = usage;
> +
> + if (size <= 2) {
> + parser->local.usage_page_last = false;
> + parser->local.usage[parser->local.usage_index] =
> + GET_COMPLETE_USAGE(parser->global.usage_page, usage);
> + } else {
> + parser->local.usage[parser->local.usage_index] = usage;
> + }
> +
> parser->local.usage_size[parser->local.usage_index] = size;
> parser->local.collection_index[parser->local.usage_index] =
> parser->collection_stack_ptr ?
> @@ -366,6 +376,7 @@ static int hid_parser_global(struct hid_parser *parser,
> struct hid_item *item)
>
> case HID_GLOBAL_ITEM_TAG_USAGE_PAGE:
> parser->global.usage_page = item_udata(item);
> + parser->local.usage_page_last = true;
> return 0;
>
> case HID_GLOBAL_ITEM_TAG_LOGICAL_MINIMUM:
> @@ -543,13 +554,21 @@ static int hid_parser_local(struct hid_parser *parser,
> struct hid_item *item)
> * usage value."
> */
>
> -static void hid_concatenate_usage_page(struct hid_parser *parser)
> +static void
Re: [PATCH v2] HID: core: check whether usage page item is after usage id item
On Thu, Oct 10, 2019 at 5:19 AM Candle Sun wrote:
>
> On Thu, Oct 10, 2019 at 2:00 AM Jiri Kosina wrote:
> >
> > On Wed, 9 Oct 2019, Nicolas Saenz Julienne wrote:
> >
> > > > diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> > > > index 3eaee2c..3394222 100644
> > > > --- a/drivers/hid/hid-core.c
> > > > +++ b/drivers/hid/hid-core.c
> > > > @@ -35,6 +35,8 @@
> > > >
> > > > #include "hid-ids.h"
> > > >
> > > > +#define GET_COMPLETE_USAGE(page, id) (((page) << 16) + ((id) & 0x))
> > >
> > > Not sure I like the macro. I'd rather have the explicit code. That said,
> > > lets
> > > see what Benjamin has to say.
> >
> > Not sure about Benjamin :) but I personally would ask for putting it
> > somewhere into hid.h as static inline.
> >
> > And even if it's for some reason insisted on this staying macro, please at
> > least put it as close to the place(s) it's being used as possible, in
> > order to maintain some code sanity.
> >
> > Thanks,
> >
> > --
> > Jiri Kosina
> > SUSE Labs
> >
>
> Thanks Nicolas and Jiri,
> If macro is not good, I will change it to static function. But the
> funciton is only used in hid-core.c,
> maybe placing it into hid.h is not good?
I would rather use a function too (in hid-core.c, as it's not reused
anywhere else), and we can make it simpler from the caller point of
view (if I am not mistaken):
---
static void concatenate_usage_page(struct hid_parser *parser, int index)
{
parser->local.usage[index] &= 0x;
parser->local.usage[index] |= (parser->global.usage_page & 0x) << 16;
}
// Which can then be called as:
+ parser->local.usage[parser->local.usage_index] = usage;
+ if (size <= 2)
+ concatenate_usage_page(parser, parser->local.usage_index);
+
// And
for (i = 0; i < parser->local.usage_index; i++)
- if (parser->local.usage_size[i] <= 2)
- parser->local.usage[i] +=
parser->global.usage_page << 16;
+ if (parser->local.usage_size[i] <= 2) {
+ concatenate_usage_page(parser, i);
+ }
}
---
And now that I have written this, the check on the size could also be
very well integrated in concatenate_usage_page().
Cheers,
Benjamin
>
> Regards,
> Candle
Re: [PATCH] Input: add input_get_poll_interval()
Hi Dmitry,
On Wed, Oct 2, 2019 at 5:58 PM Dmitry Torokhov
wrote:
>
> Some drivers need to be able to know the current polling interval for
> devices working in polling mode, let's allow them fetching it.
>
> Signed-off-by: Dmitry Torokhov
Not sure if you really need my input on this one, but, sure, looks good to me:
Acked-By: Benjamin Tissoires
Cheers,
Benjamin
> ---
> drivers/input/input-poller.c | 9 +
> include/linux/input.h| 1 +
> 2 files changed, 10 insertions(+)
>
> diff --git a/drivers/input/input-poller.c b/drivers/input/input-poller.c
> index 1b3d28964bb2..7d6b4e8879f1 100644
> --- a/drivers/input/input-poller.c
> +++ b/drivers/input/input-poller.c
> @@ -123,6 +123,15 @@ void input_set_max_poll_interval(struct input_dev *dev,
> unsigned int interval)
> }
> EXPORT_SYMBOL(input_set_max_poll_interval);
>
> +int input_get_poll_interval(struct input_dev *dev)
> +{
> + if (!dev->poller)
> + return -EINVAL;
> +
> + return dev->poller->poll_interval;
> +}
> +EXPORT_SYMBOL(input_get_poll_interval);
> +
> /* SYSFS interface */
>
> static ssize_t input_dev_get_poll_interval(struct device *dev,
> diff --git a/include/linux/input.h b/include/linux/input.h
> index 31da4feaa1d8..a420324b7882 100644
> --- a/include/linux/input.h
> +++ b/include/linux/input.h
> @@ -387,6 +387,7 @@ int input_setup_polling(struct input_dev *dev,
> void input_set_poll_interval(struct input_dev *dev, unsigned int interval);
> void input_set_min_poll_interval(struct input_dev *dev, unsigned int
> interval);
> void input_set_max_poll_interval(struct input_dev *dev, unsigned int
> interval);
> +int input_get_poll_interval(struct input_dev *dev);
>
> int __must_check input_register_handler(struct input_handler *);
> void input_unregister_handler(struct input_handler *);
> --
> 2.23.0.444.g18eeb5a265-goog
>
>
> --
> Dmitry
Re: [PATCH] HID: core: add usage_page_preceding flag for hid_concatenate_usage_page()
Hi,
[also addingg Nicolas, the author of 58e75155009c]
On Mon, Sep 30, 2019 at 10:10 AM Candle Sun wrote:
>
> From: Candle Sun
>
> Upstream commit 58e75155009c ("HID: core: move Usage Page concatenation
> to Main item") adds support for Usage Page item following Usage items
> (such as keyboards manufactured by Primax).
>
> Usage Page concatenation in Main item works well for following report
> descriptor patterns:
>
> USAGE_PAGE (Keyboard) 05 07
> USAGE_MINIMUM (Keyboard LeftControl)19 E0
> USAGE_MAXIMUM (Keyboard Right GUI) 29 E7
> LOGICAL_MINIMUM (0) 15 00
> LOGICAL_MAXIMUM (1) 25 01
> REPORT_SIZE (1) 75 01
> REPORT_COUNT (8)95 08
> INPUT (Data,Var,Abs)81 02
>
> -
>
> USAGE_MINIMUM (Keyboard LeftControl)19 E0
> USAGE_MAXIMUM (Keyboard Right GUI) 29 E7
> LOGICAL_MINIMUM (0) 15 00
> LOGICAL_MAXIMUM (1) 25 01
> REPORT_SIZE (1) 75 01
> REPORT_COUNT (8)95 08
> USAGE_PAGE (Keyboard) 05 07
> INPUT (Data,Var,Abs)81 02
>
> But it makes the parser act wrong for the following report
> descriptor pattern(such as some Gamepads):
>
> USAGE_PAGE (Button) 05 09
> USAGE (Button 1)09 01
> USAGE (Button 2)09 02
> USAGE (Button 4)09 04
> USAGE (Button 5)09 05
> USAGE (Button 7)09 07
> USAGE (Button 8)09 08
> USAGE (Button 14) 09 0E
> USAGE (Button 15) 09 0F
> USAGE (Button 13) 09 0D
> USAGE_PAGE (Consumer Devices) 05 0C
> USAGE (Back)0a 24 02
> USAGE (HomePage)0a 23 02
> LOGICAL_MINIMUM (0) 15 00
> LOGICAL_MAXIMUM (1) 25 01
> REPORT_SIZE (1) 75 01
> REPORT_COUNT (11) 95 0B
> INPUT (Data,Var,Abs)81 02
>
> With Usage Page concatenation in Main item, parser recognizes all the
> 11 Usages as consumer keys, it is not the HID device's real intention.
>
> This patch adds usage_page_preceding flag to detect the third pattern.
> Usage Page concatenation is done in both Local and Main parsing.
> If usage_page_preceding equals 3(the third pattern encountered),
> hid_concatenate_usage_page() is jumped.
For anything core related (and especially the parsing), I am trying to
enforce having regression tests.
See https://gitlab.freedesktop.org/libevdev/hid-tools/merge_requests/37
for the one related to 58e75155009c.
So I would like to have a similar-ish MR adding the matching tests so
I know we won't break this in the future.
Few other comments in the code:
>
> Signed-off-by: Candle Sun
> Signed-off-by: Nianfu Bai
> ---
> drivers/hid/hid-core.c | 21 +++--
> include/linux/hid.h| 1 +
> 2 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> index 3eaee2c..043a232 100644
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -221,7 +221,15 @@ static int hid_add_usage(struct hid_parser *parser,
> unsigned usage, u8 size)
> hid_err(parser->device, "usage index exceeded\n");
> return -1;
> }
> - parser->local.usage[parser->local.usage_index] = usage;
> + if (!parser->local.usage_index && parser->global.usage_page)
parser->global.usage_page is never reset, so unless I am misreading,
it will always be set to a value except for the very first elements.
I am just raising this in case you rely on global.usage_page being
null in your algorithm.
> + parser->local.usage_page_preceding = 1;
> + if (parser->local.usage_page_preceding == 2)
> + parser->local.usage_page_preceding = 3;
Can't we use an enum at least for those 1, 2, 3 values?
Unless you are counting the previous items, in which we should rename
the field .usage_page_preceding with something more explicit IMO.
> + if (size <= 2 && parser->global.usage_page)
> + parser->local.usage[parser->local.usage_index] =
> + (usage & 0x) + (parser->global.usage_page << 16);
we could use a function as this assignment is also reused in
hid_concatenate_usage_page()
> + else
> + parser->local.usage[parser->local.usage_index] = usage;
> parser->local.usage_size[parser->local.usage_index] = size;
> parser->local.collection_index[parser->local.usage_index] =
> parser->collection_stack_ptr ?
> @@ -366,6 +374,8 @@ static
Re: [PATCH] HID: core: clean up indentation issue
On Wed, Sep 25, 2019 at 1:48 PM Dan Carpenter wrote:
>
> On Mon, Sep 23, 2019 at 01:04:13PM +0200, Jiri Kosina wrote:
> > On Sun, 22 Sep 2019, Colin King wrote:
> >
> > > From: Colin Ian King
> > >
> > > There is an if statement that is indented by one extra space,
> > > fix this by removing the extraneous space.
> > >
> > > Signed-off-by: Colin Ian King
> > > ---
> > > drivers/hid/hid-core.c | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> > > index 3eaee2c37931..9469c382a182 100644
> > > --- a/drivers/hid/hid-core.c
> > > +++ b/drivers/hid/hid-core.c
> > > @@ -2329,10 +2329,10 @@ int hid_add_device(struct hid_device *hdev)
> > > /*
> > > * Check for the mandatory transport channel.
> > > */
> > > -if (!hdev->ll_driver->raw_request) {
> > > + if (!hdev->ll_driver->raw_request) {
> > > hid_err(hdev, "transport driver missing .raw_request()\n");
> > > return -EINVAL;
> > > -}
> > > + }
> >
> > Let's not pollute git blame and wait for an ocasion when we need to touch
> > the code for some more valid reason.
>
> Just use `git blame -w`.
>
> This probably came from a Smatch warning. Smatch warns very seldom
> warns about style issues, but in this case the indenting is legitimately
> bad.
Well, I tend to agree with Jiri here. Yes, you can use a particular
flag in a tool to 'solve' the git blame/history issue, but this is
putting the workload on the user, while tthe code is fine, in this
case. Why do we need to pollute the history of a file for no good
reasons?
Cheers,
Benjamin
Re: [PATCH 1/2] HID: i2c-hid: allow delay after SET_POWER
Hi,
On Wed, Sep 25, 2019 at 11:43 AM You-Sheng Yang
wrote:
>
> According to HID over I2C specification v1.0 section 7.2.8, a device is
> allowed to take at most 1 second to make the transition to the specified
> power state. On some touchpad devices implements Microsoft Precision
> Touchpad, it may fail to execute following set PTP mode command without
> the delay and leaves the device in an unsupported Mouse mode.
>
> This change adds a post-setpower-delay-ms device property that allows
> specifying the delay after a SET_POWER command is issued.
I must confess I have at least 2 problems with your series:
- this patch is quite hard to review. There are unrelated changes and
it should be split in at least 2 (I'll detail this in the code review
below)
- you are basically adding a new quirk when Windows doesn't need it.
So before we merge this, I'd like to actually know if Windows is doing
the same and if we could not mimic what Windows is doing to prevent
further similar quirks in the future.
>
> References: https://bugzilla.kernel.org/show_bug.cgi?id=204991
> Signed-off-by: You-Sheng Yang
> ---
> .../bindings/input/hid-over-i2c.txt | 2 +
> drivers/hid/i2c-hid/i2c-hid-core.c| 46 +++
> include/linux/platform_data/i2c-hid.h | 3 ++
> 3 files changed, 32 insertions(+), 19 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/input/hid-over-i2c.txt
> b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
> index c76bafaf98d2f..d82faae335da0 100644
> --- a/Documentation/devicetree/bindings/input/hid-over-i2c.txt
> +++ b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
> @@ -32,6 +32,8 @@ device-specific compatible properties, which should be used
> in addition to the
> - vdd-supply: phandle of the regulator that provides the supply voltage.
> - post-power-on-delay-ms: time required by the device after enabling its
> regulators
Why are you removing those 2 properties?
>or powering it on, before it is ready for communication.
> +- post-setpower-delay-ms: time required by the device after a SET_POWER
> command
> + before it finished the state transition.
couple of issues:
- the name might not be the best. It is similar to the
post-power-on-delay while having a complete different impact. (note: I
don't have a better name at hand)
- checkpatch complains that device tree changes should be in a
separate patch, and I tend to agree.
>
> Example:
>
> diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c
> b/drivers/hid/i2c-hid/i2c-hid-core.c
> index 2a7c6e33bb1c4..a5bc2786dc440 100644
> --- a/drivers/hid/i2c-hid/i2c-hid-core.c
> +++ b/drivers/hid/i2c-hid/i2c-hid-core.c
> @@ -168,6 +168,7 @@ static const struct i2c_hid_quirks {
> __u16 idVendor;
> __u16 idProduct;
> __u32 quirks;
> + __u32 post_setpower_delay_ms;
> } i2c_hid_quirks[] = {
> { USB_VENDOR_ID_WEIDA, HID_ANY_ID,
> I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV },
> @@ -189,21 +190,20 @@ static const struct i2c_hid_quirks {
> * i2c_hid_lookup_quirk: return any quirks associated with a I2C HID device
> * @idVendor: the 16-bit vendor ID
> * @idProduct: the 16-bit product ID
> - *
> - * Returns: a u32 quirks value.
> */
> -static u32 i2c_hid_lookup_quirk(const u16 idVendor, const u16 idProduct)
> +static void i2c_hid_set_quirk(struct i2c_hid *ihid,
> + const u16 idVendor, const u16 idProduct)
> {
> - u32 quirks = 0;
> int n;
>
> for (n = 0; i2c_hid_quirks[n].idVendor; n++)
> if (i2c_hid_quirks[n].idVendor == idVendor &&
> (i2c_hid_quirks[n].idProduct == (__u16)HID_ANY_ID ||
> -i2c_hid_quirks[n].idProduct == idProduct))
> - quirks = i2c_hid_quirks[n].quirks;
> -
> - return quirks;
> +i2c_hid_quirks[n].idProduct == idProduct)) {
> + ihid->quirks = i2c_hid_quirks[n].quirks;
> + ihid->pdata.post_setpower_delay_ms =
> + i2c_hid_quirks[n].post_setpower_delay_ms;
> + }
Why are you changing the signature of i2c_hid_set_quirk? If this is
really a good thing to do, it should go in a separate patch.
> }
>
> static int __i2c_hid_command(struct i2c_client *client,
> @@ -431,8 +431,22 @@ static int i2c_hid_set_power(struct i2c_client *client,
> int power_state)
> power_state == I2C_HID_PWR_SLEEP)
> ihid->sleep_delay = jiffies + msecs_to_jiffies(20);
>
> - if (ret)
> + if (ret) {
> dev_err(>dev, "failed to change power setting.\n");
> + goto set_pwr_exit;
> + }
> +
> + /*
> +* The HID over I2C specification states that if a DEVICE needs time
> +* after the PWR_ON request, it should utilise CLOCK stretching.
> +* However, it has been observered that the Windows driver provides a
> +* 1ms sleep between
Re: [PATCH v3 3/3] HID: core: fix dmesg flooding if report field larger than 32bit
On Thu, Aug 29, 2019 at 1:26 AM Joshua Clayton wrote:
>
> ping?
> I'd love to see this get in.
> with distro kernel I have effectively no dmesg due to this issue
Apologies for the delay.
I really thought we should find a better way of fixing this, until I
got a laptop affected by it. This series is a must have.
Applied to for-5.4/core
Cheers,
Benjamin
>
> On Mon, Aug 12, 2019 at 9:20 AM wrote:
> >
> > From: Joshua Clayton
> >
> > Only warn once of oversize hid report value field
> >
> > On HP spectre x360 convertible the message:
> > hid-sensor-hub 001F:8087:0AC2.0002: hid_field_extract() called with n (192)
> > > 32! (kworker/1:2)
> > is continually printed many times per second, crowding out all else.
> > Protect dmesg by printing the warning only one time.
> >
> > The size of the hid report field data structure should probably be
> > increased.
> > The data structure is treated as a u32 in Linux, but an unlimited number
> > of bits in the USB hid spec, so there is some rearchitecture needed now that
> > devices are sending more than 32 bits.
> >
> > Signed-off-by: Joshua Clayton
> >
> > diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
> > index 210b81a56e1a..3eaee2c37931 100644
> > --- a/drivers/hid/hid-core.c
> > +++ b/drivers/hid/hid-core.c
> > @@ -1311,8 +1311,8 @@ u32 hid_field_extract(const struct hid_device *hid,
> > u8 *report,
> > unsigned offset, unsigned n)
> > {
> > if (n > 32) {
> > - hid_warn(hid, "hid_field_extract() called with n (%d) > 32!
> > (%s)\n",
> > -n, current->comm);
> > + hid_warn_once(hid, "%s() called with n (%d) > 32! (%s)\n",
> > + __func__, n, current->comm);
> > n = 32;
> > }
> >
> > --
> > 2.21.0
> >
[PATCH] Input - elan_i2c: remove Lenovo Legion Y7000 PnpID
Looks like the Bios of the Lenovo Legion Y7000 is using ELAN061B
when the actual device is supposed to be used with hid-multitouch.
Remove it from the list of the supported device, hoping that
no one will complain about the loss in functionality.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=203467
Fixes: Fixes: 738c06d0e456 ("Input: elan_i2c - add hardware ID for multiple
Lenovo laptops")
Signed-off-by: Benjamin Tissoires
---
Note to self: once this gets in, we need to send a similar patch
to stable, as there are a few stable branches with this PnpID.
include/linux/input/elan-i2c-ids.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/input/elan-i2c-ids.h
b/include/linux/input/elan-i2c-ids.h
index ceabb01a6a7d..1ecb6b45812c 100644
--- a/include/linux/input/elan-i2c-ids.h
+++ b/include/linux/input/elan-i2c-ids.h
@@ -48,7 +48,7 @@ static const struct acpi_device_id elan_acpi_id[] = {
{ "ELAN0618", 0 },
{ "ELAN0619", 0 },
{ "ELAN061A", 0 },
- { "ELAN061B", 0 },
+/* { "ELAN061B", 0 }, not working on the Lenovo Legion Y7000 */
{ "ELAN061C", 0 },
{ "ELAN061D", 0 },
{ "ELAN061E", 0 },
--
2.21.0
[PATCH stable 5.2/4.19] Revert "Input: elantech - enable SMBus on new (2018+) systems"
This reverts commit 60956b018bfe23b879405a7d88103d0a8f06a5e3.
This patch depends on an other series:
https://patchwork.kernel.org/project/linux-input/list/?series=122327=%2A=both
It was a mistake to backport it in the v5.2 branch, as there
is a high chance we encounter a touchpad that needs the series
above.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=204733
Link: https://bugzilla.kernel.org/show_bug.cgi?id=204771
Signed-off-by: Benjamin Tissoires
---
Hi,
this is a stable only patch aimed at kernels v5.2 and v4.19 branches.
We already have 2 bug reports of a failing touchpad, and I don't think
it is worth trying to get a smoother touchpad if we randomly
break a few of them in the way.
Cheers,
Benjamin
---
drivers/input/mouse/elantech.c | 54 ++
1 file changed, 29 insertions(+), 25 deletions(-)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index a47c7add4e0e..a4345052abd2 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -1807,30 +1807,6 @@ static int elantech_create_smbus(struct psmouse *psmouse,
leave_breadcrumbs);
}
-static bool elantech_use_host_notify(struct psmouse *psmouse,
-struct elantech_device_info *info)
-{
- if (ETP_NEW_IC_SMBUS_HOST_NOTIFY(info->fw_version))
- return true;
-
- switch (info->bus) {
- case ETP_BUS_PS2_ONLY:
- /* expected case */
- break;
- case ETP_BUS_SMB_HST_NTFY_ONLY:
- case ETP_BUS_PS2_SMB_HST_NTFY:
- /* SMbus implementation is stable since 2018 */
- if (dmi_get_bios_year() >= 2018)
- return true;
- default:
- psmouse_dbg(psmouse,
- "Ignoring SMBus bus provider %d\n", info->bus);
- break;
- }
-
- return false;
-}
-
/**
* elantech_setup_smbus - called once the PS/2 devices are enumerated
* and decides to instantiate a SMBus InterTouch device.
@@ -1850,7 +1826,7 @@ static int elantech_setup_smbus(struct psmouse *psmouse,
* i2c_blacklist_pnp_ids.
* Old ICs are up to the user to decide.
*/
- if (!elantech_use_host_notify(psmouse, info) ||
+ if (!ETP_NEW_IC_SMBUS_HOST_NOTIFY(info->fw_version) ||
psmouse_matches_pnp_id(psmouse, i2c_blacklist_pnp_ids))
return -ENXIO;
}
@@ -1870,6 +1846,34 @@ static int elantech_setup_smbus(struct psmouse *psmouse,
return 0;
}
+static bool elantech_use_host_notify(struct psmouse *psmouse,
+struct elantech_device_info *info)
+{
+ if (ETP_NEW_IC_SMBUS_HOST_NOTIFY(info->fw_version))
+ return true;
+
+ switch (info->bus) {
+ case ETP_BUS_PS2_ONLY:
+ /* expected case */
+ break;
+ case ETP_BUS_SMB_ALERT_ONLY:
+ /* fall-through */
+ case ETP_BUS_PS2_SMB_ALERT:
+ psmouse_dbg(psmouse, "Ignoring SMBus provider through alert
protocol.\n");
+ break;
+ case ETP_BUS_SMB_HST_NTFY_ONLY:
+ /* fall-through */
+ case ETP_BUS_PS2_SMB_HST_NTFY:
+ return true;
+ default:
+ psmouse_dbg(psmouse,
+ "Ignoring SMBus bus provider %d.\n",
+ info->bus);
+ }
+
+ return false;
+}
+
int elantech_init_smbus(struct psmouse *psmouse)
{
struct elantech_device_info info;
--
2.21.0
Re: [PATCH v2] HID: apple: Fix stuck function keys when using FN
On Tue, Sep 3, 2019 at 8:33 PM João Moreno wrote:
>
> Hi Benjamin,
>
> On Tue, 3 Sep 2019 at 16:46, Benjamin Tissoires
> wrote:
> >
> > From: Joao Moreno
> >
> > This fixes an issue in which key down events for function keys would be
> > repeatedly emitted even after the user has raised the physical key. For
> > example, the driver fails to emit the F5 key up event when going through
> > the following steps:
> > - fnmode=1: hold FN, hold F5, release FN, release F5
> > - fnmode=2: hold F5, hold FN, release F5, release FN
> >
> > The repeated F5 key down events can be easily verified using xev.
> >
> > Signed-off-by: Joao Moreno
> > Co-developed-by: Benjamin Tissoires
> > Signed-off-by: Benjamin Tissoires
> > ---
> >
> > Hi Joao,
> >
> > last chance to pull back :)
> >
> > If you are still happy, I'll push this version
> >
> > Cheers,
> > Benjamin
> >
>
> Looks great. Thanks a bunch for your help!
>
Thanks.
Applied to for-5.4/apple
Cheers,
Benjamin
> Cheers,
> João
>
> > drivers/hid/hid-apple.c | 49 +++--
> > 1 file changed, 28 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
> > index 81df62f48c4c..6ac8becc2372 100644
> > --- a/drivers/hid/hid-apple.c
> > +++ b/drivers/hid/hid-apple.c
> > @@ -54,7 +54,6 @@ MODULE_PARM_DESC(swap_opt_cmd, "Swap the Option (\"Alt\")
> > and Command (\"Flag\")
> > struct apple_sc {
> > unsigned long quirks;
> > unsigned int fn_on;
> > - DECLARE_BITMAP(pressed_fn, KEY_CNT);
> > DECLARE_BITMAP(pressed_numlock, KEY_CNT);
> > };
> >
> > @@ -181,6 +180,8 @@ static int hidinput_apple_event(struct hid_device *hid,
> > struct input_dev *input,
> > {
> > struct apple_sc *asc = hid_get_drvdata(hid);
> > const struct apple_key_translation *trans, *table;
> > + bool do_translate;
> > + u16 code = 0;
> >
> > if (usage->code == KEY_FN) {
> > asc->fn_on = !!value;
> > @@ -189,8 +190,6 @@ static int hidinput_apple_event(struct hid_device *hid,
> > struct input_dev *input,
> > }
> >
> > if (fnmode) {
> > - int do_translate;
> > -
> > if (hid->product >= USB_DEVICE_ID_APPLE_WELLSPRING4_ANSI &&
> > hid->product <=
> > USB_DEVICE_ID_APPLE_WELLSPRING4A_JIS)
> > table = macbookair_fn_keys;
> > @@ -202,25 +201,33 @@ static int hidinput_apple_event(struct hid_device
> > *hid, struct input_dev *input,
> > trans = apple_find_translation (table, usage->code);
> >
> > if (trans) {
> > - if (test_bit(usage->code, asc->pressed_fn))
> > - do_translate = 1;
> > - else if (trans->flags & APPLE_FLAG_FKEY)
> > - do_translate = (fnmode == 2 && asc->fn_on)
> > ||
> > - (fnmode == 1 && !asc->fn_on);
> > - else
> > - do_translate = asc->fn_on;
> > -
> > - if (do_translate) {
> > - if (value)
> > - set_bit(usage->code,
> > asc->pressed_fn);
> > - else
> > - clear_bit(usage->code,
> > asc->pressed_fn);
> > -
> > - input_event(input, usage->type, trans->to,
> > - value);
> > -
> > - return 1;
> > + if (test_bit(trans->from, input->key))
> > + code = trans->from;
> > + else if (test_bit(trans->to, input->key))
> > + code = trans->to;
> > +
> > + if (!code) {
> > + if (trans->flags & APPLE_FLAG_FKEY) {
> > + switch (fnmode) {
> > + case 1:
> > + do_translate
Re: [PATCH v6] HID: sb0540: add support for Creative SB0540 IR receivers
On Tue, Sep 3, 2019 at 4:15 PM Bastien Nocera wrote: > > Hey, > > On Tue, 2019-07-02 at 10:39 +0200, Bastien Nocera wrote: > > From: Bastien Nocera > > > > Add a new hid driver for the Creative SB0540 IR receiver. This > > receiver > > is usually coupled with an RM-1500 or an RM-1800 remote control. > > > > The scrollwheels on the RM-1800 remote are not bound, as they are > > labelled for specific audio controls that don't usually exist on most > > systems. They can be remapped using standard Linux keyboard > > remapping tools. > > I'm back from travelling, so ready to update/respin this patch if > needed. > Nope, looks good now. Applied to for-5.4/sb0540 Sorry for the delay, a mess in my mailbox hid the v6. Cheers, Benjamin
[PATCH v2] HID: apple: Fix stuck function keys when using FN
From: Joao Moreno
This fixes an issue in which key down events for function keys would be
repeatedly emitted even after the user has raised the physical key. For
example, the driver fails to emit the F5 key up event when going through
the following steps:
- fnmode=1: hold FN, hold F5, release FN, release F5
- fnmode=2: hold F5, hold FN, release F5, release FN
The repeated F5 key down events can be easily verified using xev.
Signed-off-by: Joao Moreno
Co-developed-by: Benjamin Tissoires
Signed-off-by: Benjamin Tissoires
---
Hi Joao,
last chance to pull back :)
If you are still happy, I'll push this version
Cheers,
Benjamin
drivers/hid/hid-apple.c | 49 +++--
1 file changed, 28 insertions(+), 21 deletions(-)
diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
index 81df62f48c4c..6ac8becc2372 100644
--- a/drivers/hid/hid-apple.c
+++ b/drivers/hid/hid-apple.c
@@ -54,7 +54,6 @@ MODULE_PARM_DESC(swap_opt_cmd, "Swap the Option (\"Alt\") and
Command (\"Flag\")
struct apple_sc {
unsigned long quirks;
unsigned int fn_on;
- DECLARE_BITMAP(pressed_fn, KEY_CNT);
DECLARE_BITMAP(pressed_numlock, KEY_CNT);
};
@@ -181,6 +180,8 @@ static int hidinput_apple_event(struct hid_device *hid,
struct input_dev *input,
{
struct apple_sc *asc = hid_get_drvdata(hid);
const struct apple_key_translation *trans, *table;
+ bool do_translate;
+ u16 code = 0;
if (usage->code == KEY_FN) {
asc->fn_on = !!value;
@@ -189,8 +190,6 @@ static int hidinput_apple_event(struct hid_device *hid,
struct input_dev *input,
}
if (fnmode) {
- int do_translate;
-
if (hid->product >= USB_DEVICE_ID_APPLE_WELLSPRING4_ANSI &&
hid->product <=
USB_DEVICE_ID_APPLE_WELLSPRING4A_JIS)
table = macbookair_fn_keys;
@@ -202,25 +201,33 @@ static int hidinput_apple_event(struct hid_device *hid,
struct input_dev *input,
trans = apple_find_translation (table, usage->code);
if (trans) {
- if (test_bit(usage->code, asc->pressed_fn))
- do_translate = 1;
- else if (trans->flags & APPLE_FLAG_FKEY)
- do_translate = (fnmode == 2 && asc->fn_on) ||
- (fnmode == 1 && !asc->fn_on);
- else
- do_translate = asc->fn_on;
-
- if (do_translate) {
- if (value)
- set_bit(usage->code, asc->pressed_fn);
- else
- clear_bit(usage->code, asc->pressed_fn);
-
- input_event(input, usage->type, trans->to,
- value);
-
- return 1;
+ if (test_bit(trans->from, input->key))
+ code = trans->from;
+ else if (test_bit(trans->to, input->key))
+ code = trans->to;
+
+ if (!code) {
+ if (trans->flags & APPLE_FLAG_FKEY) {
+ switch (fnmode) {
+ case 1:
+ do_translate = !asc->fn_on;
+ break;
+ case 2:
+ do_translate = asc->fn_on;
+ break;
+ default:
+ /* should never happen */
+ do_translate = false;
+ }
+ } else {
+ do_translate = asc->fn_on;
+ }
+
+ code = do_translate ? trans->to : trans->from;
}
+
+ input_event(input, usage->type, code, value);
+ return 1;
}
if (asc->quirks & APPLE_NUMLOCK_EMULATION &&
--
2.19.2
Re: [PATCH] HID: apple: Fix stuck function keys when using FN
Hi João,
On Mon, Sep 2, 2019 at 4:44 PM João Moreno wrote:
>
> Hi Benjamin,
>
> First of all, sorry for the late reply. Turns out a newborn baby can
> keep one quite busy, who would have known? :)
heh. Well, congrats!
>
> On Tue, 27 Aug 2019 at 18:57, Benjamin Tissoires
> wrote:
> >
> > Hi João,
> >
> > On 8/12/19 6:57 PM, Benjamin Tissoires wrote:
> > > Hi João,
> > >
> > > On Thu, Aug 8, 2019 at 10:35 PM João Moreno wrote:
> > >>
> > >> Hi Benjamin,
> > >>
> > >> On Mon, 8 Jul 2019 at 22:35, João Moreno wrote:
> > >>>
> > >>> Hi Benjamin,
> > >>>
> > >>> No worries, also pretty busy over here. Didn't mean to press.
> > >>>
> > >>> On Mon, 1 Jul 2019 at 10:32, Benjamin Tissoires
> > >>> wrote:
> > >>>>
> > >>>> Hi João,
> > >>>>
> > >>>> On Sun, Jun 30, 2019 at 10:15 PM João Moreno
> > >>>> wrote:
> > >>>>>
> > >>>>> Hi Jiri & Benjamin,
> > >>>>>
> > >>>>> Let me know if you need something else to get this patch moving
> > >>>>> forward. This
> > >>>>> fixes an issue I hit daily, it would be great to get it fixed.
> > >>>>
> > >>>> Sorry for the delay, I am very busy with internal corporate stuff, and
> > >>>> I tried setting up a new CI system at home, and instead of spending a
> > >>>> couple of ours, I am down to 2 weeks of hard work, without possibility
> > >>>> to switch to the new right now :(
> > >>>> Anyway.
> > >>>>
> > >>>>>
> > >>>>> Thanks.
> > >>>>>
> > >>>>> On Mon, 10 Jun 2019 at 23:31, Joao Moreno wrote:
> > >>>>>>
> > >>>>>> This fixes an issue in which key down events for function keys would
> > >>>>>> be
> > >>>>>> repeatedly emitted even after the user has raised the physical key.
> > >>>>>> For
> > >>>>>> example, the driver fails to emit the F5 key up event when going
> > >>>>>> through
> > >>>>>> the following steps:
> > >>>>>> - fnmode=1: hold FN, hold F5, release FN, release F5
> > >>>>>> - fnmode=2: hold F5, hold FN, release F5, release FN
> > >>>>
> > >>>> Ouch :/
> > >>>>
> > >>>
> > >>> Right?!
> > >>>
> > >>>>>>
> > >>>>>> The repeated F5 key down events can be easily verified using xev.
> > >>>>>>
> > >>>>>> Signed-off-by: Joao Moreno
> > >>>>>> ---
> > >>>>>> drivers/hid/hid-apple.c | 21 +++--
> > >>>>>> 1 file changed, 11 insertions(+), 10 deletions(-)
> > >>>>>>
> > >>>>>> diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
> > >>>>>> index 1cb41992aaa1..81867a6fa047 100644
> > >>>>>> --- a/drivers/hid/hid-apple.c
> > >>>>>> +++ b/drivers/hid/hid-apple.c
> > >>>>>> @@ -205,20 +205,21 @@ static int hidinput_apple_event(struct
> > >>>>>> hid_device *hid, struct input_dev *input,
> > >>>>>> trans = apple_find_translation (table, usage->code);
> > >>>>>>
> > >>>>>> if (trans) {
> > >>>>>> - if (test_bit(usage->code, asc->pressed_fn))
> > >>>>>> - do_translate = 1;
> > >>>>>> - else if (trans->flags & APPLE_FLAG_FKEY)
> > >>>>>> - do_translate = (fnmode == 2 &&
> > >>>>>> asc->fn_on) ||
> > >>>>>> - (fnmode == 1 && !asc->fn_on);
> > >>>>>> + int fn_on = value ? asc->fn_on :
> > >>>>>> + test_bit(usage->code,
> > >>>>>> asc->pressed_fn);
> > >>>>>>
Re: [PATCH] HID: apple: Fix stuck function keys when using FN
Hi João,
On 8/12/19 6:57 PM, Benjamin Tissoires wrote:
> Hi João,
>
> On Thu, Aug 8, 2019 at 10:35 PM João Moreno wrote:
>>
>> Hi Benjamin,
>>
>> On Mon, 8 Jul 2019 at 22:35, João Moreno wrote:
>>>
>>> Hi Benjamin,
>>>
>>> No worries, also pretty busy over here. Didn't mean to press.
>>>
>>> On Mon, 1 Jul 2019 at 10:32, Benjamin Tissoires
>>> wrote:
>>>>
>>>> Hi João,
>>>>
>>>> On Sun, Jun 30, 2019 at 10:15 PM João Moreno wrote:
>>>>>
>>>>> Hi Jiri & Benjamin,
>>>>>
>>>>> Let me know if you need something else to get this patch moving forward.
>>>>> This
>>>>> fixes an issue I hit daily, it would be great to get it fixed.
>>>>
>>>> Sorry for the delay, I am very busy with internal corporate stuff, and
>>>> I tried setting up a new CI system at home, and instead of spending a
>>>> couple of ours, I am down to 2 weeks of hard work, without possibility
>>>> to switch to the new right now :(
>>>> Anyway.
>>>>
>>>>>
>>>>> Thanks.
>>>>>
>>>>> On Mon, 10 Jun 2019 at 23:31, Joao Moreno wrote:
>>>>>>
>>>>>> This fixes an issue in which key down events for function keys would be
>>>>>> repeatedly emitted even after the user has raised the physical key. For
>>>>>> example, the driver fails to emit the F5 key up event when going through
>>>>>> the following steps:
>>>>>> - fnmode=1: hold FN, hold F5, release FN, release F5
>>>>>> - fnmode=2: hold F5, hold FN, release F5, release FN
>>>>
>>>> Ouch :/
>>>>
>>>
>>> Right?!
>>>
>>>>>>
>>>>>> The repeated F5 key down events can be easily verified using xev.
>>>>>>
>>>>>> Signed-off-by: Joao Moreno
>>>>>> ---
>>>>>> drivers/hid/hid-apple.c | 21 +++--
>>>>>> 1 file changed, 11 insertions(+), 10 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
>>>>>> index 1cb41992aaa1..81867a6fa047 100644
>>>>>> --- a/drivers/hid/hid-apple.c
>>>>>> +++ b/drivers/hid/hid-apple.c
>>>>>> @@ -205,20 +205,21 @@ static int hidinput_apple_event(struct hid_device
>>>>>> *hid, struct input_dev *input,
>>>>>> trans = apple_find_translation (table, usage->code);
>>>>>>
>>>>>> if (trans) {
>>>>>> - if (test_bit(usage->code, asc->pressed_fn))
>>>>>> - do_translate = 1;
>>>>>> - else if (trans->flags & APPLE_FLAG_FKEY)
>>>>>> - do_translate = (fnmode == 2 &&
>>>>>> asc->fn_on) ||
>>>>>> - (fnmode == 1 && !asc->fn_on);
>>>>>> + int fn_on = value ? asc->fn_on :
>>>>>> + test_bit(usage->code, asc->pressed_fn);
>>>>>> +
>>>>>> + if (!value)
>>>>>> + clear_bit(usage->code, asc->pressed_fn);
>>>>>> + else if (asc->fn_on)
>>>>>> + set_bit(usage->code, asc->pressed_fn);
>>>>
>>>> I have the feeling that this is not the correct fix here.
>>>>
>>>> I might be wrong, but the following sequence might also mess up the
>>>> driver state, depending on how the reports are emitted:
>>>> - hold FN, hold F4, hold F5, release F4, release FN, release F5
>>>>
>>>
>>> I believe this should be fine. Following the code:
>>>
>>> - hold FN, sets asc->fn_on to true
>>> - hold F4, in the trans block fn_on will be true and we'll set the F4
>>> bit in the bitmap
>>> - hold F5, in the trans block fn_on will be true and we'll set the F5 bit
>>> - release F4, in the trans block fn_on will be true (because of the bitmap)
>>> and
>>> we'll clear the F4 bit
>>> - release FN, asc->fn_on will be false, but it d
Re: [PATCH v4] hid-logitech-hidpp: read battery voltage from newer devices
Hi Pedro,
On Fri, Aug 23, 2019 at 5:51 PM Pedro Vanzella wrote:
>
> Newer Logitech mice report their battery voltage through feature 0x1001
> instead of the battery levels through feature 0x1000.
>
> When the device is brought up and we try to query the battery, figure
> out if it supports the old or the new feature. If it supports the new
> feature, record the feature index and read the battery voltage and
> its status.
>
> If everything went correctly, record the fact that we're capable
> of querying battery voltage.
>
> Note that the protocol only gives us the current voltage in millivolts.
>
> Like we do for other ways of interacting with the battery for other
> devices, refresh the battery status and notify the power supply
> subsystem of the changes in voltage and status.
>
> Signed-off-by: Pedro Vanzella
I still have comments, please see inline:
> ---
> drivers/hid/hid-logitech-hidpp.c | 140 ++-
> 1 file changed, 138 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/hid-logitech-hidpp.c
> b/drivers/hid/hid-logitech-hidpp.c
> index 0179f7ed77e5..5c9c3133d2ae 100644
> --- a/drivers/hid/hid-logitech-hidpp.c
> +++ b/drivers/hid/hid-logitech-hidpp.c
> @@ -87,6 +87,7 @@ MODULE_PARM_DESC(disable_tap_to_click,
> #define HIDPP_CAPABILITY_HIDPP20_BATTERY BIT(1)
> #define HIDPP_CAPABILITY_BATTERY_MILEAGE BIT(2)
> #define HIDPP_CAPABILITY_BATTERY_LEVEL_STATUS BIT(3)
> +#define HIDPP_CAPABILITY_BATTERY_VOLTAGE BIT(4)
>
> /*
> * There are two hidpp protocols in use, the first version hidpp10 is known
> @@ -135,12 +136,14 @@ struct hidpp_report {
> struct hidpp_battery {
> u8 feature_index;
> u8 solar_feature_index;
> + u8 voltage_feature_index;
> struct power_supply_desc desc;
> struct power_supply *ps;
> char name[64];
> int status;
> int capacity;
> int level;
> + int voltage; /* in millivolts */
> bool online;
> };
>
> @@ -1219,6 +1222,122 @@ static int hidpp20_battery_event(struct hidpp_device
> *hidpp,
> return 0;
> }
>
> +/*
> -- */
> +/* 0x1001: Battery voltage
> */
> +/*
> -- */
> +
> +#define HIDPP_PAGE_BATTERY_VOLTAGE 0x1001
> +
> +#define CMD_BATTERY_VOLTAGE_GET_BATTERY_VOLTAGE 0x00
> +
> +static int hidpp20_battery_map_status_voltage(u8 data[3], int *voltage)
> +{
> + int status;
> +
> + switch (data[2]) {
> + case 0x00: /* discharging */
> + status = POWER_SUPPLY_STATUS_DISCHARGING;
> + break;
> + case 0x10: /* wireless charging */
> + case 0x80: /* charging */
> + status = POWER_SUPPLY_STATUS_CHARGING;
> + break;
> + case 0x81: /* fully charged */
> + status = POWER_SUPPLY_STATUS_FULL;
> + break;
> + default:
> + status = POWER_SUPPLY_STATUS_NOT_CHARGING;
> + }
> +
> + *voltage = (data[0] << 8) + data[1];
If I am not wrong, you can use get_unaligned_be16 here instead
> +
> + return status;
> +}
> +
> +static int hidpp20_battery_get_battery_voltage(struct hidpp_device *hidpp,
> + u8 feature_index,
> + int *status, int *voltage)
> +{
> + struct hidpp_report response;
> + int ret;
> + u8 *params = (u8 *)response.fap.params;
> +
> + ret = hidpp_send_fap_command_sync(hidpp, feature_index,
> +
> CMD_BATTERY_VOLTAGE_GET_BATTERY_VOLTAGE,
> + NULL, 0, );
> +
> + if (ret > 0) {
> + hid_err(hidpp->hid_dev, "%s: received protocol error
> 0x%02x\n",
> + __func__, ret);
> + return -EPROTO;
> + }
> + if (ret)
> + return ret;
> +
> + hidpp->capabilities |= HIDPP_CAPABILITY_BATTERY_VOLTAGE;
> +
> + *status = hidpp20_battery_map_status_voltage(params, voltage);
> +
> + return 0;
> +}
> +
> +static int hidpp20_query_battery_voltage_info(struct hidpp_device *hidpp)
> +{
> + u8 feature_type;
> + int ret;
> + int status, voltage;
> +
> + if (hidpp->battery.voltage_feature_index == 0xff) {
> + ret = hidpp_root_get_feature(hidpp,
> HIDPP_PAGE_BATTERY_VOLTAGE,
> +
> >battery.voltage_feature_index,
> +_type);
> + if (ret)
> + return ret;
> + }
> +
> + ret = hidpp20_battery_get_battery_voltage(hidpp,
> +
> hidpp->battery.voltage_feature_index,
> + , );
>
Re: [Resubmit] Read battery voltage from Logitech Gaming mice
On Fri, Aug 23, 2019 at 4:48 PM Filipe Laíns wrote: > > On Fri, 2019-08-23 at 16:32 +0200, Benjamin Tissoires wrote: > > The problem I have with quirks, and that I explained to Filipe on IRC > > is that this is kernel ABI. Even if there is a very low chance we have > > someone using this, re-using the same drv_data bit in the future might > > break someone's device. > > But we can reserve those bits. I don't expect there to be a ton of > devices that need to be quirked, so using the remaining bits should be > perfectly fine. Do you agree? Nope. If the code is not ready for upstream, it should not be included. Cheers, Benjamin
