Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hauppauge WinTV-dualHD (Model 01595) Support #2091

Closed
wants to merge 7 commits into from

Conversation

philburr
Copy link

These patches add support for Hauppauge WinTV-dualHD dual tuner.

The first two patches are from the 4.11 tree. Both applied cleanly to 4.9. The remaining 5 patches are not in the mainline kernel tree. They add support for the second tuner. The patches originate from https://www.mail-archive.com/linux-media@vger.kernel.org/msg113120.html

I've tested receiving simultaneously from both tuners on my dualHD.

kkch3ng and others added 7 commits June 28, 2017 15:18
Adds an i2c mux to the lgdt3306a demodulator.  This was done to support
the Hauppauge WinTV-dualHD 01595 USB TV tuner (em28xx), which utilizes two
si2157 tuners behind gate control.

Signed-off-by: Kevin Cheng <kcheng@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Hauppauge WinTV-dualHD model 01595 is a USB 2.0 dual ATSC/QAM tuner with
the following components:

USB bridge: Empia em28274
Demodulator: 2x LG LGDT3306a at addresses 0xb2 and 0x1c
Tuner: 2x Silicon Labs si2157 at addresses 0xc0 and 0xc4

This patch enables only the first tuner.

Signed-off-by: Kevin Cheng <kcheng@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
@mi-hol
Copy link

mi-hol commented Jul 4, 2017

@philburr @qaweizoux in reply to initial request Hauppauge's Brad Love promised to upstream the patches.
I'd guess this would affect Linux 4.13 or later. Do you happen to know the status of his activity in this regard?

@popcornmix
Copy link
Collaborator

We will consider adding patches from upstream when there is demand and the risks seem low.
In general we are not keen on carrying patches that haven't been accepted upstream.
Keep up informed of the status of the second tuner patches. We are more likely to consider this if they have been accepted upstream.

@philburr
Copy link
Author

philburr commented Jul 4, 2017

Would it be preferable to break this into two pull requests? One for the initial tuner support from 4.11 and a second for the second tuner support when it lands upstream?

@popcornmix
Copy link
Collaborator

It would have a better chance of being merged.

@rkluwen
Copy link

rkluwen commented Oct 12, 2017

About the question if there's a demand: We are using this patch and are quite happy with it.

@djwesty
Copy link

djwesty commented Jan 4, 2018

Is there a guide on how I can apply this patch, being that it is not in the mainline kernel tree?
I have the ATSC/QAM Bulk model (2040:826d) for my pi, currently at 4.9.73.
I'd appreciate any advice on how to apply the patch to get at-least one of the tuners working!

@6by9
Copy link
Contributor

6by9 commented Jan 8, 2018

@djwesty Simplest approach is to follow https://www.raspberrypi.org/documentation/linux/kernel/building.md, but use
git clone --depth=10 https://github.com/philburr/linux
instead of
git clone --depth=1 https://github.com/raspberrypi/linux

If you have a small amount of git foo, follow the instructions as written and prove you can build a working kernel. Then in your kernel source tree:

git remote add philburr https://github.com/philburr/linux.git
git fetch philburr
git cherry-pick 40b97ef 2f083f0 bde05a9 fa22c49 6732652 0307dc6 37b5c4a

Hopefully it won't complain about any conflicts, so rebuild. The list of magic numbers in the cherry-pick are the commit IDs on philburr's tree, as can be read with git log --oneline phillburr/rpi-4.9.y.

@djwesty
Copy link

djwesty commented Jan 11, 2018

Thank you for your help @6by9

This worked perfectly, and I now have two DVB adapters showing up. Cheers

@6by9
Copy link
Contributor

6by9 commented Jan 14, 2018

Further movement upstream - https://www.spinics.net/lists/linux-media/msg127060.html
According to b-rad-NDi/Ubuntu-media-tree-kernel-builder#27 he's got clearance from his bosses, so hopefully patches will be merged to linux-media soon.

@b-rad-NDi
Copy link
Contributor

Hello everyone. Every Hauppauge device and all additional support required for their usage has been submitted upstream. It's up to the maintainers now :)

@6by9
Copy link
Contributor

6by9 commented Jan 20, 2018

Thanks @b-rad-NDi - quite an effort, so many thanks to you, and to your bosses for allowing you to.

Is that submitted to the list for review, or submitted into upstream trees? I'd seen a flurry of patches from you but can't see any recent merges on linuxtv.org, and the patches are flagged as new on https://patchwork.kernel.org/project/linux-media/list/

