Controller list in preferences shows garbage

[JosepMa]

Mixxx 1.12 (currently build 5557, but happened with earlier versions too). I can't remember if it happened too with 1.11 (i tried that one briefly before jumping to 1.12)

Windows 10 (Upgraded from 7).
Intel core 2 Duo
Integrated video and audio

I have found a strange bug in Mixxx. It is mostly a visual annoyance than anything serious, but I would like to help in fixing it.

Concretely, in the preferences, under the controllers list, several controllers appear with garbage in their name. (The name is shown as if it was chinese, but the "letters" change from launch to launch so I am quite sure it is garbage or numerical data interpreted as text).

When I select them, some of them show "Generic HID keyboard", others "Unknown HID device", so maybe they should appear, but with a correct name, not with these strange characters.

Here there is a screenshot showing the bug on the left, and the hardware devices of windows on the right: http://psycle.free.fr/josepma/mixxx/mixxx-error%20controladors.png

[JosepMa (josepma)]

Log file reports things like this:

Debug [Controller]: Found 0xaf4678750 0xaf4678670 "r272" S/N 0xaf4678660 "Usage Page 65468 Usage 137"
Debug [Controller]: Found 0xaf4678820 0xaf4678710 "r272" S/N 0xaf4678800 "Usage Page 12 Usage 1"

This output comes from the file src/controllers/hid/hidenumerator.cpp

        qDebug() << "Found"
                 << cur_dev->manufacturer_string
                 << cur_dev->product_string
                 << QString("r%1").arg(cur_dev->release_number)
                 << "S/N" << cur_dev->serial_number
                 << (cur_dev->interface_number == -1 ? QString("Usage Page %1 Usage %2").arg(
                     QString::number(cur_dev->usage_page),
                     QString::number(cur_dev->usage)) :
                     QString("Interface %1").arg(cur_dev->interface_number));

manufacturer, product and serial number are not being printed because they are wchar_t* , and probably require using a QString, or formatting like the release_number.

Then, on src/controllers/hid/hidcontroller.cpp there is this, that obtains the texts into a QString

    hid_serial = safeDecodeWideString(deviceInfo.serial_number, 512);
    hid_manufacturer = safeDecodeWideString(deviceInfo.manufacturer_string, 512);
    hid_product = safeDecodeWideString(deviceInfo.product_string, 512);

The method safeDecodeWideString is this:

QString safeDecodeWideString(const wchar_t* pStr, size_t max_length) {
#ifdef __WINDOWS__
    // We cannot use Qts wchar_t functions, since the may work or not
    // depending on the '/Zc:wchar_t-' build flag in the Qt configs
    if (sizeof(wchar_t) == sizeof(QChar)) {
        return QString::fromUtf16((const ushort *)pStr, (int)max_length);
    } else {
        return QString::fromUcs4((uint *)pStr, (int)max_length);
    }
#else
    return QString::fromWCharArray(pStr, (int)max_length);
#endif
}

I wonder if the workaround for Windows is really working or not, and I don't have a way to know due to the log file not printing the text.

(I am not able to compile Mixxx on Windows right now. No QT4 installer)

[Daniel Schürmann (daschuer)]

This is probably a duplicate of: Bug #1514335

[Daniel Schürmann (daschuer)]

Would you mind to Test this? :
https://owncloud.blaisot.org/index.php/s/ADmPNxpxBtCBzv3

It still contains all the garbage behind the strings Bug #1514335, but it includes the recent HIDAPI
Maybe we see a difference.

[JosepMa (josepma)]

If i have time, I'll try it in half an hour. Else. I'll do it in 7 or 8
hous.
El dia 19/11/2015 11:30, "Daniel Schürmann" <email address hidden> va
escriure:

> Would you mind to Test this? :
> https://owncloud.blaisot.org/index.php/s/ADmPNxpxBtCBzv3
>
> It still contains all the garbage behind the strings Bug #1514335, but it
> includes the recent HIDAPI
> Maybe we see a difference.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1502448
>
> Title:
> Controller list in preferences shows garbage
>
> Status in Mixxx:
> Confirmed
>
> Bug description:
> Mixxx 1.12 (currently build 5557, but happened with earlier versions
> too). I can't remember if it happened too with 1.11 (i tried that one
> briefly before jumping to 1.12)
>
> Windows 10 (Upgraded from 7).
> Intel core 2 Duo
> Integrated video and audio
>
> I have found a strange bug in Mixxx. It is mostly a visual annoyance
> than anything serious, but I would like to help in fixing it.
>
> Concretely, in the preferences, under the controllers list, several
> controllers appear with garbage in their name. (The name is shown as
> if it was chinese, but the "letters" change from launch to launch so I
> am quite sure it is garbage or numerical data interpreted as text).
>
> When I select them, some of them show "Generic HID keyboard", others
> "Unknown HID device", so maybe they should appear, but with a correct
> name, not with these strange characters.
>
> Here there is a screenshot showing the bug on the left, and the
> hardware devices of windows on the right:
> http://psycle.free.fr/josepma/mixxx/mixxx-error%20controladors.png
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1502448/+subscriptions
>

[JosepMa (josepma)]

Hi.

I've finally tested it.

This shows the same behaviour than the buggy 1.12.

I guess it does not include the patch for null-terminating the strings.
I connected one of the devices (a wireless mouse), and it appears... several times, and without null-terminating the string, and one can see other texts that are in no way related to the controller.

Notice that this time, the wireless mouse appears because I have connected it. The other examples were with no external usb hardware connected to the laptop.

[Daniel Schürmann (daschuer)]

Thank you for the update:

Even though now the strings are not terminated the first part should be valid.
Since this is not the case, there seems something odd going on which is not fixed by an HIDAPI update.

