66 replies to this topic

[IanSav]

Hi,

 

This is a driver/hardware related issue.  The Beyonwiz team found similar image display and blending issues using the hardware modes on some hardware.

 

I am not involved with this aspect of the code but I believe if you set software emulation mode for the blending modes it should work on all/most hardware.  You will need to browse the Beyonwiz repository and forum if you want to see exactly what was done.  One of the main forum topics is http://beyonwiz.com....hp?f=54&t=12380

 

Regards,

Ian.

[Huevos]

And vu’s work a round is the way to go.... you should push the problem where it comes from and not change the code itself for some manufacturers who have a bug in the drivers...

FORCE_NO_BLENDING_ACCELERATION in config.ac does not fix the et8500. Just built that and it does not work. So we need another solution.

[littlesat]

I think not only the blend stuff should be disabled here...

[Sicilian]

Tried OpenATV ET8500, same issues. They've took onboard these changes.

 

As Huevos has posted, tested the following with OpenViX ET8500:

 

FORCE_ALPHABLENDING_ACCELERATION - same issues.

FORCE_NO_BLENDING_ACCELERATION - sames issues.

 

Before these changes with ET8500 we had:

FORCE_BLENDING_ACCELERATION

 

Dags7362 had:

FORCE_NO_BLENDING_ACCELERATION - now has issues.

 

Issues are present with a Openpli homebuild for these machines.

Edited by Sicilian, 15 April 2018 - 12:03.

[MiLo]

Maybe run a test at startup, i.e. hardware blit something and then read back the video buffer to verify the result. Only use blended accel if that test passes. Then you don't need any #ifdefs..

[ims]

But this "clearing" code (in case if #ifndef GFX_SURFACE_ACCELERATION_THRESHOLD) to one line cannot work, if this limits are important:

 

for 8bit:  something * 1 > 48000 instead "something> 12000" ???

for 32bit: something * 4 > 48000 ... it is same as "something > 12000" ,  but for 32bit we wanted "something > 48000"

Edited by ims, 15 April 2018 - 17:02.

[ims]

There could be:

GFX_SURFACE_ACCELERATION_THRESHOLD 12000
...
return (surface->y * surface->stride) >= GFX_SURFACE_ACCELERATION_THRESHOLD * surface->bypp;

 

 

Edited by ims, 15 April 2018 - 17:06.

[betacentauri]

Right. That is what I just suggested in github.

[betacentauri]

 

There could be:

GFX_SURFACE_ACCELERATION_THRESHOLD 12000
...
return (surface->y * surface->stride) >= GFX_SURFACE_ACCELERATION_THRESHOLD * surface->bypp;

 

 

Can somebody confirm, that this fixes the bug?

[pieterg]

I used a threshold in bytes, for a reason.

[pieterg]

If you are having problems now that the threshold is lower, that does NOT mean the threshold is too low.
It simply means your hardware does not support alpha blending, and the lower the threshold, the more obvious this is showing.

So do not modify the threshold, disable hardware alphablending on hardware which does not support it.

[Sicilian]

 

 

There could be:

GFX_SURFACE_ACCELERATION_THRESHOLD 12000
...
return (surface->y * surface->stride) >= GFX_SURFACE_ACCELERATION_THRESHOLD * surface->bypp;

 

 

Can somebody confirm, that this fixes the bug?

 

I could run a test build now, just one question though, line 125, should that remain at 48?

 

https://github.com/O...pixmap.cpp#L125

Edited by Sicilian, 15 April 2018 - 18:54.

[Sicilian]

 

 

There could be:

GFX_SURFACE_ACCELERATION_THRESHOLD 12000
...
return (surface->y * surface->stride) >= GFX_SURFACE_ACCELERATION_THRESHOLD * surface->bypp;

 

 

Can somebody confirm, that this fixes the bug?

 

This looks to have fixed the issue on ET8500, I'll update some other boxes and report back.

 

Thank you guys.

[Sicilian]

Looks fixed on Dags7362 boxes too.

 

https://github.com/O...0bee316c60f0df3

 

Again thanks guys.

[pieterg]

Please guys, try to disable alpha blending acceleration instead. Increasing the acceleration threshold is not a real fix, it just reduces the number of times you will notice the issue.

[Sicilian]

Please guys, try to disable alpha blending acceleration instead. Increasing the acceleration threshold is not a real fix, it just reduces the number of times you will notice the issue.

In OpenViX Dags machines had alpha blending disabled, but still had the issue prior to this fix: https://github.com/O...nfigure.ac#L347

[Abu Baniaz]

Is the "$BOXTYPE" value in this file determined by

cat /proc/stb/info/boxtype

[littlesat]

Still pieterg is 100+% right... ask these boxes to upgrade the feature or disabble the feature in a proper way... increasing the threshold is not done... that is masking out the issue... and we can discuss further on the quality software thread...

Edited by littlesat, 16 April 2018 - 06:51.

[babsy98]

we have report the issue to xtrend and xtrend have fix asap the issue

 

we have report to nextv but no answer

 

we have report to dags and dags working on a solution the box have many more framebuffer bugs  so need time for a fix

 

ini drivers cant be fixed company was dead, we have disable but drivers works incorrect openvix have report

[Huevos]

Is the "$BOXTYPE" value in this file determined by

cat /proc/stb/info/boxtype

Not in OpenViX.