In any case I'll start making up a Pi 4.14 branch with them merged, and I do have a couple of WinTV-dualHD devices to try them with.

@b-rad-NDi
Copy link
Contributor

Only submitted for review so far, hoping for first pull request this weekend.

@6by9
Copy link
Contributor

6by9 commented Jan 20, 2018

Thanks for the confirmation - I'll keep an eye out for reviews.

@jussisallinen
Copy link

jussisallinen commented Jan 22, 2018

This is great news, just got myself a dualHD for Tvheadend use on Raspberry.

@6by9
Copy link
Contributor

6by9 commented Jan 23, 2018

https://github.com/6by9/linux/tree/rpi-4.14.y-hauppauge is the Pi 4.14 branch with most of Brad's patches applied, plus a couple of other minor dependencies from the linux-media tree. I dropped the patch set related to cx23885 as the Pi has no PCI/PCI-e slot and they weren't merging cleanly.

The branch builds, but I haven't tested it yet (I'll look at doing that tonight if I get a chance).
I suspect that there will only be a couple of modules changed, so it may be possible to just push those somewhere until the changes are merged.

@jussisallinen
Copy link

@6by9 If it runs don't hesitate to drop it to me for more testing if needed.
Don't have time to start setting up cross-compile environment at the moment.
You can reach me at jussi@jus.si.

@6by9
Copy link
Contributor

6by9 commented Jan 25, 2018

Still not had a chance to check this as yet, but here's a tarball of the ArmV7 (ie Pi2/3) kernel built from my rpi-4.14.y-hauppauge branch.
rpi-4.14.y-hauppauge.tar.gz
PLEASE DON'T USE THESE ON A CRITICAL PI! I take no responsibility if it requires a reinstall of your SD card. Files go in the fairly obvious places.

I'll try to run it later today, but things have been a little busy.
I guess we may want to pick up the USB fixes that have been kicking around recently too (see thread https://www.spinics.net/lists/linux-media/msg126274.html - a USB stack DoS workaround was impacting high throughput USB traffic such as DVB broadcasts and causing drops)

@6by9
Copy link
Contributor

6by9 commented Jan 25, 2018

Booting, and WinTV-DualHD detecting correctly.
I appear to have put the new kernel on a Jessie install instead of Stretch, but that's not a big deal.
I've built w_scan and tvheadend.
w_scan isn't picking up the one DVB-T2 mux we have here (UK Sandy Heath), but otherwise seems to do the right thing (100 services over 6 muxes - nothing on BBCB (T2), COM7 or COM8). I do need to check signal strength as I do get odd errors running them as single tuners on my Ubuntu 17.04 box (kernel 4.10.0-42-generic), but there tvheadend is getting 8 live muxes (it doesn't know about the local mux on 626MHz).

