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 <rydberg@xxxxxxxxxxx> wrote: > > 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 -- 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
