I'm wondering, would the x.org people take possession of this driver? At least then, it would probably be modified if other parts of X required it...
On Fri, 2 Feb 2007 19:18:59 -0500 Ricardo Lugo <[EMAIL PROTECTED]> wrote: > > On Feb 2, 2007, at 3:36 PM, John Harvey wrote: > > > > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] On Behalf Of Ian Armstrong > >> Sent: 02 February 2007 17:52 > >> To: Discussion list for development of the IVTV driver > >> Subject: Re: [ivtv-devel] Fixed bug in trunk, please test! > >> > >> On Friday 02 February 2007 16:40, Ricardo Lugo wrote: > >>> On Feb 2, 2007, at 7:58 AM, Ian Armstrong wrote: > >>>> On Friday 02 February 2007 03:21, Ricardo Lugo wrote: > >>>>> Ian, > >>>>> > >>>>> I compiled the PPC binary that's on the wiki at the moment. What > >>>>> changes would I have to make to the source? > >>>> > >>>> Try the following two patches. These are done against the trunk > >>>> version of the X driver. The first patch just brings it > >> more up to > >>>> date. The second is the endian patch. > >>>> > >>>> I may have got the byte swap wrong. If I have, the code > >> is located > >>>> in the FBshadowUpdatePacked routine in ivtvdev.c. It's > >> easy enough > >>>> to understand. > >>> > >>> The colors are right on! > >>> And it doesn't seem as though there is too much overhead when using > >>> mplayer -vo xv. > >>> > >>> BUT while playing a recording on the decoder in MythTV (or watching > >>> Live TV), the OSD colors are messed up as before. > >> > >> MythTV bypasses X & writes direct to the osd. The fix could > >> have gone into the ivtv driver itself but I'm reluctant to do > >> this. If you move the byte-swap code into the ivtv driver, > >> you would have to disable the osd dma for anything other than > >> an 8 bit display. MythTV redraws the entire 32 bit display > >> several times a second when playing an mpeg through the 350, > >> so the cpu load would be horrendous. > >> > >> The best fix would be to do the byte-swap in MythTV itself, > >> as it could still take advantage of the dma transfer for the > >> osd updates. I have no idea what would be involved in getting > >> MythTV to render in the correct byte order. > >> > >> -- > >> Ian > >> > >> _______________________________________________ > >> ivtv-devel mailing list > >> [email protected] > >> http://ivtvdriver.org/mailman/listinfo/ivtv-devel > > > > It should be fairly easy to do in myth and I agree that is the > > better place > > to do it, otherwise we will end up with yet another copy of the > > data being > > stored in the driver before it can be DMA'd. > > > > Now that Xv is working though Myth can use that and avoid talking > > to the > > frame buffer/decoder directly. > > That sounds like a great idea (ie a very stable idea). > > Well, if whoever has access to the ivtvdriver.org website would mind > copying the PPC xdriver binary off of my site and changing the link > on the wiki, I would be very thankful. It is the trunk xdriver with > Ian's 2 patches, compiled for Xorg 6.9.0 under Slackintosh 11.0. > > http://tube.dnsalias.net/~rick/ivtv/ivtvdev_drv.so.gz > > Many thanks, everyone! > - Rick > > > > > JOhn > > > > > > _______________________________________________ > > ivtv-devel mailing list > > [email protected] > > http://ivtvdriver.org/mailman/listinfo/ivtv-devel > > > _______________________________________________ > ivtv-devel mailing list > [email protected] > http://ivtvdriver.org/mailman/listinfo/ivtv-devel _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