Running tvheadend is causing all sorts of errors (complains Error in `./build.linux/tvheadend': corrupted double-linked list: 0x71c004d0 on exit), and results in w_scan then tuning and claiming to get a signal, but "no data from PAT". I need to find a stable tag and rebuild.

@b-rad-NDi
Copy link
Contributor

I haven't submitted it for upstream review yet, but there is a patch in my repo which enables auto T/T2 detection. We have found this is required to get a lot of apps to pick up T2 signals.

@6by9
Copy link
Contributor

6by9 commented Jan 25, 2018

w_scan goes through the whole scan allegedly for both DVB-T and DVB-T2 independently.
tvheadend also supports both.

I've picked up patch https://github.com/b-rad-NDi/Ubuntu-media-tree-kernel-builder/blob/master/patches/mainline-extra/4.13.0/0021-si2168-Change-from-DVB-T-to-DVB-T-T2-autodetect.patch and will see what I get. I probably also ought to try the tuner with the original 4.14 kernel and see what that does on the one tuner.

I've checked the aerial feed on our Sony TV and that picks up 182 services, so whilst not necessarily the strongest of signals, the muxes are there.

@6by9
Copy link
Contributor

6by9 commented Jan 25, 2018

Reverting to the standard Pi 4.14 kernel (now 4.14.15), whilst I only get the one tuner, w_scan and tvheadend can both find all 8 muxes and seem to tune and stream happily.
I guess I'll need to merge the patches one at a time, and possibly take all the patches on linux_media and try them on my x86 box. Not sure when I'll get time to do all that.

@mrapathy
Copy link

Sorry to intrude. Are the x86 drivers specific to Ubuntu?
Got a Huappauge USB WintTV dual HD tuner 01595 that I would like to get working in Slackware. Everywhere I have looked patches or kernel seems to be for raspberry pi or Ubuntu. If I am wrong could someone point me out to kernel patch that will work with slackware x86.

@mrapathy
Copy link

thanks for the help.

I got to

git clone --depth=1 git://linuxtv.org/media_build.git cd media_build ./build --main-git

but I got error

make[3]: *** No rule to make target '/home/kmfdm/Downloads/media_build/v4l/frame_vector.c', needed by '/home/kmfdm/Downloads/media_build/v4l/frame_vector.o'. Stop. Makefile:1507: recipe for target '_module_/home/kmfdm/Downloads/media_build/v4l' failed make[2]: *** [_module_/home/kmfdm/Downloads/media_build/v4l] Error 2 make[2]: Leaving directory '/usr/src/linux-4.14.13' Makefile:51: recipe for target 'default' failed make[1]: *** [default] Error 2 make[1]: Leaving directory '/home/kmfdm/Downloads/media_build/v4l' Makefile:26: recipe for target 'all' failed make: *** [all] Error 2 build failed at ./build line 526

going to try the same on my laptop see if I get same results. Think I got bad source code from V4L.

@mrapathy
Copy link

mrapathy commented Feb 2, 2018

got media_build downloaded and installed though one part were the help request diverges with me is the raspberry pi. just using x86 system should have made that clear earlier.
found fix for frame_vector.c issue at the following site.
https://www.tbsdtv.com/forum/viewtopic.php?f=87&t=24789

thanks for the help though dont have my hauppauge usb tuner working yet though credit that to my effort and not your advice.

@mrapathy
Copy link

mrapathy commented Feb 12, 2018

Apologies, didnt originally notice the patchwork link. looks like what I need to get things going.

Thanks

juggling a bit much on my plate and have ADD.

installed [5/9] em28xx: Add Hauppauge SoloHD/DualHD bulk models patch on kernel 4.14.13 and it works.

@6by9
Copy link
Contributor

6by9 commented Mar 11, 2018

I've finally had a chance to bisect this. It looks like "si2168: Add ts bus coontrol, turn off bus on sleep" is the patch that causes the problems with the WinTV-dualHD.
I note there is a v2 for that patch at https://patchwork.kernel.org/patch/10214387/, but it looks identical to v1. I'll check the others when I get a chance.

I've rebased to 4.14.24 and added all the relevant patches + a revert of that one to https://github.com/6by9/linux/tree/rpi-4.14.y-hauppauge. That seems to be working OK for me at the moment based on a quick scan. (Add that patch and w_scan finds the mux, but can't find any services).

I see there has been no activity in upstream reviewing and merging those patches. I'll talk with others over whether we merge these ahead of them being merged upstream.

@b-rad-NDi
Copy link
Contributor

b-rad-NDi commented Mar 11, 2018

All patches in that particular series have been accepted.

@b-rad-NDi
Copy link
Contributor

v2 of the ts bus control patch works, v1 is missing enabling ts bus in set_frontend.

@6by9
Copy link
Contributor

6by9 commented Mar 11, 2018

Thanks @b-rad-NDi for the response. I obviously don't understand patchwork then as for example https://patchwork.kernel.org/patch/10214387/ is still flagged as new, but looking in media-tree I see they are there. I'll cherry-pick across and make a new PR.
Thanks for your help and efforts.

@b-rad-NDi
Copy link
Contributor

I was told patchwork underwent some sort of kerfluffle in January. Some of my v2 were skipped, so you'll want to grab my additional various fixes along with DualHD related 3f127ce.

@6by9
Copy link
Contributor

6by9 commented Mar 11, 2018

Thanks again. I'll grab straight out of git://linuxtv.org/media_tree.git master branch and see what happens :-)

@b-rad-NDi
Copy link
Contributor

b-rad-NDi commented Mar 12, 2018

Keep me in the loop if anything is abnormal, I think I have most flavours of rPi.

@jussisallinen
Copy link

@6by9 Great, finally we're making progress 👍

@alastaircoote
Copy link

Hi, I've been reading through this thread with interest, as I've just bought a RPi and a Hauppauge WinTV-soloHD (which seems to have the same chipset etc). Apologies for the newbie question, but I'm a little lost with the current state of affairs now that some things have been merged and others haven't. What steps would I now need to take in order to get my soloHD talking to the RPi? I tried rebuilding the kernel with https://github.com/philburr/linux as a source, but so far no dice.

@6by9
Copy link
Contributor

6by9 commented Mar 13, 2018

I've cherry-picked all the apparently applicable commits from the upstream linuxtv tree, and pushed them to https://github.com/6by9/linux/tree/rpi-4.14.y-hauppauge. It certainly seems to be tuning quite happily on my WinTV-dualHD, so I've created PR #2434.

@6by9
Copy link
Contributor

6by9 commented Mar 13, 2018

@alastaircoote I would have expected a SoloHD to work with the standard kernel, as long as you add the relevant firmware file to /lib/firmware/

https://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-soloHD says supported since 2015-11-19, and the commit text references dvb-demod-si2168-b40-01.fw as the firmware. You can find that at https://github.com/OpenELEC/dvb-firmware/blob/master/firmware/dvb-demod-si2168-b40-01.fw amongst many other places.

@alastaircoote
Copy link

@6by9 d'oh! It isn't working for me out of the box (with firmware downloaded) and I assumed it was related to this issue, but I should have looked closer! Sounds like my issue would be better discussed on a forum, so I'll take discussion there. Thanks!

@Eukanuba863
Copy link

Eukanuba863 commented Mar 14, 2018

Hi guys,

I was able to successfully patch the kernel by recompiling kernel and reinstalling it on the RPi with the instructions here. Thanks @6by9! & @b-rad-NDi!

Now I got a few questions...

  1. Is there a way to apply these patches without recompiling kernel?
  2. When is the expected release to the stable kernel in https://github.com/raspberrypi/linux?
  3. @6by9, how do I apply the https://github.com/6by9/linux/tree/rpi-4.14.y-hauppauge that you compiled on my sd card? Straight copy to blank card?

Even if you don't answer this, you guys are the bomb and are light years ahead on me on this stuff! I know eventually this'll hit the mainstream, but I do wish to learn your linux-jedi ways!

@Kazipallo
Copy link

One noobie here is trying to figure out how to get with least troubles my 2x dualHD working again. They have been working well >6 months non-stop in my libreelec htpc (v8.0.2). All 4 tuners were working like charm. They are both model 1590.

This libreelec was not supposed to get updated to newer version because in newer versions this dualHD have only 1 tuner/unit active. Something fishy with the drivers in the newer versions. My friend decided to do me a favor and upgrade the system. He did not know that there was a reason why it was the old version. Now 2xdualHD is 2xsoloHD and cannot go back from 8.2.4 to 8.0.2 without reinstalling all.

I decided to scrap the set and make a new infra. I put the system to VM of my NAS. What drivers (firmware) do I need to use to get dualHDs working again? At there moment in VM there is Linux Mint 18.3 with updates and upgrades. (Linux MintSylvia 4.10.0-38-generic #42~16.04.1-Ubuntu). I will upgrade it to 19 Tara when it is available.

There is a huge set of drivers in hauppage-linuxtv package but there must be easier way to do this. A year ago I tried Palosaari's drivers. Does that work with this kernel and those firmwares? (=.fw files to /lib/firmware) or is there some progress with these dualHDs and kernel?

Please tell what files to get and where to put. Please very detailed instructions. Otherwise I'm soooo out.

@6by9
Copy link
Contributor

6by9 commented Mar 26, 2018

@Eukanuba863

  1. No, there is no way to use these patches without recompiling the kernel (or at least significant chunks of it).
  2. I've just pinged the other relevant people over merging 4.14 Hauppauge DVB drivers #2434. Once merged then they'll appear in the next rpi-update build, or LibreElec tends to make very regular builds from the top of the tree.
  3. Installing to your SD card - for Raspbian see https://www.raspberrypi.org/documentation/linux/kernel/building.md

@6by9
Copy link
Contributor

6by9 commented Mar 26, 2018

@Kazipallo What system are you building for? This is a Raspberry Pi repository - whilst it may be possible to apply patches from here elsewhere, we aren't going to be giving support on VM's on random NAS boxes.

I'm not 100% certain where you got a kernel that supported both tuners of the dualHD anyway - AFAIK the patches I'm pulling in will be first released in probably 4.17 (they've missed the 4.16 merge window). Unless you were using Brad's out-of-tree patches before - https://github.com/b-rad-NDi/Ubuntu-media-tree-kernel-builder

@Eukanuba863
Copy link

@6by9 You are a baller boss! Thanks for the quick response! Everything you suggested worked!

How will I know when the #2434 will be incorporated?

@6by9
Copy link
Contributor

6by9 commented Mar 27, 2018

How will I know when the #2434 will be incorporated?

There's a subscribe button on the right hand side. Subscribe if you want to get updates.
I'm currently having a few issues with tvheadend not tuning that I need to track down before it'll get merged.

@chilliwebs
Copy link

Thank you @6by9! & @b-rad-NDi! and anyone else for your hard work on this. so far is working flawlessly (for rpi-3):

git clone -b rpi-4.14.y-hauppauge --depth=10 https://github.com/6by9/linux
cd linux
KERNEL=kernel7
make bcm2709_defconfig
make -j4 zImage modules dtbs
sudo make modules_install
sudo cp arch/arm/boot/dts/.dtb /boot/
sudo cp arch/arm/boot/dts/overlays/
.dtb* /boot/overlays/
sudo cp arch/arm/boot/dts/overlays/README /boot/overlays/
sudo cp arch/arm/boot/zImage /boot/$KERNEL.img
sudo reboot

and after reboot i can see:

dmesg | grep -i Hauppauge
[ 4.995260] em28xx 1-1.5:1.0: Identified as Hauppauge WinTV-dualHD 01595 ATSC/QAM (card=100)
[ 5.000236] tveeprom: Hauppauge model 204101, rev B2I6, serial# 13838644
[ 6.305260] em28xx 1-1.5:1.0: Identified as Hauppauge WinTV-dualHD 01595 ATSC/QAM (card=100)
[ 6.310091] tveeprom: Hauppauge model 204101, rev B2I6, serial# 13838644
[ 6.646243] Registered IR keymap rc-hauppauge

I have never built a kernel before but this worked perfectly! THANK YOU! :)

@Kazipallo
Copy link

@6by9 I am building DVR. I know this is raspberry repository. I previously tried also with my Pi3B to get dual-dualHD setup working but no. Therefore I ended up here. I have couple pi3Bs and was wondering to set one of them or use this NAS based VM. Latter seems to be better. 4 tuners with DVB-T2 gives raspy a hefty load to carry. I know that you are not supporting random setups but was just wandering that there could be one to assist a bit. If even Sir Brad could have commented but I am happy with this.

That kernel supporting both tuners was built in as default in Libreelec v8.0.2. And in that version only. Ask libreelec ppl more about it. I can't recall did I add Palosaari's firmwares there too or not. Maybe yes. The setup with dual-dualHD was rock solid and running non-stop for 200+ days with 1000+ recordings. I was very pleased with that one. Libeelec do not support virtualization and therefore was trying now something else.

I installed Brads Linux repos and stuff according to instructions at Hauppauges official pages. 2xdualHD = 4 tuners working in VM. But it was a heavy package with all kinds of stuff. My hope was to go with a light and easy way but guess it is not possible right now. Have to it the hard way.

Can't wait to try my pi3B with dualHDs. If I can help you with your efforts with Pi I will do that. Like I said I have 2xdualHD (v1590) setup here to try out.

@Eukanuba863
Copy link

@6by9 Any progress on getting merged?

@6by9
Copy link
Contributor

6by9 commented Apr 25, 2018

Sorry, not been a priority.
Two things that could be done.

  1. Reduce the list of commits to be merged to not include 2f2244c or later. That should get the dual tuners working and the rest can be looked at later.
  2. Check with the media_build tree to see whether the upstream media tree is happy. If it is then there must be something silly wrong with my cherry-pick.

@jussisallinen
Copy link

@6by9 Got time to work on this in the near future?

@6by9
Copy link
Contributor

6by9 commented Jul 6, 2018

I'm working from home for a couple of days next week so will have access to an aerial during working hours. I'll see if I can find some time to pick this back up again.

@6by9
Copy link
Contributor

6by9 commented Nov 6, 2018

4.19 is available via BRANCH=next rpi-update and appears to work with the WinTV-dualHD. I've had tvheadend scanning two muxes simultaneously through it.

Hopefully switching to 4.19 as the standard kernel won't be far off, so I'd propose we close this PR (actually to 4.9!) and advise people to use 4.19. I've already closed #2434 for merging the patches into 4.14.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.