On Wed, Oct 26, 2022 at 9:50 PM Andreas Bergmeier <abergmeier@xxxxxxx> wrote: > > On Tue, 25 Oct 2022 at 09:46, Benjamin Tissoires > <benjamin.tissoires@xxxxxxxxxx> wrote: > > Depending on how the device presents itself, we might have to use > > hid-logitech-hidpp, not hid-lg FWIW. > Ah, indeed it seems to be a hidpp device. \o/ > I so far wrote code to interact with the device using hidraw and > hiddev. What are the implications of a hidpp device? It's just Logitech's common HID protocol. The advantage is that if Logitech reuses the feature on a different hardware, we won't have to implement anything new in the kernel. > How is hidpp exposed to userspace? It's not exposed to userspace. It's all kernel internal, or used by userspace applications like solaar[0] through hidraw > From a search it seems like there are very few userspace programs that > handle hidpp on Linux. IIRC you have solaar, and fwupd. > > > And to answer the question "how to map the device to input > > "primitives".", it all depends on how the device exports itself. > All information that I have gathered so far is on > https://github.com/abergmeier/litra_glow_linux. great thanks. > > The output of `hidpp-list-features /dev/hidraw0` is: > ``` > Logi Litra Glow (046d:c900) is a HID++ 4.2 device > Feature 0x01: [0x0001] Feature set > Feature 0x02: [0x0003] Device FW version > Feature 0x03: [0x0005] Device name > Feature 0x04: [0x1990] ? > Feature 0x05: [0x1eb0] ? (hidden) > Feature 0x06: [0x00c2] DFUcontrol 3 (hidden) > ``` > Is it possible that Feature 0x04 is the protocol for sending changes > to the device? AFAICT, given the dumps on your github project, this is very much the case: Events and commands are starting with "11 ff 04" meaning: - 11: report id (HID++ protocol) - ff: device index (0xff in case of a USB connected device, but could be different when used over a wireless receiver.) - 04: feature index 04, which is defined as 0x1990 in the internal Logitech specification. > All the payload that is sent to the device has a 0x04 directly in > front of the instructions. > As an example, for turning the light on you send raw bytes: [0x11, > 0xff, 0x04, 0x10, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, > 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00] > 0x10 seems to indicate setting the on state. You seem to be correct :) This 4rth byte is the command index. 0x00 is sent by the device on events, and then the command is supposed to be the command index (0x10, 0x20, 0x30, etc...) with the program index. So to not confuse other userspace programs, you should use something like 0x11 or 0x12 (0x01 is used by the kernel FWIW) > > > > To recap there are 5 hardware buttons and 3 states: > > > - State: "Color temperature in range [u, x]" Button: up > > > - State: "Color temperature in range [u, x]" Button: down > > > - State/Button On/Off > > > - State "Brightness in range [y, z]" Button: up > > > - State "Brightness in range [y, z]" Button: down > > > > FWIW, you should be able to use hid-recorder[0] (as root) to record > > traces of the events, and to parse them on the fly. Also, if you > > provide us the output, we can replay the traces locally as if we > > virtually plugged in the device. > > See the GitHub repo - there are already initial recordings. > > > FWIW, if the first byte you have to send to control the LED is 0x10, > > 0x11 or 0x12 then this is a HID++ device that needs to go in > > hid-logitech-hidpp and a lot of groundwork is already done in the > > kernel for it. > I am trying to get up to speed with hidpp - but I am not there yet. > Do you have any hints on what code to read specifically since > logitech-hidpp is a bit long... You have some public documentation at [1]. But from where you are now, you should probably be able to implement the basic on/off feature by looking at the function 0x1000 in the hid-logitech-hidpp code: - you need define a few macros for your functionality (the class, the commands, the events) - 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 - you need to also add a hook in hidpp_raw_hidpp_event for when a button is emitted by the device. Then you can either directly control the LED from the kernel, or let userspace deal with it (and probably have some form of hybrid solution where the kernel directly controls the LED, but also notifies user space through regular buttons, but you can allow control of the LED through the LED class). Note that the kernel doesn't do a full enumeration of the device features, so you need to register the device as a new class, in the supported device ids. > > Thanks for the feedback so far > No worries. Cheers, Benjamin [0] https://pwr-solaar.github.io/Solaar [1] https://github.com/pwr-Solaar/Solaar/blob/master/docs/hidpp-documentation.txt
