On Wed, 18 Feb 2015 11:04:01 +0100 Michal Suchanek <[email protected]> wrote:
> 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. That's a good point about double-buffering. The FBIOPAN_DISPLAY ioctl is probably also needed for a full recovery. When directly using the framebuffer, each application has full access to it (preferably with nobody else concurrently using the framebuffer, or things become really ugly) and may leave the framebuffer in whatever messed up state as it likes. With great power comes great responsibility. *Maybe* the sunxi display driver in the kernel could keep track of the FBIOPAN_DISPLAY ioctl use. And automatically restore the start of the visible part of the framebuffer to the default value when two conditions are met: 1. a framebuffer descriptor is closed 2. this particular descriptor was the last one to set the panning I wonder how are the other framebuffer drivers handling this situation? -- Best regards, Siarhei Siamashka -- 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.
