uDMX: Unknown device

[blshkv]

Dear qlcplus,

I'm testing the latest release qlcplus-4.10.5b (Gentoo Linux, compiled with QT5) with a USB-DMX512 cheap dongle and got the following error:

This plugin provides DMX output support for Anyma uDMX devices.
Unknown device
Cannot connect to USB device.

The relevant lsusb -v output is below:

Bus 002 Device 004: ID 16c0:05dc Van Ooijen Technische Informatica shared ID for use with libusb
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.01
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x16c0 Van Ooijen Technische Informatica
  idProduct          0x05dc shared ID for use with libusb
  bcdDevice            1.02
  iManufacturer           1 www.anyma.ch
  iProduct                2 uDMX
  iSerial                 3 ilLUTZminator001
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           18
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass         0 
      bInterfaceSubClass      0 
      bInterfaceProtocol      0 
      iInterface              0 
Device Status:     0x0000
  (Bus Powered)

I have checked the source code, 16c0:05dc is specified properly in uDMX plugin.

would you have an idea what's wrong?

Thank you.

[mcallegari]

Permission problems on /dev/ttyUSB0 ?

[blshkv]

I actually don't have that symlink. I did install z65-anyma-udmx.rules which was provided so it should be 666 (rw for all)

EDIT: I've just checked, it is:

ls -al /dev/bus/usb/001/005 
crw-rw-rw- 1 root plugdev 189, 4 Jun 21 20:43 /dev/bus/usb/001/005

and my user in the plugdev group too.

[blekenbleu]

Hi Anton -

idVendor 0x16c0 Van Ooijen Technische Informatica

idProduct 0x05dc shared ID for use with libusb

I apologize if this was already answered, but the libusb driver does not appear to have been installed: (see 2.1) http://www.qlcplus.org/docs/udmxoutput.html

[blshkv]

