Logitech have started shipping Unified devices, which means you can have up to 6 wireless devices connected to one little USB dongle thing. They’ve also invented a protocol called HID++, and it’s already in version 2. It’s basically a way to issue low level commands in a structured way to HID devices. It’s actually tons better than Bluetooth as it’s got a lower latency and also uses up less power on the sender and receiver.
I’m fairly familiar with low level protocols like this, as this is just the kind of thing the ColorHug is doing. Write a request packet, and get a response packet a few ms later. Julien Danjou had already added some support for the Unifying devices to UPower, albeit just for the K750 keyboard. Armed with a draft HID++v2 specification document and a newly purchased T620 I figured I could support most devices very easily by implementing the Battery Unified Level Status part of the specification.
Tuesday evening I started reading the specification sheet. By Wednesday lunchtime I had some test code in UPower that should have worked for all devices. But it didn’t. The percentage value was always 4%.
So, back to my trusty Windows XP VM. I loaded the Logitech client software, and that reported the percentage value correctly. I then dug out a hardware USB protocol analyser and made a trace of what the Windows client software was doing. Bingo. The BatteryLevelStatus ASE/SWID nibbles were swapped in the request packet. Either the documentation is wrong (unlikely, given the other ASE’s are the right way around) or the Logitech firmware engineer implementing the specification got them the wrong way around. I can’t blame them, the specification doesn’t explicitly specify an order, although you could easily work out what is likely as the byte order is specified as big endian.
Hi,
I have a K340 logitech keyboard & M505 mouse. Will I be able to use this new code to monitor the battery level from my laptop?
Any idea when this change will be in fedora releases? I guess it will have to wait for Fedora 19?
Is this/Will this be fully integrated in GNOME (and end up in the same indicator showing my laptop battery?)
Thanks for the support,
Nathan
Testing would be very appreciated. There’s also no reason this couldn’t be pushed into F17 or F18. And yes, I now get a mouse indication in the gnome-shel drop-down. :)
Any sugestions how to test this out (relatively easily).
I am not afraid on running preproduction software (proving that I am running Fedora 18 for some months now).
I am even willing to try compiling the latest and greatest UPower, but the problem I have is that it is a system deamon which are most of the time slightly more complicated to install than just ‘./configure && make && sudo make install’.
‘
There’s a sprm here: http://people.freedesktop.org/~hughsient/fedora/17/SRPMS/
Just download it, do “rpmbuild –rebuild foo.rpm” and then install the result. Then reboot :)
Glad to see the Beagle is of use :)
Sweet… I have one of these mice, which I like very much. The big missing feature was that I had to use a windows computer to get them all paired up to the same dongle.
Besides the cool factor of being able to see my device battery life in gnome, do you have any ideas on how to use the data into a useful desktop feature? This could turn into a fun hack.
Note that my mouse has on an onboard led battery indicator.
Thanks,
James
FWIW: Since I last paired my mouse things have changed. This now exists:
https://wiki.archlinux.org/index.php/Logitech_Unifying_Receiver
and worked perfectly for me.
Cheers
I have installed the SRPM on fedora 18, and rebooted.
An additional “battery” (Accu) is added, but it is marked as Unknown and always at 0%.
More awesomeness. Thank you.
One question – do you know if upower –monitor displays all devices that were detected using your patch? I have M325 mouse that is displayed, however my K360 keyboard is not.
I could upload some logs if that would help finding a reason why it’s not detected.
The log from upowerd –verbose and lsusb would be useful indeed, thanks.
http://pastebin.com/rPxeScf9 – upowerd log, previous instance was killed, then new one was started with –verbose, after few seconds the unifying receiver was unplugged and plugged again.
http://pastebin.com/9LKZ7Lfc – lsusb –verbose log – part regarding unifying receiver.
And running upowerd once again resulted in detecting only keyboard – http://pastebin.com/PpA3w2zP
I see what’s happening. We’re trying to use /dev/hidraw0 for both devices. I’ll have a think how to fix this properly.
Tried running upowerd today – seems that both devices are sometimes read, however it seems that data is wrong (both devices having the same levels etc).
http://pastebin.com/PqxDBTR7