mripard / xf86-video-armsoc

MIT License
11 stars 22 forks source link

Non-GLES apps render only black rectangles #11

Open tpgalchenko opened 4 years ago

tpgalchenko commented 4 years ago

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 commented 4 years ago

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

tpgalchenko commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

tpgalchenko commented 4 years ago

Here is it

dmesg.log

mripard commented 4 years ago

And I guess X starts around 20s from boot?

Do you have devmem installed on that board?

tpgalchenko commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Yes, you are right!!!

tpgalchenko commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

https://lore.kernel.org/linux-arm-kernel/20200728134810.883457-1-maxime@cerno.tech/

tpgalchenko commented 4 years ago

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 commented 4 years ago

Do you need any other information?

mripard commented 4 years ago

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

tpgalchenko commented 4 years ago

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

mripard commented 4 years ago

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