Collaboration

[hanetzer]

As requested, opening a separate issue. Indeed, I know that the g105 is not an hid++ device, I just meant we could pool all the data regarding the g line of devices. I believe the g602 to be hid++, however. I've not yet pushed its data to the repo, still collecting stuff, but it responds to your tools.

[cvuchener]

Indeed, I know that the g105 is not an hid++ device, I just meant we could pool all the data regarding the g line of devices.

No problem with that, but I won't be able to contribute to this part. Would you prefer to push things here or to make a new repo with less ties to the G500? (I was thinking about it, since it grew beyond that)

I believe the g602 to be hid++, however. I've not yet pushed its data to the repo, still collecting stuff, but it responds to your tools.

Which tool exactly? I don't think they would work with HID++ 2.0 devices, it must be HID++ 1.0 despite being the same generation as the G502.

Is it using the Unifying Receiver? I am not sure my tools work with it. But if I understand the DJ driver correctly, you may interact with unifying devices like they were wired.

[hanetzer]

Which tool exactly?

send-raw-request, I used the for loop mentioned in the readme to scan for values to be read. Its not a unifying device, and it responds to hid++ commands using pyusb (my primary testing tool atm)

Would you prefer to push things here or to make a new repo with less ties to the G500

I did setup an organization in hopes of attracting collaborators, @GSeriesDev, and definitely want to document as much as possible on these devices. If I can figure out a way to do the stuff I'm doing in pyusb without it (since using it apparently removes the ability to use the device in question) I'm going to be writing a daemon and configuration software similar to the LGS.

[cvuchener]

send-raw-request, I used the for loop mentioned in the readme to scan for values to be read. Its not a unifying device, and it responds to hid++ commands using pyusb (my primary testing tool atm)

send-raw-request will work with any HID device. It simply writes stdin in the hidraw file and wait for something to read. Nothing specific.

I added logitech-raw-command for low-level HID++ 1.0 commands. I should update the README. Try ./scan-read-command.sh /dev/hidrawX (as root if you don't have read/write acces to the hidraw node)

If I can figure out a way to do the stuff I'm doing in pyusb without it (since using it apparently removes the ability to use the device in question) I'm going to be writing a daemon and configuration software similar to the LGS.

I don't know Python very well. If I remember correctly Pyusb is libusb bindings for Python. You may not need that. Use the hidraw interface, you just need to open the /dev/hidrawX file and use the equivalent of read(2), write(2), ioctl(2) in Python.

[hanetzer]

Ah, I didn't mean particularly to use pyusb for the final product, I'm just using it to do testing and prototyping. But I'm fairly certain this is a hid++, as the usbmon logs show what look like short and long hid++ packets:
Long request

s 21 09 0211 0001 0014 20 = 11010e3f 02030000 05000004 00001a00 0000001e

Short request

s 21 09 0210 0001 0007 7 = 10ff8000 000100

In fact pyusb is probably not what I should use at all for the final product, because once you claim the device in it you basically lose the ability to do anything of real import with it.

[cvuchener]

s 21 09 0211 0001 0014 20 = 11010e3f 02030000 05000004 00001a00 0000001e

Yes, this is HID++. I can't say which version exactly but it is from an unifying device (the device index is not 0).

s 21 09 0210 0001 0007 7 = 10ff8000 000100

This one enables wireless notifications on an unifying receiver. There is some Unifying receiver and devices documentation there that you may want to check.

[hanetzer]

I don't know that it is a unifying device per se; it doesn't seem to be able to be added to an existing reciever I have using solaar-git, but yes, it is wireless. On that note I just realized I emphasized the wrong bits of the logs, lol. I've managed to use pyusb to, for example, remap the buttons in the same way that LGS does, but like you said, I should probably be using something else.

[hanetzer]

s 21 09 0211 0001 0014 20 = 11010e3f 02030000 05000004 00001a00 0000001e

the above is the command used to set middle mouse click to be treated as mouse button 3 (eg, set it back to what it is)

s 21 09 0211 0001 0014 20 = 11010e3f 02000004 05000004 00001a00 0000001e

sets the middle mouse button to be treated as 'a'

[cvuchener]

It must be HID++ 2.0. There is a document about it in the google drive linked above. I don't know anything more than what is in this document. Benjamin Tissoires might know more about it. There is also some code in the kernel using HID++ 2.0 (look at drivers/hid/hid-logitech-hidpp.c). And I forgot libratbag has HID++ 2.0 code too.

[hanetzer]

Yeah, I've been checking out pretty much all the info you've been linking, lol. While I realize that not all the logitech devices will be hid++ they are all grouped together thematically, which is why I'm looking for additional conspirators in getting them all well supported in linux.

[hanetzer]

On that note, is there some way I can contact you in real time? You seem to be a lot more knowledgeable about some of this stuff than I, and I'd like to pick your brain a bit

[cvuchener]

Email/Gtalk (clement dot vuchener at gmail com) or XMPP if you prefer (ask the jid by email).

[hanetzer]

never used xmpp personally, any suggestions as to a client?

[cvuchener]

I have used pidgin and empathy. You would need to find a server to create an account if you never used it. It may simpler to find an irc chat room.

[hanetzer]

True enough. I'm on a few, freenode/##linux, freenode/#lg4l (pretty much dead atm, but they previously did kernel modules for these devices). Do you have any preference? In any case, I just setup jabber, sent you that email