Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Android: Red screen an some devices (Samsung Galaxy S3, Galaxy Note 8, Galaxy Note 2) #1265

Closed
SDLBugzilla opened this issue Feb 10, 2021 · 0 comments
Closed

Android: Red screen an some devices (Samsung Galaxy S3, Galaxy Note 8, Galaxy Note 2) #1265

SDLBugzilla opened this issue Feb 10, 2021 · 0 comments

Comments

@SDLBugzilla
Copy link
Collaborator

This bug report was migrated from our old Bugzilla tracker.

These attachments are available in the static archive:

Reported in version: 2.0.1
Reported for operating system, platform: Android (All), ARM

Comments on the original bug report:

On 2013-12-09 18:20:55 +0000, Daniel Knobe wrote:

Hallo,
i have a productive app in the androidstore and some users reported that a red screen occures an his device (Samsung Galaxy S3, original rom).

One user helped me to run testrendercopyex.c to detect if is an SDL bug. It is a bug.
I tested the default testrendercopyex.c and a modified testrendercopyex.c without rendering in a texture. Both draw a red screen. When the user creates a screenshot the screenshot shows correct drawing (no redscreen). The screen of the app stays red.

On 2013-12-11 18:03:08 +0000, Daniel Knobe wrote:

Created attachment 1488
starting testrendercopyex with and without rendering in texture

On 2013-12-11 18:04:12 +0000, Daniel Knobe wrote:

Created attachment 1489
taking screenshot testrendercopyex with and without rendering in texture

On 2013-12-11 18:06:31 +0000, Daniel Knobe wrote:

Created attachment 1490
starting testgles

On 2013-12-11 18:06:46 +0000, Daniel Knobe wrote:

Created attachment 1491
starting testgles2

On 2013-12-11 18:07:30 +0000, Daniel Knobe wrote:

Created attachment 1492
open pulldownmenu testrendercopyex with and without rendering in texture

On 2013-12-11 18:08:03 +0000, Daniel Knobe wrote:

Created attachment 1493
pressing volume testrendercopyex with and without rendering in texture

On 2013-12-11 18:15:44 +0000, Daniel Knobe wrote:

I did some more tests with a help of an S3 user.

When the app testrendercopyex starts (with and without drawing in texture) it looks like image: --starting testrendercopyex with and without rendering in texture--.

When I take i screenshot during the app is running the screenshot looks like in image: --taking screenshot testrendercopyex with and without rendering in texture-- But the drawing of the apps stays red like in the image: --starting testrendercopyex with and without rendering in texture--

When the app is running the screens gets normal, when I press a volume button or open the pulldown menu, see image: --open pulldownmenu testrendercopyex with and without rendering in texture-- or --pressing volume testrendercopyex with and without rendering in texture--. When the volumebar or the pulldownmenu disappears the screen looks again like in image: -- starting testrendercopyex with and without rendering in texture--.

Interesting note:

  • Open testrendercopyex app
  • Press home button once so that the app goes on background
  • Hold home button so that it shows running/recently used apps
  • Open app and the colors are normal

The testgles and testgles2 looks ok: --starting testgles-- and --starting testgles2--

On 2013-12-12 16:57:43 +0000, Gabriel Jacobo wrote:

Out of many possible issues, it may be a problem with the config chooser code in EGL (SDL_EGL_ChooseConfig), because of the way the colors look...hard to say for sure without some log.

On 2013-12-14 19:33:21 +0000, Daniel Knobe wrote:

Hopyfully some user will send me a log soon.
One user reported, that he has the issue on a Samsung Galaxy tab 8.0, too.

On 2013-12-18 13:43:23 +0000, Martin Gerhardy wrote:

Having the same issue here for some S3 users.

from my log I have caught the pixelformat.
current desktop mode: 1280x720@0Hz (SDL_PIXELFORMAT_RGB565)

Please let me know what else I can log. I don't have such a device and would have to wait for users to report anything. But of course I would update my app to include the needed logging. Getting a adb logcat output from such a device would also not be a problem.

On 2013-12-18 14:15:17 +0000, Martin Gerhardy wrote:

works here:
current desktop mode: 800x480@0Hz (SDL_PIXELFORMAT_RGB565)

On 2013-12-19 10:43:31 +0000, Martin Gerhardy wrote:

Galaxy Note 8.0 (kona3g) is affected by this error, too

On 2013-12-19 13:48:55 +0000, Gabriel Jacobo wrote:

@martin, are you using the SDL render functions or calling GLES directly?

If you are testing with testrendercopyex, what about adding:

state->gl_red_size = 8;
state->gl_green_size = 8;
state->gl_blue_size = 8;

...before creating the window?

On 2013-12-19 13:53:43 +0000, Martin Gerhardy wrote:

I'm using the SDL renderer stuff. But I don't think I can execute the test on the users devices. I could only test my apk by handing them over to the user by beta test stage in the google play store. Will add it and report back:

    SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 8);
    SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 8);
    SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 8);

On 2013-12-19 15:25:22 +0000, Martin Gerhardy wrote:

I tried that and the user report that I didn't change anything.

There was also some more details about the issue. The first few milliseconds (just as long to notice it) the screen is correct. Then it changes to red.

On shutting down the app it's right again for a very short moment.

On 2013-12-20 08:56:37 +0000, Sylvain wrote:

Hello,

I talked a few days ago with Daniel, and my apps worked fine with his user.

@martin :

Could you try adding only this attribute before SDL_CreateWindow :

SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 0);

On some device, I saw the egl-config choosen were a little bit different.

Otherwise, could this commit has an effet https://hg.libsdl.org/SDL/rev/a5f8137ccf01 ?

On 2013-12-20 10:14:42 +0000, Martin Gerhardy wrote:

@Sylvain: I'm already doing this. This is and was my default behaviour.

On 2013-12-21 00:29:32 +0000, Daniel Knobe wrote:

Created attachment 1501
Logcat from User S3

On 2013-12-21 00:31:40 +0000, Daniel Knobe wrote:

An User send me an logcat (see attachment).
He found out another way to get it solved by doing the following steps:

  • Open app phone in vertical position
  • Flip phone to horisontal position
  • press home key once
  • hold home key and open the app again

If he don't flip it the app still appears reddish.

Someone an idea?

On 2013-12-31 11:23:25 +0000, Martin Gerhardy wrote:

One of my users also reported the volume buttons "fix". He even managed to keep in in a non-red-version for further playing. But often it's the case the whenever the volume change overlay is gone, that the screen gets red again.

On 2014-01-05 11:47:02 +0000, Daniel Knobe wrote:

Created attachment 1513
Logcat from User S3, Android 4.1.2 (Samsung TouchWiz Stock Rom)

On 2014-01-05 12:44:48 +0000, Martin Gerhardy wrote:

I own a S3 now, too. So please let me know what exactly I should log in order to help here.

Btw. when the adsview gets active, the red screen is gone, too and everything looks normal.

