Re: [PATCH 1/3] HID: Add HID_CLAIMED_OTHER for non-generic drivers

On Mon, Jul 16, 2012 at 09:08:47PM +0200, David Herrmann wrote:

Hi Henrik

On Mon, Jul 16, 2012 at 8:45 PM, Henrik Rydberg [off-list ref] wrote:

quoted

Hi David,

Perhaps one should make hid-core warn instead of bailing out instead?
Something may need to be done to make sure everything works smoothly,
but really, why would hid-core mind keeping a device on the bus with a
non-standard io driver?

No, I think bailing out is the correct thing to do. If we emit a
warning but leave the device on the bus, the device will have no
driver loaded and idling in background. Hence, dropping the device is
the best solution for 99% of the devices.

If the driver that picks up the device (wiimote for instance) decides
it does not want to use any of the io drivers (HID_CONNECT*) by
calling hid_hw_start(hdev, 0), in what way is that different from
calling it with, say, hid_hw_start(hdev, HID_CONNECT_TO_OTHER)?  (The
latter would be an equivalent (but cleaner) way of setting your
HID_CLAIMED_OTHER flag).

To catch possible mistakes, one could check for the presence of
raw_event() instead, for instance.

What I am getting at is that we really do not need to create any more
backdoors into the hid core - on the contrary, we can most likely
easily remove some of them instead.

However, devices that explicitly do not require the generic drivers
(like picolcd and wiimote) should be able to stay on the bus. We could
of course put them out of the HID subsystem as they have very little
in common with the other HID drivers, but that wouldn't make the
situation any better. It would mean writing transport-level drivers
for picolcd and wiimote which are exactly the same as USBHID and HIDP.
Hence, I think allowing non-standard drivers on the BUS is ok as long
as they explicitly request it.

Yes, the question is only what that request looks like. The simpler
the better, don't you agree?

Thanks,
Henrik