A lot of suggesitons, wow! With a10disp I've obtained some results. I need to disable the hdmi, but enabling back doesn't work. I need to re-apply the display settings. This seems forces a rewrite of the fb. It uses fbset which has give me some partial results in the past. So console comes back. If I need to refresh X11 as well, a xrefresh does the trick. All commands are executable via ssh as well and helps me to prevent writing without seeing what I'm typing :)
Thanks!! Simon Il giorno mercoledì 18 febbraio 2015 12:51:23 UTC+1, Siarhei Siamashka ha scritto: > > On Wed, 18 Feb 2015 11:04:01 +0100 > Michal Suchanek <hram...@gmail.com <javascript:>> wrote: > > > On 18 February 2015 at 06:15, Siarhei Siamashka > > <siarhei....@gmail.com <javascript:>> wrote: > > > On Wed, 18 Feb 2015 07:08:42 +0200 > > > Siarhei Siamashka <siarhei....@gmail.com <javascript:>> wrote: > > > > > >> On Fri, 13 Feb 2015 09:04:48 -0800 (PST) > > >> Simo Xefil <xe...@xefil.com <javascript:>> 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
