Date: Fri, 21 Dec 2007 01:31:26 +0100 From: "Danny Pansters" <danny@ricin.com> To: freebsd-multimedia@freebsd.org Subject: Re: PVR-150 on 6-STABLE: success and mini HOWTO Message-ID: <200712210131.26943.danny@ricin.com> In-Reply-To: <20071220233634.GE52400@tube5.mine.nu> References: <200712191659.28032.danny@ricin.com> <c39ec84c0712201415w5a8dcf35h508dfb32692e1ca6@mail.gmail.com> <20071220233634.GE52400@tube5.mine.nu>
next in thread | previous in thread | raw e-mail | index | archive | help
Come to think of it, I don't think that the SETTYPE ioctl was ever meant to set the broadcasting standard or channelset, but for the tuner make. I found that odd the first time I looked at it. May work or might have worked by accident only before. Dan On Friday 21 December 2007 00:36:34 User Mat wrote: > On Dec 20, usleepless@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 > _______________________________________________ > freebsd-multimedia@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-multimedia > To unsubscribe, send any mail to > "freebsd-multimedia-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200712210131.26943.danny>