On Wed, Jul 15, 2020 at 08:59:52AM +0200, Marius Zachmann wrote: > On 15.07.20 at 04:36:22 CEST, Guenter Roeck wrote > > On Tue, Jul 14, 2020 at 12:52:30PM +0200, Marius Zachmann wrote: > > > I found a project which uses hidraw to communicate with the device. > > > Because I do not want to break any existing userspace code, I > > > changed this to a hid driver, so hidraw can still be used. > > > Do I need to include the hid maintainers for the undo in hid-quirks? > > > > > That changelog needs some improvements. It should state what change > > was made, and why, but not include any questions or personal statements > > such as "I found ...". > > > > You never really explained why you had changed the driver from hid to > > usb. Maybe you can explain that decision now ? > > > > Thanks, > > Guenter > > > > This device does not use numbered hid input reports. As far as I know > it is not possible to determine from which command a response was > requested. This being a usb driver would not allow any other driver > to send data to the device. > In the first (hid) version I did not use hid reports and got > the usb_device directly from the hid_device which is not intended. > In this version, requests are made via hid_hw_output_report, waited > for and received via raw_event. > If one uses hidraw and this driver at the same time, it still could > be possible to get switched responses but there is nothing I can > do about it, as far as I know. This is only about giving the > possibility to unload the driver and using a userspace driver > if one chooses. > What a mess. Can you add some of this as comment to the top of the driver to explain the reasoning ? Thanks, Guenter
