Re: [linux-sunxi] Re: sunxi-mali and FRAMEBUFFER issues

2015-02-18 Thread Simo Xefil

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 > wrote: 
>
> > On 18 February 2015 at 06:15, 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: 
> > >> 
> > >> > 
> > >> > 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 
> > >  
> > > 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 te

Re: [linux-sunxi] Re: sunxi-mali and FRAMEBUFFER issues

2015-02-18 Thread Siarhei Siamashka
On Wed, 18 Feb 2015 11:04:01 +0100
Michal Suchanek  wrote:

> On 18 February 2015 at 06:15, 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:
> >>
> >> >
> >> > 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
> > 
> > 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 fram

Re: [linux-sunxi] Re: sunxi-mali and FRAMEBUFFER issues

2015-02-18 Thread Michal Suchanek
On 18 February 2015 at 06:15, 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:
>>
>> >
>> > 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
> 
> 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

2015-02-18 Thread Bruno Prémont
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
> 
> 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

2015-02-17 Thread Siarhei Siamashka
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:
> 
> > 
> > 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

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

2015-02-17 Thread Siarhei Siamashka
On Fri, 13 Feb 2015 09:04:48 -0800 (PST)
Simo Xefil  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

2015-02-16 Thread Simo Xefil

*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 
>
> 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 .
> 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

2015-02-16 Thread Andreas Baierl

You could look into https://github.com/mittorn/a10disp and simply do a

./a10disp displayoff
./a10disp enablehdmi 

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 
.

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

2015-02-16 Thread 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.
For more options, visit https://groups.google.com/d/optout.


Re: [linux-sunxi] Re: sunxi-mali and FRAMEBUFFER issues

2015-02-16 Thread Andreas Baierl

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



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.


--
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

2015-02-16 Thread 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
>
> 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

2015-02-16 Thread Andreas Baierl

Hello Simon,
Am 13.02.2015 um 18:04 schrieb Simo Xefil:


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.


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

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 > 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 visibl

Re: [linux-sunxi] Re: sunxi-mali and FRAMEBUFFER issues

2015-02-13 Thread Simo Xefil

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 > 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

Re: [linux-sunxi] Re: sunxi-mali and FRAMEBUFFER issues

2015-02-12 Thread Siarhei Siamashka
On Thu, 12 Feb 2015 06:54:30 -0800 (PST)
Simo Xefil  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.