On Wed, 22 Mar 2017, Colenbrander, Roelof wrote: > On a sidenote I'm starting to wonder how we should deal with multiple > devices in this driver in the future. The driver is starting to support > many different kinds of devices (mostly game controllers) and a few > other devices (vaio). They are all HID, but behave very differently and > some share concepts e.g. LEDs, touchpads or motion sensors. It is > starting to become more and more painful to handle many very different > devices in kind of one driver even though they are not really related. > There are layers of abstractions to dispatch to the right 'subdriver' > e.g. in sony_raw_event and many other places. There is a shared driver > structure (sony_sc), but some portions like function pointers or work > structs only apply to some devices. If this is going to become a real problem, the most straightforward solution to me would be to actually separate the driver into completely different 'sub-drivers', but have them link at the end of the day into one 'hid-sony', mostly for compatibility reasons (but also to keep following the general pattern we have). > Also thinking a bit in how to use this driver in actual products. We may > only want certain pieces (e.g. game controller support) and not support > for the other devices either because we already have another driver for > it or we don't want to include this code as we don't intend to support > it (and verify behaviour) on said product. It is in nobody's interest to > have multiple code bases. You can always blacklist/unbind the device if you're going to ship some out-of-tree driver, but I don't think we should really optimize the in-kernel code for that. Thanks, -- Jiri Kosina SUSE Labs -- 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
