If I don't use a flipping surface, then everything behaves correctly. I
had thought it was some kind of namespace clash since I am combining two
rather large applications.
DirectFBSetOption("vsync-none", NULL); does "solve" the issue, while
allowing me to use flipping surfaces. Running my directfb application
as a standalone daemon, and not part of the main application did not
present this problem.
The hardware I am using is a geode GX1 (sc1200). So odd effects is the
theme of the day. sigma 8741 -> geode VIP gets mixed with the
framebuffer in the geode video processor, and output out DVI-I. I am
using directfb 0.9.20.
On Wed, 2004-02-11 at 02:45, Denis Oliver Kropp wrote:
> Quoting Brian G. Rhodes:
> > Are there any issues starting directfb from a thread? I haven't looked
> > into it very much, but if there is a known reason why this shouldn't
> > work, it will save me some time.
> >
> > #0 0x41d269ef in primaryWaitVSync ()
> > from /usr/local/lib/directfb-0.9.20/systems/libdirectfb_fbdev.so
> > #1 0x4025a46f in dfb_layer_wait_vsync () from
> > /usr/lib/libdirectfb-0.9.so.20
> > #2 0x402581a4 in dfb_layer_flip_buffers () from
> > /usr/lib/libdirectfb-0.9.so.20
> > #3 0x40236bd5 in IDirectFBSurface_Layer_Flip ()
> > from /usr/lib/libdirectfb-0.9.so.20
> >
> > This isn't the first time Flip is called for the primary surface in the
> > application.
>
> The stack trace looks fine. Most of the time is spent (or slept using
> vsync interrupt) in the primaryWaitVSync(). That's normal if you use
> DSFLIP_WAITFORSYNC. You can forbid vsync waiting by using the "vsync-none"
> option, see directfbrc(5) for more details about configuration files and
> command line parameters.
>
> Do you have any other odd effect?
--
Info: To unsubscribe send a mail to [EMAIL PROTECTED] with
"unsubscribe directfb-users" as subject.