D/dalvikvm( 2081): Trying to load lib /data/data/org.caveexpress/lib/libSDL2.so 0x4292b870
D/dalvikvm( 2081): Added shared lib /data/data/org.caveexpress/lib/libSDL2.so 0x4292b870
D/dalvikvm( 2081): Trying to load lib /data/data/org.caveexpress/lib/libSDL2_image.so 0x4292b870
D/dalvikvm( 2081): Added shared lib /data/data/org.caveexpress/lib/libSDL2_image.so 0x4292b870
D/dalvikvm( 2081): No JNI_OnLoad found in /data/data/org.caveexpress/lib/libSDL2_image.so 0x4292b870, skipping init
D/dalvikvm( 2081): Trying to load lib /data/data/org.caveexpress/lib/libSDL2_mixer.so 0x4292b870
D/dalvikvm( 2081): Added shared lib /data/data/org.caveexpress/lib/libSDL2_mixer.so 0x4292b870
D/dalvikvm( 2081): No JNI_OnLoad found in /data/data/org.caveexpress/lib/libSDL2_mixer.so 0x4292b870, skipping init
D/dalvikvm( 2081): Trying to load lib /data/data/org.caveexpress/lib/libSDL2_net.so 0x4292b870
D/dalvikvm( 2081): Added shared lib /data/data/org.caveexpress/lib/libSDL2_net.so 0x4292b870
D/dalvikvm( 2081): No JNI_OnLoad found in /data/data/org.caveexpress/lib/libSDL2_net.so 0x4292b870, skipping init
V/SDL ( 2081): onResume()
V/SDL ( 2081): onPause()
V/SDL ( 2081): surfaceCreated()
V/SDL ( 2081): surfaceChanged()
V/SDL ( 2081): pixel format RGB_565
V/SDL ( 2081): Window size:720x1280
D/SensorManager( 2081): registerListener :: handle = 0 name= LSM330DLC 3-axis Accelerometer delay= 20000 Listener= org.libsdl.app.SDLSurface@429496b0
I/SDL ( 2081): SDL_Android_Init()
I/SDL ( 2081): SDL_Android_Init() finished!
I/SDL ( 2081): external storage state: mounted
I/caveexpress 1.5( 2081): INFO: (LOG_CLIENT) current desktop mode: 720x1280@0Hz (SDL_PIXELFORMAT_RGB565)
E/caveexpress 1.5( 2081): ERROR: (LOG_CLIENT) That operation is not supported (jni/src/client/SDLFrontend.cpp:652 => virtual int SDLFrontend::init(int, int, bool, EventHandler&))
I/caveexpress 1.5( 2081): INFO: (LOG_CLIENT) 720x1280@0Hz SDL_PIXELFORMAT_RGB565
V/SDL ( 2081): SDL audio: opening device
V/SDL ( 2081): SDL audio: wanted stereo 16-bit 44.1kHz, 4096 frames buffer
V/SDL ( 2081): SDL audio: got stereo 16-bit 44.1kHz, 4096 frames buffer

On 2014-01-05 13:52:38 +0000, Gabriel Jacobo wrote:

You can try a couple of things...since IIRC this seems to be related to the Render* functions.

  1. Try forcing the ES 1.1 renderer, and see what happens
  2. Go to GLES_RenderCopy and GLES2_RenderCopyEx and trace the code that selects the source type and then selects a program with GLES2_SelectProgram. If I had to bet, I would say there could be a problem there.

Other than that, experiment to try to narrow the problem down. The best shot at solving this is troubleshooting with the device in hand.

On 2014-01-05 14:39:46 +0000, Sylvain wrote:

If needed, I can help to build .apk to track down the problem.

@martin, do you need help for that ?
Is the red screen always reproducible with your S3 ?

On 2014-01-05 17:48:25 +0000, Martin Gerhardy wrote:

using gles1 works, looks like only gles2 is affected.

will try to debug GLES2_RenderCopyEx now.

On 2014-01-05 18:15:14 +0000, Martin Gerhardy wrote:

oh sorry. Yes, the red screen is always reproducible with my s3 and the gles2 renderer

On 2014-01-09 09:56:53 +0000, Martin Gerhardy wrote:

now also gles1.x has the error again - so both of the gles renderers are affected.

@Sylvain Which apk would you build?

My logging from the rendercopyex function did not yet revealed anything suspicious

On 2014-01-09 10:18:47 +0000, Sylvain wrote:

@martin,

I was asking if you needed some help to build/debug the SDL.
But it seems, you know how to do that.

You have the chance to have the device to reproduce your bug, so this is great.

To debug that, I would suggest to see if this is a regression : take an older (10 month old) revision of the SDL, and see if you can get the bug with that version !

On 2014-01-10 15:56:14 +0000, Martin Gerhardy wrote:

nailed it down to SDL_EGL_ChooseConfig.

Only using this:
attribs[i++] = EGL_RED_SIZE;
attribs[i++] = 5;
attribs[i++] = EGL_GREEN_SIZE;
attribs[i++] = 6;
attribs[i++] = EGL_BLUE_SIZE;
attribs[i++] = 5;
attribs[i++] = EGL_SAMPLES;
attribs[i++] = 4;
attribs[i++] = EGL_NONE;
fixes the problem.

More information as I have more ;)

On 2014-01-10 15:58:13 +0000, Martin Gerhardy wrote:

it really is "only" about wrong values in:
_this->gl_config.red_size, _this->gl_config.green_size and _this->gl_config.blue_size

Setting them manually works. Investigating more.

On 2014-01-10 16:01:28 +0000, Martin Gerhardy wrote:

haha - all in all, it was my own fault.

i have several classes that inherit from each other and i had a typo in one of the derived classes. So for android i also called :

SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 8);
SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 8);
SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 8);

fixed the typo in the method name of the android specific class and thus not calling SDL_GL_SetAttribute(SDL_GL_*_SIZE, xxx); at all fixes the problem. Let me know whether this also fixed it for you. If you have apks for me to test on my device, let me know, too.

On 2014-01-10 16:03:27 +0000, Martin Gerhardy wrote:

erm. sorry. calling
SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 6);
SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 5);
SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 6);
in the android glue code. that fixes the problem. I'm not yet sure why a wrong value was picked for this before.

On 2014-01-10 16:24:32 +0000, Martin Gerhardy wrote:

E/SDL/ERROR( 7390): Failed loading eglChooseConfig: Invalid library handle:

On 2014-01-10 16:30:54 +0000, Martin Gerhardy wrote:

the eglChooseConfig is not the reason - another user with a working device just send me this:
Failed loading eglChooseConfig: dlsym library handle is null

On 2014-01-10 16:45:45 +0000, Martin Gerhardy wrote:

