Hi Benjamin,
> > Everyone with an umatched hid device, even completely unrelated to
> > touch, will be surprised to find the hid-multitouch module loaded.
> >
>
> Well, this is a problem that can not be easily solved: IIRC, we can
> not force the load of an external driver from within the kernel.
> The best solution would be to merge hid-input and hid-multitouch.
Yes, or actually adding a dynamic mechanism. With hid, it would
clearly be beneficial to be able to load modules based on the result
of the report parsing.
> Indeed both systems aim at handling generic devices.However, I'd
> rather not doing it now as we are not as "good" as the Win 7 driver
> (i.e. there are some fallback modes that allow every devices to be
> handled even if they don't send clean hid reports).
What's wrong with having a generic handling in addition to the
specific device list in hid-multitouch?
> And, even if hid-multitouch is loaded, only 2 or 3 lines of codes will
> be executed to reject the driver in mt_probe, which won't be very time
> consuming for end user.
The time to load the module will hit _every_ user, which is worse than
having the code merged with hid-input. Not to mention the annoyance,
it is simply unacceptable.
> For your second point:
> >> > 2. It did not work after removing the tested device from the hid core
> >> > whitelist; the device quirk seemed to get lost in the process.
>
> Didn't you forget to remove the following line?
>
> --- a/drivers/hid/hid-core.c
> +++ b/drivers/hid/hid-core.c
> @@ -1230,7 +1230,6 @@ int hid_connect(struct hid_device *hdev,
> unsigned int connect_mask)
> hdev->claimed |= HID_CLAIMED_INPUT;
> if (hdev->quirks & HID_QUIRK_MULTITOUCH) {
> /* this device should be handled by hid-multitouch, skip it */
> - hdev->quirks &= ~HID_QUIRK_MULTITOUCH;
> return -ENODEV;
> }
>
>
Gah, how did that end up there? Yes, I missed that line in my testing,
which explains it (although I won't test again right now).
> If not, that's maybe that you encountered the only case that is not
> correctly handled:
> if you register hid-multitouch before hid, then it will be the first
> driver tested, and hid-input won't set the quirk correctly.
> BTW, it's not a big deal, because if systems do have this behavior, we
> can easily put the device from the user space by using
> /sys/module/hid_multitouch/drivers/hid\:hid-multitouch/new_id
This is also hackish. I _do_ understand the benefits of what we are
aiming at here, but we are piling up crap in the kernel.
To summarize, the idea looked good at first glance, but I think it
creates unacceptable dependencies between modules.
To try again later on, at the very least one should move the essence
of hid-multitouch to something like hid-input-mt, and have hid-input
either include it, select it or depend dynamically on it, in a
try_module_get fashion. The hid_multitouch would then simply contain
the device white list, leaving the general case to hid-input.
Henrik
--
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
