<asdf28>
it seems to be an issue between your display and the graphics driver
lurchi__ is now known as lurchi_
<gediz0x539>
MoeIcenowy: btw there are some related nodes about panels like tcon0, tcon0_out, lcd, you know. I've just copied them from a similar dts, I don't know if I could set them right. can you please look if it seems okay? it's dtb decompiled. http://ix.io/2HQA
<libv>
gediz0x539: are you getting display at all on the lcd?
<gediz0x539>
asdf28: I'm really not sure if there's only one issue. I may have multiple :)
<gediz0x539>
libv: yes, there's a blinking cursor at the top left corner of the screen.
apritzel has quit [Ping timeout: 264 seconds]
<libv>
gediz0x539: then you can stop barking up the display side of the tree :)
<gediz0x539>
I've tried to put some garbage there through /dev/fb0 and it displays well
<libv>
you are already showing rgb through the backend through the tcon
<asdf28>
you could try the modetest tool
<libv>
and then this is about lima, or about the application not being able to tie two different drm nodes together
<libv>
smart idea that, throwing display and rendering together, and then mashing it around
<gediz0x539>
libv: which makes me think about dts is this part: [drm:sun4i_drv_probe [sun4i_drm]] Endpoint is our panel... skipping
<libv>
gediz0x539: you have a cursor
<libv>
it's not a display issue
<gediz0x539>
asdf28: oh it looks cool. let me try modetest
<asdf28>
you might already have it installed if you have mesa
<gediz0x539>
libv: I could not really understand that part. what do you recommend? reading through sources or some kind of documentation?
<gediz0x539>
I mean, graphics stack. kinda hard for newbies.
<gediz0x539>
asdf28: is executable name "modetest"?
<libv>
gediz0x539: a 3d renderer does not share anything with a display engine
<asdf28>
yes but it could be that it wasn't compiled on your image
<libv>
and even on discrete gpus, they mostly share interrupts, different parts of register space, memory or memory bandwidth (and perhaps a command processing queue)
<libv>
they are separate.
<libv>
3d engine renders to a buffer
<libv>
display engine displays a buffer
<libv>
you have a cursor, you have a working display engine
<gediz0x539>
libv: I get this part at some shallow level.
<libv>
no amount of poking at kms is going to fix the inability of an application to show a buffer coming from a rendering engine onto the display
<gediz0x539>
the part I could not comprehend was especially drm side
<libv>
perhaps the application just is not smart enough to work around an old and stupid "design" flaw of drm/dri/kms
<libv>
well, drm kms came into existence when Jakob Bornecrantz took the X randr1.2 header and reformatted it to be kernel style
<libv>
gediz0x539: sun4i_drm is a pure display driver
<libv>
no rendering being done there
<libv>
kms got traction when ATI affectionados sidestepped AMD management in 2008, once again
<gediz0x539>
I'm told that lack of a proper sun4i_drm may cause another /dev/dri/cardN entry to not exist
<libv>
and as usual, the people involved there had/have no sense of structure or separation
<libv>
may?
<asdf28>
sorry gediz0x539, it's not in mesa, the modetest tool is in a subproject "drm" in the mesa repository, so you probably don't have it installed
<libv>
it would be really stupid to have lima not be usable when there is no display loaded
<asdf28>
you could check if there's a package "drm" or "libdrm" in your build system
<libv>
there's a ton of usecases for 3d engines outside of displaying graphics
<asdf28>
gediz0x539 i think /dev/dri/cardN is not your issue, it doesn't reach this point
<asdf28>
because it cannot open the display
<gediz0x539>
libv: I may have interpreted it wrong, too. when you do not fully understand a concept, things mix up. sorry
<gediz0x539>
asdf28: okay. I will compile it then.
<libv>
gediz0x539: drm used to be independent of the kernel, and it used to just manage access to 3d rendering hw
<libv>
until dave airlie came around in 2004, threw out all the code supporting BSDs and such, and made it build inside the kernel tree, and then called himself king
<libv>
3-4 years later, they badly threw modesetting into the lot, with no sense of structure or separation
lurchi_ is now known as lurchi__
<libv>
which then came to bite them when arm SoCs happened, as suddenly there were different drivers needed for (wholly) different hw blocks
<libv>
which is why they are all called drm nodes today still
<gediz0x539>
lack of documentation, abstractions, layers, abbreviations all over the place. one would probably need months, if not years to fully understand them.
<libv>
and even then it makes little sense
apritzel has joined #linux-sunxi
<libv>
as there's a lot of stupidity in there
<gediz0x539>
and no rewrite from scratch for the sake of backward compatibility?
<gediz0x539>
or is it even viable to rewrite whole the stack?
<libv>
the people involved are rancunous beyond believe, and do not stop for anything that diminishes their false sense of superiority.
<libv>
as long as they are getting paid by a big player, that actually support this behaviour, there's no point
<asdf28>
this sounds terrible
<asdf28>
gediz0x539: have you tried this suggestion from the issue you linked? "sun4i-drm has both a kernel driver and the userspace part (provided by kmsro) that you pointed to. Looks like you have both lima and sun4i-drm as built-in in your kernel and lima is loading first, claiming card0."
<asdf28>
" Try making lima a module in your kernel so it will load later."
<gediz0x539>
libv: wow that's bad. even reading is demotivating. please do not get me wrong, I do really like to listen to you. it's like no point of return.
<gediz0x539>
asdf28: I've blacklisted lima
<gediz0x539>
tweaked with the order of probe
<asdf28>
but you loaded it afterwards?
<gediz0x539>
1st sun4i_drm, 2nd lima and vice versa
<gediz0x539>
yep
<asdf28>
okay
<gediz0x539>
/dev/dri/card1 did not get created in any scenario
<gediz0x539>
and /dev/dri/card0 is only created/removed when lima is probed/ "modprobe -r"d
<gediz0x539>
it's kind of fun to tinker with it but after a while you feel really dumb. I mean, I know that it's not that easy but it's also not rocket science.
<libv>
gediz0x539: oh, one other option, simplefb
<libv>
heh, i wrote the original code, and now i overlook it
<gediz0x539>
instead of panels?
<libv>
gediz0x539: is there anything about simple-framebuffer in your dmesg?
<gediz0x539>
yep
<gediz0x539>
[ 0.128642] simple-framebuffer 5fe89000.framebuffer: framebuffer at 0x5fe89000, 0x177000 bytes, mapped to 0x(ptrval)
<libv>
btw, and you now have modular sun4i_drm and for some reason that driver was not loaded, hopefully because it could not satisfy the panel-simple dependency
<libv>
so maybe it gets loaded automatically now
<gediz0x539>
im praying for the gods of mitgard right now
<gediz0x539>
midgard, sorry lol
<gediz0x539>
holy shit
<gediz0x539>
kmscube works
<gediz0x539>
card0 and card1 is there
<gediz0x539>
thank you a lot libv
<asdf28>
man, that's awesome
<gediz0x539>
and asdf28
<asdf28>
who would have thought?
<gediz0x539>
and MoeIcenowy
<asdf28>
i just tried kmscube, i just get a black screen but it's outputting FPS messages
<libv>
i also have no idea why panel_simple is not part of sunxi_defconfig
<libv>
but cool
<gediz0x539>
libv: its very much appreciated, really. thank you so much.
<gediz0x539>
asdf28: cube with gradients on it is spinning right now with ~60fps
<libv>
forgetting about simplefb was pretty daft though ;)
<gediz0x539>
:D
<gediz0x539>
its really a dumb move
<gediz0x539>
after working with fex for a long time, you lose some common sense
<gediz0x539>
:D
<asdf28>
gediz0x539: does it stutter or move smoothly?
<gediz0x539>
buttery smooth
<asdf28>
nice
<libv>
as said, i am the original author of the uboot driver, and doubled the size of the driver, and caused a mail discussion with 2x the messages compared to the added kloc, as i once again put the finger on the sore spot
<asdf28>
i had it running once on my banana pi, but it was stuttering after every second
<gediz0x539>
you know how things work
apritzel has quit [Ping timeout: 256 seconds]
<gediz0x539>
asdf28: on framebuffer?
<asdf28>
no, using DRM
<asdf28>
i also have no idea how to tell it which monitor/video output it should use
<gediz0x539>
which SoC was on the BPi? A20?
<asdf28>
it feels like it
<asdf28>
it's outputting to the wrong source and i get a black screen
<asdf28>
yes A20
<gediz0x539>
interesting
<gediz0x539>
btw A13 renders it using software, iirc A20 can render and display faster with faster mali and G2D
<gediz0x539>
idk if it'd still help but I can try these on A20 too
<asdf28>
yes it would be interesting if you can get better performance out of it
<asdf28>
it runs very smooth for a second, but then it stutters for a split second and continues
<asdf28>
the same with other benchmarks and games
<libv>
it does not need g2d
<libv>
it could just display the mali rendered buffer in one of the free display planes
<libv>
it's what overlays are for
<libv>
and what is rendered via software?
<gediz0x539>
sorry, I mean displayed using software
<gediz0x539>
a20 is able to both render and display using hardware right?
<libv>
same for a13
<gediz0x539>
so okay I get G2D completely wrong
<libv>
if you mean mali for the former, and the display engine for the latter
<libv>
there is no g2d driver in mainline
<gediz0x539>
I see
<libv>
i am actually writing a rudimentary on as we speak
<libv>
gediz0x539: an overlay is where the display engine gets told: from pixel (x,y) until position (x+w,y+h), show this buffer here instead (with buffer layout added)
<libv>
it's easy enough hw, and a much easier driver (if done right)
<libv>
than having to bring up a 3d engine to do trivial compositing
<libv>
and sun4i-drm has some support for overlays
<gediz0x539>
are overlays different from planes of DEBE?
<libv>
that is, if not showing the buffer directly on the main "plane"
<libv>
which is an actual plane on our hw
<gediz0x539>
hmm
<libv>
but which intel's jesse barnes did not think of being possible when he wrote up the original kms planes in 2011 (to make up for why wayland was so powerhungry vs android hw composer)
<libv>
(as intel had just removed all but one plane from its hw)
<gediz0x539>
cursor plane?
<libv>
as a separate object
<libv>
which, incidentally, was only allowed to be 64x64 rgb until like 2014/2015
<libv>
which is what happens when people have not done display drivers before
<libv>
but yes, that too is an overlay
<libv>
and it was not treated as a kms plane
<libv>
which would then be pretty broken, as i think in our case kms planes are synced with vrefresh, so every cursor movement then has the input thread of wayland/X stall until the next frame starts
<libv>
iirc, someone here ran into that last year when i was talking about the sprites in our display engine, and he/she decided to try it out
<gediz0x539>
he was doing h6 bare metal games iirc
<MoeIcenowy>
interestingly H616 and V831 now supports to set PF port IO voltage to 1.8V
<MoeIcenowy>
for UHS application
<gediz0x539>
it is fun to play with display engine at register level. but things get harder while trying to integrate them into something actually useful.
laurentC has quit [Ping timeout: 272 seconds]
<gediz0x539>
I feel like fps is capped. I get either 30 or 60 fps at glmark2.