> -----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. JOhn _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
