error identifying/opening HID devices on Windows

[shalty]

Hi

Under the 1.11 version of Mixxx (and i suspect this is something that fails since the added HID support), the HID devices under Windows have a problem with some devices.

An example seen trough the log file:

Debug [Controller]: Found 0x10c85240 0x113cd690 "r608" S/N 0x0 "Interface 1"
Debug [Controller]: Found 0x10ef4518 0x9135500 "r256" S/N 0x177ee808 "Usage Page 1 Usage 1"
...
Debug [Controller]: Loading controller preset from "E:/portableapps/Mixxx_1.11/controllers/Hercules_DJ_Control_MP3__1.hid.xml"
...
Debug [Controller]: Loading controller preset from "E:/portableapps/Mixxx_1.11/controllers/CTH-470_?.hid.xml"
...

There are two things here: one is the "cosmetic" bug at the debug info (in HidEnumerator::queryDevices) that doesn't do a, like, safeDecodeWideString, to convert wchar to QString, so it print pointer addresses instead of char data. With the code changed, it should be something like this (note that i only modified manufacturer and model strings, not the serial):

Debug [Controller]: Found "Wacom Co.,Ltd." "CTH-470" "r256" S/N 0x12cd2168 "Interface 0"

The other (more annoying) bug is with the serial number. Some devices (like the Hercules on the example) put a null string, so the device name set at HidController::HidController is "Hercules_DJ_Control_MP3_(empty)_1.hid.xml", and everything works fine (at least if you don't have two hercules, i sure don't ;))

But the wacom doesn't get a null string, instead it gets a lonely 409 decimal wchar'acter. This breaks the use of the controller (or trying to do a mapping for it, as it's my case ;)), probably because of the conversion to "?" in not unicodeaware code, and creates files that are difficult to use on the filesystem (some app's cannot open them, etc...). After a test change with another "more reasonable" device name, the same hw works fine (can be opened and report incoming packet data fine)

As this doesn't happens under linux with the same hw, i'm inclined to think that probably is something about hidapi.

I'm on win8 x64, but i have seen the same behaviour with an old laptop on xp (and the same devices)

[shalty (neogeo-dc)]

Sorry, when i said it was the 409 decimal char, i was wrong: it's 409h, so its this

http://www.htmlescape.net/04/unicode_char_0409.html

[shalty (neogeo-dc)]

Probably it's the same bug reported here

https://bugs.launchpad.net/mixxx/+bug/1215275

[Sean M. Pappalardo (pegasus-renegadetech)]

Yes, good find. But since your report is more detailed, I've marked that one a duplicate of this. I'm the one who added the HID code and can take a look at this, but not for a couple of months. I'll leave it unassigned until then incase someone else wants to take it.

[Dennis Rohner (midzer)]

I suppose a bug in hidapi lib affected this issue.

It has been fixed a month ago:
https://github.com/signal11/hidapi/commit/54eb31dc16dcc67d0b689ed947bc53a038608c0e
and https://github.com/signal11/hidapi/commit/d17db57b9d4354752e0af42f5f33007a42ef2906

We should update mixxx hidapi lib to latest head revision.

I will test afterwards if this bug still exists.

[shalty (neogeo-dc)]

I'm not so sure :(

After some debugging, i'm inclined to think that the fail is in on the wacom drivers for windows: the call to HidD_GetSerialNumberString (that it's responsability of the driver, AFAIK, being windows just a "common proxy"), returns this strange unicode symbol (bogus data). The rest of the common calls (HidD_GetManufacturerString, HidD_GetProductString...) works fine.

Anyway, it's true that i don't know jack how hid works at a low level, so perhaps those patches really do something :). I'll try when available (i have a working 1.11 compiling windows setup and i don't want to mess with it *again* :) :) )

[shalty (neogeo-dc)]

I have applied the patch https://github.com/signal11/hidapi/commit/54eb31dc16dcc67d0b689ed947bc53a038608c0e on a very recent build of the 1.12 beta (rev4824), and sadly it doesn't change anything :(

As i said, it seems the bug is on the wacom drivers, so i don't see an easy solution (short of expecting bad data and work around it).

Anyway, it is more of an experiment (this is not a controller ;)), so if it doesn't work, and usually proper/real DJ controllers are detected fine, i wouldn't worry at all... (i can always force it in my build if i *really* want to experiment).

Thank you

[RJ Skerry-Ryan (rryan)]

Ok, so it sounds like if we're going to use funky, untrusted input like the device-reported serial number in Mixxx then we need to do some basic testing to make sure the characters are valid for the intersection of filesystems our users use since Mixxx uses the device name as the filename for the preset.

[Be (be.ing)]

Is this still an issue?

[Launchpad Janitor (janitor)]

[Expired for Mixxx because there has been no activity for 60 days.]

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/7162