Date: Thu, 01 Mar 2007 00:36:11 -0800 From: Vadim Mikhailov <lirc@mikhailov.org> To: Greg 'groggy' Lehey <grog@FreeBSD.org> Cc: freebsd-multimedia@freebsd.org, Daniel O'Connor <doconnor@gsoft.com.au>, matt@mattsteg.com Subject: Re: Problems with PVR 250 and MythTV Message-ID: <45E6907B.7000905@mikhailov.org> In-Reply-To: <20070301014625.GD18777@wantadilla.lemis.com> References: <45E50C32.9090703@puresimplicity.net> <45E53F89.70803@mikhailov.org> <20070301014625.GD18777@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45E6907B.7000905>