On 18 February 2015 at 06:15, Siarhei Siamashka <[email protected]> wrote: > On Wed, 18 Feb 2015 07:08:42 +0200 > Siarhei Siamashka <[email protected]> wrote: > >> On Fri, 13 Feb 2015 09:04:48 -0800 (PST) >> Simo Xefil <[email protected]> wrote: >> >> > >> > Hello Siarhei, >> > >> > First of all thanks for your answer. >> > Basically, I'm searching a way to let the drivers work properly based on >> > the hardware performances. framebuffer is much more faster >> >> Yes, the mali framebuffer driver is roughly ~20% faster than the x11 >> driver, at least as measured in glmark2-es2. >> >> And the difference is even bigger than that if the system is not >> configured optimally. For example, the ondemand cpufreq governor >> interacts really bad with the X server. Also you need to get the >> buffers reservation right, but having the settings partially in the >> script.bin and partially in the command line for the sunxi-3.4 kernel >> does not make it particularly easy. >> >> There were attempts to ensure that the configuration is reasonable >> "out of the box". But there was always somebody with some sort of >> objections. That's how "democracy" works. >> >> Just one week of "dictatorship" could have really solved a lot >> of issues in the sunxi-3.4 kernel :-) >> >> >, so, for such devices is the best choise. >> >> Assuming that you can accept the limitations. There is no free lunch. >> >> > I'm not asking the driver to handle multi-tasking. Using the 'test' program >> > from the terminal (not within X11) I got the same results. >> > The monitor is not refreshed after the triangle is drawn even if the >> > program is already exited. >> >> If a program has rendered a triangle in the framebuffer, then this >> triangle just stays in the framebuffer. This is a perfectly obvious >> outcome. >> >> If you don't want to see this triangle anymore, then somebody needs to >> clear the framebuffer and use it for something else. >> >> > Back to desktop env, programs like XBMC (A10 fork) or emulators like >> > retroarch, compiled to use framebuffer, are working very well, expect when >> > you exit the program. >> > At this point, the last printed image remains on screen. The only way I've >> > found until today is to restart lxde or switch between X11 and terminal to >> > force a refresh. >> >> There are surely plenty of ways to clear the framebuffer. And you can >> also even make a copy of the old framebuffer data and restore it after >> the application has terminated. Everything is up to you. Or up to the >> developers of the framebuffer based applications. >> >> > With an emulator, where I could need switch between games often, every time >> > I quit the game, the image remains impressed and I cannot change it. >> > >> > I've no idea how to invent a way to force the refresh. If you have an idea >> > I would try to investigate in that direction. >> > I don't expect a finished solution (even it, in case, would be of course >> > appreciated). I'd try to find/try by myself, but have no idea where to >> > search. >> > >> > Any suggestion is really welcome :-) >> >> Does, for example, running "cat /dev/zero > /dev/fb0" help? > > Or create a simple wrapper shell script, which might look like: > > #!/bin/sh > > dd if=/dev/fb0 of=/tmp/fbbackup.bin > <run-your-cool-game-or-emulator> > dd if=/tmp/fbbackup.bin of=/dev/fb0 >
Is this actually working? iirc there are two issues. 1) framebuffer is not cleared (graphics remains visible but typed text is also visible) 2) dual-buffering or other layer operation leaves enabled a layer different from the one fbcon draws to (graphics remains visible, typed text is not seen) I always used the graphics tests remotely exactly to mitigate issues like these so I don't see much practical difference between the two. In the doublebufferling case you can just run the test repeatedly until the right buffer happens to be on-screen when the test ends. For running tests from local console the buffering bug might be much more annoying. Thanks Michal -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
