search

NicoG60 / QDmxLib

Qt Dmx library
2 stars 0 forks source link

Crash on linux with enttec dmx usb pro #2

Open skankerror opened 1 year ago

skankerror commented 1 year ago

when I connect my dmx usb pro, it crashes because it calls pure virtual method for readLabel in QDmxUsbDevicePrivate::init(). It works with my enttec opendmx. I'm trying to debug to see where the problem is

skankerror commented 1 year ago

The problem is that q can't call readLabel method. I tried a workaround to bypass this problem : 

    else if (/*_officialName.contains("DMX USB PRO") || */_officialName.contains("ULTRADMX"))
    {
        /** Check if the device responds to label 77 and 78, so it might be a DMXking adapter */
        int ESTAID = 0;
        int DEVID = 0;
        QString manName = q->readLabel(dmxusb_details::dmxking_usb_device_manufacturer, ESTAID);
        qDebug() << "--------> Device Manufacturer: " << manName;
        ...

    }
    else if (_officialName.contains("DMX USB PRO"))
    {
        _type = QDmxUsbDevice::ProRXTX;
        _outputCount = 1;
//        _inputCount = 1;
        _inputCount = 0;
        _name = _officialName;
        _iface = new QEnttecPro(q);
    }

I had also to add this line 166 in QEnttecPro.cpp, because mutex wasn't locked : 

void QEnttecPro::newDataCallback()
{
  if (_newData.try_lock())
    _newData.unlock();
}

with this, my dmx usb pro tx is working, but only if I don't enable the input. If input is enabled it crashes at line 16 of qenttecpro.cpp :

auto device = enttec->_device;

at this point, enttec is a null pointer.

I really don't think these workarounds are worth doing a push request.

NicoG60 commented 1 year ago

Interesting... I've been writing that bit getting inspiration from what qlc+ does. The problem is that I don't own a enttec pro, just the open dmx one so I can't do extensive testing. I will review your code, compare it what qlc+ does and try to come with a fix.

NicoG60 commented 1 year ago

Hi, I reviewed you code and shuffle stuff around to have the readLabel() method accessible. Unfortunately I'm unable to test that because:

  1. I'm not at my place currently, I don't have my OpenDMX on me
  2. I don't have the Pro version so I can't really tell... If you don't mind testing that for me, I created a dmx-usb branch with the fix pushed. Let me know how it goes!
skankerror commented 1 year ago

Hi Things are getting better.

with openDMX : 

"[dmxusb]" loading configuration at: "/home/ray/dev/build-QontreJour-Desktop-Debug/dmxusb.json"
[dmxusb] New device detected: "OpenDMX" "A901CVG4" "403" "6001"
"[dmxusb]" has been set to be enabled
[ftdi] "A901CVG4" Default latency is 16

Then if I patch the device :

[qdmxlib] Patching "OpenDMX" port 0 to universe 0
[dmxusb] New device detected: "OpenDMX" "A901CVG4" "403" "6001"
[dmxusb] New device detected: "OpenDMX" "A901CVG4" "403" "6001"
[dmxusb] New device detected: "OpenDMX" "A901CVG4" "403" "6001"
[dmxusb] New device detected: "OpenDMX" "A901CVG4" "403" "6001"
[dmxusb] New device detected: "OpenDMX" "A901CVG4" "403" "6001"
[dmxusb] New device detected: "OpenDMX" "A901CVG4" "403" "6001"
etc...

with dmxusbpro : 

"[dmxusb]" loading configuration at: "/home/ray/dev/build-QontreJour-Desktop-Debug/dmxusb.json"
[ftdi] Reply message wrong start code:  "0"
--------> Device Manufacturer:  ""
--------> Device Name:  ""
--------> ESTA Code:  "0" , Device ID:  "0"
[dmxusb] New device detected: "" "EN263538" "403" "6001"
--------> Device Manufacturer:  ""
--------> Device Name:  ""
--------> ESTA Code:  "0" , Device ID:  "0"
[dmxusb] New device detected: "" "EN263538" "403" "6001"
--------> Device Manufacturer:  ""
--------> Device Name:  ""
--------> ESTA Code:  "0" , Device ID:  "0"
[dmxusb] New device detected: "" "EN263538" "403" "6001"
etc....

As you notice, both devices have a kind of loop, and for dmxpro, respond is not read from the device, array is full of 0.

I will continue to search what happens.

NicoG60 commented 1 year ago

Awesome, thanks for your time. I'll have a access to my stuff again next week so I'll be able to throw a debugger at it and see how it behaves.

NicoG60 commented 1 year ago

Hi, Found an issue I introduced while shuffling things around in the function that handles detected devices already present in the list of devices. it would not clear correctly and certainly create a new device each time the lib polls for new devices. Pushed that fix in the same branch in you want to try

skankerror commented 1 year ago

yes no more weird loop, opendmx works fine. there's still an issue with ftdi that can't read the response in readLabel() method.

NicoG60 commented 1 year ago

Alright, thanks for your time. As said earlier, I will try to have a deeper look next week when I have access to all my setup

skankerror commented 1 year ago

About time, thanks for yours.

I'll try to find things to solve on my side. If I have results I'll post.