- 14 May, 2024 7 commits
-
-
Jiri Kosina authored
- Implement loading firmware from host in intel-ish driver, needed to support Lunar Lake and later (Zhang Lixu)
-
Jiri Kosina authored
- PM fixes for STM and Weida Tech devices (Kenny Levinsen)
-
Jiri Kosina authored
- conversion from sprintf() to sysfs_emit() (Li Zhijian)
-
Jiri Kosina authored
- support for missing mappings and codes from HUT 1.5 in hid-debug (Thomas Kuehne)
-
Jiri Kosina authored
- updates to HID-BPF infrastructure, with some of the specific fixes (e.g. rdesc fixups) abstracted into separate BPF programs for consumption by libevdev/udev-hid-bpf (Benjamin Tissoires)
-
Jiri Kosina authored
- initial support for ROG Ally and ROG X13 devices (Luke D. Jones) - other small assorted cleanups of hid-asus driver (Luke D. Jones)
-
Jiri Kosina authored
- PM fix and assorted other code cleanups for amd-sfh (Basavaraj Natikar)
-
- 07 May, 2024 23 commits
-
-
Benjamin Tissoires authored
udev-hid-bpf is still not installed everywhere, and we should probably not assume it is installed automatically. Link: https://lore.kernel.org/r/20240506143612.148031-1-bentiss@kernel.orgReviewed-by:
Peter Hutterer <peter.hutterer@who-t.net> Signed-off-by:
Benjamin Tissoires <bentiss@kernel.org>
-
Benjamin Tissoires authored
The only interesting bit is the HAT switch, and we use a BPF program to fix it. So ensure this works correctly. Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-18-a8bf16033ef8@kernel.orgReviewed-by:
-
Benjamin Tissoires authored
More in line with the other test_* files. No code change Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-17-a8bf16033ef8@kernel.orgReviewed-by:
-
Benjamin Tissoires authored
We need to slightly change base_device.py for supporting HID-BPF, so instead of monkey patching, let's just embed it in the kernel tree. Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-16-a8bf16033ef8@kernel.orgReviewed-by:
-
Benjamin Tissoires authored
This tablets gets a lot of things wrong: - the secondary button is reported through Secondary Tip Switch - the third button is reported through Invert We need to add some out of proximity intermediate state when moving back and forth with the eraser mode as it can only be triggered by physically returning the pen, meaning that the tolerated transitions can never happen. Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-15-a8bf16033ef8@kernel.orgReviewed-by:
-
Benjamin Tissoires authored
The values are taken from the HID-BPF file. Basically we are recomputing the array provided there. Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-14-a8bf16033ef8@kernel.orgReviewed-by:
-
Benjamin Tissoires authored
Those tablets don't need special initialization, but are reporting the events with the wrong usages: - tip switch is used when the eraser should be used - eraser is used instead of the secondary barrel switch Add tests for those so we don't regress in the future. Currently we set x/y tilt to 0 to not trigger the bpf program compensate_coordinates_by_tilt() Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-13-a8bf16033ef8@kernel.orgReviewed-by:
-
Benjamin Tissoires authored
All the *_WITH*BUTTON states were almost identical except for the button itself. I need to add a new device with a third button, and adding a bunch of states is going to be quite cumbersome. So convert the `button` parameter of PenState as a boolean, and store which button is the target as an argument to all functions that need it. Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-12-a8bf16033ef8@kernel.orgReviewed-by:
-
Benjamin Tissoires authored
few required changes: - we need to count how many times a udev 'bind' event happens - we need to tell `udev-hid-bpf` to not automatically attach the provided HID-BPF objects - we need to manually attach the ones from the kernel tree, and wait for the second udev 'bind' event to happen Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-11-a8bf16033ef8@kernel.orgReviewed-by:
-
Benjamin Tissoires authored
We need to slightly change base_device.py for supporting HID-BPF, so instead of monkey patching, let's just embed it in the kernel tree. Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-10-a8bf16033ef8@kernel.orgReviewed-by:
-
Benjamin Tissoires authored
This device is already fixed by "HID: do not assume HAT Switch logical max < 8", but for people without the fix already, having the HID-BPF locally can fix the device while they wait for their distribution to update. Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-9-a8bf16033ef8@kernel.orgReviewed-by:
-
Benjamin Tissoires authored
This tablets gets a lot of things wrong: - the secondary button is reported through Secondary Tip Switch - the third button is reported through Invert Fortunately, before entering eraser mode, (so Invert = 1), the tablet always sends an out-of-proximity event. So we can detect that single event and: - if there was none but the invert bit was toggled: this is the third button - if there was this out-of-proximity event, we are entering eraser mode, and we will until the next out-of-proximity. Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-8-a8bf16033ef8@kernel.orgReviewed-by:
-
Benjamin Tissoires authored
When using the XBox Wireless Controller Elite 2 over Bluetooth, the device exports the paddle on the back of the device as a single bitfield value of usage "Assign Selection". The kernel doesn't process those usages properly and report KEY_UNKNOWN for it. SDL doesn't know how to interprete that KEY_UNKNOWN and thus ignores the paddles. Given that over USB the kernel uses BTN_TRIGGER_HAPPY[5-8], we can tweak the report descriptor to make the kernel interprete it properly: - we need an application collection of gamepad (so we have to close the current Consumer Control one) - we need to change the usage to be buttons from 0x15 to 0x18 Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-7-a8bf16033ef8@kernel.orgReviewed-by:
-
Benjamin Tissoires authored
This pen is compatible with multiple Wacom tablets, but we only add support for the Intuos Pro 2 M, as this is the one our user reported the bug against. We can not generically add all compatible Wacom tablets as we are writing the offsets by hand. The point of this HID-BPF program is to work around a firmware limitation where the pressure is repeated every other report. Given that we know this will happen, we can change the first new pressure information with the mean compared to the previous one. This way we smooth the incoming pressure without losing information. Cc: Ping Cheng <pinglinux@gmail.com> Cc: Jason Gerecke <killertofu@gmail.com> Cc: Aaron Armstrong Skomra <skomra@gmail.com> Cc: Joshua Dickens <Joshua@joshua-dickens.com> Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-6-a8bf16033ef8@kernel.orgReviewed-by:
-
Benjamin Tissoires authored
Allows to export more than 5 buttons on this 12 buttons mouse. Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-5-a8bf16033ef8@kernel.orgReviewed-by:
-
Benjamin Tissoires authored
Duplicate of commit 0db11735 ("HID: add quirk for 03f0:464a HP Elite Presenter Mouse"), but in a slightly better way. This time we actually change the application collection, making clearer for userspace what the second mouse is. Note that having both hid-quirks fix and this HID-BPF fix is not a problem at all. Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-4-a8bf16033ef8@kernel.orgReviewed-by:
-
Benjamin Tissoires authored
Same problem than the Artist 24: the second button on the pen is treated like an eraser. But the problem is even worse this time. There is an actual eraser at the tail of the pen. The compensation of the coordinates was done by Martin Signed-off-by:
Martin Sivak <mars@montik.net> Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-3-a8bf16033ef8@kernel.orgReviewed-by:
-
Benjamin Tissoires authored
This commit adds a fix for XPPen Artist 24 where the second button on the pen is used as an eraser. It's a "feature" from Microsoft, but it turns out that it's actually painful for artists. So we ship here a HID-BPF program that turns this second button into an actual button. Note that the HID-BPF program is not directly loaded by the kernel itself but by udev-hid-bpf[0]. But having the sources here allows us to also integrate tests into tools/testing/selftests/hid to ensure the HID-BPF program are actually tested. [0] https://gitlab.freedesktop.org/libevdev/udev-hid-bpf Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-2-a8bf16033ef8@kernel.orgReviewed-by:
-
Benjamin Tissoires authored
Turns out that the code can handle a greater range, but the data stored can not. This is problematic on the Raptor Mach 2 joystick which logical max is 239. The kernel interprets it as `-15` and thus ignores the Hat Switch handling. Link: https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/issues/17 Link: https://lore.kernel.org/r/20240410-bpf_sources-v1-1-a8bf16033ef8@kernel.orgReviewed-by:
-
Basavaraj Natikar authored
Newer processors support various MP2 register sets. Therefore, to ensure compatibility and obtain C2P data, use the amd_get_c2p_val(). Co-developed-by:
Patil Rajesh Reddy <patreddy@amd.com> Signed-off-by:
Basavaraj Natikar <Basavaraj.Natikar@amd.com> Signed-off-by:
Jiri Kosina <jkosina@suse.com>
-
Basavaraj Natikar authored
Resume or suspend each sensor device based on the num_hid_devices. Therefore, add a check to handle the special case where no sensors are present. Fixes: 93ce5e02 ("HID: amd_sfh: Implement SFH1.1 functionality") Signed-off-by:
-
Basavaraj Natikar authored
Modify log messages, but only log errors when sensors are missing or a true failure occurs to avoid misleading "failed" messages. Signed-off-by:
-
Kenny Levinsen authored
This label was left behind when the wake-up logic was moved from i2c_hid_set_power to i2c_hid_probe_address. Clean it up as it causes warnings-as-errors builds to fail. Fixes: bb1033c8a3ea ("HID: i2c-hid: Use address probe to wake on resume") Reported-by:Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Kenny Levinsen <kl@kl.wtf> Signed-off-by:
-
- 06 May, 2024 10 commits
-
-
Chen Ni authored
Add a check for the return value of pci_alloc_irq_vectors() and return error if it fails. [jkosina@suse.com: reworded changelog based on Srinivas' suggestion] Fixes: 74fbc7d3 ("HID: intel-ish-hid: add MSI interrupt support") Signed-off-by:
Chen Ni <nichen@iscas.ac.cn> Acked-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by:
-
Zhang Lixu authored
This patch enhances the firmware reset handler in the Intel Integrated Sensor Hub (ISH) driver. Previously, the ISH firmware would send a MNG_RESET_NOTIFY message in response to an empty IPC message from the ish_wakeup function. With the introduction of the feature to load ISH firmware from the host on the LunarLake platform, the ISH bootloader now involves the IPC function. This results in an additional MNG_RESET_NOTIFY message being sent by ISH bootloader after power on. Consequently, the driver receives two MNG_RESET_NOTIFY messages during system boot up. This can disrupt the dev->dev_state during the first reset flow due to the subsequent reset notify message. To address this, the patch modifies the fw_reset_work_fn function to skip the execution of ishtp_reset_compl_handler during the first reset flow if a reset is pending. The ishtp_reset_compl_handler will then be executed during the second reset flow, ensuring the dev->dev_state is not disrupted. Signed-off-by:
Zhang Lixu <lixu.zhang@intel.com> Acked-by:
-
Zhang Lixu authored
Starting from the Lunar Lake generation, the ISH firmware has been divided into two components for better space optimization and increased flexibility. These components include a bootloader that is integrated into the BIOS, and a main firmware that is stored within the operating system's file system. Introduce support for loading ISH main firmware from host. This feature is applicable for Lunar Lake and later generation. Current intel-ishtp-loader, is designed for Chrome OS based systems which uses core boot and has different firmware loading method. For non chrome systems the ISH firmware loading uses different method. Key differences include: 1. The new method utilizes ISHTP capability/fixed client to enumerate the firmware loader function. It does not require a connection or flow control, unlike the method used in Chrome OS, which is enumerated as an ISHTP dynamic client driver, necessitating connect/disconnect operations and flow control. 2. The new method employs a table to describe firmware fragments, which are sent to ISH in a single operation. Conversely, the Chrome OS method sends firmware fragments in multiple operations within a loop, sending only one fragment at a time. Additionally, address potential error scenarios to ensure graceful failure handling. - Firmware Not Found: Triggers if request_firmware() fails, leaving ISH in a waiting state. Recovery: Re-insmod the ISH drivers to retry. - DMA Buffer Allocation Failure: Occurs during prepare_dma_bufs(), leading to ISH waiting state. Allocated resources are released. Recovery: Re-insmod the ISH drivers to retry. - Incorrect Firmware Image: Causes ISH to refuse loading after three failed attempts. Recovery: A platform reset is required. Please refer to the [Documentation](Documentation/hid/intel-ish-hid.rst) for the details on flows. Signed-off-by:
-
Zhang Lixu authored
Introduces a new structure, ishtp_driver_data, to hold driver-specific data, including the firmware filename for different hardware variants of the Intel Integrated Sensor Hub (ISH). Signed-off-by:
-
Qianru Huang authored
Add a section to describe the ISH firmware loading process for Lunar Lake and later generations. Signed-off-by:
Qianru Huang <qianru.huang@intel.com> Signed-off-by:
-
Qianru Huang authored
Remove section numbering from the Intel Integrated Sensor Hub (ISH) documentation to simplify the structure, making it easier to maintain and update in the future. Suggested-by:
Andy Shevchenko <andriy.shevchenko@intel.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
-
Kenny Levinsen authored
Certain devices, both from STM and Weida Tech, need to be woken up after having entered a deeper sleep state. The relevant places to wake up such device is during our initial HID probe, and after resuming. A retry for power commands was previously added to i2c_hid_set_power to wake up Weida Tech devices, but lacked sufficient sleep for STM devices. Replace the power command retry with the same address probe we using during our initial HID probe. Signed-off-by:
-
Kenny Levinsen authored
Some STM microcontrollers need 400µs after rising clock edge in order to come out of their deep sleep state. This in turn means that our address probe will fail as the device is not ready to service it. Retry the probe once after a delay to see if the device came alive, otherwise treat the device as missing. Link: https://lore.kernel.org/all/20240405102436.3479210-1-lma@chromium.org/#tCo-developed-by:
Radoslaw Biernacki <rad@chromium.org> Co-developed-by:
Lukasz Majczak <lma@chromium.org> Signed-off-by:
-
Luke D. Jones authored
Add init of the lightbar which is a small panel on the back of the ASUS ROG Z13 and uses the same MCU as keyboards. Signed-off-by:
Luke D. Jones <luke@ljones.dev> Signed-off-by:
-
Luke D. Jones authored
A handful of buttons on the ROG Ally are not actually part of the xpad device and are instead keyboard keys (a typical use of the MCU that asus uses). We attach a group of F<num> key codes which aren't used much and which the handheld community has already accepted as defaults here. Signed-off-by:
-
