On Thu, Jun 8, 2017 at 12:49 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote:
>
> So maybe CONFIG_HID_ASUS should default to Y? I'll leave it up to Hans
> to straighten this out.
No, I think the main problem is that the hid_have_special_driver[]
array change is garbage.
It adds the ASUS ID, regardless of whether the special driver exists or not.
We *really* shouldn't do that. We had a very similar regression wrt
the "improved" synaptics RMI handling in commit 279967a65b32.
If you didn't have HID_RMI enabled at all, that commit made the
regular HID driver not take care of the device, and without an RMI
driver there was nothing else that took care of it either.
So when you add things like "don't react to this device", you damn
well should make sure that something else *does* react to the device
instead.
So those ASUSTEK entries that get disabled in hid-core.c should be
protected by something like
#if IS_ENABLED(CONFIG_HID_ASUS)
...
#endif
exactly so that the core HID subsystem doesn't ignore them when
nothing else picks up the slack.
I note that *some* cases do do that. Too few, apparently.
PLEASE STOP THIS MINDLESS "DISABLE GENERIC DEVICE DISCOVERY" CRAP!
It's only ok to disable a generic device if you actually have a real
working fallback that is actually enabled!
So that commit 76dd1fbebbae ("HID: asus: Add support for T100
keyboard") is actively buggy, because it incorrectly assumes a
particular config.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