It is not the case either :(. I have two versions libusb-compat-0.1.5 (http://libusb.sourceforge.net/) and libusb-1.0.21 (https://github.com/libusb/libusb) installed.

I also have other software (ola, uDMX from udmx-pyusb) installed and it works. So I don't think it is a problem with my setup.

[blshkv]

hm.. I have checked the code. Somehow, qlc+ requires both libraries. Some modules use include <libusb.h> which is libusb, others (udmx and peperoni plugins) call include <usb.h> which is provided by libusb-compat. Could it be the problem?

[blekenbleu]

On Wed, Jun 21, 2017 at 7:21 PM, Anton Bolshakov notifications@github.com wrote:

I have two versions libusb-compat-0.1.5

uDMX is a libusb-0.1 device; I think QLC wants that interface (at least, it did a year ago) My understanding is that libusb-compat converts libusb-0.1 calls into their libusb-1.0 equivalents, which neither uDMX nor QLC would expect.

-- Steven Carmichael

[blshkv]

ok, both libraries can so-exist but you need to call the one which is required.

So it looks like you need to convert all include lines into include <libusb.h> and all .pro files into PKGCONFIG += libusb-1.0 . Currently, there are few .pro files with PKGCONFIG += libusb which is provided by libusb-compat and this is not what you want.

[blshkv]

it is even more mixed up with the peperoni plugin. peperoni/common files use libusb.h (libusb) but peperoni/unix use usb.h (libusb-compat).

I suggest to migrate everything to libusb.

[blshkv]

any progress here please?

[mcallegari]

What am I supposed to do with this ? I don't have your same adapter, but I have a clone and it works correctly:

I don't know how you ended up saying that usb.h is part of libusb-compat, but in my Ubuntu 16.04 system, I've got libusb-0.1.12 and libusb-1.0.20 installed. Header files are taken from libusb-0.1.12 and that's where usb.h is found

If I install libusb-1.0.20 dev package, the header file to be used should be /usr/include/libusb-1.0/libusb.h

[blshkv]

http://www.libusb.org/wiki/libusb-compat-0.1

regardless of the name, there is a clear mix of "old" library (usb.h) with a new one (libusb.h)

P.S. My adapter is also clone.

[mcallegari]

regardless of the name, there is a clear mix of "old" library (usb.h) with a new one (libusb.h)

Does it hurt you ?

Some of the QLC+ code has been written 10+ years ago, when libusb 1.0 didn't even exist or at least was not the default in Linux distros. Also, don't just focus on Linux only. QLC+ is cross platform and needs to accomodate different build systems with different libraries. I can migrate everything to libusb 1.0, but honestly I don't see the benefit in doing it.

[blekenbleu]

My understanding is that libusb-compat-0.1 only enables apps written for libusb-0.1 to work with libusb-1.0 drivers; on the device side, uDMX does NOT work with libusb 1.0 driver: "Attention: the udmx needs libusb 0.1 in order to function (libusb 1.0 will not work)." http://www.anyma.ch/research/udmx/

[mcallegari]

@blekenbleu for the record, libusb is NOT a driver. It's a user space library that translates high level calls into raw USB packets and sends them to a kernel space driver. (usually with ioctl calls)

[blekenbleu]

I apologize for any confusion using the term "driver" may have provoked. FWIW, I have used uDMX with QLC+ on linux, macOS and Windows. For Windows, QLC+ is used with libusb-win32, which includes "kernel driver libusb0.sys" and refers to its user-space code as "a filter driver": https://sourceforge.net/p/libusb-win32/wiki/Home/

[mcallegari]

I apologize for any confusion using the term "driver" may have provoked.

No problem at all. Just wanted to point out the difference. This may be confusing if you think of Windows. There we have DLLs (which in some other cases are the counterpart of Linux's .so libraries) that are the actual driver code. However in Linux the difference is clearer: user space = shared library (.so), kernel space = driver (.ko)

[blekenbleu]

For Linux, I read that "libusb provides a direct interface to USB devices, allowing arbitrary USB commands to be sent to any connected USB device." https://lwn.net/Articles/703785/ While uDMX's Atmel Atmega8 has hardware support for DMX serial I/O, USB was implemented by bit-banging and took liberties with USB protocol which are tolerated by libusb-0.1 but, so far as I can tell, NOT supported by libusb-1.0.

[blshkv]

the statement about libusb-1.0 is likely not true or valid for Mac OS only. Here is an example of a similar plugin which uses libusb.h: https://github.com/prescottprue/PiOpenLighting/blob/master/plugins/usbdmx/UsbDmxPlugin.cpp There are a lot of examples how to migrate to the newer library and even a Python pyusb module which works with either of them just fine.

I was just taking a while guess that mixing both libraries is not a good idea because it might case a weird race of conditions. Feel free to ignore it if you think it is not the case.

Please let me know what else can be useful to debug my issue. Thank you.

[mcallegari]

Please let me know what else can be useful to debug my issue. Thank you.

To be honest I still don't get your issue. If you see "Unknown device. Cannot connect to USB device." it means a device is actually listed in the input/output manager. I saw it too and it might be a glitch in the device status (that I can easily fix), but it doesn't mean the device will not work. Have you tried to activate the checkbox of the corresponding output line and see if it works ?

[blshkv]

There is no checkbox displayed next to it

[blshkv]

oh, wait a min. I did not see the horizontal scroll. Sorry my fault. There is a checkbox in the "output" column! Let me play around it before I close this bug.

[mcallegari]

I'm closing this regardless, cause it seemed like a major plugin issue and ended up being a missed scrollbar.

[blshkv]

Yes, the bug is invalid probably. But the reason why I haven't came back because I'm still not able to make it work. I selected the output and setup a simple test with Generic RGB but it does not change the colors. It is still works via command line.

Next, I tried to setup it via OLA plugin. Again, I'm able to change colors via OLA console but it does not work via my simple test. I guess I'm doing something wrong again (this is a first time for me). I will look for support at the forum first.

Thank you