On Tue, Jan 9, 2018 at 3:20 AM, Daniel Drake <drake@xxxxxxxxxxxx> wrote:
> 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).
> config HID_ASUS
> tristate "Asus"
> depends on LEDS_CLASS
> + depends on ACPI_WMI
No, for sure.
Imagine someone who on possession of laptop where it's not needed
having old kernel configuration.
Building new kernel with old configuration will bring a regression.
Selection is also not a solution since we don't need all crap in
kernel because of some particular case.
So, NO.
> --- a/drivers/hid/hid-asus.c
> +++ b/drivers/hid/hid-asus.c
> +#define ASUS_WMI_MGMT_GUID "97845ED0-4E6D-11DE-8A39-0800200C9A66"
> +#define ASUS_WMI_METHODID_DSTS2 0x53545344 /* Device STatuS #2*/
> +#define ASUS_WMI_DEVID_KBD_BACKLIGHT 0x00050021
> +#define ASUS_WMI_UNSUPPORTED_METHOD 0xFFFFFFFE
> +#define ASUS_WMI_DSTS_PRESENCE_BIT 0x00010000
> +/* WMI-based keyboard backlight LED control (via asus-wmi driver) takes
> + * precedence. We only activate HID-based backlight control when the
> + * WMI control is not available.
> + */
> +static bool asus_kbd_wmi_led_control_present(struct hid_device *hdev)
> +{
> +}
I have feelings that the code above should be located somewhere under
drivers/platform/x86.
--
With Best Regards,
Andy Shevchenko
