[mythtv-users] HD-PVR2 support (please vote)

[Devin Heitmueller]

Devin here from Kernel Labs.  I'm travelling this weekend and Monday,
but will try to answer questions when I have reasonably reliable
Internet access (which is proving more of a problem than expected).
:-)

On Sun, Aug 9, 2015 at 6:16 PM, Gary Buhrmaster
<gary.buhrmaster at gmail.com> wrote:
> On Sun, Aug 9, 2015 at 8:45 PM, John P Poet <jppoet at gmail.com> wrote:
> ....
>> For Devin to commit to this work, he would need to see enough interest to
>> make it worth while.  How many of you would like to see robust support for
>> the HD-PVR2 and improved support for other V4L2 devices?
>
> I have no personal interest (my MSO is mostly copy freely), but I
> might be interested in providing some (limited) funding for the good
> of the community (and in an ideal world, everyone who uses MythTV
> would considering doing so too even if they would not personally
> benefit).  However, I am going to presume that the kernel code to
> support the HD-PVR2 is not going to be able to be merged into
> the LinuxTV core (and eventually the mainstream kernel), and
> that likely means that it will have the usual kernel variant build
> issues.  Is that correct?  Is the proposed solution a binary blob
> for specific kernels (i.e. you must run RHEL kernel 3.x), or using
> an interposer library (ala nvidia), or something like source distribution
> with dkms?  I am guessing not the later (since the IP is the source),
> but there might even be a fourth way I have no considered.  The
> method of license management might also be of concern.

The thinking at this point would be to do the driver entirely in
userland (i.e. libusb), and leverage John Poet's relatively recent
work on the ExternalRecorder facility in Myth 0.28.  It's pretty clear
that the framework he's put into that initiative is good stuff, but
would definitely need to be extended to provide a good user experience
for the use cases we care about (exposing some of the same controls in
mythtv-setup that users have become accustomed to in configuring the
HDPVR1 - things like input selection and bitrate controls).

Doing a userland-only approach has both benefits and drawbacks, and I
continue to weight the merits of each.  While we can argue the
statements below, this is my "thinking out load" at this point:

Userland - pros
 - No dependencies on kernel frameworks, which for anybody who has
actually used a V4L2/DVB driver for more than a few releases, are well
aware that they tend to be a moving target.  For some tuners I can
flip a coin and guess whether it will work after any given kernel
release.  With my history as a kernel developer working on LinuxTV
drivers over the years, that is an incredibly frustrating assertion to
make - but it's the truth.
 - No need to rebuild the driver with every new kernel release (am I
the only one who has had DKMS drivers for Nvidia and/or Broadcom
wireless fail to build after a kernel update, leaving my system
broken?)
 - No need to continuously adjust the code as the kernel changes.  We
would provide a binary, and it would continue to work across kernel
updates.  The kernel ABIs used by libusb are *far* more stable than
what we've seen in v4l-dvb over the years.
 - No GPL ambiguity/issues.  While there are plenty of people who have
strong feelings on both sides of the "Closed source binary modules"
question, doing a solution that doesn't involve any kernel drivers
avoids the question entirely.

Userland - cons
 - It's not *really* a V4L2 driver, and thus can't simply pretend to
be an HDPVR1
 - It will require me to explicitly add support to MythTV for the
device (rather than simply treating it as another HDPVR, IVTV, or
other V4L2 device).
 - The driver won't really work for other applications that already
have support for V4L2 devices.  This probably isn't really applicable
to MythTV users who don't use a bunch of other V4L2 applications, but
somebody might operate under the expectation that if they get a driver
that it would work with VLC, gStreamer, mplayer, tvheadend, insert
other application name here...
 - It would likely be exclusively targeted at x86/x86_64.

Note:  I'm really not trying to start a flame war with the above
statements.  Let's try to stay focused on how to have a productive
conversation on whether there is sufficient interest in HDPVR2 support
for a commercial party to spend the time/effort providing it.

> Based on past proof by example (and their likely demanding
> commercial audience), I have no doubt the kernellabs drivers
> are quite good.

We take pride in our work, and our customers are generally very
satisfied.  It's probably also worth noting that for the HDPVR2 this
would be the same code we've been shipping in HDPVRCapture on OSX for
several years now, which has a userbase that is probably several
orders of magnitude larger than MythTV.  While we would obviously be
adding code to Myth an extending its frameworks to best support the
device, the driver code itself won't be a new undertaking, and would
benefit from having been already deployed widely across a large number
of environments.

> But I had to admit to having a lot of doubt that the community
> will be able to step up to provide the needed funding (writing
> and maintaining code costs money).  I am hoping I am
> completely and utterly wrong about this.

I share your concerns, which is really I think what prompted John to
pose the question to the community (John, thanks for taking the time
to do such, btw).  Let's face it - if there are fifty guys in the
whole world using MythTV with their HDPVR and who would consider
upgrading to the HDPVR2, then this initiative would be a waste of
time.  Without any objective measures though for how large the user
base is, how many of them are using HDPVRs, what percentage of them
might consider upgrading to an HDPVR2, and what subset of those would
actually pay some actual money for software that would allow them to
do such, it's hard to gauge how much time/effort this is worth.  We've
seen the smolt numbers, and I'm hoping to find out the user base is
considerably larger than that.

As a long time contributor and user of MythTV/Linux, it frustrates me
to see that even in 2015 the only HD capture device supported is the
original HDPVR.  It would great to see a much more modern piece of
hardware working, and for me it's largely just a question of whether
we can make that happen while not taking a huge loss on the
engineering and integration required, and not creating a huge headache
for tech support (e.g. "I'm running Gentoo with a modified 2.6.23
kernel and Myth 0.21 and I've bought your HDPVR2 driver - make it work
in my environment or give me a full refund and personal apology!") .

Devin

-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com