with a lot of logging I was able to tackle this issue on my side. My problem was that I was calling SDL_VideoInit manually after calling SDL_Init(SDL_INIT_VIDEO). This leads to overriding the parameters set by SDL_GL_SetAttribute and set them back to the default values. So my RGB565 was ignored. I hope this helps on your side. Make sure to call SDL_Init(SDL_INIT_VIDEO) before doing the SDL_GL_SetAttribute calls and don't call SDL_VideoInit manually.

On 2014-01-10 18:11:56 +0000, Daniel Knobe wrote:

So SDL sets the parameters wrong on S3 by default. Hopyfully we get this fixed soon!

On 2014-01-10 18:20:31 +0000, Gabriel Jacobo wrote:

I don't think the error is in SDL, at least according to what Martin has found.

On 2014-01-10 18:28:45 +0000, Gabriel Jacobo wrote:

@martin, can you figure out why testrendercopyex with the default SDL android project shows this bug as well?

On 2014-01-10 19:34:14 +0000, Martin Gerhardy wrote:

SDL is not setting wrong values - it does not set any value by default as far as I can see.

And it looks like the S3 is really picky about the values there - setting anything else than RGB656 doesn't seem to work.

@gabriel: The problem is that SDLTest_CommonCreateState does not set 656, but 332 - which the S3 can't handle. Setting this to 656 will do the trick.

Btw. is there a way to determine this before the window is created? I get the correct pixel format for the display modes of the window - but I would need it earlier to the the rgb sizes. This isn't possible, as the function would require a window pointer ;)
Did I miss something?

On 2014-01-17 19:13:24 +0000, Martin Gerhardy wrote:

anything new here? has anyone an advice how to fix it properly without hardcoding the color sizes?

On 2014-01-18 10:06:00 +0000, Sylvain wrote:

@martin,
on my apps, I don't hardcode the color size. And I think I got no problem on S3.
(maybe you can double check my apps on your S3)

I call :

SDL_Init(SDL_INIT_VIDEO)
SDL_Init(SDL_INIT_AUDIO)
SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 0);
SDL_GL_SetAttribute(SDL_GL_RETAINED_BACKING, 0);
SDL_CreateWindow
SDL_CreateRenderer

Notice that SDL_VideoInit internally set {red, green, blue}_size at (3,3,2)
which should be sent to eglChooseConfig to get an optimal config.

Maybe you need to dump:

  • the egl config asked (before calling eglChooseConfig)
  • all the egl configuration available + print the "bitdiff" (see SDL_egl.c)
  • the egl config actually selected

@gabriel,
I see the "depth_size" is by default "16".
and, I have seen sometimes this case.
application request by default (red_size, green_size, red_size, depth_size)
(3,3,2,16)
the closest is (3,3,2,18) which appears to be very slow.
but a better one (4,4,4,16) is then not selected.

Sometimes, I saw a weight of 10 is affected on the "objective function" to select the optimisal config.

I have seen also there is an attribute EGL_SLOW_CONFIG that could be usefull :)

On 2014-01-20 20:15:45 +0000, Daniel Knobe wrote:

The Galaxy Note 2 (Android 4.3) has the problem, too. :-/

On 2014-01-21 15:00:25 +0000, Gabriel Jacobo wrote:

My intuition tells me this is a problem with the GLES2 shaders. Let's say you don't define the RGB size and end up with a 332 for the screen, what texture format are you using? SDL_RenderCopy/Ex needs to determine the right shader to blit the texture correctly (and map the colors correctly as well if you are mixing, for example, ARGB with RGBA), and this is probably failing.

So, to better figure this out, it may be useful to let SDL choose the 332 format for the screen, make a note of what texture format you are using, and see what shader gets picked via GLES2_SelectProgram. Then, try playing with that shader to figure out what needs to be fixed.

I'm just guessing here, but it may very well be that other devices don't support a 332 format (or whatever ends up being picked by SDL), and that's why we don't see the problem more often.

On 2014-03-30 13:16:33 +0000, Daniel Knobe wrote:

Nothing new about that problem?

On 2014-04-02 21:13:42 +0000, Daniel Knobe wrote:

Sylvain was right:
SDL_GL_SetAttribute(SDL_GL_DEPTH_SIZE, 0);
fixes the problem. Really strange.

On 2014-04-10 10:18:19 +0000, Sylvain wrote:

@martin, what about you? does this fix your red-screen too ? can you double-check ?

@gabriel, I think Daniel does not use shaders but maybe Martin does

@daniel :

I think we should not let something strange get fixed like this.
I try to explain my guess ( but Gabriel is the expert:) ) :

There are several different opengl "configs" available on each device.
And one configuration has to be choosen/set to start rendering !

You choose your configuration by giving a set of parameter (size of depth, red, green, blue, and so on),
and finding the closest matching configuration available on the device.

SDL has already a set of default parameters.
But, in your Game/Application you can override them (with the SDL_GL_SetAttribute() calls!).

SDL uses its default parameters, your requirements, and find the closed opengl configuration available :

There are two ways to do that :
1/ Easy way : use an API to ask the closest matching configuration
2/ Manual way : browse all configurations, compute for each configuration an "absolute error", and in the end, select the configuration with minimum error.
(The "absolute error" is the sum of all the absolute value of differences between the required value and the available (currently browsed) config. It always increase as the browsed config gets different, so selecting the one with minimun error mean finding the closest matching).

Historically we were using (2) in Java language, then (1) in C language, then (2) in C language.

Often, there is already a perfect match so it works!
Sometimes a near match is found but it can :

  • be very slow (happens to me on some devices because depth-18 was choosen)
  • produce red-screen like on your device (could this be a SDL bug?)
  • and also work correctly :)

Then :

Maybe :

  • you could dump all configs inside SDL code (with basic prinfs in SDL_egl.c).
    so that we understand : what configuration is asked, what configuration are available, and which one get choosen.

(Also, with your parameters, what method (1) would have choosen ?)

  • With this information, maybe we could try to set the same context that is choosen on your device and understand why SDL is making a red-screen. Maybe there are some format conversion function missing in SDL.

Cheers.
Sylvain

On 2014-04-13 07:49:27 +0000, Daniel Knobe wrote:

For me its not possible to check all that stuff :-/, because I'm not owning an affected Samsung device. Is there somebody else how can do that? Martin?

On 2014-06-27 13:48:52 +0000, ardi wrote:

This bug is a showstopper for me, because I need to allocate a depth buffer on Android devices and, if I'm reading this thread correctly, the workaround for this S3 issue is to avoid allocating a depth buffer...

On 2014-06-28 07:38:53 +0000, Sylvain wrote:

ardi,
I am note sure "depth" buffer is missing.
It's more like "we ask to eglConfig a config no depth buffer, to solve the red screen issue."
Maybe there are configurations with depth buffer, that are working.

Do you have a Samsung S3 ?

On 2014-06-28 15:56:43 +0000, Gabriel Jacobo wrote:

FWIW, I just tried testrendercopyex and testgles2 on a 2014 Samsung Galaxy Tab 12, and both worked perfectly.

