Hi,
just received my new Vero4K+ to replace RPi3B+, as RPi didn’t have enough power for DVB-T2. Just started, but so far impressed, thanks for such a great product.
Everything seems to be working so far, except my Hauppauge DualHD USB stick. dmesg is reporting only new device:
[ 449.690406] usb 1-1: new high-speed USB device number 7 using xhci-hcd
[ 449.830967] usb 1-1: New USB device found, idVendor=2040, idProduct=8265
[ 449.830992] usb 1-1: New USB device strings: Mfr=3, Product=1, SerialNumber=2
[ 449.831006] usb 1-1: Product: dualHD
[ 449.831020] usb 1-1: Manufacturer: HCW
[ 449.831033] usb 1-1: SerialNumber: 0014105122
I have searched the forum and found it should work, but it doesn’t :-). On first sight, I can see the USB id is slightly different. In other reports, idProduct was reported as 0265, mine is 8265. Looking around the web, seems it should be the same HW, just different id.
Any suggestions what to do? Maybe just updating some udev rule to allow the driver to load?
Anyway, I am sure it is supported on at least some Linux versions, it was running fine on RPi3B+ (just too jerky to be usable, but both tuners were found and working). I can post logs from RPi, if it helps.
Looking for the IDs on the net, I found this:
Hauppauge is mentioned there with both IDs, and from quick look, it does not look they would be handled separately.
2040:0265 Hauppauge WinTV-dualHD DVB Isoc
2040:8265 Hauppauge WinTV-dualHD DVB Bulk
Edit: there are differences in the code to handle bulk transfer, supported by the newer cards, I was wrong, sorry. So probably driver update is needed?
Unplug the dongle, then run the commands: sudo modprobe em28xx echo "2040 8265" | sudo tee "/sys/module/em28xx/drivers/usb:em28xx/new_id"
Plug in the dongle
Thanks for the hint. This made a change, but it’s not enough. The LED on the tuner is now lit, so it at least gets power, but dmesg reports:
[162655.745812] usb 1-2: new high-speed USB device number 9 using xhci-hcd
[162655.886338] usb 1-2: New USB device found, idVendor=2040, idProduct=8265
[162655.886351] usb 1-2: New USB device strings: Mfr=3, Product=1, SerialNumber=2
[162655.886356] usb 1-2: Product: dualHD
[162655.886361] usb 1-2: Manufacturer: HCW
[162655.886365] usb 1-2: SerialNumber: 0014105122
[162655.888007] em28xx 1-2:1.0: New device HCW dualHD @ 480 Mbps (2040:8265, interface 0, class 0)
[162655.888019] em28xx 1-2:1.0: DVB interface 0 found: bulk
[162655.888415] em28xx 1-2:1.0: chip ID is em28174
[162656.025835] em28xx 1-2:1.0: failed to read eeprom (err=-110)
[162656.025850] em28xx 1-2:1.0: em28xx_i2c_register: em28xx_i2_eeprom failed! retval [-110]
[162656.025857] em28xx 1-2:1.0: em28xx_init_dev: em28xx_i2c_register bus 0 - error [-110]!
[162656.025884] em28xx: probe of 1-2:1.0 failed with error -110
Just for completeness, on RPi, the kernel version is:
Linux osmc 4.14.78-4-osmc #1 SMP PREEMPT Wed Dec 12 17:58:11 UTC 2018 armv7l GNU/Linux
on the Vero:
Linux vero4k 3.14.29-156-osmc #1 SMP Tue Oct 15 20:21:25 UTC 2019 aarch64 GNU/Linux
Modinfo on the em28xx module gives version 0.2.2 both on the Vero and RPi, but the src version hash is different, F51222A423F006A25AA455A on Vero, 223A218F99372888D6B5037 on RPi. But that may not be important, it’s a backport on Vero, so there may be some other changes after all.
So, I have backported some parts of the em28xx driver from RPi to Vero and my USB tuner is now working. (Only one tuner at this moment, still looking into that.)
Are you interested in these changes, should I clean it up and submit? Or is switch to the new kernel imminent and updating the old one is no longer worth it?
BTW, learning to work with the OSMC source code and build system is a pain. Don’t take this as a complain, I am really happy you guys created all this, it’s rather a suggestion where to make some future improvements. But I spent most of the time not in the code, that was so far quite quick, but finding the place where to make the changes (the kernel repo contains multiple instances of the driver, but only one, the most hidden, is being compiled) and hacking the build system not to delete my changes and to compile just the modules instead of the whole kernel (including re-download of everything), that was the real challenge… And missing developer documentation does not help either :-).
Improvements are still good, as we are using 4.9 media build drivers.
I assume your problems stem from the media build tarball. This will be removed in the next kernel and you have simply run in to being a victim of our aggressive backports to modernise 3.14.
The original media build and the new are compiled, with new modules in a backport directory.
How to submit the changes? As the files are tarred in the github repo, simple PR with diffs won’t make much sense. Should I do a PR for a patch file to the “backports” folder to be applied on top of the tar? Or a PR against the 4.9 kernel branch? Or both?
Should I try preparing a set of minimal changes which works for my HW to keep the risk of regressions low, or should I try backporting most of the em28xx driver from RPi source tree to add also other HW present there, but which I can’t test?
: