Hi all, I have been working on a DirectFB port to the SH4 architecture and to CE devices produced by STMicroelectronics. I have noticed that applications (such as the examples) that draw to the primary surface are not suspended when the VT is switched and continue to draw over the framebuffer, along with whatever is supposed to be on the new VT.
At first I thought I had missed something in my gfxcard driver for the hardware, but then discovered that the PC version using vesafb has the same behaviour. Additionally if applications are forced into a window (--dfb:force-windowed) it all works as expected. Turing on debug shows that the suspend is being attempted in both cases and the only difference between non-windowed and windowed is an additional message, from dfb_surface_software_lock (surfaces.c:801), "accessing video memory during suspend". The code path does not appear to consider this to be an error, or at least no error code is returned when this happens. Is this behaviour expected or would you consider it a bug? I could understand a point of view which says an application drawing directly to the primary surface never expects to lose the display. However AFAIK you can't prevent a VT switch from happening, in which case I would expect DirectFB to work with the rest of the system. The code does appear to be trying to do the suspend, but something (which I am unable to determine with only a brief look at the code) is preventing this from working. BTW I have reproduced this with a pre 0.9.22 CVS snapshot and a 0.9.23 snapshot 2005-06-23-04-25-09-UTC, so the behaviour has been like this for some time. Best Regards, -stephen _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