On 2014-06-29 09:28:16 +0000, wrote:

I guess I'll add my 2 cents.

The same red tint is happening in OpenXcom android port on some Samsung devices (see http://openxcom.org/forum/index.php?topic=1864.msg16739#msg16739 for an example), and the solution is to disable hardware overlay in developer settings.

OpenXcom uses SDL1.2 and renders to a SDL_Surface, the Android port uses SDL2 and uploads the contents of that SDL_Surface to a SDL_Texture. I get the same effect if there's a mismatch between [RGBA]masks of the surface and pixelformat of the texture (i.e. if I set masks for ARGB8888 and texture's pixelformat is RGBA8888). Unfortunately I don't have a Samsung device, so I can't confirm if setting format to RGBA8888 solves the problem (and if it's something in the Samsung's Android implementation that forces texture pixelformat).

Hope this helps!

On 2014-06-30 14:52:51 +0000, Gabriel Jacobo wrote:

Can anyone with access to a S3 or other of the affected devices print the output of the config selection loop in SDL_EGL_ChooseConfig ? (It's the loop that starts on line 363 of SDL_egl.c)
If we get a complete dump of the modes with SDL_GL_DEPTH_SIZE==0 and SDL_GL_DEPTH_SIZE!=0 and what ends up being selected we may gain some insight into what's going on here.

I did some research on the pixel formats of the native surface, it seems a ARGB format is not available, so that should not (in theory) be the problem.

Also, if you have better ideas (or patches!) to improve the very crude config selection that we do to select the best configuration, they'll be most welcome!

On 2014-06-30 22:49:45 +0000, Sylvain wrote:

Created attachment 1721
patch dump of egl params

No access to S3 ..

but, here's a patch for "SDL_egl.c" to dump all configs + the attribs requests.

Easy to activate for someone who wants to use it : just uncomment the DEBUG_EGL_CONFIG.

On 2014-07-01 08:22:57 +0000, Martin Gerhardy wrote:

I will try that patch and post the output. Imo this patch should go upstream. And maybe it should get activated by a hint or something like that. That way we could get the data even from users without recompiling anything.

On 2014-07-01 08:47:27 +0000, Martin Gerhardy wrote:

got a segfault in Android_JNI_GetTouchDeviceIds - will investigate

On 2014-07-01 16:51:25 +0000, Sylvain wrote:

Martin, yep, that would be great.

Also, Here's a new version of the patch so that the "value" of each attrib is also converted to a string.

On 2014-07-01 16:51:59 +0000, Sylvain wrote:

Created attachment 1722
patch dump of egl params

On 2014-07-01 18:10:51 +0000, Martin Gerhardy wrote:

I will post the data from the updated patch. But first I have to get my head around this strange segfault. The mid is NULL - really strange, because it's definitely there in the java file. But I'm on it - must be some local build env error.

On 2014-07-01 18:29:24 +0000, Martin Gerhardy wrote:

btw. this might help, too:
http://stackoverflow.com/questions/10758975/how-can-i-create-an-egl-context-
from-a-native-function-when-the-nativewindowtype

examples:
https://github.com/bkaradzic/bgfx/blob/master/src/glcontext_egl.cpp
https://github.com/floooh/oryol/blob/master/code/Modules/Render/egl/eglDisplayMgr.cc

I will try both on my S3 to see whether it works with those libs - but of course first SDL with the latest patch.

On 2014-07-01 19:06:55 +0000, Gabriel Jacobo wrote:

It may be worth adding ANativeWindow_setBuffersGeometry if it fixes the problem...can you try it?

On 2014-07-03 07:42:17 +0000, Martin Gerhardy wrote:

I will try it of course, too. I should have the time today to test all the stuff. Will report back.

On 2014-07-03 08:03:58 +0000, Martin Gerhardy wrote:

Created attachment 1726
dump of egl variables

the testgles works fine on my S3 now (also no red screen there). But i'm also not sure whether the test was ever broken. For my app this only happened after a second call to SDL_InitVideo (see my comments above)

On 2014-07-03 10:44:58 +0000, Daniel Knobe wrote:

testgles was never broken. Only testrendercopyex has the redscreen.

On 2014-07-03 12:11:47 +0000, Martin Gerhardy wrote:

Created attachment 1727
dump of egl variables for rendercopyex test

On 2014-07-03 12:15:31 +0000, Martin Gerhardy wrote:

@gabriel - is there a hint on to include the bitmaps in the apk with the android build script? I can't find it. I'm not sure whether the current egl vars are useful, because the test doesn't work without the sprites loading.

On 2014-07-03 20:37:51 +0000, Gabriel Jacobo wrote:

Let me know if this fixes it: https://hg.libsdl.org/SDL/rev/c30e826412d1

Otherwise we may try requesting a config with EGL_NATIVE_VISUAL_ID == 7 on Android.

On 2014-07-04 21:36:28 +0000, ardi wrote:

Thanks a lot for all this effort. I don't have an S3 for testing, but I need that this bug is fixed for targetting Android. So, thanks a lot, and I hope the patch by Gabriel fixes it. I'm following the findings on this bug. Thanks a lot.

On 2014-07-08 13:19:16 +0000, Gabriel Jacobo wrote:

@martin, did you get a chance to test the fix?

On 2014-07-08 13:40:57 +0000, Martin Gerhardy wrote:

@gabriel: See my comment from 2014-07-03 12:15:31 UTC

I didn't had the time to fix or extend the build script or to do it manually. If there is an automated way, please let me know - otherwise I will try to copy the bitmaps manually and rebuild the apk manually. But that might take soem time.

On 2014-07-08 13:43:27 +0000, Gabriel Jacobo wrote:

After the build script finishes and before running "ant debug install", just create an "assets" folder and copy every *.bmp file from test there.

On 2014-07-08 17:57:50 +0000, Martin Gerhardy wrote:

unfortunately the proposed fix doesn't fix it.

On 2014-07-08 18:00:33 +0000, Martin Gerhardy wrote:

not sure whether it was mentioned before - but the first frame(s) look(s) fine.

On 2014-07-08 18:19:49 +0000, Martin Gerhardy wrote:

the error is definitely in SDL_EGL_ChooseConfig for ( i=0; i<found_configs; i++ ) { ... }

if i do:

if (_this->egl_data->eglChooseConfig(_this->egl_data->egl_display, attribs, &_this->egl_data->egl_config, 1, &found_configs) == EGL_FALSE || found_configs == 0) {
    return SDL_SetError("Couldn't find matching EGL config");
}
return 0;

it works perfectly.

On 2014-07-08 18:25:36 +0000, Martin Gerhardy wrote:

just doing this:

    if (bitdiff < best_bitdiff || best_bitdiff == -1) {
        _this->egl_data->egl_config = configs[0];
        
        best_bitdiff = bitdiff;
    }

works perfectly, too.

so it "just" picks the wrong config

On 2014-07-08 18:30:17 +0000, Gabriel Jacobo wrote:

Yes, we need to know why. That's what this whole exercise is about :)

On 2014-07-08 18:42:18 +0000, Martin Gerhardy wrote:

if this behaviour with the bitdiff is really needed - then maybe there should be a hint to disable it. as far as i know eglChooseConfig will always return at least the requested type - but maybe higher values - in our case we e.g. request 565 and get 888 - which has a higher diff than the format we requested. it's still weird that the mode we finally requested isn't working.

btw. the bestdiff stuff is also weird because it doesn't really take into account that there might be several modes with the same diff - which one is better then?

I/SDL/APP (20206): Dump config 8
I/SDL/APP (20206): {
I/SDL/APP (20206): EGL_ALPHA_SIZE => 4
I/SDL/APP (20206): EGL_ALPHA_MASK_SIZE => 0
I/SDL/APP (20206): EGL_BIND_TO_TEXTURE_RGB => EGL_TRUE (1 == 0x00000001)
I/SDL/APP (20206): EGL_BIND_TO_TEXTURE_RGBA => EGL_TRUE (1 == 0x00000001)
I/SDL/APP (20206): EGL_BLUE_SIZE => 4 ******* (requested=2, diff=2)
I/SDL/APP (20206): EGL_BUFFER_SIZE => 16
I/SDL/APP (20206): EGL_COLOR_BUFFER_TYPE => EGL_RGB_BUFFER (12430 == 0x0000308e)
I/SDL/APP (20206): EGL_CONFIG_CAVEAT => EGL_NONE (12344 == 0x00003038)
I/SDL/APP (20206): EGL_CONFIG_ID => 21
I/SDL/APP (20206): EGL_CONFORMANT => 0x00000005 (5 == 0x00000005)
I/SDL/APP (20206): EGL_DEPTH_SIZE => 24 ******* (requested=16, diff=8)
I/SDL/APP (20206): EGL_GREEN_SIZE => 4 ******* (requested=3, diff=1)
I/SDL/APP (20206): EGL_LEVEL => 0
I/SDL/APP (20206): EGL_LUMINANCE_SIZE => 0
I/SDL/APP (20206): EGL_MAX_PBUFFER_WIDTH => 4096
I/SDL/APP (20206): EGL_MAX_PBUFFER_HEIGHT => 4096
I/SDL/APP (20206): EGL_MAX_PBUFFER_PIXELS => 16777216
I/SDL/APP (20206): EGL_MAX_SWAP_INTERVAL => 10
I/SDL/APP (20206): EGL_MIN_SWAP_INTERVAL => 0
I/SDL/APP (20206): EGL_NATIVE_RENDERABLE => EGL_TRUE (1 == 0x00000001)
I/SDL/APP (20206): EGL_NATIVE_VISUAL_ID => 7
I/SDL/APP (20206): EGL_NATIVE_VISUAL_TYPE => 0
I/SDL/APP (20206): EGL_RED_SIZE => 4 ******* (requested=3, diff=1)
I/SDL/APP (20206): EGL_RENDERABLE_TYPE => 0x00000005 (5 == 0x00000005) ******* (requested=4, diff=1)
I/SDL/APP (20206): EGL_SAMPLE_BUFFERS => 0
I/SDL/APP (20206): EGL_SAMPLES => 0
I/SDL/APP (20206): EGL_STENCIL_SIZE => 8
I/SDL/APP (20206): EGL_SURFACE_TYPE => 0x00000405 (1029 == 0x00000405)
I/SDL/APP (20206): EGL_TRANSPARENT_TYPE => EGL_NONE (12344 == 0x00003038)
I/SDL/APP (20206): EGL_TRANSPARENT_RED_VALUE => -1
I/SDL/APP (20206): EGL_TRANSPARENT_GREEN_VALUE => -1
I/SDL/APP (20206): EGL_TRANSPARENT_BLUE_VALUE => -1
I/SDL/APP (20206): }
I/SDL/APP (20206): bitdiff = 12
I/SDL/APP (20206): New best bitdiff = 12 !

this is the mode i finally get

I/SDL/APP (16088): Dump config 0
I/SDL/APP (16088): {
I/SDL/APP (16088): EGL_ALPHA_SIZE => 0
I/SDL/APP (16088): EGL_ALPHA_MASK_SIZE => 0
I/SDL/APP (16088): EGL_BIND_TO_TEXTURE_RGB => EGL_TRUE (1 == 0x00000001)
I/SDL/APP (16088): EGL_BIND_TO_TEXTURE_RGBA => EGL_TRUE (1 == 0x00000001)
I/SDL/APP (16088): EGL_BLUE_SIZE => 8 ******* (requested=5, diff=3)
I/SDL/APP (16088): EGL_BUFFER_SIZE => 32
I/SDL/APP (16088): EGL_COLOR_BUFFER_TYPE => EGL_RGB_BUFFER (12430 == 0x0000308e)
I/SDL/APP (16088): EGL_CONFIG_CAVEAT => EGL_NONE (12344 == 0x00003038)
I/SDL/APP (16088): EGL_CONFIG_ID => 32
I/SDL/APP (16088): EGL_CONFORMANT => 0x00000005 (5 == 0x00000005)
I/SDL/APP (16088): EGL_DEPTH_SIZE => 24 ******* (requested=16, diff=8)
I/SDL/APP (16088): EGL_GREEN_SIZE => 8 ******* (requested=5, diff=3)
I/SDL/APP (16088): EGL_LEVEL => 0
I/SDL/APP (16088): EGL_LUMINANCE_SIZE => 0
I/SDL/APP (16088): EGL_MAX_PBUFFER_WIDTH => 4096
I/SDL/APP (16088): EGL_MAX_PBUFFER_HEIGHT => 4096
I/SDL/APP (16088): EGL_MAX_PBUFFER_PIXELS => 16777216
I/SDL/APP (16088): EGL_MAX_SWAP_INTERVAL => 10
I/SDL/APP (16088): EGL_MIN_SWAP_INTERVAL => 0
I/SDL/APP (16088): EGL_NATIVE_RENDERABLE => EGL_TRUE (1 == 0x00000001)
I/SDL/APP (16088): EGL_NATIVE_VISUAL_ID => 2
I/SDL/APP (16088): EGL_NATIVE_VISUAL_TYPE => 0
I/SDL/APP (16088): EGL_RED_SIZE => 8 ******* (requested=5, diff=3)
I/SDL/APP (16088): EGL_RENDERABLE_TYPE => 0x00000005 (5 == 0x00000005) ******* (requested=1, diff=4)
I/SDL/APP (16088): EGL_SAMPLE_BUFFERS => 0
I/SDL/APP (16088): EGL_SAMPLES => 0
I/SDL/APP (16088): EGL_STENCIL_SIZE => 0
I/SDL/APP (16088): EGL_SURFACE_TYPE => 0x00000407 (1031 == 0x00000407)
I/SDL/APP (16088): EGL_TRANSPARENT_TYPE => EGL_NONE (12344 == 0x00003038)
I/SDL/APP (16088): EGL_TRANSPARENT_RED_VALUE => -1
I/SDL/APP (16088): EGL_TRANSPARENT_GREEN_VALUE => -1
I/SDL/APP (16088): EGL_TRANSPARENT_BLUE_VALUE => -1
I/SDL/APP (16088): }
I/SDL/APP (16088): bitdiff = 17
I/SDL/APP (16088): New best bitdiff = 17 !

this is the mode that works

What if we just say - if we get a mode that has a diff of 0 => pick it - otherwise just choose the first one. I've checked the other two projects i've linked earlier and both are working - both just take the first returned config.

On 2014-07-08 18:47:50 +0000, Martin Gerhardy wrote:

Created attachment 1741
proposed patch to fix the issue

This fixes the issue for me - tested on S1, S2 and S3 (only S3 was affected - but I wanted to make sure that it still works on the others)

On 2014-07-08 18:56:52 +0000, Gabriel Jacobo wrote:

I don't think selecting the first config available is the solution here though it may fix this particular issue. We can modify the selection algorithm though, suggestions on that are welcome.

On 2014-07-08 19:00:57 +0000, Gabriel Jacobo wrote:

It looks like the source of problems is with EGL_NATIVE_VISUAL_ID and maybe EGL_NATIVE_VISUAL_TYPE. Can you try adding a EGL_NATIVE_VISUAL_ID==7 (or some other value) to the bitdiff logic and see if that makes the algorithm select a valid choice?

On 2014-07-08 19:05:58 +0000, Martin Gerhardy wrote:

I don't have any other suggestion than that - just judging from all the engines I've digged in order to see how they are doing it - and of course from the fact that the selection is already done as good as it could be.

According to e.g. blackbarry docs [1] (and also some others), it's fine to just pick the first one.

I'm not sure what exactly speaks against this in the SDL context - can you explain?

[1] http://docs.blackberry.com/en/developers/deliverables/17967/Configure_EGL_1232264_11.jsp

On 2014-07-08 19:06:31 +0000, Martin Gerhardy wrote:

yes - will try to do the EGL_NATIVE_VISUAL_ID stuff

On 2014-07-08 19:53:29 +0000, Martin Gerhardy wrote:

SDL_Log("eglGetConfigAttrib(EGL_NATIVE_VISUAL_ID) => %i - original value was: %i\n", format, ANativeWindow_getFormat(nw));

this gives 7 with original value of 4

if i skip EGL_NATIVE_VISUAL_ID 7 i get a working mode (555)

the original mode of 4 works fine. so (at least for android) it would also be a valid fix to choose the config that has the EGL_NATIVE_VISUAL_ID set to ANativeWindow_getFormat(nw)

On 2014-07-09 06:59:52 +0000, Sylvain wrote:

Hi! See in the dump log the "request = " this is the asked parameters.
Config_8 (not working) and Config_0 (working) have been obtained by requesting difference set of parameters :
r/g/b/depth = 3/3/2/16 for Cfg0 and 5/5/5/16 for Cfg8.

is that correct or did the "attrib[]" table is changing wrongly? because this is use for the BitDiff !

Also. A SDL question : once we got a Config, why dont we never tell SDL about the retrieved configuration. Isn't it necessay for interna Format conversion ?

On 2014-07-16 16:47:36 +0000, Sylvain wrote:

Hey,

So I got a S3. I have updated to the latest trunk. I am able to reproduce the bug with my applications.

What happens:

The screen is blinking once red each time SDL_RenderPresent() is called.

Adding:

SDL_GL_SetAttribute(SDL_GL_RETAINED_BACKING, 0);

solves this issue.

(the call to ANativeWindow_setBuffersGeometry is done, but that does not solve the issue).

On 2014-07-16 16:52:11 +0000, Gabriel Jacobo wrote:

A possible solution I was toying with was getting (for Android only) the pixel format with is filtering the configs selecting those that match the native format returned by ANativeWindow_getFormat. I'll get a patch at some point done, but feel free to try that idea out in the meantime.

On 2014-07-16 17:08:38 +0000, Sylvain wrote:

Created attachment 1764
dump of config ok, and error.

Here's dump a config OK and BlinkRed.
the only difference what done by asking a depth of 0.

On 2014-07-16 17:09:43 +0000, Sylvain wrote:

I will look at ANativeWindow_getFormat after! thanks.
but the bug look very strange : it just blinks red once each SDL_RenderPresent, then the display is absolutely correct.

On 2014-07-16 18:58:46 +0000, Sylvain wrote:

ANativeWindow_get format gives a relevant value after the config has be set.

in my previous example, when the good config is set, the format is 4.
For the blink red config, the format is 7.

29 enum {
30 WINDOW_FORMAT_RGBA_8888 = 1,
31 WINDOW_FORMAT_RGBX_8888 = 2,
32 WINDOW_FORMAT_RGB_565 = 4,
33 };

On 2014-07-16 21:27:57 +0000, Sylvain wrote:

Created attachment 1765
Samsung S3 spreadsheet

Here's a spread sheet with all configurations of the galaxy S3.
I tried the 19 configs:

  • three of them are broken with a red screen blinking (21/22/23)
  • one is broken with the screen reverse + shift of colors (40)
  • and others are working correctly.

All the red-screened configs have a EGL_NATIVE_VISUAL_ID of 7. And there are the only one to have this value of 7.
And the other (40) one has a wrong(?) EGL_NATIVE_VISUAL_ID (842094169).

This EGL_NATIVE_VISUAL_ID also seems to be the same value returned from ANativeWindow_geFormat.

A solution would be to had a penalty to EGL_NATIVE_VISUAL_ID of 7 (not to discard those configs absolutely).

_this->egl_data->eglGetConfigAttrib(_this->egl_data->egl_display, configs[i], EGL_NATIVE_VISUAL_ID, &value);
if (value == 7)
{
bitdiff += 1000;
}

Maybe this happens on other phones?
My HTC has no config of visual id 7.

On 2014-07-17 21:39:55 +0000, Sylvain wrote:

A few updates :

  • A mistake in one of my previous message : ANativeWindow_getFormat() returns a value of "4" before choosing any egl-config on the S3.
    So we could filter the configs with this value. That would solve the samsung S3 issue, but we would also discard some working config and could produce bug on other hardware.

  • I have tried an android 2.3.3 motorola defy, and a nexus7. All configs are working,
    the 'defy' has a few slow configs that are correctly displaying but unusable though.

  • According to http://developer.android.com/reference/android/app/NativeActivity.html
    EGL_NATIVE_VISUAL_ID is an attribute of the EGLConfig that is guaranteed to be accepted by ANativeWindow_setBuffersGeometry().
    But this is not always the case. On the S3, one problematic EGL_NATIVE_VISUAL_ID has a value 842094169 (and not working).
    I think, I saw on the motorolla a EGL_NATIVE_VISUAL_ID of 8 (but working correctly).

We can had "big" penalties to sort out the problematic configs, without discarding them totally. A big enough offset so that it cannot be catch-up by small diff.
The problematic configs would be choosen only if no working config are avaiblable.

something like :

_this->egl_data->eglGetConfigAttrib(_this->egl_data->egl_display, configs[i], EGL_NATIVE_VISUAL_ID, &value);
if (value == 1 || value == 2 || value == 4)
{
// no penalty, most usual case. So we should select those configs first!
}
else if (value == 7)
{
// Biggest penalty. Samsung S3
bitdiff += 5000;
}
else if (value > 7)
{
// ? Also big penalty ?
}
else
{
// Medium penalty for intermediate. (because format is bitmask?)
bitdiff += 500;
}

_this->egl_data->eglGetConfigAttrib(_this->egl_data->egl_display, configs[i], EGL_CONFIG_CAVEAT, &value);
if (value == EGL_SLOW_CONFIG)
{
// Medium penalty.
bitdiff += 500;
}

On 2014-07-17 21:54:16 +0000, Gabriel Jacobo wrote:

This is all work arounds to what seems to me a problem in the custom Android that Samsung is shipping (there's reports that this issues does not happen with Cyanogen). I wouldn't hardcode a value of 7 (which seems an OR'ed value of the 3 pixel formats), instead we can either prioritize or just only select those formats that have EGL_NATIVE_VISUAL_ID == ANativeWindow_getFormat.

Or we can just embrace the workaround nature of this and apply this extra logic (or whatever funky logic we come up with) only for these models:

#include <sys/system_properties.h>
char model_string[PROP_VALUE_MAX+1];
__system_property_get("ro.product.model", model_string);

Ref: https://groups.google.com/forum/#!topic/android-ndk/UP5v_S0BDdY

On 2014-07-17 22:15:57 +0000, Sylvain wrote:

This also seems to me a problem of the samsung S3 Android. For the S3, but maybe also for other samsung models.
(Sure about cyanogen? could all configs be tried?)

Maybe testing all configs on other could unveil some problems.

I agree hardcoding a penalty of 7 for Samsung S3 is not a great idea.
But I wouldn't add code to match a specific model neither (to many models to cover).

I agree, to prioritize (but not to filter others !) :

EGL_NATIVE_VISUAL_ID == ANativeWindow_getFormat.

but I would still had :

_this->egl_data->eglGetConfigAttrib(_this->egl_data->egl_display, configs[i], EGL_NATIVE_VISUAL_ID, &value);

if (EGL_NATIVE_VISUAL_ID == ANativeWindow_getFormat)
{
// no penalty, we match the native format
}
else if (value == 1 || value == 2 || value == 4)
{
// single format (but not ANativeWindow_getFormat)
// small penalty
bitdiff += 1000;
}
else if (value & ~7 == 0)
{
//a few formats
// medium penalty
bitdiff += 2000;
}
else
{
// out of bounds
// big penalty
bitdiff += 3000;
}

// Penalty for slow config
_this->egl_data->eglGetConfigAttrib(_this->egl_data->egl_display, configs[i], EGL_CONFIG_CAVEAT, &value);
if (value == EGL_SLOW_CONFIG)
{
// Medium penalty.
bitdiff += 1000;
}

1, 2, 4 and 7 to be replaced by
( WINDOW_FORMAT_RGBA_8888, WINDOW_FORMAT_RGBX_8888, WINDOW_FORMAT_RGB_565 )

  • Also... What if this wasn't a problem of S3 but a bug in SDL Render?
    Could I run an egl app with SDL without the SDL renderer?

On 2014-07-18 08:23:37 +0000, Sylvain wrote:

I have tried the SDL testgles2 :
when I force one of the config with format=7 of the S3, I get a red tinted cube on the screen. If I had also a SDL_Delay after the SwapWindow I get the red blinking effect.
So, this is exactly what I observed previously with SDL renderer.

I have tried to reduce the testgles2 to a basic testcase :

  • no shader, not even creation of shader.

    SDLTest_CommonInit / SDL_GL_CreateContext / LoadContext
    ...
    SDL_GL_MakeCurrent(state->windows[0], context[0]);
    while (1)
    {
    GL_CHECK(ctx.glClearColor(0.0, 0.0, 0.0, 1.0);
    GL_CHECK(ctx.glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT | GL_STENCIL_BUFFER_BIT)));
    SDL_GL_SwapWindow(state->windows[0]);
    SDL_Delay(100);
    }

This also produce a red blinking screen before coloring to black.
Maybe this egl config is somehow similar to debug mode existing on some device ?

On 2014-07-19 13:42:14 +0000, Sylvain wrote:

I have no more idea about this issue! let me know if you want more information with this S3.

On 2014-07-19 13:56:41 +0000, Gabriel Jacobo wrote:

Can you let me know the output of:

#include <sys/system_properties.h>
char man[PROP_VALUE_MAX + 1], mod[PROP_VALUE_MAX + 1];
int lman = __system_property_get("ro.product.manufacturer", man);
int lmod = __system_property_get("ro.product.model", mod);

On 2014-07-19 17:31:16 +0000, Sylvain wrote:

yes, it's:

I/SDL/APP (13320): lman=7 man=samsung
I/SDL/APP (13320): lmod=8 mod=GT-I9300

Also, the samsung device has just been factory reset.
Android version = 4.3

On 2014-07-20 11:00:32 +0000, Sylvain wrote:

Again, let me know if you need more information before I give back the S3.

Someone seems to have the red-screen issue on other devices: https://bugzilla.libsdl.org/show_bug.cgi?id=2653
So I wouldn't go for specific patch to samsung s3.

On 2014-07-22 16:06:36 +0000, Thomas Faller wrote:

Created attachment 1783
possible patch

I've a S3 and the red screen issue. I think I know the problem.
The problem is, please correct me if it's wrong, that the pixelformat (determined by Java "surfaceChanged") was not supplied into gl config, so gl pixelformat is RGB332 (default value). It seams that a S3 can't use RGB332.
I added into Android_VideoInit() some changes which sets color sizes. And I disabled overwriting color sizes in SDL_test_common.c when compiling for Android. This solved it on my S3.

On 2014-07-22 20:22:27 +0000, Sylvain wrote:

Looks interesting: it makes sense that the java pixel format should be sent to eglChooseConfig to find the appropriate config.

I believe this makes the red-screen disappear because you reduced the number of config retrieved by eglChooseConfig !

Especially, because the config that are problematic are RGBA == 4444 (CONFIG_ID = 21, 22, 23).
and that you are requesting config > 565. (eglChooseConfig could give configs greater than requested)

(But maybe your patch is the good solution !)

It would be nice to try to things differents :

  • try your patch + explicitly force one of the bad EGL config (use the debug patch to have outputs!).
    (I usually patch SDL_egl.c, attrib[0] = EGL_NONE to have all config browsed)
    => I am almost sure you'll get the red-screen

  • try your patch + explicity force one of the bad EGL config, and try to request explicitly a surface RGB_4444 in java :

see http://stackoverflow.com/questions/8829943/how-to-find-the-best-pixelformat-for-an-android-surfaceview

public void surfaceCreated(final SurfaceHolder holder) {
...
holder.setFormat(PixelFormat.RGBA_4444);
...
}

=> I would be curious to see if the screen is still red !

On 2014-07-23 21:13:37 +0000, Thomas Faller wrote:

You're right,the screen is still red with a RGBA4444 config.
I wrote a little Java App which tests these configs in a GLSurfaceView - the screen is red too.
I think these configs are not ok, maybe we can't solve it completely, but with my patch RGB565 and RGBA8888 works now.

On 2014-07-28 06:32:05 +0000, Sylvain wrote:

Just a confirmation, When you said you have the red blinking screen with RGB_4444.
Can you confirm you have added the java line
"holder.setFormat(PixelFormat.RGBA_4444);" ??

like in:
http://stackoverflow.com/questions/8829943/how-to-find-the-best-pixelformat-for-an-android-surfaceview

On 2014-07-28 17:54:59 +0000, Thomas Faller wrote:

I confirm, I've added these line. The screen is still red.

On 2014-10-27 22:39:23 +0000, Hak Matsuda wrote:

I experienced the issue in these devices and had worked around that.

Basically the issue is that in those devices, 1555 rendering is broken, so I needed to avoid rendering in 1555.
By default, SDL is looking for best optimal render target closer to 332, which is 1555.
By setting RT format to 565 (or 888), it worked fine in these devices.

// Set back buffer format to 565
SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 5);
SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 6);
SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 5);

