Re: BUG: hid-multitouch causes 10 second delay and error

["Henrik Rydberg" <rydberg@euromail.se>]

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