<schurig>
Hi ... I'm a bit struggling with using Etnaviv (from self-compiled kernel 5.6.12) on an i.MX6 with Xorg ... both in Debian Buster and Debian SID
<schurig>
when I have no xorg.conf file, X won't even start (e.g. when started with "Xorg -keeptty vt1" or "xinit")
<schurig>
when I have one, I need to add a
<schurig>
Option "AccelMethod" "none"
<schurig>
clause to make it start ... but my suspicion is that this is then just framebuffer ?!?!
hanzelpeter has quit [Quit: leaving]
<schurig>
and without an xorg.file, I get "Require OpenGL version 2.1 or later." followed by "(EE) modeset(0): Failed to initialize glamor at ScreenInit() time."
<schurig>
any idea on how to debug this further?
<lynxeye>
schurig: don't use the generic modesetting driver and glamor on etnaviv
<lynxeye>
use the xf86-video-armada driver to get proper 2D acceleration
<schurig>
oh, I thouht that that one was outdated in favor of the xorg modesetting driver. Okay, I'll give it a try.
<lynxeye>
schurig: modesetting is the way to go on most modern GPUs, which don't even have a 2D unit anymore. i.MX6 on the other hand has a full GPU just dedicated for 2D tasks, so you really want to use it for Xorg accel. And the only way to do so is using the armada driver.
<schurig>
master is really old, last commit 2014 ...
<austriancoder>
schurig: unstable
pcercuei has joined #etnaviv
hanzelpeter has joined #etnaviv
berton has joined #etnaviv
hanzelpeter has quit [Quit: leaving]
_whitelogger has joined #etnaviv
<schurig>
Jookia: you updated one does still need some headers from the attic/ of etna_viv ?
<Jookia>
schurig: yes. the instructions should still work fine
<schurig>
when I saw the non-X11 demo-app "kmscube" running I thought that this is what Wayland (and also modesetting for X11) will use ...
<schurig>
so kmscube was more or less just a test for me that I got my device tree right?
<Jookia>
i don't know
CoLa-M has joined #etnaviv
<CoLa-M>
hi, I am trying to obtain the etnaviv GPU counters with glGetPerfMonitorGroupsAMD(&n, 0, NULL) but get no output value written into n, does anyone have an idea what I might do wrong?
<CoLa-M>
oh, apparently I do not find the extension... /o\ from which Mesa version onwards should that be available? I am running with Mesa 18.1.9
<schurig>
okay, I compiled it and I added then Section / Driver "armada" / EndSection thingy, and my Xorg now starts
<Jookia>
schurig: congrats :)
<schurig>
so far so good ...
<schurig>
but when I start "glxinfo", I see two error messages:
<schurig>
1: libGL error: failed to authenticate magic 1
<schurig>
2: libGL error: failed to load driver: etnaviv
<schurig>
I used strace, and it could at least open the file: openat(AT_FDCWD, "/usr/lib/arm-linux-gnueabihf/libdrm_etnaviv.so.1", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 4
<Marex>
CoLa-M: you want to update mesa to 20.1.y or master, there are A LOT of fixes
<Marex>
schurig: is there any particular reason for X11 ?
<CoLa-M>
Marex: no hope to get the GL extension working for mesa 18.1? I am kind of stuck with an embedded device that das not want to have a new mesa for the next 1/2 year
<Marex>
CoLa-M: there were fixes for race conditions and incorrect rendering, so you want that update
<schurig>
Marex: why X11? Because Wayland support in Debian Buster sucks. There's not even sway ... and I don't want to compile all by myself. Would I have wanted that, then I would have used Yocto in the first place ...
<CoLa-M>
thanks, will definitely look into updating it
<schurig>
Marex: yesterday I made myself mesa .deb's compiled against Buster from mesa HEAD. I now installed them (libegl-mesa0 libgbm1 libgl1-mesa-dri libglapi-mesa libglx-mesa0), but the error messages stay
<Marex>
schurig: btw do you know Richard from OE ?
* Marex
checks something unrelated :)
<Marex>
schurig: btw I tested etnaviv on debian testing (which one is that now , that's not buster, is it ?) and mesa from experimental with WL and that worked quite well
<Marex>
oh yes, buster is stable and I can imagine that would suck with WL
<Marex>
although I'm not particularly sure using x11 is a big win
<schurig>
Marex: I knew Richard Purdie once ... I'm one of the Bitbake/OE founders, together with Kergoth, MickeyL and Zecke. RP came a bit later. But I more or less stopped using OE years ago.
<Marex>
schurig: can you pastebin the x11 log (/var/log/X*) ? maybe there is some hint
<Marex>
I suspected as much ...
<schurig>
I think in the git history of "bitbake" you find me still, but someone removed my name from copyright comment :-(
<schurig>
Debian testing ... is nothing, really. It's just has a meaning directly when the next Debian Stable is meant. Outside of this small window, it should better not be used.
<schurig>
but when there is no Stable in the works, then packages move from Sid to Testing based on "Days without grave bugs" (it's a bit more complicated). So you can wait for some perfectly valid package, or a security bug fix, until these days are over.
<schurig>
whereas in both Stable and Sid you'll have the security fix right away. So I never use Testing.
<Marex>
schurig: it might make sense to try sid then and see whether you have more luck with X11 there, and if so, find the diffeerence between that and stable
<schurig>
I "apt update" & "apt upgrade" to Sid. Still get those two error messages. The various glx* programs (e.g. glxheads) still show that they use llvmpipe, just now based on llvm-10 instead of llvm-7
<lynxeye>
schurig: etnaviv_dri.so is present in /usr/lib/dri ?
<Marex>
lynxeye: seems like it's loaded according to the x11 log
<lynxeye>
Marex: not talking about the Xorg driver, which seems to be loaded okay, but the GL driver
<schurig>
yes, it's there. Strangely a lot of those files have the exact same length
<lynxeye>
schurig: That's megadrivers, aka one big driver file with all HW support. All of them are just hardlinks IIRC