On 2015-02-27 09:25:27 +0000, Limanima wrote:

I'm also experiencing this problem.
I'm also confused.
After all this comments I'm nto sure if there's a good workaround for this or not.

1)This was suggested. Have someone else tryed this out? And:
Where should I place this calls?
After SDL_Init(SDL_INIT_VIDEO)?

SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 5);
SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 6);
SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 5);

  1. How about this:
    https://bugzilla.libsdl.org/attachment.cgi?id=1741&action=diff

Is it safe to use any of this methods?

On 2015-03-03 11:57:51 +0000, Limanima wrote:

I did this:

SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 5);
SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 6);
SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 5);

After creating the rendering and it solved the problem on the faulting device. It doesn't seem to have broken the other devices.

On 2015-03-03 11:59:42 +0000, Limanima wrote:

Correction to the previous post: it's not after, it's before creating the renderer.

On 2016-08-18 11:43:30 +0000, Emmanuel wrote:

The issue also occurs on (Lenovo) Motorola G4 Plus phones running Android 6.0.1.

Requiring a R8G8B8 backbuffer solves the issue by never selecting the broken A1R5G5B5 mode:

SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 8);
SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 8);
SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 8);

This needs to be done before creating the renderer

On 2016-08-18 14:20:26 +0000, Sylvain wrote:

