Stefan Lucke a écrit :
> On Donnerstag, 29. September 2005 22:05, Stefan Lucke wrote:
>
>>On Donnerstag, 29. September 2005 12:25, Mark Adams wrote:
>>
>>>>for A/V-sync I'm measuring the frame rate of current screen with
>>>>two WaitForSync() calls. for VIA unichrome I get some strange result:
>>>>A/V sync seems to be OK (no frames dropped) when time is set hardcoded.
>>>>Without that I'll get:
>>>>
>>>>[dfb] Display frame time is 99949 microseconds
>>>>[dfb] Display frame time is 99950 microseconds
>>>
>>>OK, I think I know what's happening there.
>>>
>>>Which framebuffer driver are you using?
>>>
>>>The 'patcher2k' version of viafb (and possibly other versions too) has
>>>a bug in it. The vblank interrupt is enabled and a handler installed
>>>but the interrupt then gets disabled again when the video mode is set
>>>up. Thus the driver gets no interrupts at all. The 0.1 second
>>>interval you are seeing is the wait timeout that's there to prevent a
>>>complete hang in the event that the interrupt never arrives.
>>>
>>>If you look at one of the earlier unichrome threads, you'll find a
>>>patch for that version of viafb that I posted. It should fix this
>>>problem (as well as providing improved tv-out capability and the
>>>option of frame syncs). If you only want to fix this bug, you should
>>>be able to find the appropriate part of the patch to apply but if not,
>>>get back to me and I'll post further details.
>>
>>If you are referring to Nicolas mail from 2005-09-06,
>>
>>http://mail.directfb.org/pipermail/directfb-users/2005-September/000551.html
>>
>>reenabling does not do the trick. My via_fbobj.c now has the the following
>>diff compared to patcher2k.viafb_03.diff:
>
>
> That is/was reenabling interrupts at the wrong place :-) .
> This was in function VIAPostSetTV3Mode(). But I'm not using TV out,
> just VGA. I moved that to a place after VIAPostSetTV3Mode() gets called.
>
> Now I get measured frame times of:
> [surface capabilities] videoSurface: videoonly double-buffered flipping
> [dfb] (re)configured 0x08100609
> [dfb] Display frame time is 16653 microseconds
> [dfb] Display frame time is 16657 microseconds
> [softdevice] Subplugin successfully opend
>
> My diff against patcher2k patch is attached.
>
>
>
> ------------------------------------------------------------------------
>
> --- via_fbobj.c.orig 2005-09-23 05:01:23.000000000 +0200
> +++ via_fbobj.c 2005-09-29 23:13:48.000000000 +0200
> @@ -427,6 +427,11 @@
> VIAPostSetTV3Mode(info,x,y,b);
> break;
> }
> +
> + /* must now re-enable vsync interrupt */
> + outb(0x11, 0x3d4);
> + outb(inb(0x3d5) | 0x30, 0x3d5);
> +
> via_set_regs();
> return 1;
> }
> @@ -1019,6 +1024,8 @@
> /* Turn on all Composite and S-Video output */
> I2C_wdata(I2CPort, I2CAddrTV, 0x0E, 0);
>
> + /* Reset interrupt count (and hopefully get correct field parity) */
> + par->irq_cnt = 0;
> }
>
> void VIAPostSetTV3Mode(struct fb_info *info,int xres,int yres,int bpp)
I just applied the first part of the patch (since I don't mind about
field parity), and I get the following result (0.1.3) :
[dfb] Display frame time is 17668 microseconds
(was something like 99950 us before the patch, and video was a
succession of 1s fast-paced images and 1s still-image, like someone
described on the ML recently)
Since I output on PAL TV @ 50Hz, this timing seems odd (should be 20000
us, isn't it ? not 17,668 ms / 56Hz) I'm not in front of the TV so I
can't check image quality.
[EMAIL PROTECTED]:~# fbset -i
mode "720x576-50"
# D: 28.000 MHz, H: 31.250 kHz, V: 50.000 Hz
geometry 720 576 720 1152 32
timings 35714 32 8 46 0 136 3
rgba 8/16,8/8,8/0,8/24
endmode
Frame buffer device information:
Name : UNICHROME
Address : 0xe4000000
Size : 33288192
Type : PACKED PIXELS
Visual : TRUECOLOR
XPanStep : 0
YPanStep : 1
YWrapStep : 0
LineLength : 2880
MMIO Address: 0xe8000000
MMIO Size : 16777216
Accelerator : Unknown (77)
--
NH
_______________________________________________
directfb-users mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
