Mark Adams a écrit : > No patches should be required any more. All this stuff should work if you > have linux-viafb from DirectFB CVS and DirectFB-rc4 or later.
I actually used DirectFB rc2, which needs "dfb_unichrome_flip_ioctl-libcle266mpegdec_GetFBOffset.patch". I didn't upgraded this one since Laz said it was working with an even older version (2006-10). DFB++ needed a similar patch, but latest CVS didn't need it. I upgraded viafb to get rid of it's latest patch. So you're correct : no more patches. I'll test 1.0rc4 >> ------------------------ >> Try adding a printk in viafb_wait_for_sync (via_fbobj.c), just before it >> returns: >> >> printk(KERN_INFO "wait vsync: %d %d %d\n", field_option, p->irq_cnt & 1, >> ret); > > OK, so we see this: > >> Feb 11 11:39:47 vdr kernel: wait vsync: 3 0 25 >> Feb 11 11:39:47 vdr last message repeated 2 times >> Feb 11 11:39:47 vdr kernel: wait vsync: 3 1 25 >> Feb 11 11:39:47 vdr last message repeated 2 times >> Feb 11 11:39:47 vdr kernel: wait vsync: 3 0 25 >> Feb 11 11:39:47 vdr last message repeated 2 times >> Feb 11 11:39:47 vdr kernel: wait vsync: 3 1 25 >> Feb 11 11:39:47 vdr kernel: wait vsync: 3 1 25 > > field_option 3 is a wait for a kernel-assisted flip to complete. The 25's > (HZ/10) mean that the wait calls are returning immediately (presumably > because a fair amount of processing was required to get the next frame > ready > and the previous frame had been displayed by that point). The mixture of > 0's and 1's means that the video is sometimes on the top field and > sometimes > on the bottom when the wait happens. > > All that is fine provided that you're using triple buffering. That's > perhaps something I should enforce when this method is being used and fall > back to the old method if not. > > Are you using triple buffering? Softdevice developpers should give a sound answer. The logs say : [surface capabilities] videoSurface: videoonly flipping triple-buffered PixelFormat = 0x08100609 > Can you try using df_xine (from DirectFB-extra)? This I know to work > perfectly on my hardware and it would be a good starting point to see if > this works for you before going much further. I think I've asked this > before but I don't remember you reporting back what the result was. Use > something like: > > df_xine -m 720x576 -l 1 -b triple -f top <filename> > > There are some more useful tests we can do if we still don't find out > what's > happening but try the above first. I'll do that and report. Thank you very much for all your help. -- NH _______________________________________________ directfb-users mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
