Re: KWorld UB435-Q support?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri August 14 2009, Jarod Wilson wrote:
> On Aug 14, 2009, at 1:12 AM, Thomas Fjellstrom wrote:
> > On Thu August 13 2009, Jarod Wilson wrote:
> >> On Aug 13, 2009, at 12:53 AM, Thomas Fjellstrom wrote:
> >>> 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?
> >>
> >> 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.
> >
> > 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

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 :)

-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux