Open opdenkamp opened 10 years ago
Any updates on this?
I think that it could have something to do with this, which I just found out today while using usb debugging on Windows
English product name: "USB-CEC Adapter"
ConnectionStatus:
Current Config Value: 0x01 -> Device Bus Speed: Full (is not SuperSpeed or higher capable)
Device Address: 0x01
Open Pipes: 4
===>Device Descriptor<===
bLength: 0x12
bDescriptorType: 0x01
bcdUSB: 0x0110
bDeviceClass: 0x00
*!*ERROR: device class should be Multi-interface Function 0xEF
When IAD descriptor is used
bDeviceSubClass: 0x00
*!*ERROR: device SubClass should be USB Common Sub Class 2
When IAD descriptor is used
bDeviceProtocol: 0x00
*!*ERROR: device Protocol should be USB IAD Protocol 1
When IAD descriptor is used
bMaxPacketSize0: 0x20 = (32) Bytes
idVendor: 0x2548 = Pulse-Eight Limited
idProduct: 0x1002
bcdDevice: 0x1000
iManufacturer: 0x01
English (United States) "Pulse-Eight"
iProduct: 0x02
English (United States) "USB-CEC Adapter"
iSerialNumber: 0x03
English (United States) "v7"
bNumConfigurations: 0x01
I'll have to address this in the firmware.
Can the firmware be upgraded on existing units? It has been quite a while since I've tinkered with my usb adapter now. I should really get around to setting this up again.
Yes, the firmware can be upgraded (once it's been fixed, including an issue that can apply to recent Intel NUCs), but only on Windows unfortunately. We don't have any updater available for OS X.
You can download the beta upgrader here, but you'll need Windows to apply it. Just plug in the adapter and run the executable from the zip: cec-firmware-v8.zip
The upgrader will be available on our website once it passed all our tests.
Can confirm v8 solved my issue 😀 😀 😀 (Libreelec v8.2)
c+p from the old ticket created by @iKenndac
Hello,
I'm writing a client against libCEC, and I've noticed that if the device is connected to the computer during boot, it can't be detected by libCEC until it's been unplugged and reconnected. This hasn't always happened, and as such I thought it was a problem with my device. However, a user of my client has the same problem.
If memory services me correctly, I believe this started around the time the composite device firmware arrived.
My device is running firmware v4:
libCEC version = 2.1.3, client version = 2.1.3, firmware version = 4, firmware build date: Thu Dec 6 11:15:20 2012 +0000, logical address(es) = Playback 2 (8) , physical address: 1.1.0.0, host: unknown, features: unknown, compiled: Sep 29 2013
I did some digging around in IOJones, and found the following:
1) When the device is working correctly, IOKit sees the adapter correctly with three devices: Serial control, serial data and the HID device.
/dev/tty.usbmodemv2 r1
exists.2) Just after boot, the three composite devices are listed but only the HID device has any information.
/dev/tty.usbmodemv2 r1
(or anything similar) does not exist. No amount of relaunching applications will fix this - only a physical unplug and plug will return the device to the first state.Unless there's some magic command that I'm missing, it actually looks like this is a problem with the device rather than libCEC itself. If you need any help debugging, I can help out.
I've been tinkering around with this and I've found a horrible workaround!
If you force the USB bus to do a "soft reset" of the device (which seems to just simulate unplugging and reconnecting the device to me, but I'm not an expert), when the device is re-detected by the system, all the services are found correctly and the device can work.
Unfortunately, this is a fair amount of extra code since you have to find the adapter by iterating USB devices rather than serial ports. I've created a sample project over here, with the interesting stuff in DKAppDelegate.m.