Pico detected by TV, but HyperHDR logs doesnt show it
dieseld23 opened this issue · comments
WebOS 4.5 - v5.30.40
HyperHDR installed onto tv directly
dmesg log on TV:
[ 278.271523] usb 7-1: USB disconnect, device number 2
[ 281.040496] usb 7-1: new full-speed USB device number 3 using ohci-platform
[ 281.269488] usb 7-1: New USB device found, idVendor=2e8a, idProduct=000a
[ 281.269503] usb 7-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 281.269509] usb 7-1: Product: Pico
[ 281.269514] usb 7-1: Manufacturer: Raspberry Pi
[ 281.269520] usb 7-1: SerialNumber: E6614C311B4FC726
[ 281.273810] cdc_acm 7-1:1.0: ttyACM0: USB ACM device
lsusb:
Bus 005 Device 002: ID 043e:3109
Bus 007 Device 003: ID 2e8a:000a
Bus 001 Device 001: ID 1d6b:0002
Bus 002 Device 001: ID 1d6b:0003
Bus 003 Device 001: ID 1d6b:0002
Bus 004 Device 001: ID 1d6b:0002
Bus 005 Device 001: ID 1d6b:0002
Bus 006 Device 001: ID 1d6b:0001
Bus 007 Device 001: ID 1d6b:0001
Bus 008 Device 001: ID 1d6b:0001
Tried two different RP2040s with no change (one is an RP2040W original, the other is a Pimoroni Plasma 2040W).
Using the latest HyperHDR v20beta and HyperSerialPico
HyperHDR set with rp2040 handshake, and to ttyACM0.
The only thing I can see is that ttyACM0 is linked to cdc_acm 7-1:1.0. But based on lsusb, it should be 7-1:1.2?
Did you notice product id and vendor id in HyperHDR logs? It's not valid: 0 so there is also 0 chance it will work. It's not HyperHDR issue and BTW webos is also not officially supported here. Latest v20 beta has also device discovery which should find valid serial devices.
I get it, I'm just trying to get any potential ideas on what's going on. Wasn't sure where to post and where the source of the issue is. The TV's operating system recognizes the Pico, but HyperHDR isn't seeing it.
Try the latest v20 beta. The device discovery tab should find Pico if it is present. Did you connect Pico to windows pc and in the device manager it was discoved as a serial port? And for webos: or the wrong serial port was selected (their name/path could change after restart) or it's caused by a comical bug in udev package (let's change something in the latest beta just before udev 'stable' release... what can go wrong?), fixed some time ago but it's propagating across various OS distroes and causes vendor/product id to be mismatched. There is a topic in the HyperHDR discussion about it.