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.

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

Non-GLES apps render only black rectangles #11

Open
tpgalchenko opened this issue Jul 14, 2020 · 18 comments
Open

Non-GLES apps render only black rectangles #11

tpgalchenko opened this issue Jul 14, 2020 · 18 comments

Comments

@tpgalchenko
Copy link

I am trying to configure Mali GPU on mainline Linux kernel 5.6.14, Debian 10 on Olimex Lime2 board with Allwinner A20 processor.

I've succeeded to build Mali kernel modules, armsoc driver and to install Mali blobs. glmark2 works just fine, I can see excellent pictures and the final score is about 120 points.

However I am facing strange issues in the ordinary X11 applications like xmessage, xterm, xloadimage - they just do not show anything and report no errors. For example, "xinit xterm" renders no graphic, only cursor is visible over a blank, black screen. Chromium browser works normally, but if I try to pop up a dialog using xmessage on the same display only one black rectangle is rendered.

As soon as I turn off armsoc driver or change DefaultDepth from 24 to 16 everything works correctly (except for glmark2 and GLES). How can I make the old good applications work? Any ideas will be highly appreciated.

I've attached my log and configuration files.

dmesg.log
xorg.conf.txt
Xorg.0.log

@mripard
Copy link
Owner

mripard commented Jul 17, 2020

Everything looks about right. Do you know the format being used on the framebuffer X gives to the kernel?

@tpgalchenko
Copy link
Author

tpgalchenko commented Jul 17, 2020

No, I do not. How can I find it out? Should I put some debug print line in the armsoc driver? Would you please point out the appropriate function?

@tpgalchenko
Copy link
Author

Please correct me if I am wrong, I suppose that native X11 applications use EXA part of the armsoc driver. I've added printing parameters of the pixmaps allocated in the EXA driver. Here is the output produced when X server started and ran Electron application (with works correctly using GLES API):

[ 41.105] (II) ARMSOC(0): ARMSOCCreatePixmap2 8x8 depth=1 bpp=1
[ 41.106] (II) ARMSOC(0): CreateNoAccelPixmap 8x8 depth=1 bpp=1
[ 41.106] (II) ARMSOC(0): ARMSOCModifyPixmapHeader 8x8 depth=0 bpp=0
[ 42.143] (II) ARMSOC(0): ARMSOCCreatePixmap2 24x24 depth=32 bpp=32
[ 42.143] (II) ARMSOC(0): CreateNoAccelPixmap 24x24 depth=32 bpp=32
[ 42.143] (II) ARMSOC(0): ARMSOCModifyPixmapHeader 24x24 depth=0 bpp=0
[ 42.196] (II) ARMSOC(0): ARMSOCCreatePixmap2 24x24 depth=32 bpp=32
[ 42.197] (II) ARMSOC(0): CreateNoAccelPixmap 24x24 depth=32 bpp=32
[ 42.197] (II) ARMSOC(0): ARMSOCModifyPixmapHeader 24x24 depth=0 bpp=0

Afterwards I've started xmessage tool which shows only a black rectangle and the the log has received the following messages:

[ 103.969] (II) ARMSOC(0): ARMSOCCreatePixmap2 24x24 depth=32 bpp=32
[ 103.969] (II) ARMSOC(0): CreateNoAccelPixmap 24x24 depth=32 bpp=32
[ 103.969] (II) ARMSOC(0): ARMSOCModifyPixmapHeader 24x24 depth=0 bpp=0
[ 103.975] (II) ARMSOC(0): ARMSOCCreatePixmap2 2x1 depth=1 bpp=1
[ 103.976] (II) ARMSOC(0): CreateNoAccelPixmap 2x1 depth=1 bpp=1
[ 103.976] (II) ARMSOC(0): ARMSOCModifyPixmapHeader 2x1 depth=0 bpp=0
[ 103.991] (II) ARMSOC(0): ARMSOCCreatePixmap2 24x24 depth=32 bpp=32
[ 103.991] (II) ARMSOC(0): CreateNoAccelPixmap 24x24 depth=32 bpp=32
[ 103.991] (II) ARMSOC(0): ARMSOCModifyPixmapHeader 24x24 depth=0 bpp=0
[ 103.991] (II) ARMSOC(0): ARMSOCCreatePixmap2 24x24 depth=32 bpp=32
[ 103.992] (II) ARMSOC(0): CreateNoAccelPixmap 24x24 depth=32 bpp=32
[ 103.992] (II) ARMSOC(0): ARMSOCModifyPixmapHeader 24x24 depth=0 bpp=0
[ 103.992] (II) ARMSOC(0): ARMSOCCreatePixmap2 24x24 depth=32 bpp=32
[ 103.992] (II) ARMSOC(0): CreateNoAccelPixmap 24x24 depth=32 bpp=32
[ 103.992] (II) ARMSOC(0): ARMSOCModifyPixmapHeader 24x24 depth=0 bpp=0
[ 103.993] (II) ARMSOC(0): ARMSOCCreatePixmap2 24x24 depth=32 bpp=32
[ 103.993] (II) ARMSOC(0): CreateNoAccelPixmap 24x24 depth=32 bpp=32
[ 103.993] (II) ARMSOC(0): ARMSOCModifyPixmapHeader 24x24 depth=0 bpp=0
[ 103.993] (II) ARMSOC(0): ARMSOCCreatePixmap2 24x24 depth=32 bpp=32
[ 103.993] (II) ARMSOC(0): CreateNoAccelPixmap 24x24 depth=32 bpp=32
[ 103.993] (II) ARMSOC(0): ARMSOCModifyPixmapHeader 24x24 depth=0 bpp=0
[ 103.994] (II) ARMSOC(0): ARMSOCCreatePixmap2 24x24 depth=32 bpp=32
[ 103.994] (II) ARMSOC(0): CreateNoAccelPixmap 24x24 depth=32 bpp=32
[ 103.994] (II) ARMSOC(0): ARMSOCModifyPixmapHeader 24x24 depth=0 bpp=0
[ 104.246] (II) ARMSOC(0): ARMSOCCreatePixmap2 2x2 depth=24 bpp=32
[ 104.246] (II) ARMSOC(0): CreateNoAccelPixmap 2x2 depth=24 bpp=32
[ 104.246] (II) ARMSOC(0): ARMSOCModifyPixmapHeader 2x2 depth=0 bpp=0
[ 104.247] (II) ARMSOC(0): ARMSOCCreatePixmap2 2x2 depth=24 bpp=32
[ 104.247] (II) ARMSOC(0): CreateNoAccelPixmap 2x2 depth=24 bpp=32
[ 104.247] (II) ARMSOC(0): ARMSOCModifyPixmapHeader 2x2 depth=0 bpp=0
[ 107.472] (II) ARMSOC(0): ARMSOCCreatePixmap2 0x0 depth=24 bpp=32
[ 107.472] (II) ARMSOC(0): CreateNoAccelPixmap 0x0 depth=24 bpp=32
[ 107.472] (II) ARMSOC(0): ARMSOCModifyPixmapHeader 0x0 depth=0 bpp=0
[ 107.472] (II) ARMSOC(0): ARMSOCModifyPixmapHeader 1279x799 depth=24 bpp=32