@emmanuel Thanks for the info. In the meantime, I got news issues and I just wondering if this could not be solved by using the flags "SDL_RENDERER_PRESENTVSYNC".

On 2017-01-23 15:57:20 +0000, Sylvain wrote:

@emmanuel

Just wondering: you solved that issue but requiring a R8G8B8 backbuffer.
On your device, what is the log of the java function "surfaceChanged()". It somehow requires a pixel format, do you know which one ?

On 2017-08-28 21:08:26 +0000, Gabriel Kind wrote:

I removed the 565 GL_Attribute lines and for me the red screen problem on my Samsung Galaxy Note didn't reappear. Must have been already fixed with SDL 2.0.4, can't reproduce it with this version either.

On 2018-08-07 21:33:05 +0000, Ryan C. Gordon wrote:

So is this issue resolved at this point, or are we still having problems on some reasonable devices?

--ryan.

On 2018-08-08 14:01:10 +0000, Sylvain wrote:

I am sure there are still issues with those phones (S3, ..).

But that got resolved by adding / forcing:

SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 5);
SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 6);
SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 5);

Maybe, we only need to update README-android.txt with this advice, or set different default rgb values for Android (SDL default is 332 from SDL_GL_ResetAttributes()).

I personally think we could also remove the "bitdiff" in SDL_egl.c, which tries to find the best config whereas there are already sorted.

