PVR-150 on 6-STABLE: success and mini HOWTO

[User Mat]

On Dec 20, usleepless at gmail.com wrote:
> Hi Danny, Mat,
> 
> ...
> 
> as the author of the pvrxxx version of the pvr250 driver, i have been
> reading along.

    Did you see the my patch in the previous message to get pvrxxx to
    compile on -current?

> 
> Danny, thanks for your mini howto, and it is nice to read it was
> pretty straightforward for you.
> 
> i noticed a couple of things:
> 
> 1. some version of mythtv fails to probe the inputs. this needs to be
> investigated: there is a problem with the v4l(2)-header-files, or the
> v4l(2) api actually changed ( i seem to recall something about his ).
> i would like to know the exact version of mythtv which fails to probe
> the inputs.

     mythtv-0.20.2.tar.bz2 built outside of the ports tree with a few
     patches from the port and one or two local hacks.

     It's the probing and setting of inputs that failing.  The
     following log snippets are from mythtv after I faked out some
     routine that matches probed inputs to the values in database --
     before the hack, it could read the names so it returned 0 avail
     inputs thus not capture.

from mythbackend

2007-12-20 17:55:54.189 Connected to database 'mythconverg' at host: localhost
2007-12-20 17:55:54.210 Could not query inputs.
                        eno: Inappropriate ioctl for device (25)
2007-12-20 17:55:54.211 Channel(/dev/cxm0): SetInputAndFormat() failed
2007-12-20 17:55:54.212 Channel(/dev/cxm0): SetInputAndFormat() failed
2007-12-20 17:55:54.212 TVRec(1) Error: Setting start channel '66' failed,
                        and backup '1' failed as well.
2007-12-20 17:55:54.218 New DB scheduler connection

from ktrace -di mythbackend

 28476 initial thread CALL  open(0x2afb0b60,O_RDWR,<unused>0)
 28476 initial thread NAMI  "/dev/cxm0"
 28476 initial thread RET   open 4
 28476 initial thread CALL  ioctl(0x4,0x40685600 ,0xbfbfdefc)
 28476 initial thread RET   ioctl 0
 28476 initial thread CALL  ioctl(0x4,0x40685600 ,0xbfbfdeb8)
 28476 initial thread RET   ioctl 0
 28476 initial thread CALL  gettimeofday(0xbfbfd8e8,0)
 28476 initial thread RET   gettimeofday 0

...

 28476 initial thread CALL  ioctl(0x4,0x40685600 ,0xbfbfdb1c)
 28476 initial thread RET   ioctl 0
 28476 initial thread CALL  ioctl(0x4,0xc04c561a ,0xbfbfdc98)
 28476 initial thread RET   ioctl -1 errno 25 Inappropriate ioctl for device
 28476 initial thread CALL  ioctl(0x4,0x403c7601 ,0xbfbfdce4)
 28476 initial thread RET   ioctl -1 errno 25 Inappropriate ioctl for device


> 
> 2. the driver is not designed for multiple reading. however, it must
> be able to be opened more than once because the tuner is not a
> separate device. this makes tuning while watching possible.

    I wonder if one can open a device for neither reading or writing,
    only IOCTLs?  Anyway, I've panic'ed my machine several times
    because of this.
    
> 
> 3. switching back from svhs is not possible?

    I not clear on the question.  Switching to the tuner after
    switching to svideo/composite does not work.
    'pvr250-setchannel -m 1'  will also panic my machine.
> 
> 4. supporting tvtime and other linux tv-viewers is on my wishlist too:
> a v4l(2) compatible reading api needs to be implemented.
> 
> 5. i experimented with the "3:2 pulldown" flag of the encoder. i think
> the current driver mistakenly enables 3:2 pulldown. fixing this will
> improve fast moving scenes ( sports ) and sliding texts.

    A question to all: Given an infinite amount of CPU what is the
    best possible deinterlacing strategy/filter for mplayer?

    --Mat