KWorld UB435-Q support?

I stupidly bought the KWorld UB435-Q usb ATSC tuner thinking it was supported under linux, and it turns out it isn't. I'm wondering what it would take to get it supported. It seems like all of the main chips it uses are supported, but the glue code is missing.

I have some C (10 years) programming experience, and have wanted to contribute to the linux kernel for quite a while, now I have a good excuse ;)

Would anyone be willing to point me in the right direction?

Quoted 8 lines · Thomas Fjellstrom

I stupidly bought the KWorld UB435-Q usb ATSC tuner thinking it was supported
under linux, and it turns out it isn't. I'm wondering what it would take to
get it supported. It seems like all of the main chips it uses are supported,
but the glue code is missing.

Quoted 5 lines

I have some C (10 years) programming experience, and have wanted to contribute
to the linux kernel for quite a while, now I have a good excuse ;)

Would anyone be willing to point me in the right direction?

The UB435-Q is a rebadge of the revision B 340U, which is an em2870 bridge, lgdt3304 demodulator and an nxp tda18271hd/c2 tuner. Its got the same device ID and everything. I've got a rev A 340U, the only difference being that it has an nxp tda18271hd/c1 tuner (also same device ID). I *had* it working just fine until the stick up and died on me, before I could push the code for merge, but its still floating about. It wasn't quite working with a c2 device, but that could have been a device problem (these are quite franky, cheap and poorly made devices, imo). It could also be that the code ate both sticks and will pickle yours as well.

With that caveat emptor, here's where the tree that should at least get you 95% of the way there with that stick resides:

http://www.kernellabs.com/hg/~mkrufky/lgdt3304-3/

The last two patches are the relevant ones. They add lgdt3304 demod support to the lgdt3305 driver (because the current lgdt3304 driver is, um, lacking) and then add the bits to wire up the stick.

Quoted 26 lines · Jarod Wilson

Quoted 8 lines · Thomas Fjellstrom

I stupidly bought the KWorld UB435-Q usb ATSC tuner thinking it was supported
under linux, and it turns out it isn't. I'm wondering what it would take to
get it supported. It seems like all of the main chips it uses are supported,
but the glue code is missing.

Quoted 5 lines

I have some C (10 years) programming experience, and have wanted to contribute
to the linux kernel for quite a while, now I have a good excuse ;)

Would anyone be willing to point me in the right direction?

The UB435-Q is a rebadge of the revision B 340U, which is an em2870 bridge, lgdt3304 demodulator and an nxp tda18271hd/c2 tuner. Its got the same device ID and everything. I've got a rev A 340U, the only difference being that it has an nxp tda18271hd/c1 tuner (also same device ID). I *had* it working just fine until the stick up and died on me, before I could push the code for merge, but its still floating about. It wasn't quite working with a c2 device, but that could have been a device problem (these are quite franky, cheap and poorly made devices, imo). It could also be that the code ate both sticks and will pickle yours as well.

Quoted 8 lines

With that caveat emptor, here's where the tree that should at least get you 95% of the way there with that stick resides:

http://www.kernellabs.com/hg/~mkrufky/lgdt3304-3/

The last two patches are the relevant ones. They add lgdt3304 demod support to the lgdt3305 driver (because the current lgdt3304 driver is, um, lacking) and then add the bits to wire up the stick.

Hi, thanks for the tips. I've applied the last two patches to v4l "tip", a few hunks failed, but I managed to apply them by hand, though possibly not correctly as I can't seem to find a program that thinks the /dev/video0 device that pops up is valid. One app claims there is no input on /dev/video0, and others just get "select timeouts" and such (also errors regarding formats and whatnot).

Quoted 37 lines · Thomas Fjellstrom

Quoted 27 lines · Jarod Wilson

Quoted 8 lines · Thomas Fjellstrom

I stupidly bought the KWorld UB435-Q usb ATSC tuner thinking it was supported
under linux, and it turns out it isn't. I'm wondering what it would take to
get it supported. It seems like all of the main chips it uses are supported,
but the glue code is missing.

Quoted 5 lines

I have some C (10 years) programming experience, and have wanted to contribute
to the linux kernel for quite a while, now I have a good excuse ;)

Would anyone be willing to point me in the right direction?

The UB435-Q is a rebadge of the revision B 340U, which is an em2870 bridge, lgdt3304 demodulator and an nxp tda18271hd/c2 tuner. Its got the same device ID and everything. I've got a rev A 340U, the only difference being that it has an nxp tda18271hd/c1 tuner (also same device ID). I *had* it working just fine until the stick up and died on me, before I could push the code for merge, but its still floating about. It wasn't quite working with a c2 device, but that could have been a device problem (these are quite franky, cheap and poorly made devices, imo). It could also be that the code ate both sticks and will
pickle yours as well.

