A year ago, I bought a
Logitech Wireless Solar Keyboard
K750. I'm
particularly picky on keyboards, but this one is good. It has an incredible
useful feature: while being wireless, it has no need for disposable or
rechargeable batteries, it uses solar power!
My problem is that there's obviously no way to know the battery status from
Linux, the provided application only working on Windows.
And one dark night, while fragging on QuakeLive, my keyboard stopped
working: it had no battery left. This activity being quite energy consuming,
it emptied the whole battery.
Someone should write code to get the battery status and light meter from
Linux: challenge accepted!
How the keyboard works
This keyboard, like many of the new wireless devices from Logitech, uses the
Unifying interface. It's an USB receiver that can be attached up to 6
differents devices (mouse, keyboards ). On old Linux kernel, the
Unifying
receiver is recognized as only one keyboard and/or one mouse device.
Recently, a driver called
hid-logitech-dj has been added to the Linux
kernel. With this driver, each device attached to the receiver is recognized
as one different device.
What the Logitech application does
The Logitech application under Windows works that way: you launch it, and it
displays the battery charge level. On the keyboard, there's a special
"light" button (up right). When pressed, a LED will light up on the
keyboard: green if the keyboard is receiving enough light and is charging,
red if the keyboard does not receive enough light and is therefore
discharging. Pushing this same button while the application is running will
makes the light meter activated: the application will tell you how much
lux your keyboard is receiving.
Let's reverse engineer this
As far as I know, there's nothing in the USB HID protocol that handles this
kind of functionality (battery status, light meter ) in a standard way. So
the first task to accomplish is, unfortunately, to reverse engineer the
program.
I discovered a bit too late that
Drew Fisher did a good presentation on USB
reverse engineering at 28c3.
You might want to take a look at it if you want to reverse engineer on USB.
I did not need it, but I learned a few things.
Anyway, my plan was the following: run the Logitech application inside a
virtual machine running Windows, give it direct access to the USB keyboard,
and sniff what happens on the USB wire.
To achieve that, you need a virtual machine emulator that can do USB
pass-through. Both
KVM and
VirtualBox can do that, but VirtualBox works
much better with USB and allow hot(un)plugging of devices, so I used it.
To sniff what happens on the USB, you need to load the
usbmon Linux kernel
module. Simply doing
modprobe usbmon will work. You can then
use
Wireshark which know how to use
usbmon
devices and understand the USB protocol.
USB stuff you need to know
You don't need to know much about USB to understand what I'll write about
below, but for the sake of comprehensibility I'll write a couple of things
here before jumping in.
To communicate with an USB device, we communicate with one of its
endpoints. Endpoints are regrouped into an
interface. Interfaces are
regrouped into a
configuration. A device might contains one or several
configurations.
There's also several types of packets in the USB wire protocol, and at least
two of them interest us there, they are:
- Interrupt packets, a packet send spontaneously;
- Controls packets, used for command and status operations.
All of this and more is well (and better) explained in the
chapter
13 of
Linux Device Drivers, Third
Edition.
Sniffed data
Once everything was set-up, I ran my beloved Wireshark. There's a
an
URB of type
interrupt sent each
time you press any key with some data in it. Therefore I advise you to plug
another keyboard (or use the laptop keyboard if you're doing this on a
laptop), otherwise you'll get crazy trying to sniff the keyboard you're
typing on.
At this point, just launching the application does a bunch of USB traffic.
Pressing the "light" button on the keyboard makes even more USB packets
coming in and out. Here's the interesting packets that I noticed once I
excluded the noise:
- When pressing the "light" button, an URB of type interrupt is sent by the
keyboard to the computer;
- An URB control packet is sent by the computer to the keyboard in
response;
- Regularly URB interrupt packets are sent just after.
With all this, the next step was clear: understand the packets and reproduce
that exchange under Linux.
What the packets mean
The "go for the light meter" packet
The packet sent from the computer to the keyboard is the following.
<figure>
Frame 17: 71 bytes on wire (568 bits), 71 bytes captured (568 bits)
Frame Length: 71 bytes (568 bits)
Capture Length: 71 bytes (568 bits)
USB URB
URB id: 0xffff880161997240
URB type: URB_SUBMIT ('S')
URB transfer type: URB_CONTROL (0x02)
Endpoint: 0x00, Direction: OUT
0... .... = Direction: OUT (0)
.000 0000 = Endpoint value: 0
Device: 6
URB bus id: 1
Device setup request: relevant (0)
Data: present (0)
URB sec: 1340124450
URB usec: 495643
URB status: Operation now in progress (-EINPROGRESS) (-115)
URB length [bytes]: 7
Data length [bytes]: 7
[Response in: 18]
[bInterfaceClass: HID (0x03)]
URB setup
bmRequestType: 0x21
0... .... = Direction: Host-to-device
.01. .... = Type: Class (0x01)
...0 0001 = Recipient: Interface (0x01)
bRequest: SET_REPORT (0x09)
wValue: 0x0210
ReportID: 16
ReportType: Output (2)
wIndex: 2
wLength: 7
0000 40 72 99 61 01 88 ff ff 53 02 00 06 01 00 00 00 @r.a....S.......
0010 22 ad e0 4f 00 00 00 00 1b 90 07 00 8d ff ff ff "..O............
0020 07 00 00 00 07 00 00 00 21 09 10 02 02 00 07 00 ........!.......
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0040 10 01 09 03 78 01 00 ....x..
</figure>
What's here interesting is the last part representing the data.
wLength
says that the length of the data is 7 bytes, so let's take a look at those 7
bytes:
10 01 09 03 78 01 00.
Well, actually, you can't decode them like that, unless you're a freak or a
Logitech engineer. And I have actually no idea what they mean. But sending
this to the keyboard will trigger an interesting thing: the keyboard will
start sending URB interrupt with some data without you pressing any more key.
The "light meter and battery values" packet
This is most interesting packet. This is the one sent by the keyboard to the
host and that contains the data we want to retrieve.
<figure>
Frame 1467: 84 bytes on wire (672 bits), 84 bytes captured (672 bits)
Frame Length: 84 bytes (672 bits)
Capture Length: 84 bytes (672 bits)
USB URB
URB id: 0xffff88010c43c380
URB type: URB_COMPLETE ('C')
URB transfer type: URB_INTERRUPT (0x01)
Endpoint: 0x83, Direction: IN
1... .... = Direction: IN (1)
.000 0011 = Endpoint value: 3
Device: 2
URB bus id: 6
Device setup request: not relevant ('-')
Data: present (0)
URB sec: 1334953309
URB usec: 728740
URB status: Success (0)
URB length [bytes]: 20
Data length [bytes]: 20
[Request in: 1466]
[Time from request: 0.992374000 seconds]
[bInterfaceClass: Unknown (0xffff)]
Leftover Capture Data: 1102091039000c061d474f4f4400000000000000
0000 80 c3 43 0c 01 88 ff ff 43 01 83 02 06 00 2d 00 ..C.....C.....-.
0010 5d c5 91 4f 00 00 00 00 a4 1e 0b 00 00 00 00 00 ]..O............
0020 14 00 00 00 14 00 00 00 00 00 00 00 00 00 00 00 ................
0030 02 00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 ................
0040 11 02 09 10 39 00 0c 06 1d 47 4f 4f 44 00 00 00 ....9....GOOD...
0050 00 00 00 00 ....
</figure>
This packets come in regularly (1 per second) on the wire for some time once
you sent the "go for the light meter" packet. At one point they are emitted
less often and do not contain the value for the light meter anymore,
suggesting that the control packet sent earlier triggers the activation of
the light meter for a defined period.
Now you probably wonder where the data are in this. They're in the 20 bytes
leftover in the capture data part, indicated by Wireshark, at the end of the
packet:
11 02 09 10 39 00 0c 06 1d 47 4f 4f 44 00 00 00 00 00 00 00.
Fortunately, it was easy to decode. Knowing we're looking for 2 values
(battery charge and light meter), we just need to observe and compare the
packet emitted on the wire with the values displayed by the Logitech Solar
App.
To achieve this, I looked both at the
Logitech Solar App and
Wireshark
while bringing more and more light near the keyboard, increasing the lux
value received by the meter on the Solar App, and saw that the fields
represented in blue (see below) where changing in Wireshark. Since 2 bytes
were changing, I guessed that it was coded on 16 bits, and therefore it was
easy to correlate the value with the Solar App.
<figure>
[ ....9....GOOD....... ]
11 02 09 10 39 00 0c 06 1d 47 4f 4f 44 00 00 00 00 00 00 00
4 bytes - 1 byte for battery charge - 2 bytes for light meter - 2 bytes - 4 bytes for GOOD - 7 bytes
</figure>
In this example, the battery has a charge of
0x39 = 57 % and
the light meter receives
0x0c = 12 lux of light. It's basically
dark, and that makes sense: it was night and the light was off in my office,
the only light being the one coming from my screen.
I've no idea what the
GOOD part of the packet is about, but
it's present in every packet and it's actually very handy to recognize such
a packet. Therefore I'm considering this as some sort of useful mark for
now.
For the other bytes, they were always the same (
0x11 0x2 0x9
0x10 at the beginning, 7 times
0x00 at the end). The 2
bytes between the light meter and GOOD probably mean something, but I've no
idea what for now.
Building our solar app
Now we've enough information to build our own very basic solar application.
We know how to triggers the light meter, and we know how to decode the
packets.
We're going to write a small application using
libusb. Here's a quick example. It's not perfect
and does not check for error codes, be careful.
<figure>
/* Written by Julien Danjou <julien> in 2012 */
#include <linux/hid.h>
#include <libusb.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int main(void)
libusb_context *ctx;
libusb_init(&ctx);
libusb_set_debug(ctx, 3);
/* Look at the keyboard based on vendor and device id */
libusb_device_handle *device_handle = libusb_open_device_with_vid_pid(ctx, 0x046d, 0xc52b);
fprintf(stderr, "Found keyboard 0x%p\n", device_handle);
libusb_device *device = libusb_get_device(device_handle);
struct libusb_device_descriptor desc;
libusb_get_device_descriptor(device, &desc);
for(uint8_t config_index = 0; config_index < desc.bNumConfigurations; config_index++)
struct libusb_config_descriptor *config;
libusb_get_config_descriptor(device, config_index, &config);
/* We know we want interface 2 */
int iface_index = 2;
const struct libusb_interface *iface = &config->interface[iface_index];
for (int altsetting_index = 0; altsetting_index < iface->num_altsetting; altsetting_index++)
const struct libusb_interface_descriptor *iface_desc = &iface->altsetting[al>tsetting_index];
if (iface_desc->bInterfaceClass == LIBUSB_CLASS_HID)
libusb_detach_kernel_driver(device_handle, iface_index);
libusb_claim_interface(device_handle, iface_index);
unsigned char ret[65535];
unsigned char payload[] = "\x10\x02\x09\x03\x78\x01\x00";
if(libusb_control_transfer(device_handle,
LIBUSB_REQUEST_TYPE_CLASS LIBUSB_RECIPIENT_INTERFACE,
HID_REQ_SET_REPORT,
0x0210, iface_index, payload, sizeof(payload) - 1, 10000))
int actual_length = 0;
while(actual_length != 20 strncmp((const char *) &ret[9], "GOOD", 4))
libusb_interrupt_transfer(device_handle,
iface_desc->endpoint[0].bEndpointAddress,
ret, sizeof(ret), &actual_length, 100000);
uint16_t lux = ret[5] << 8 ret[6];
fprintf(stderr, "Charge: %d %%\nLight: %d lux\n", ret[4], lux);
libusb_release_interface(device_handle, iface_index);
libusb_attach_kernel_driver(device_handle, iface_index);
libusb_close(device_handle);
libusb_exit(ctx);
</figure>
What the program is doing is the following:
- Request for the Unifying Receiver device based on vendor and product ID
- Get the HID interface
- Detach the HID interface from the kernel driver
- Claim the interface
- Send a control packets, were parameters are defined using the same data we captured earlier
- Read interrupt packets coming in until we receive one we recognize (length
20 containing the "GOOD" string)
- Decode the content (battery charge & light meter)
- Release the interface
- Reattach the kernel driver to the interface
This gives the following:
Found keyboard 0x0x24ec8e0
Charge: 64 %
Light: 21 lux
Challenge accomplished!
To be continued
Unfortunately, this approach has at least one major drawback. We have to
disconnect the
Logitech Unifying Receiver from the kernel. That means that
while we're waiting for the packet, we're dropping packets corresponding to
other events from every connected device (key presses, pointer motions ).
In order to solve that, I sent a request for help on the
linux-input mailing
list. That way, I learned that Logitech is actually using the HID++ protocol
to communicate with the devices using the Unifying Receiver.
Lars-Dominik
Braun managed to get the HID++ specifications from Logitech
and
published
them
with their authorization.
This opens a whole new world. With that document, I may be able to
understand the part I reverse engineered and convert this to a more useful
and generic library using the hidraw interface (so we don't have to
disconnect the devices from the kernel driver).
It's almost seven years now since I wrote/published Mermaids. It was an important step in my life, confessing publicly what I've found out about myself, how I feel and identify myself. It definitely has been a certain turning point in my life.
A year later, there was the Debconf6 in Mexico, which was just as important. I was wearing a skirt for the first time, and that for the whole duration of the two weeks. It was an enormous feeling of freedom, and I knew I was feeling at home. That was also the time I shaved off my beard.
And since? Well, I sort of limited myself to these two weeks every year. Debconf is my haven, Debconf is my home. Here I allow myself to be myself. Debian is my family. And like in every family, there are people who won't understand, but that doesn't matter. I feel comfortable to express myself in this crowd in the way I feel.
Being abroad seems to help with the confidence, and it seems like it also shines through. I haven't had lots of strange looks. To the contrary, when I went with a skirt to a homosexual acceptance event at home in Vienna, there was a group of gays who were pointing and laughing. Quite an interesting experience, one would assume that people who are wanting more acceptance would be more acceptable and tolerant themselves...
But, I don't think I will ever take the step toward actually turning my body into a female one. It was an important step for me to find out about my inner self, and it actually managed to make me accept my male body; even though I can totally relate to people not being able to understand this both people not in the situation and people being in the situation and needing the physical adjustment to be able to be happy again. But this is what and how I am: Contents may vary from packaging.
This though has an inherited problem: as I am not (usually) heading for a female appearance (besides my skirt during Debconf), people keep addressing me with a male pronoun, even, or rather especially when using my nick Rhonda. This is something that I consider a fair bit disturbing, especially when it comes from people that I consider to address with the term friends. One would assume that people who you share a fair bit of private life with would be the ones who can understand and relate better than others. But that's where we are, and I also can understand the troubles: I'm not giving them much visual help for fixing their thoughts.
I found the confidence in my body, and like most of you know, I have a son I dearly love (and miss like hell these two weeks), so I know how to use the 
Getting Hotplugging working with a DisplayLink USB to DVI adapter
I merged Dave Airlie s randr provider patches to the server and pushed
them out in preparation for freezing the X server for the version 1.13
release. Before freezing, I figured I should at least test hotplugging
my DisplayLink adapter. Well, that took all day
Sources
For the impatient, here s where all of the bits are. These work on my
machine.
Upstream bits:
So here we actually go with the usual 'quick introduction post':
I'm Arnaud Quette, 36 years old, and Debian developer since 2001. I'm
leading the upstream project called 
So dear Planet Debian readers, I'll be bothering you with some news on power
management and GreenIT in Debian. There will be both upstream and Debian
developments and releases info, so that you all can react. There may probably
be some diversion, on other Debian related topics, one way or another... All
this will depend on your feedback, and the balance with my available time and
pleasure to share with you these few tech bits.
cheers,
I've been working the past two days on debian-cd, which was the main
thing (besides git-annex assistant) I planned to work on at DebCamp.
Yesterday, Steve McIntyre and I cleaned up some cruft in debian-cd's
package lists. This freed somewhere in the area of 30 mb. I also took a
grep through d-i and made sure the CDs include packages that d-i can
optionally install in some situations.
Today, I investigated how Recommends are ordered on the CD, and concluded
it's as close to optimal as can be easily achieved. So was not able to save
space there, but I did find a way to reorganize the desktop task that avoids
needing to include a lot of printing stuff and some other stuff on the
first CD. While that helped some, it still didn't get either Gnome or Kde
to entirely fit, so getting there will probably involve rebuilding 100 or
so packages with xz, if someone decides to do that.
So it's stil TBD whether Gnome or Kde will fit on a single CD in Debian
wheezy. At this point I think most of us are getting tired of fighting this
increasingly losing battle every release, and so other options like only
having a desktop DVD are looking more appealing, as they solve the problem
long-term. This would also free up the first CD for other interesting
use cases, perhaps xfce, or perhaps a CD targeted at server users, and/or
containing high-popularity non-desktop packages.
A few days ago I had
The challenge is now more and more to find good places to run without
too much cars and noises....and not too far away.
Today, I think I made it well..:-)
After a look on the map, and some wild guess from what I now know of
the way the city is organized, I decided to go south-west of Managa,
from the hotel Seminole.
This is again a hilly run because, anyway, wherever you go south in
Managua, you're going up.
Ralf, who arrived just yesterday, joined me and, I guess, enjoyed the
run.
After going through an obviously quite rich neighbourhood with nice
villas, gardeners, huge US truck-style cars, we went close to the
Mormonschurch...and a mosque, then headed westward close to "Colegio
Americano", with fences, walls, guards in the corner, etc. Seems that
any tiny bit of USA in the world needs an army to protect it.
Crossing la Pista Suburbana, we then went on a very quiet roads
towards the hill, in a very green and peaceful area. House there were
really not as fancy as in other places, even seeming quite "poor" in
some way. However, we never felt any problem and people we meet on the
way are always friendly and smiling : "Hola", "Buenos Dias", etc.
At the end of the road, after about half an hour, we decided to head
back. However, as going back the same way is boring, I suggested we
head up west as my phone's map (it is very helpful to have a
smartphone with GPS and Google Maps for wandering through unknwon
places) was mentioning another road going north-west a little bit
westward.
So we entered a small trail between house farms...with dogs! These
were a bit "scary" as they were barking at us and of course running
entirely freely. On the other hand, none was really aggressive and we
had no problem. I however saw a few people really staring at us as I
guess there are not so many runners in this place..:-). But still, we
never felt unsafe: just in a quite uncommon place.
After abotu 500m we found the "road" that was on my map: indeed a path
going down slowly along the hill. And there was the marvel. An
incredible panoramic view going going the volcanoes that are East and
North of Leon : San Cristobal, Telica Rota, Pilas elHoj and last but
definitely not least: 
Hello, Internets!
After a bit of a disappointment with Lenovo, they ve come through with flying colors, My 520i s palmrest fractured in a couple of really gnarly ways. The machine was still usable, but the fractures were really bad, looked really gnarly and creaked a bit when I put any pressure around it.
After having 
As 
For my GSoC project this year I need to be able to enumerate all elementary
circuits of a directed graph. My code is written in Ocaml but neither the
Update on computational chemistry packages in Debian
