I’ve written a tiny survey for some market research. I need to know which hardware to buy for colord and gnome-color-manager so I can build a testing matrix to run through before each release.
If you already own a color calibration device or are planning to buy one, I would really appreciate you answering just three questions for me. Thanks.
I’ve spent a few hours each day for the last couple of weeks writing code to support the new mockups done by Allan for display calibration. This involved two pretty big patches, one for a reworked color panel in the control center, and one for the colord-session native calibration I blogged about a few weeks ago.
I’m glad to say this landed upstream yesterday after review by Bastien, and now people are trying it out and finding niggles which I’ve been busily fixing.
There are lots of nice features which required adding quite a few new properties to colord, the daemon which makes all this UI possible. colord now knows (from the kernel) if a device is internal, and can’t be removed. This allows us to make a few of the translations much better. We’ve also got the ability to “turn off” color management for a device, which is persistent between reboots. We can also remove profiles automatically added by colord (using metadata information) which is also stored in a database.
To test this, you currently need colord, gnome-settings-daemon and gnome-control-center from git master, although we’ll be doing some tarball releases in the next few days.
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.
I’ve pushed my patch to UPower. Testing very welcome.