https://www.khronos.org/registry/EGL/sdk/docs/man/html/eglChooseConfig.xhtml

"When more than one EGL frame buffer configuration matches the specified attributes, a list of matching configurations is returned. The list is sorted according to the following precedence rules, which are applied in ascending order (i.e., configurations that are considered equal by a lower numbered rule are sorted by the higher numbered rule): ..."So:

At best SDL bitdiff does nothing by selected the first, otherwise it does worse : it unsorts the config list.

On 2018-09-03 08:03:16 +0000, Steve Robinson wrote:

I experienced a blue tinting of my SDL2 Android app on an LG G7 ThinQ. I'm using SDL 2.0.8.

Thanks to the tips in this bug report, I was able to work around it with this code:
SDL_GL_SetAttribute(SDL_GL_RED_SIZE, 5);
SDL_GL_SetAttribute(SDL_GL_GREEN_SIZE, 6);
SDL_GL_SetAttribute(SDL_GL_BLUE_SIZE, 5);

It had to be before the SDL_CreateWindow call for it to work. My Moto X Pure Edition and Samsung Galaxy Nexus phones never had the problem and continued to have proper coloring after this change.

The G7 is a new phone so I think it's safe to say these tinting issues are still a problem.

On 2019-05-18 07:51:39 +0000, Daniel Knobe wrote:

I can confirm the problem with the G7 ThinQ.

On 2020-04-20 11:29:22 +0000, Richard Russell wrote:

(In reply to Sylvain from comment # 112)

I personally think we could also remove the "bitdiff" in SDL_egl.c...
At best SDL bitdiff does nothing by selected the first, otherwise it does
worse : it unsorts the config list.

Has this now been actioned? If not, what are the remaining concerns?

On 2020-04-21 04:42:43 +0000, Steve Robinson wrote:

I undid the workaround to prevent blue tinting on LG G7 ThinQ and the display looks fine now. Built with SDL 2.0.12. The phone is running Android 9 and has probably been upgraded since I first reported the problem so who knows what fixed it.
@SDLBugzilla SDLBugzilla added bug waiting Waiting on user response labels Feb 10, 2021
@icculus icculus removed the waiting Waiting on user response label Aug 11, 2021
@icculus icculus closed this as completed Aug 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@icculus @SDLBugzilla