On Thu, Nov 10, 2022 at 4:29 AM Andreas Bergmeier <abergmeier@xxxxxxx> wrote: > > On Wed, 9 Nov 2022 at 21:27, Andreas Bergmeier <abergmeier@xxxxxxx> wrote: > > > > Finally I have an environment where I can test my kernel code. > > > > On Mon, 31 Oct 2022 at 10:29, Benjamin Tissoires > > <benjamin.tissoires@xxxxxxxxxx> wrote: > > > For identifying the GLOW device you should be adding an id in the > > > table of hid-logitech-hidpp, with a driver data that tells the driver > > > to look for 0x1990. > > > > > > > > > > > > - you need to add a hook in connect_event to register the led class > > > > > device that will hook on to the actual LED of the device > > Sadly my tests did not go very far. The code fails already when > > calling the `probe` callback (`hidpp_probe`). > > When it calls into `hidpp_root_get_protocol_version` it seems to > > receive `HIDPP_ERROR_RESOURCE_ERROR`. > > Which then leads to an error message: Device not connected > > Upon looking at `HIDPP_ERROR_RESOURCE_ERROR` (9) there is no > > documentation what it means in code. > > From a look into the docs it says that 9 is UNSUPPORTED error for 2.0 > > devices. Thus I am wondering how the code knows > > that it is a problem with connectivity. >From the top of my memory, this was told to us that this is the way we detect if the device was connected or not in the unifying case. Though in your case, it's a USB device, so there is no such thing as "not connected"... > > Couldn't it also mean that the > > device is not supporting getting the protocol version? Probably. What happens if you comment out that protocol version request and force connected to be true? > > And why is protocol version only enforced for non unifying devices? Unifying devices are wireless, and when we probe the device, we are actually talking to the receiver. So The device might not be connected, and we should wait for the device to be present and not reject it. On non unifying devices, if the device is not connected, this likely means that the device is not behaving properly, and so we can not handle it in the driver. In your case though, it would be interesting to know if we should bypass that verification. > Also, looking into `supported_reports` turned out to be 2 (very long). Oops, you mistook the bit definition with the value: #define HIDPP_REPORT_SHORT_SUPPORTED BIT(0) -> value of 1 #define HIDPP_REPORT_LONG_SUPPORTED BIT(1) -> value of 2 #define HIDPP_REPORT_VERY_LONG_SUPPORTED BIT(2) -> value of 4 Which is coherent with what your device exports: only one report ID of value 0x11, HIDPP_REPORT_LONG. > Inside of `hidpp_root_get_protocol_version` it does upgrade SHORT to > LONG if the former is not supported. Yep, this should be good for your device. > On a whim I then added upgrade of LONG to VERY LONG if the former is > not supported. Sadly, the results stayed the same. > And this is expected because you don't have VERY_LONG support on your device. Cheers, Benjamin
