2011/6/28 "Ing. Daniel Rozsnyó" <[email protected]>
> **
> You can test it with mplayer - no audio and specify FPS larger than the
> VSync, then it should top on the real vsync rate.. I was experimenting with
> producing binary data out of the dvi port and I used this during
> development:
>
> mplayer $1 -demuxer rawvideo -rawvideo w=640:h=480:format=rgb32:fps=60
> -loop 0
>
> I do not remember if it went through -vo x11 or xv, anyway in the mplayer
> source there are multiple implementations of vsync - does OGP present a
> framebuffer device too or only an X driver?
>
I think the synchronization code hasn't been implemented:
martin@hop:~/Downloads/ogp/trunk/drivers/xf86-video-ogd/src$ less ogd_dga.c
[...]
static DGAFunctionRec ogddga_functions =
{
ogddga_open_framebuffer,
NULL, /* CloseFramebuffer */
ogddga_set_mode,
ogddga_set_viewport,
ogddga_get_viewport,
NULL, /* Sync */
NULL, /* FillRect */
NULL, /* BlitRect */
NULL, /* BlitTransRect */
};
[...]
The source is there: svn co svn://svn.opengraphics.org/ogp
I think the fastest solution to my problem would be to use the kernel
messages to lock into the interrupts
(60Hz isn't that fast after all) and estimate in user level when it is save
to update screen contents.
That is if no one suggests some way to wait for the interrupts with libpci.
--
Martin Kielhorn
Randall Division of Cell & Molecular Biophysics
King's College London, New Hunt's House
Guy's Campus, London SE1 1UL, U.K.
tel: +44 (0) 207 848 6519, fax: +44 (0) 207 848 6435
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