Quoted 8 lines

With that caveat emptor, here's where the tree that should at least get you 95% of the way there with that stick resides:

http://www.kernellabs.com/hg/~mkrufky/lgdt3304-3/

The last two patches are the relevant ones. They add lgdt3304 demod support to the lgdt3305 driver (because the current lgdt3304 driver is, um, lacking) and then add the bits to wire up the stick.

Quoted 10 lines

Hi, thanks for the tips. I've applied the last two patches to v4l "tip", a few
hunks failed, but I managed to apply them by hand, though possibly not correctly as I can't seem to find a program that thinks the /dev/ video0 device
that pops up is valid. One app claims there is no input on /dev/ video0, and
others just get "select timeouts" and such (also errors regarding formats and
whatnot).

These sticks are digital-only. Its a driver shortcoming that the *analog* /dev/video0 device is being created. You need to be hitting / dev/dvb/adapterX/*, not /dev/video0. See
http://linuxtv.org/wiki/index.php/Testing_your_DVB_device

Quoted 49 lines · Jarod Wilson

Quoted 37 lines · Thomas Fjellstrom

Quoted 27 lines · Jarod Wilson

Quoted 8 lines · Thomas Fjellstrom

I stupidly bought the KWorld UB435-Q usb ATSC tuner thinking it was supported
under linux, and it turns out it isn't. I'm wondering what it would take to
get it supported. It seems like all of the main chips it uses are supported,
but the glue code is missing.

Quoted 5 lines

I have some C (10 years) programming experience, and have wanted to contribute
to the linux kernel for quite a while, now I have a good excuse ;)

Would anyone be willing to point me in the right direction?

The UB435-Q is a rebadge of the revision B 340U, which is an em2870 bridge, lgdt3304 demodulator and an nxp tda18271hd/c2 tuner. Its got the same device ID and everything. I've got a rev A 340U, the only difference being that it has an nxp tda18271hd/c1 tuner (also same device ID). I *had* it working just fine until the stick up and died on me, before I could push the code for merge, but its still floating about. It wasn't quite working with a c2 device, but that could have been a device problem (these are quite franky, cheap and poorly made devices, imo). It could also be that the code ate both sticks and will
pickle yours as well.

Quoted 8 lines

With that caveat emptor, here's where the tree that should at least get you 95% of the way there with that stick resides:

http://www.kernellabs.com/hg/~mkrufky/lgdt3304-3/

The last two patches are the relevant ones. They add lgdt3304 demod support to the lgdt3305 driver (because the current lgdt3304 driver is, um, lacking) and then add the bits to wire up the stick.

Quoted 10 lines

Hi, thanks for the tips. I've applied the last two patches to v4l "tip", a few
hunks failed, but I managed to apply them by hand, though possibly not correctly as I can't seem to find a program that thinks the /dev/ video0 device
that pops up is valid. One app claims there is no input on /dev/ video0, and
others just get "select timeouts" and such (also errors regarding formats and
whatnot).

Quoted 4 lines

These sticks are digital-only. Its a driver shortcoming that the *analog* /dev/video0 device is being created. You need to be hitting / dev/dvb/adapterX/*, not /dev/video0. See
http://linuxtv.org/wiki/index.php/Testing_your_DVB_device

Ah, thanks for that.

So far I've noticed the lgdt driver is very NOT robust, or maybe its one of the other drivers (em28xx?) causing it to die, but if the stick looses connection with usb at all, the driver locks up, spews a BUNCH of errors to dmesg, and eventually the kernel complains:

[  840.552148] INFO: task khubd:170 blocked for more than 120 seconds.
[  840.552155] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables
this message.
[  840.552162] khubd         D ffff8800010220c0     0   170      2
[  840.552172]  ffff88003793a500 0000000000000046 ffff88007bd2f600
0000000000000286
[  840.552182]  ffff88007a011900 00000000000120c0 000000000000e250
ffff88007d13a3c0
[  840.552191]  ffff88007d13a6b0 000000008034e421 ffff88007bd3d800
ffffffffa046a7c8
[  840.552200] Call Trace:
[  840.552220]  [<ffffffff804b4810>] ? schedule+0x9/0x1d
[  840.552243]  [<ffffffffa046d9ce>] ? dvb_dmxdev_release+0xd8/0x119
[dvb_core]
[  840.552253]  [<ffffffff80254736>] ? autoremove_wake_function 
+0x0/0x2e
[  840.552265]  [<ffffffffa00dd06e>] ? dvb_fini+0x5b/0x91 [em28xx_dvb]
[  840.552289]  [<ffffffffa045b099>] ? em28xx_close_extension 
+0x35/0x56
[em28xx]
[  840.552308]  [<ffffffffa0459654>] ? em28xx_usb_disconnect 
+0xf4/0x120
[em28xx]
[  840.552319]  [<ffffffff803e3628>] ? usb_unbind_interface+0x5b/0xe1
[  840.552329]  [<ffffffff803d2618>] ? __device_release_driver 
+0x77/0x9e
[  840.552336]  [<ffffffff803d26f7>] ? device_release_driver+0x1e/0x2a
[  840.552344]  [<ffffffff803d1d7d>] ? bus_remove_device+0x8d/0xac
[  840.552352]  [<ffffffff803d07ad>] ? device_del+0x130/0x198
[  840.552359]  [<ffffffff803e0d91>] ? usb_disable_device+0x6c/0xe4
[  840.552370]  [<ffffffff803dc9f4>] ? usb_disconnect+0x8c/0x10a
[  840.552378]  [<ffffffff803dd9a1>] ? hub_thread+0x625/0x1040
[  840.552387]  [<ffffffff80235f65>] ? dequeue_entity+0xf/0x11f
[  840.552395]  [<ffffffff80254736>] ? autoremove_wake_function 
+0x0/0x2e
[  840.552403]  [<ffffffff803dd37c>] ? hub_thread+0x0/0x1040
[  840.552410]  [<ffffffff803dd37c>] ? hub_thread+0x0/0x1040
[  840.552418]  [<ffffffff803dd37c>] ? hub_thread+0x0/0x1040
[  840.552427]  [<ffffffff8025437a>] ? kthread+0x54/0x80
[  840.552435]  [<ffffffff80210aca>] ? child_rip+0xa/0x20
[  840.552444]  [<ffffffff80254326>] ? kthread+0x0/0x80
[  840.552450]  [<ffffffff80210ac0>] ? child_rip+0x0/0x20

I'm assuming the only way to restore any kind of function is to reboot (rmmoding em28xx_dbv hangs, and rmmod is unkillable).

I'll try working with this a bit more tomorrow (if I can figure out why its hanging), as it is I'm off for some sleep :)

Quoted 118 lines · Thomas Fjellstrom

Quoted 58 lines · Jarod Wilson

Quoted 45 lines · Thomas Fjellstrom

Quoted 35 lines · Jarod Wilson

Quoted 10 lines · Thomas Fjellstrom

I stupidly bought the KWorld UB435-Q usb ATSC tuner thinking it was
supported
under linux, and it turns out it isn't. I'm wondering what it would
take to
get it supported. It seems like all of the main chips it uses are supported,
but the glue code is missing.

Quoted 6 lines

I have some C (10 years) programming experience, and have wanted to
contribute
to the linux kernel for quite a while, now I have a good excuse ;)

Would anyone be willing to point me in the right direction?

The UB435-Q is a rebadge of the revision B 340U, which is an em2870 bridge, lgdt3304 demodulator and an nxp tda18271hd/c2 tuner. Its got
the same device ID and everything. I've got a rev A 340U, the only difference being that it has an nxp tda18271hd/c1 tuner (also same device ID). I *had* it working just fine until the stick up and died
on me, before I could push the code for merge, but its still floating
about. It wasn't quite working with a c2 device, but that could have
been a device problem (these are quite franky, cheap and poorly made
devices, imo). It could also be that the code ate both sticks and will
pickle yours as well.

Quoted 8 lines

With that caveat emptor, here's where the tree that should at least get you 95% of the way there with that stick resides:

http://www.kernellabs.com/hg/~mkrufky/lgdt3304-3/

The last two patches are the relevant ones. They add lgdt3304 demod support to the lgdt3305 driver (because the current lgdt3304 driver is, um, lacking) and then add the bits to wire up the stick.

Quoted 11 lines

Hi, thanks for the tips. I've applied the last two patches to v4l "tip", a few
hunks failed, but I managed to apply them by hand, though possibly not
correctly as I can't seem to find a program that thinks the /dev/ video0 device
that pops up is valid. One app claims there is no input on /dev/ video0, and
others just get "select timeouts" and such (also errors regarding formats and
whatnot).

Quoted 5 lines

These sticks are digital-only. Its a driver shortcoming that the *analog* /dev/video0 device is being created. You need to be hitting /
dev/dvb/adapterX/*, not /dev/video0. See
http://linuxtv.org/wiki/index.php/Testing_your_DVB_device

Ah, thanks for that.

So far I've noticed the lgdt driver is very NOT robust, or maybe its one of
the other drivers (em28xx?) causing it to die, but if the stick looses connection with usb at all, the driver locks up, spews a BUNCH of errors to
dmesg, and eventually the kernel complains:

[  840.552148] INFO: task khubd:170 blocked for more than 120 seconds.
[  840.552155] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables
this message.
[  840.552162] khubd         D ffff8800010220c0     0   170      2
[  840.552172]  ffff88003793a500 0000000000000046 ffff88007bd2f600
0000000000000286
[  840.552182]  ffff88007a011900 00000000000120c0 000000000000e250
ffff88007d13a3c0
[  840.552191]  ffff88007d13a6b0 000000008034e421 ffff88007bd3d800
ffffffffa046a7c8
[  840.552200] Call Trace:
[  840.552220]  [<ffffffff804b4810>] ? schedule+0x9/0x1d
[  840.552243]  [<ffffffffa046d9ce>] ? dvb_dmxdev_release+0xd8/0x119
[dvb_core]
[  840.552253]  [<ffffffff80254736>] ? autoremove_wake_function
+0x0/0x2e
[  840.552265]  [<ffffffffa00dd06e>] ? dvb_fini+0x5b/0x91 [em28xx_dvb]
[  840.552289]  [<ffffffffa045b099>] ? em28xx_close_extension
+0x35/0x56
[em28xx]
[  840.552308]  [<ffffffffa0459654>] ? em28xx_usb_disconnect
+0xf4/0x120
[em28xx]
[  840.552319]  [<ffffffff803e3628>] ? usb_unbind_interface+0x5b/0xe1
[  840.552329]  [<ffffffff803d2618>] ? __device_release_driver
+0x77/0x9e
[  840.552336]  [<ffffffff803d26f7>] ? device_release_driver+0x1e/0x2a
[  840.552344]  [<ffffffff803d1d7d>] ? bus_remove_device+0x8d/0xac
[  840.552352]  [<ffffffff803d07ad>] ? device_del+0x130/0x198
[  840.552359]  [<ffffffff803e0d91>] ? usb_disable_device+0x6c/0xe4
[  840.552370]  [<ffffffff803dc9f4>] ? usb_disconnect+0x8c/0x10a
[  840.552378]  [<ffffffff803dd9a1>] ? hub_thread+0x625/0x1040
[  840.552387]  [<ffffffff80235f65>] ? dequeue_entity+0xf/0x11f
[  840.552395]  [<ffffffff80254736>] ? autoremove_wake_function
+0x0/0x2e
[  840.552403]  [<ffffffff803dd37c>] ? hub_thread+0x0/0x1040
[  840.552410]  [<ffffffff803dd37c>] ? hub_thread+0x0/0x1040
[  840.552418]  [<ffffffff803dd37c>] ? hub_thread+0x0/0x1040
[  840.552427]  [<ffffffff8025437a>] ? kthread+0x54/0x80
[  840.552435]  [<ffffffff80210aca>] ? child_rip+0xa/0x20
[  840.552444]  [<ffffffff80254326>] ? kthread+0x0/0x80
[  840.552450]  [<ffffffff80210ac0>] ? child_rip+0x0/0x20

Quoted 6 lines

I'm assuming the only way to restore any kind of function is to reboot (rmmoding em28xx_dbv hangs, and rmmod is unkillable).

I'll try working with this a bit more tomorrow (if I can figure out why its
hanging), as it is I'm off for some sleep :)

Huh, that looks nothing like anything I ever saw with my stick. However, I will note that mine seemed to have major issues keeping a solid physical connection to the usb bus, but it only manifested as huge amounts of packet loss. These are cheaply made devices that I have little faith in now...

Yeah, I've had absolutely no luck with it so far, and have returned it :( given your experience, and mine combined, I don't think its worth the time to fix it. Especially since I can't even tune a channel on the darn thing in any OS I have access to.

It did indeed have trouble keeping a connection, but when ever it lost connection, I got that message. And the driver is pretty much stuck. can't rmmod it, and it won't redetect the stick, so every single time it looses connection, I have to reboot. Hardly a good way to work.

Quoted 7 lines · Thomas Fjellstrom

Yeah, I've had absolutely no luck with it so far, and have returned it :(
given your experience, and mine combined, I don't think its worth the time to
fix it. Especially since I can't even tune a channel on the darn thing in any
OS I have access to.

Now, did you try it with some other OS before trying it under Linux, and it failed to work, or did you only try other OS after trying under Linux w/that tree? There's some concern that perhaps the stick might be getting neutered on the Linux side by an incorrect gpio setting or something... But my stick worked (flaky usb connection aside) for quite some time before it stopped working, even with lots of unplugging and replugging over several days while working on the driver...

Quoted 6 lines

It did indeed have trouble keeping a connection, but when ever it lost connection, I got that message. And the driver is pretty much stuck. can't
rmmod it, and it won't redetect the stick, so every single time it looses
connection, I have to reboot. Hardly a good way to work.

Indeed. I wonder if there are bad solder joints in these, or what?... Mine's dead, yours is dead, Mike Krufky had to RMA his first one and his second one seems it might be dead too... :\