Re: [linux-sunxi] Re: sunxi-mali and FRAMEBUFFER issues
Hi Simo, On Wed, 18 Feb 2015 07:15:22 +0200 Siarhei Siamashka wrote: On Wed, 18 Feb 2015 07:08:42 +0200 Siarhei Siamashka wrote: On Fri, 13 Feb 2015 09:04:48 -0800 (PST) Simo Xefil wrote: 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 If I remember correctly, in you application you can switching current VT from TEXT mode into GRAPHICS mode so the kernel stops interfering with the framebuffer and once you revert the VT to TEXT mode kernel will just redraw the whole console, erasing what your application left around. If you want to have things operate properly in case of application mis-behavior/crash you probably need a wrapper process to perform that work and react to VT switches (STOP your application when leaving VT, resume it when coming back). Bruno -- 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.
Re: [linux-sunxi] Re: sunxi-mali and FRAMEBUFFER issues
On 18 February 2015 at 06:15, Siarhei Siamashka siarhei.siamas...@gmail.com wrote: On Wed, 18 Feb 2015 07:08:42 +0200 Siarhei Siamashka siarhei.siamas...@gmail.com wrote: On Fri, 13 Feb 2015 09:04:48 -0800 (PST) Simo Xefil xe...@xefil.com 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 linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: sunxi-mali and FRAMEBUFFER issues
On Wed, 18 Feb 2015 11:04:01 +0100 Michal Suchanek hramr...@gmail.com wrote: On 18 February 2015 at 06:15, Siarhei Siamashka siarhei.siamas...@gmail.com wrote: On Wed, 18 Feb 2015 07:08:42 +0200 Siarhei Siamashka siarhei.siamas...@gmail.com wrote: On Fri, 13 Feb 2015 09:04:48 -0800 (PST) Simo Xefil xe...@xefil.com 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
Re: [linux-sunxi] Re: sunxi-mali and FRAMEBUFFER issues
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
Re: [linux-sunxi] Re: sunxi-mali and FRAMEBUFFER issues
On Fri, 13 Feb 2015 09:04:48 -0800 (PST) Simo Xefil xe...@xefil.com 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? -- 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.
Re: [linux-sunxi] Re: sunxi-mali and FRAMEBUFFER issues
On Wed, 18 Feb 2015 07:08:42 +0200 Siarhei Siamashka siarhei.siamas...@gmail.com wrote: On Fri, 13 Feb 2015 09:04:48 -0800 (PST) Simo Xefil xe...@xefil.com 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 -- 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.
Re: [linux-sunxi] Re: sunxi-mali and FRAMEBUFFER issues
You could look into https://github.com/mittorn/a10disp and simply do a ./a10disp displayoff ./a10disp enablehdmi your_hdmi_mode and check if it works. If so, you can either execute some batch script after you finished displaying or put the ioctls into your player's source code. libvdpau-sunxi for example. It'd be ugly, but maybe a workaround. Remember, i have not tried that by myself :) Regards Andreas Am 16.02.2015 um 17:07 schrieb Simo Xefil: Hi Andreas, Ok, in case that would be the workaround, do you think trying to compile a simple program that does exactly that could be a solution to refresh a screen after such a behaviour? Not having experience, I'd try it if that could be a possible solution (even if I've no idea where to start :) ) Thank you again, Simon Il giorno lunedì 16 febbraio 2015 16:46:19 UTC+1, Andreas Baierl ha scritto: Hi Simon, i only think, that Allwinner already did a workaround against that non-screen-clearing issue in their in code. They do DISP_CMD_HDMI_OFF, DISP_CMD_HDMI_SET_MODE and DISP_CMD_HDMI_ON after finishing displaying on the framebuffer. They reset the HDMI. I haven't tested that. So that is just a guess and maybe a hint, where to look for... Regards Andreas -- 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 mailto:linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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.
Re: [linux-sunxi] Re: sunxi-mali and FRAMEBUFFER issues
Hi Simon, i only think, that Allwinner already did a workaround against that non-screen-clearing issue in their in code. They do DISP_CMD_HDMI_OFF, DISP_CMD_HDMI_SET_MODE and DISP_CMD_HDMI_ON after finishing displaying on the framebuffer. They reset the HDMI. I haven't tested that. So that is just a guess and maybe a hint, where to look for... Regards Andreas Am 16.02.2015 um 16:11 schrieb Simo Xefil: Hallo Andreas, Sorry, I'm not totally understanding your answer. You mean I should replace some part of my drivers recompiling a part of what you've linked? Thanks, Simon Il giorno lunedì 16 febbraio 2015 10:12:56 UTC+1, Andreas Baierl ha scritto: I don't know the reason, but i suppose, that issue is the reason, why Allwinner themselves placed this workaround in their example code: https://github.com/linux-sunxi/cedarx-libs/blob/master/libcedarv/linux-armhf/sample/render/render.c#L254 https://github.com/linux-sunxi/cedarx-libs/blob/master/libcedarv/linux-armhf/sample/render/render.c#L254 A display bug may be a reason for this issue at all. Regards Andreas -- 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 mailto:linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- 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.
Re: [linux-sunxi] Re: sunxi-mali and FRAMEBUFFER issues
Hi Andreas, Ok, in case that would be the workaround, do you think trying to compile a simple program that does exactly that could be a solution to refresh a screen after such a behaviour? Not having experience, I'd try it if that could be a possible solution (even if I've no idea where to start :) ) Thank you again, Simon Il giorno lunedì 16 febbraio 2015 16:46:19 UTC+1, Andreas Baierl ha scritto: Hi Simon, i only think, that Allwinner already did a workaround against that non-screen-clearing issue in their in code. They do DISP_CMD_HDMI_OFF, DISP_CMD_HDMI_SET_MODE and DISP_CMD_HDMI_ON after finishing displaying on the framebuffer. They reset the HDMI. I haven't tested that. So that is just a guess and maybe a hint, where to look for... Regards Andreas -- 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.
Re: [linux-sunxi] Re: sunxi-mali and FRAMEBUFFER issues
*GREAT!!* I'll give a try and let you know. :-) Thanks Andreas!!! Simon Il giorno lunedì 16 febbraio 2015 17:28:43 UTC+1, Andreas Baierl ha scritto: You could look into https://github.com/mittorn/a10disp and simply do a ./a10disp displayoff ./a10disp enablehdmi your_hdmi_mode and check if it works. If so, you can either execute some batch script after you finished displaying or put the ioctls into your player's source code. libvdpau-sunxi for example. It'd be ugly, but maybe a workaround. Remember, i have not tried that by myself :) Regards Andreas Am 16.02.2015 um 17:07 schrieb Simo Xefil: Hi Andreas, Ok, in case that would be the workaround, do you think trying to compile a simple program that does exactly that could be a solution to refresh a screen after such a behaviour? Not having experience, I'd try it if that could be a possible solution (even if I've no idea where to start :) ) Thank you again, Simon Il giorno lunedì 16 febbraio 2015 16:46:19 UTC+1, Andreas Baierl ha scritto: Hi Simon, i only think, that Allwinner already did a workaround against that non-screen-clearing issue in their in code. They do DISP_CMD_HDMI_OFF, DISP_CMD_HDMI_SET_MODE and DISP_CMD_HDMI_ON after finishing displaying on the framebuffer. They reset the HDMI. I haven't tested that. So that is just a guess and maybe a hint, where to look for... Regards Andreas -- 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...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- 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.
Re: [linux-sunxi] Re: sunxi-mali and FRAMEBUFFER issues
Hallo Andreas, Sorry, I'm not totally understanding your answer. You mean I should replace some part of my drivers recompiling a part of what you've linked? Thanks, Simon Il giorno lunedì 16 febbraio 2015 10:12:56 UTC+1, Andreas Baierl ha scritto: I don't know the reason, but i suppose, that issue is the reason, why Allwinner themselves placed this workaround in their example code: https://github.com/linux-sunxi/cedarx-libs/blob/master/libcedarv/linux-armhf/sample/render/render.c#L254 A display bug may be a reason for this issue at all. Regards Andreas -- 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.
Re: [linux-sunxi] Re: sunxi-mali and FRAMEBUFFER issues
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, so, for such devices is the best choise. 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. 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. 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 :-) Many thanks! Simon Il giorno giovedì 12 febbraio 2015 16:26:25 UTC+1, Siarhei Siamashka ha scritto: On Thu, 12 Feb 2015 06:54:30 -0800 (PST) Simo Xefil xe...@xefil.com javascript: wrote: Il giorno mercoledì 11 febbraio 2015 00:07:58 UTC+1, Simo Xefil ha scritto: Hello! I've installed the sunxi-mail drivers following the guide found on http://linux-sunxi.org/Mali_binary_driver using EGL_TYPE=framebuffer. I'm using a Banana-Pi board with a MALI-400 gpu. I need to use it with framebuffer to increase the graph performances. The compilation works well, but I've noticed a strange behaviour. Running the test utility (make test test/test) I obtain correctly the colorful triangle, and here the cli output: EGL Version: 1.4 Linux-r3p0-04rel0 EGL Vendor: ARM EGL Extensions: EGL_KHR_image EGL_KHR image_base EGL_KHR_image_pixmap EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_reusable_sync EGL_KHR_fence_sync EGL_KHR_lock_surface EGL_KHR_lock_surface2 Surface size: 480x480 GL Vendor: ARM GL Renderer: Mali-400 MP GL Version: OpenGL ES 2.0 GL Extensions: GL_OES_texture_npot GL_OES_compressed_ETC1_RGB8_texture GL_OES_standard_derivatives GL_OES_EGL_image GL_OES_depth24 GL_ARM_rgba8 GL_ARM_mali_shader_binary GL_OES_depth_texture GL_OES_packed_depth_stencil GL_EXT_texture_format_BGRA GL_EXT_blend_minmax GL_OES_EGL_image_external GL_OES_EGL_sync GL_EXT_multisampled_render_to_texture GL_EXT_discard_framebuffer GL_OES_get_program_binary GL_EXT_shader_texture_lod The problem is I cannot exit the test, or better, it kills the test, but I still have the triangle on screen. I need to switch between two consoles (i.e. if I'm in console Alt+F1 I need to change Alt+F2 and then Alt+F1 back), only so I obtain a refresh of the view. What could cause the problem? This behaviour happens on any program that uses framebuffer to redender the images. So, in example, if I exit a program that uses FB, I need to switch between views to force a refresh. Is there a way to debug it or, better, a solution? Hello again. Sorry if I top post the thread, but seems strange I'm the only having this issue. It happens with different distros as well as on different boards. I would exclude OS or hardware problems. If someone suggest me how to debug, would be good. A sort of backgroun screen-refresh would be a workaround as well, but don't know how. Right after executing the test, the mouse remains visible. I've tested 'xrefresh -black' as well, as found somewhere on the net, but it doesn't rebuild the desktop. I've seen the 'test' program is launched and it exits immediatly, also It's not a matter of the program itself. Strange is, sometimes the terminal (withing x11) I use to launch the test program, comes back visible. In example if I launch 'fbset -xres 1280 -yres 1024' right after the 'test' (I need to write the command without seeing what I'm writing, because all is hidden by the trianble) I get a refresh of only the terminal window. Moving then the terminal I can redraw the rest of the desktop. In fact the problem is unchanged. I'm again thinking that resolving this issue could resolve automatically the problems I get with other applications as well. Basically, it looks like you want to have your cake and eat it too :-) The framebuffer mali driver is designed for single-tasking, with just one application ever drawing something to the screen. The x11 mali driver is
Re: [linux-sunxi] Re: sunxi-mali and FRAMEBUFFER issues
On Thu, 12 Feb 2015 06:54:30 -0800 (PST) Simo Xefil xe...@xefil.com wrote: Il giorno mercoledì 11 febbraio 2015 00:07:58 UTC+1, Simo Xefil ha scritto: Hello! I've installed the sunxi-mail drivers following the guide found on http://linux-sunxi.org/Mali_binary_driver using EGL_TYPE=framebuffer. I'm using a Banana-Pi board with a MALI-400 gpu. I need to use it with framebuffer to increase the graph performances. The compilation works well, but I've noticed a strange behaviour. Running the test utility (make test test/test) I obtain correctly the colorful triangle, and here the cli output: EGL Version: 1.4 Linux-r3p0-04rel0 EGL Vendor: ARM EGL Extensions: EGL_KHR_image EGL_KHR image_base EGL_KHR_image_pixmap EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_reusable_sync EGL_KHR_fence_sync EGL_KHR_lock_surface EGL_KHR_lock_surface2 Surface size: 480x480 GL Vendor: ARM GL Renderer: Mali-400 MP GL Version: OpenGL ES 2.0 GL Extensions: GL_OES_texture_npot GL_OES_compressed_ETC1_RGB8_texture GL_OES_standard_derivatives GL_OES_EGL_image GL_OES_depth24 GL_ARM_rgba8 GL_ARM_mali_shader_binary GL_OES_depth_texture GL_OES_packed_depth_stencil GL_EXT_texture_format_BGRA GL_EXT_blend_minmax GL_OES_EGL_image_external GL_OES_EGL_sync GL_EXT_multisampled_render_to_texture GL_EXT_discard_framebuffer GL_OES_get_program_binary GL_EXT_shader_texture_lod The problem is I cannot exit the test, or better, it kills the test, but I still have the triangle on screen. I need to switch between two consoles (i.e. if I'm in console Alt+F1 I need to change Alt+F2 and then Alt+F1 back), only so I obtain a refresh of the view. What could cause the problem? This behaviour happens on any program that uses framebuffer to redender the images. So, in example, if I exit a program that uses FB, I need to switch between views to force a refresh. Is there a way to debug it or, better, a solution? Hello again. Sorry if I top post the thread, but seems strange I'm the only having this issue. It happens with different distros as well as on different boards. I would exclude OS or hardware problems. If someone suggest me how to debug, would be good. A sort of backgroun screen-refresh would be a workaround as well, but don't know how. Right after executing the test, the mouse remains visible. I've tested 'xrefresh -black' as well, as found somewhere on the net, but it doesn't rebuild the desktop. I've seen the 'test' program is launched and it exits immediatly, also It's not a matter of the program itself. Strange is, sometimes the terminal (withing x11) I use to launch the test program, comes back visible. In example if I launch 'fbset -xres 1280 -yres 1024' right after the 'test' (I need to write the command without seeing what I'm writing, because all is hidden by the trianble) I get a refresh of only the terminal window. Moving then the terminal I can redraw the rest of the desktop. In fact the problem is unchanged. I'm again thinking that resolving this issue could resolve automatically the problems I get with other applications as well. Basically, it looks like you want to have your cake and eat it too :-) The framebuffer mali driver is designed for single-tasking, with just one application ever drawing something to the screen. The x11 mali driver is designed to work in the multi-tasking x11 window system environment, where each application has its own window. Naturally, doing the synchronization to ensure that all the applications play nice together incurs a little bit of overhead. So you just need to pick the right driver for your use case. -- 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.