"Found 0xaf4678750 0xaf4678670 "r272" S/N 0xaf4678660"

This prints the address of the wcahr_t* stead of the string itself.

I assume this is because it uses the "operator<<(const void * p)"

I will fix that.

[Daniel Schürmann (daschuer)]

The debug issue is fixed here:
https://github.com/mixxxdj/mixxx/commit/26fb6ff9d68e7b1e3089e3fd55b6aa1474b2f791
Please try out once it is available from the buildserver.

The remaining Questions: What is the garbage device and where is the issue?

[JosepMa (josepma)]

Installed git5638 and i can say that the Mixxx side of this bug is fixed.

The strings are properly terminated, and the log now shows what it should show

Debug [Controller]: Found "??" "??" "r272" S/N "??" "Usage Page 1 Usage 1"
Debug [Controller]: Found "MOSART Semi." "Wireless Keyboard & Mouse" "r256" S/N "" "Interface 0"
Debug [Controller]: Found "MOSART Semi." "Wireless Keyboard & Mouse" "r256" S/N "" "Interface 1"

As for the hidapi/windows 10 side, I am assuming that somehow, these "no name" devices should simply not appear (like there are some Apple devices that are hidden).

There is still the issue that there are several times the same device, but that's another bug reported elsewhere.

Out of curiosity, I installed locally Mixxx 1.11 to doublecheck what did it show. Well, it shows the strings properly terminated too on the screen and has the bug on the log file. But it also showed the garbage devices.

Since I remember that I saw their names once, I think that these "no name" devices are a problem from the migration of Windows 7 to Windows 10, or maybe some issues with compatibility of hidapi with Windows 10 itself (or the mentioned possibility that these should be simply hidden).

Btw, you also asked me in the other thread if i could build for Windows.. Well... I am nearly there, but not yet :)

[Be (be.ing)]

see https://github.com/mixxxdj/mixxx/pull/783

I updated hidapi to 0.8.0-rc1 on GNU/Linux and this bug was fixed for the listing of my mouse in the controller preferences.

[JosepMa (josepma)]

More info on this issue.

I compiled the "hidtest" project and I am attaching its output.

It seems that the unnamed hid devices come from the infrared receiver that this laptop has:
  path: \\?\hid#irdevicev2&col01#2&2818a073&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
  path: \\?\hid#irdevicev2&col02#2&2818a073&0&0001#{4d1e55b2-f16f-11cf-88cb-001111000030}
  path: \\?\hid#irdevicev2&col03#2&2818a073&0&0002#{4d1e55b2-f16f-11cf-88cb-001111000030}

There are 8 of those entries, each entry increments the index "col01", "col02"... ( and 0000, 0001...)
All of these entries have no name (null terminated empty string) and have interface= -1 and different values in usage and usage page.

Then, there is the wireless mouse. It is a wireless receiver that it can host multiple devices, usually one mouse and one keyboard, but I think that I tried it once with two keyboards. This might be the reason why there appear more than two entries.
In this case, there is a difference. there is one separate element, and then another with different indexes:

  path: \\?\hid#vid_062a&pid_0102&mi_00#7&2fced162&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
  path: \\?\hid#vid_062a&pid_0102&mi_01&col01#7&bf793a0&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
  path: \\?\hid#vid_062a&pid_0102&mi_01&col02#7&bf793a0&0&0001#{4d1e55b2-f16f-11cf-88cb-001111000030}
  path: \\?\hid#vid_062a&pid_0102&mi_01&col03#7&bf793a0&0&0002#{4d1e55b2-f16f-11cf-88cb-001111000030}
  path: \\?\hid#vid_062a&pid_0102&mi_01&col04#7&bf793a0&0&0003#{4d1e55b2-f16f-11cf-88cb-001111000030}
  path: \\?\hid#vid_062a&pid_0102&mi_01&col05#7&bf793a0&0&0004#{4d1e55b2-f16f-11cf-88cb-001111000030}

First one has interface = 0 and the others have interface = 1

Another thing to note is that serial_number is a null terminated empty string on the IR device, and is the text "(null)" on the mouse device.

Finally, I'm not sure why, but my debug compile of 2.0.0.1 (branch 1.12 from the end of december) seems to "show" the name correctly as an empty string, while the 2.0.0 release build downloaded from the web, as well as a 2.1 alpha from 2 january also downloaded from the web show garbage in the case of these empty-name devices.
I wonder if there is anything wrong in the windows build server or what.

[JosepMa (josepma)]

Ok, I've pinpointed the problem to lib\hidapi-0.8.0-rc1\windows\hid.c:

@392:
tmp = (struct hid_device_info*) calloc(1, sizeof(struct hid_device_info));
+++ // Initialize all memory to zero:
+++ memset(tmp, 0, sizeof(struct hid_device_info));

And then:

@425:
+++ wstr[0] = 0x0000;
/* Serial Number */
res = HidD_GetSerialNumberString(write_handle, wstr, sizeof(wstr));

I opened an issue on hidapi's github, but i don't have much confidence on being incorporated any time soon..

[RJ Skerry-Ryan (rryan)]

https://github.com/signal11/hidapi/issues/315

BTW the HIDAPI author has been responsive to feedback in the past -- and we can patch our local copy of it anyway. Do you have a working fix?

[JosepMa (josepma)]

Ok.. it was just that i got the feeling that the project was a bit dormant looking at the pull requests and the commits.

As for a working fix, it is exactly the two changes i've put above. Maybe it is simply the wstr change, if calloc really zeroes the memory.

[JosepMa (josepma)]

This can be closed.

libhidapi was updated and included in the mixxx/lib on https://github.com/mixxxdj/mixxx/pull/2633

[Swiftb0y (swiftb0y)]

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