ColorHug2 USB invalid read errors on Fedora 24

[Rob Foehl]

I just received my ColorHug2 a few weeks ago -- thanks, Richard and Ania!
-- and have only had a few opportunities to play with it so far, mostly
due to trouble when attempting to use it on several Fedora 24 machines.

After connecting the ColorHug and attempting a single sample with
gcm-picker running as a normal user, both that and colord log the
following:

(gcm-picker:2600): Gcm-WARNING **: failed to get sample: usb:00:01:01: Invalid read: retval=0x0a [Invalid value] cmd=0x35 [get-remote-hash] (expected 0x35 [get-remote-hash]) len=64 (expected 22 or 64)

Sep 09 22:38:41 xxx colord[1950]: (colord:1950): Cd-WARNING **: ignoring error: usb:00:01:01: Invalid read: retval=0x0a [Invalid value] cmd=0x35 [get-remote-hash] (expected 0x35 [get-remote-hash]) len=64 (expected 22 or 64)

The "sampled" data is all zeroes, unsurprisingly. This happens on three
separate systems I've tried, and on all of 4.6.3, 4.6.4, and 4.7.2 kernels
as shipped in Fedora. I've confirmed it's not a hardware issue by testing
with the live USB stick, and I've been trying with the 2.0.6 firmware that
was loaded onto the device shortly after it arrived.

This also happens on the first attempt only; subsequent attempts just emit
this lock error from gcm-picker without first reconnecting the device:

(gcm-picker:2856): Gcm-WARNING **: failed to lock: failed to lock: usb:00:01:01: Invalid read: retval=0x0a [Invalid value] cmd=0x35 [get-remote-hash] (expected 0x35 [get-remote-hash]) len=64 (expected 22 or 64)

I'm also having issues with the faint-but-apparent red shift in profiles
generated by gnome-color-manager as noted in some other posts here, and
testing at all has been complicated by being unable to boot the live image
on UEFI systems with secure boot enabled.

One thing at a time, though...

-Rob

[Richard Hughes]

On 10 September 2016 at 04:02, Rob Foehl <r...@loonybin.net> wrote:
> Sep 09 22:38:41 xxx colord[1950]: (colord:1950): Cd-WARNING **: ignoring
> error: usb:00:01:01: Invalid read: retval=0x0a [Invalid value] cmd=0x35
> [get-remote-hash] (expected 0x35 [get-remote-hash]) len=64 (expected 22 or
> 64)

That's harmless; thats just saying that no ICC profile hash is stored
in the device, which is a little-used and optional feature.

> This also happens on the first attempt only; subsequent attempts just emit
> this lock error from gcm-picker without first reconnecting the device:

Hmm, what version gnome-color-manager?

> I'm also having issues with the faint-but-apparent red shift in profiles
> generated by gnome-color-manager as noted in some other posts here, and
> testing at all has been complicated by being unable to boot the live image
> on UEFI systems with secure boot enabled.

Did you try with dispcalGUI?

Richard

[Rob Foehl]

On Sat, 10 Sep 2016, Richard Hughes wrote:

> On 10 September 2016 at 04:02, Rob Foehl <r...@loonybin.net> wrote:
>> Sep 09 22:38:41 xxx colord[1950]: (colord:1950): Cd-WARNING **: ignoring
>> error: usb:00:01:01: Invalid read: retval=0x0a [Invalid value] cmd=0x35
>> [get-remote-hash] (expected 0x35 [get-remote-hash]) len=64 (expected 22 or
>> 64)
>
> That's harmless; thats just saying that no ICC profile hash is stored
> in the device, which is a little-used and optional feature.

Hm, okay... That's the only log output, and doesn't happen with the live
image. Could this still be causing the all-zeroes samples? Overzealous
error path, maybe?

>> This also happens on the first attempt only; subsequent attempts just emit
>> this lock error from gcm-picker without first reconnecting the device:
>
> Hmm, what version gnome-color-manager?

Sorry, should've been specific. They're all current Fedora 24, so appears
to be these (and related packages):

argyllcms-1.8.3-2.fc24.x86_64
colord-1.3.3-1.fc24.x86_64
colorhug-client-0.2.8-2.fc24.x86_64
gnome-color-manager-3.20.0-1.fc24.x86_64

>> I'm also having issues with the faint-but-apparent red shift in profiles
>> generated by gnome-color-manager as noted in some other posts here, and
>> testing at all has been complicated by being unable to boot the live image
>> on UEFI systems with secure boot enabled.
>
> Did you try with dispcalGUI?

Not yet. Just tried it, appears to be able to read the sensor -- seems
promising, I'll have to play with it later when the display isn't sitting
in direct sunlight.

-Rob