Problems with PVR 250 and MythTV

[Vadim Mikhailov]

Greg 'groggy' Lehey wrote:
> On Wednesday, 28 February 2007 at  0:38:33 -0800, Vadim Mikhailov wrote:
>   
>>   Few months ago I decided to stop fighting windmills and converted
>> FreeBSD MythTV box to Linux, and boy, how much better experience it is!
>> Everything just works out of the box 
>>     
> It's interesting that I've had pretty much the opposite experience.
> Sure, I still don't have MythTV working on FreeBSD, but I spent months
> in vain trying to get it to work on Linux.  And my draft HOWTO for
> FreeBSD is only half the size of the one for Linux.
>   
  It was easier because I did not compile MythTV from source on Linux.
I've just installed FC5 (I guess today FC6 or F7 would be better idea),
configured it to use atrpms repository, and then I just ran "yum install
mythtv-suite". Whole process took less than 2 hours - everything was
properly detected (tuner, remote, video card).
Most of the time was spent configuring X11 and MythTV settings. For
how-to I mostly relied on http://wilsonet.com/mythtv/fcmyth.php.

>> tuner appears to get much better picture - I have no idea why.
>>     
> I get almost as good a picture from the PVR 250 under FreeBSD as I do
> from a DVB-T card under Linux.  If there's any difference, I'd
> attribute it to the different transmission format.
  I've had a problem with cxm that no matter how much memory machine had
(512MB or 1GB), during LiveTV recording FreeBSD disk buffers were almost
always exhausted (free memory quickly went to 10MB or less) and  picture
started stuttering a lot. Linux's ivtv driver (for PVR-150/250/350/500)
does not exhibit this problem.
  Also I couldn't get Nvidia's XvMC to work on FreeBSD. On Linux it
works out of the box,which helps to drop CPU utilization from 99% to 13%
(my CPU is P4 2.4GHz) on my 1920x1080p TV.
Another nice Linux perk is XFS filesystem. It means that no matter what
file system size is (mine is almost 1TB), I never have to wait for fsck
on reboot.
With FreeBSD/UFS I had to wait long time for fsck to finish on my big
RAID drive should anything bad to happen or if I had to hit power button.
BTW, I am wondering what happened with efforts to fully port XFS to FreeBSD?

>   There's only one
> thing I've seen which puzzles me: sometimes the brightness levels
> fluctuate over a period of 10-20 seconds, rather like the results of
> trying to copy macrovision-protected VHS tapes (but not as bad).  Has
> anybody seen anything like this?
>   
Did not see anything like this on FreeBSD.

>> Talking about REAL fix for PVR350 remote: I believe the only good
>> solution to this is to enhance cxm kernel driver to create another
>> device like /dev/cxmr0 (in addition to /dev/cxm0) for remote
>> control, so select() on it could be used by LIRC and avoid polling.
>>     
> I haven't looked at your patch, but I think that the remote control
> should be handled by LIRC, not by the cxm driver.  Well, not by the
> cxm driver.  I'd like to see better remote control software than LIRC.
>
> How is the remote control supported in Linux?
>   
  On Linux it works like this: LIRC always needs to have some device to
talk to in /dev. For some simple IR devices it could be /dev/tty1 or
something l(basically COM port),
for others kernel driver is required. Such kernel driver is supposed to
maintain virtual /dev/lirc0 or something like that. For simplicity
typically symlink /dev/lirc is created pointing to actual remote low
level kernel device.
  On LIRC side there is also user-mode driver, which talks to /dev/lirc.
LIRC open()'s it, then uses select() to await for any button pushes or
other events.
When select() fires, it read()'s from /dev/lirc and parses whatever
happened with remote, translating it to friendly button codes. Button
layout is typically described in /etc/lircrc - it helps LIRC to perform
actual mapping.
LIRC's lircd daemon creates socket /dev/lircd, which is supposed to be
used by client programs (like MythTV) to get button events.

In our specific case of PVR-350, on Linux there is kernel driver called
lirc_i2c. This driver probes IR chip on PVR-350 and creates /dev/lirc
for it. LIRC talks to this /dev/lirc to do whatever was described above.

So, what I am proposing - improve cxm driver to do the same job as Linux
lirc_i2c kernel driver does - to create /dev/lirc (or /dev/cxmr0 or
whatever).
Once this is done, creating LIRC user-mode driver for it is piece of cake.

Today, you can easily get PVR-350 remote events using code like this:

struct bktr_remote r;
int dev = open("/dev/cxm0", O_RDONLY);
ioctl(REMOTE_GETKEY, &r);

and r will contain some information about pressed button. In other
words, a low level code which knows how to talk to hardware IR chip is
already implemented inside cxm driver - it just needs to be exposed out
of kernel using a more LIRC-suitable way. LIRC basically requires remote
device to provide select() and read() to properly operate, and cannot
use /dev/cxm0 because cxm's read() and select() are reserved for video
streaming.
My patch bypassed select() requirement by using polling each 0.1 sec or
something, but this goes against overall LIRC architecture.

  Hope that helps.

Vadim Mikhailov