An error occurred fetching the project authors.
- 06 May, 2024 4 commits
-
-
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: Jiri Kosina <jkosina@suse.com>
-
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: Luke D. Jones <luke@ljones.dev> Signed-off-by: Jiri Kosina <jkosina@suse.com>
-
Luke D. Jones authored
Some of the n-key stuff is old and outdated, so make asus_kbd_init() generic to use with other report ID and remove rog_nkey_led_init(). Signed-off-by: Luke D. Jones <luke@ljones.dev> Signed-off-by: Jiri Kosina <jkosina@suse.com>
-
Luke D. Jones authored
Adjusts the report descriptor for N-Key devices to make the output count 0x01 which completely avoids the need for a block of filtering. Signed-off-by: Luke D. Jones <luke@ljones.dev> Signed-off-by: Jiri Kosina <jkosina@suse.com>
-
- 22 Nov, 2023 2 commits
-
-
Denis Benato authored
Some devices managed by this driver automatically set brightness to 0 before entering a suspended state and reset it back to a default brightness level after the resume: this has the effect of having the kernel report wrong brightness status after a sleep, and on some devices (like the Asus RC71L) that brightness is the intensity of LEDs directly facing the user. Fix the above issue by setting back brightness to the level it had before entering a sleep state. Signed-off-by: Denis Benato <benato.denis96@gmail.com> Signed-off-by: Luke D. Jones <luke@ljones.dev> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
Denis Benato authored
In the function asus_kbd_set_report the parameter buf is read-only as it gets copied in a memory portion suitable for USB transfer, but the parameter is not marked as const: add the missing const and mark const immutable buffers passed to that function. Signed-off-by: Denis Benato <benato.denis96@gmail.com> Signed-off-by: Luke D. Jones <luke@ljones.dev> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
- 23 May, 2023 3 commits
-
-
Luke D. Jones authored
Older formatting of this block was beginning to get somewhat cluttered. Condensing the block and putting comments to the side makes it easier to read and scan the scancodes plus keycodes. Signed-off-by: Luke D. Jones <luke@ljones.dev> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
Luke D. Jones authored
These two keys are found on some models with dual display. - 0x6a is intended for controlling the secondary screen brightness. - 0x4b is intended for toggling the arrow keys between arrows and page up / page down. This key is found on a slightly modified keyboard layout. - 0xc7 is intended to cycle through keybvoard brightnesses (upwards) but there is not suitable existing code for this behaviour. Using `KEY_KBDILLUMTOGGLE` is different behaviour to Windows but at least is picked up by many desktops already. Signed-off-by: Luke D. Jones <luke@ljones.dev> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
Luke D. Jones authored
Add support for the ROG Z13 keyboard. This is a variant of the last few ASUS ROG keyboards and has much of the same functionality. Signed-off-by: Luke D. Jones <luke@ljones.dev> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
- 13 Apr, 2023 1 commit
-
-
Thomas Weißschuh authored
Instead of relying on an accidental, transitive inclusion of linux/leds.h use it directly. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Link: https://lore.kernel.org/r/20230215-power_supply-leds-hid-v1-3-35b6f1dcee8a@weissschuh.netSigned-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
-
- 15 Feb, 2023 2 commits
-
-
Pietro Borrello authored
Use spinlocks to deal with workers introducing a wrapper asus_schedule_work(), and several spinlock checks. Otherwise, asus_kbd_backlight_set() may schedule led->work after the structure has been freed, causing a use-after-free. Fixes: af22a610 ("HID: asus: support backlight on USB keyboards") Signed-off-by: Pietro Borrello <borrello@diag.uniroma1.it> Link: https://lore.kernel.org/r/20230125-hid-unregister-leds-v4-5-7860c5763c38@diag.uniroma1.itSigned-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
-
Pietro Borrello authored
asus driver has a worker that may access data concurrently. Proct the accesses using a spinlock. Fixes: af22a610 ("HID: asus: support backlight on USB keyboards") Signed-off-by: Pietro Borrello <borrello@diag.uniroma1.it> Link: https://lore.kernel.org/r/20230125-hid-unregister-leds-v4-4-7860c5763c38@diag.uniroma1.itSigned-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
-
- 02 Nov, 2022 1 commit
-
-
Colin Ian King authored
Variable count is just being incremented and it's never used anywhere else. The variable and the increment are redundant so remove it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
- 25 Aug, 2022 1 commit
-
-
Josh Kilmer authored
On an Asus G513QY, of the 5 bytes in a 0x5a report, only the first byte is a meaningful keycode. The other bytes are zeroed out or hold garbage from the last packet sent to the keyboard. This patch fixes up the report descriptor for this event so that the general hid code will only process 1 byte for keycodes, avoiding spurious key events and unmapped Asus vendor usagepage code warnings. Signed-off-by: Josh Kilmer <srjek2@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
- 02 Dec, 2021 1 commit
-
-
Greg Kroah-Hartman authored
A number of HID drivers already call hid_is_using_ll_driver() but only for the detection of if this is a USB device or not. Make this more obvious by creating hid_is_usb() and calling the function that way. Also converts the existing hid_is_using_ll_driver() functions to use the new call. Cc: Jiri Kosina <jikos@kernel.org> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: linux-input@vger.kernel.org Cc: stable@vger.kernel.org Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Link: https://lore.kernel.org/r/20211201183503.2373082-1-gregkh@linuxfoundation.org
-
- 12 Nov, 2021 1 commit
-
-
Vinícius Angiolucci Reis authored
This reverts commit 2ea5999d. As Dmitry Torokhov pointed out, the previous code (KEY_DISPLAY_OFF) is actually correct. The real issue is that current desktop environments don't deal it properly. Mapping it to another event does not solve the issue. So I'm reverting that change, keeping key 0x35 mapped to KEY_DISPLAY_OFF Signed-off-by: Vinícius Angiolucci Reis <angiolucci@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
- 19 Oct, 2021 1 commit
-
-
Vinícius Angiolucci Reis authored
On Windows systems, ASUS laptops uses the "turn display off" key (usually fn+f6) to turn both display and keyboard backlit off. On Linux systems, this key has no effect at all since most desktop enviroments don't deal with KEY_DISPLAY_OFF. By mapping it to KEY_SCREENLOCK instead, would enable desktop environments to handle this key as a screen lock intent from the user, out of the box. Signed-off-by: Vinícius Angiolucci Reis <angiolucci@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
- 20 Aug, 2021 1 commit
-
-
Luke D. Jones authored
Prevent the ASUS Claymore keyboard from sending a suspend event when the device sleeps itself. The suspend event causes a system suspend if uncaught. Signed off by: Luke D Jones <luke@ljones.dev> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
- 15 Jul, 2021 1 commit
-
-
Luke D. Jones authored
Remove the early return on LED brightness set so that any controller application, daemon, or desktop may set the same brightness at any stage. This is required because many ASUS ROG keyboards will default to max brightness on laptop resume if the LEDs were set to off before sleep. Signed-off-by: Luke D Jones <luke@ljones.dev> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
- 27 May, 2021 1 commit
-
-
Hans de Goede authored
There is no need to use a quirk and then return -ENODEV from the asus_probe() function to avoid that hid-asus binds to the hiddev for the USB-interface for the hid-multitouch touchpad. The hid-multitouch hiddev has a group of HID_GROUP_MULTITOUCH_WIN_8, so the same result can be achieved by making the hid_device_id entry for the dock in the asus_devices[] table only match on HID_GROUP_GENERIC instead of having it match HID_GROUP_ANY. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
- 05 May, 2021 2 commits
-
-
Luke D Jones authored
The G713 and G733 both emit an unexpected keycode on some key presses such as Fn+Pause. The device in this case is emitting two events on key down, and 3 on key up, the third key up event is report ID 0x02 and is unfiltered, causing incorrect event. This patch filters out the single problematic event. Signed-off-by: Luke D Jones <luke@ljones.dev> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
Luke D Jones authored
Older ROG keyboards emit a similar stream of bytes to the new N-Key keyboards and require filtering to prevent a lot of unmapped key warnings showing. As all the ROG keyboards use QUIRK_USE_KBD_BACKLIGHT this is now used to branch to filtering in asus_raw_event. Signed-off-by: Luke D Jones <luke@ljones.dev> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
- 08 Mar, 2021 1 commit
-
-
Luke D Jones authored
Some new 2021 version of ASUS gamer laptops are using an updated N-Key keyboard with the PID of 0x19b6. This version is using the same init sequence and brightness control as the 0x1866 keyboard. Signed-off-by: Luke D Jones <luke@ljones.dev> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
- 29 Oct, 2020 1 commit
-
-
Luke D Jones authored
The ASUS N-Key keyboard uses the productId of 0x1866 and is used in almost all modern ASUS gaming laptops with slight changes to the firmware. This patch enables: Fn+key hotkeys, keyboard backlight brightness control. Additionally this keyboard requires the LED interface to be initialized before such things as keyboard backlight control work. Signed-off-by: Luke D Jones <luke@ljones.dev> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
- 06 May, 2020 6 commits
-
-
Hans de Goede authored
The mute key, is broken. All the consumer keys on the keyboard USB interface work normally, except for mute which only sends press events and never sends release events. The touchpad key sends the otherwise unused input report with a report-id of 5 on the touchpad interface. It too only sends press events. This also requires extra special handling since the multi-touch touchpad events and the KEY_F21 events for the touchpad toggle must not be send from the same input_dev (userspace cannot handle this). This commit adds special handlig for both, fixing these keys not working. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
Hans de Goede authored
The multi-touch touchpad found on the Medion Akoya E1239T's keyboard-dock, uses the same custom multi-touch protocol as the Asus keyboard-docks (same chipset vendor, Integrated Technology Express / ITE). Add support for this using the existing multi-touch touchpad support in the hid-asus driver. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
Hans de Goede authored
Add the report_size to struct asus_touchpad_info instead of calculating it. This is a preparation patch for adding support for the multi-touch touchpad found on the Medion Akoya E1239T's keyboard-dock, which uses the same custom multi-touch protocol as the Asus keyboard-docks (same chipset vendor, Integrated Technology Express / ITE). The only difference in that the Akoya E1239T keyboard-dock's input-reports have a 5 byte footer instead of a 1 byte footer, which requires the report_size to be configurable per touchpad-model. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
Hans de Goede authored
Add a hid_is_using_ll_driver(usb_hid_driver) check to ensure that the parent device is an usb_interface, before casting the parent device pointer to an usb_interface pointer with to_usb_interface(). Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
Hans de Goede authored
Before this commit the code was trying to keep the mapping for the left mouse-button, do avoid the hidinput_has_been_populated() check in hid-input.c from triggering and causing the touchpad input_dev ro get cleaned up. But the hidinput_has_been_populated() check happens after the input_configured callback which sets up all the input bit for the touchpad, so there is no need to preserve the left button mapping. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
Hans de Goede authored
Make asus_input_mapping() only set EV_REP if we are adding a mapping. The T100CHI bluetooth keyboard dock has a few input reports for which we do not create any mappings (these input-reports are present in the descriptors but never send). The hid-asus code relies on the HID core not creating input devices for input-reports without any mappings. But the present of the EV_REP but counts as a mapping causing 6 /dev/input/event# nodes to be created for the T100CHI bluetooth keyboard dock. This change brings the amount of created /dev/input/event# nodes / input-devices down to 4. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
- 13 Dec, 2019 1 commit
-
-
Hans de Goede authored
At least on a T100HA an Asus vendor-page usage-code 0xff event is send on every suspend and again on resume, resulting in the following warning: asus 0003:0B05:1807.0002: Unmapped Asus vendor usagepage code 0xff being logged twice on every suspend/resume. This commit silences the "Unmapped Asus vendor usagepage code ..." warning for usage-code 0xff to avoid these warnings being logged. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
- 17 Jun, 2019 1 commit
-
-
Yurii Pavlovskyi authored
The DSTS method detection mistakenly selects DCTS instead of DSTS if nothing is returned when the method ID is not defined in WMNB. As a result, the control of keyboard backlight is not functional for TUF Gaming series laptops. Implement detection based on _UID of the WMI device instead. There is evidence that DCTS is handled by ACPI WMI devices that have _UID ASUSWMI, whereas none of the devices without ASUSWMI respond to DCTS and DSTS is used instead [1]. DSDT examples: FX505GM (_UID ATK): Method (WMNB, 3, Serialized) { ... If ((Local0 == 0x53545344)) { ... Return (Zero) } ... // No return } K54C (_UID ATK): Method (WMNB, 3, Serialized) { ... If ((Local0 == 0x53545344)) { ... Return (0x02) } ... Return (0xFFFFFFFE) } [1] Link: https://lkml.org/lkml/2019/4/11/322Signed-off-by: Yurii Pavlovskyi <yurii.pavlovskyi@gmail.com> Suggested-by: Daniel Drake <drake@endlessm.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-
- 30 May, 2019 1 commit
-
-
Thomas Gleixner authored
Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later version extracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-later has been chosen to replace the boilerplate/reference in 3029 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.deSigned-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 13 Feb, 2019 2 commits
-
-
NOGUCHI Hiroshi authored
Add battery monitoring support for Transbook T100CHI/T90CHI's Bluetooth keyboard dock. They report rest battery level and charging status. Signed-off-by: NOGUCHI Hiroshi <drvlabo@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
NOGUCHI Hiroshi authored
Add Transbook T90CHI support into hid-asus. T90CHI returns same BT vendor/product values as T100CHI, so identifies T90CHI by name. Signed-off-by: NOGUCHI Hiroshi <drvlabo@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
- 17 Dec, 2018 1 commit
-
-
Aleix Roca Nonell authored
The ASUS T101HA keyboard dock generates HID events using the ASUS vendor specific UsagePage 0xff31. In consequence, some multimedia keys such as brightness up and down are not working with hid-generic. This commit adds the T101HA dock into the supported device list of the hid-asus driver. It also prevents the dock's integrated touchpad to be bound with hid-asus given that it is already working fine with hid-multitouch. Signed-off-by: Aleix Roca Nonell <kernelrocks@gmail.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
-
- 30 Nov, 2018 2 commits
-
-
Hans de Goede authored
The ASUS FX503VD laptop uses an USB keyboard with several hotkeys which use the Asus Vendor specific UsagePage. This uses two usage-codes within the page which have not been seen before, 0x7c for its mic-mute hotkey and 0x99 for Fn+F5 which has a "fan" symbol as hotkey symbol on the keyb. we map this to KEY_PROG4 (PROG1-PROG3 are already used). This commit adds the mappings for the 2 new usage codes and the USB-ids for this keyboard to the hid-asus driver. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
-
Hans de Goede authored
Various Asus devices generate HID events using the Asus Vendor specific UsagePage 0xff31 and hid-asus will map these in its input_mapping for all devices to which it binds (independent of any quirks). Add an event callback which check for unmapped (because sofar unknown) usages within the Asus Vendor UsagePage and log a warning for these. The purpose of this patch is to help debugging / find such unmapped codes and add them to the asus_input_mapping() function. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
-
- 06 Nov, 2018 1 commit
-
-
Arnd Bergmann authored
asus_wmi_evaluate_method() is an empty dummy function when CONFIG_ASUS_WMI is disabled, or not reachable from a built-in device driver. This leads to a theoretical evaluation of an uninitialized variable that the compiler complains about, failing to check that the hardcoded return value makes this an unreachable code path: In file included from include/linux/printk.h:336, from include/linux/kernel.h:14, from include/linux/list.h:9, from include/linux/dmi.h:5, from drivers/hid/hid-asus.c:29: drivers/hid/hid-asus.c: In function 'asus_input_configured': include/linux/dynamic_debug.h:135:3: error: 'value' may be used uninitialized in this function [-Werror=maybe-uninitialized] __dynamic_dev_dbg(&descriptor, dev, fmt, \ ^~~~~~~~~~~~~~~~~ drivers/hid/hid-asus.c:359:6: note: 'value' was declared here u32 value; ^~~~~ With an extra IS_ENABLED() check, the warning goes away. Fixes: 3b692c55 ("HID: asus: only support backlight when it's not driven by WMI") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
-
- 31 Oct, 2018 1 commit
-
-
Daniel Drake authored
The Asus GL502VSK has the same 0B05:1837 keyboard as we've seen in several Republic of Gamers laptops. However, in this model, the keybard backlight control exposed by hid-asus has no effect on the keyboard backlight. Instead, the keyboard backlight is correctly driven by asus-wmi. With two keyboard backlight devices available (and only the acer-wmi one working), GNOME is picking the wrong one to drive in the UI. Avoid this problem by not creating the backlight interface when we detect a WMI-driven keyboard backlight. We have also tested Asus GL702VMK which does have the hid-asus backlight present, and it still works fine with this patch (WMI method call returns UNSUPPORTED_METHOD). A direct "depends on ASUS_WMI" is intentionally avoided so that HID_ASUS users who have ASUS_WMI=n will not quietly lose their HID_ASUS driver on a kernel upgrade. Signed-off-by: Daniel Drake <drake@endlessm.com> Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
-