Hi,
First of all lets add the HID subsys maintainers to the To list (done).
On 08-06-17 22:17, Linus Torvalds wrote:
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.
Right, so this is not really a problem with this specific patch,
but with how the hid_have_special_driver array works in general
currently it has very few #if IS_ENABLED(CONFIG_FOO) guards
around all the devices it blacklists the generic HID driver for.
I think this is on purpose to stop things becoming one big
#ifdef party, but as you rightfully say this means that people
may end up with not having a driver at all.
Some device-specific drivers have this in their Kconfig:
default !EXPERT
Which the HID_ASUS entry lacks.
Jiri, Benjamin, how do you want to solve this ?
Regards,
Hans
--
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