It is remarkable that there pixmaps depth is sometimes 24, sometimes 32. Can it be the cause for the problem?

I've tried to change DefaultFbbpp option but it seems to have no effect.

@mripard
Copy link
Owner

mripard commented Jul 23, 2020

Can you add drm.debug=0x1f to your kernel command line, and paste the dmesg output ?

@tpgalchenko
Copy link
Author

Here is it

dmesg.log

@mripard
Copy link
Owner

mripard commented Jul 23, 2020

And I guess X starts around 20s from boot?

Do you have devmem installed on that board?

@tpgalchenko
Copy link
Author

tpgalchenko commented Jul 24, 2020

For your convenience I've attached another log where the moment Xserver starts is delimited explicitly ("Starting X").

dmesg-1.log

No, devmem is not installed but if it is necessary to investigate the issue deeper I will install it.

Just tell me what to do with it.

@mripard
Copy link
Owner

mripard commented Jul 24, 2020

Yeah, please retrieve devmem2 from here: https://bootlin.com/pub/mirror/devmem2.c

And run:

devmem2 0x01e60804 w 0x000000ff
devmem2 0x01e60870 w 0x00000003

If my guess is right, instead of the black windows you should have them blue now.
If so, then try

devmem2 0x01e608a0 w 0x00000900
devmem2 0x01e60870 w 0x00000003

And it should bring back the content of your windows.

@tpgalchenko
Copy link
Author

tpgalchenko commented Jul 24, 2020

Yes, you are right!!!

@tpgalchenko
Copy link
Author

tpgalchenko commented Jul 24, 2020

What is it? What's wrong about my system configuration? How should I mend it?

As far as I can understand, your commands write framebuffer format SUN4I_BACKEND_LAY_FBFMT_XRGB8888 to SUN4I_BACKEND_ATTCTL_REG1(0). Does it mean that my kernel is missing a patch?

@mripard
Copy link
Owner

mripard commented Jul 28, 2020

Your kernel doesn't really miss a patch but that behaviour was seen (and worked around) on other SoCs. We don't have the work around enabled on the A20 though, since it was supposed to be immune to that behaviour, but it turns out it's not.

I'll send a patch, do you want to be in Cc?

@tpgalchenko
Copy link
Author

tpgalchenko commented Jul 28, 2020

Any form of patch will do for me. To be honest, I do not see clearly the difference for me whether I will be in CC or not. Will it take you much time to prepare the patch?

Thank you a lot for your help, before your answer I've been thinking I was stuck.

@mripard
Copy link
Owner

mripard commented Jul 28, 2020

@tpgalchenko
Copy link
Author

tpgalchenko commented Jul 29, 2020

I've applied your patch but it does not help.

I wonder if I mislead you unwillingly in a previous message: you asked me to issue devmem commands to alter some registers and there were two sets of commands. The first set considered the blue background. You told that my "black" windows should have turned blue, but instead of that the whole screen became blue. Does it matter? In fact, the second command set was enough to make my apps visible.

I am attaching kernel log, may be it will help.

dmesg.log

@tpgalchenko
Copy link
Author

Do you need any other information?

@mripard
Copy link
Owner

mripard commented Aug 25, 2020

Did you apply both patches? The first one isn't enough to fix it

@tpgalchenko
Copy link
Author

Yes, I've seen that the patch consisted of two parts. Yet, it has not helped.

@mripard
Copy link
Owner

mripard commented Sep 21, 2020

I'm sorry, I just don't have the time to look into it further.

Generally speaking, this is pretty much deprecated nowadays, lima is in a good state now and the modesetting DDX is well maintained

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants