rellla changed the topic of #linux-sunxi to: Allwinner/sunxi /development discussion - did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait! - https://github.com/linux-sunxi/ - Logs at http://irclog.whitequark.org/linux-sunxi - *only registered users can talk*
qschulz has joined #linux-sunxi
t3st3r has quit [Remote host closed the connection]
t3st3r has joined #linux-sunxi
lurchi_ has quit [Ping timeout: 272 seconds]
mnemoc has quit [Remote host closed the connection]
_whitelogger has joined #linux-sunxi
mnemoc has joined #linux-sunxi
apritzel has quit [Ping timeout: 272 seconds]
Mangy_Dog has quit [Ping timeout: 240 seconds]
jstein has quit [Quit: quit]
lurchi_ has joined #linux-sunxi
tuxd3v has quit [Ping timeout: 256 seconds]
lurchi_ has quit [Ping timeout: 265 seconds]
victhor has quit [Ping timeout: 260 seconds]
cnxsoft has joined #linux-sunxi
cnxsoft1 has quit [Read error: Connection reset by peer]
lucascastro has quit [Ping timeout: 256 seconds]
chewitt has quit [Read error: Connection reset by peer]
chewitt_ has joined #linux-sunxi
ChriChri_ has joined #linux-sunxi
ChriChri has quit [Ping timeout: 246 seconds]
ChriChri_ is now known as ChriChri
JohnDoe_71Rus has joined #linux-sunxi
TheSeven has quit [Ping timeout: 258 seconds]
TheSeven has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.1 Aria http://www.kvirc.net/]
JohnDoe_71Rus has joined #linux-sunxi
chewitt_ has quit [Read error: Connection reset by peer]
chewitt has joined #linux-sunxi
diego71 has quit [Ping timeout: 260 seconds]
BorgCuba has quit [Quit: Leaving]
asdf28 has joined #linux-sunxi
chewitt has quit [Read error: Connection reset by peer]
chewitt has joined #linux-sunxi
diego71 has joined #linux-sunxi
apritzel has joined #linux-sunxi
fevv8[m] has quit [Quit: Idle for 30+ days]
apritzel has quit [Ping timeout: 256 seconds]
iamfrankenstein has joined #linux-sunxi
cmeerw has joined #linux-sunxi
kaspter has joined #linux-sunxi
chewitt has quit [Read error: Connection reset by peer]
chewitt has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
kaspter has quit [Quit: kaspter]
kaspter has joined #linux-sunxi
kaspter has quit [Ping timeout: 264 seconds]
stalls has joined #linux-sunxi
kaspter has joined #linux-sunxi
jstein has joined #linux-sunxi
cmeerw has quit [Ping timeout: 272 seconds]
victhor has joined #linux-sunxi
AneoX has joined #linux-sunxi
cmeerw has joined #linux-sunxi
JohnDoe1 has joined #linux-sunxi
JohnDoe1 has quit [Client Quit]
JohnDoe6 has joined #linux-sunxi
gediz0x539 has quit [Quit: Leaving.]
gediz0x539 has joined #linux-sunxi
BorgCuba has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 260 seconds]
cmeerw has quit [Quit: Leaving]
chewitt has quit [Read error: Connection reset by peer]
chewitt_ has joined #linux-sunxi
cmeerw has joined #linux-sunxi
apritzel has joined #linux-sunxi
Mangy_Dog has joined #linux-sunxi
<gediz0x539> what should I do to have both "card0" and "card1" created under "/dev/dri/" ? I have enabled LIMA and SUN4I_DRM.
lurchi_ has joined #linux-sunxi
Ke has quit [Ping timeout: 260 seconds]
<asdf28> gediz0x539: do you have a display engine node in your device tree?
<asdf28> i vaguely remember something about that
Ke has joined #linux-sunxi
<asdf28> it looks like this: &de { status = "okay"; };
<asdf28> have you connected a HDMI screen or a TV screen?
dev1990 has quit [Remote host closed the connection]
chewitt_ has quit [Read error: Connection reset by peer]
chewitt has joined #linux-sunxi
<gediz0x539> asdf28: yep. display-engine has set 'status = "okay";'
<gediz0x539> I've decompiled dtb to make sure it is there
<gediz0x539> not hdmi but I have an LCD connected. unfortunately there's no HDMI output on A13.
<gediz0x539> there's another property in display-engine node, "allwinner,pipelines = <&fe0>;". is it valid? or should I add be0 there too?
kaspter has quit [Remote host closed the connection]
kaspter has joined #linux-sunxi
<MoeIcenowy> gediz0x539: no need, be is internally connected to fe
<libv> for some value of connected :)
dev1990 has joined #linux-sunxi
embed-3d has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
embed-3d has joined #linux-sunxi
<gediz0x539> MoeIcenowy: okay
<MoeIcenowy> gediz0x539: but you may need to assign a panel to tcon
<asdf28> gediz0x539: you have nothing under /dev/dri?
<gediz0x539> some context about dmesg, /dev/dri and kmscube: http://ix.io/2HQw
<gediz0x539> MoeIcenowy: I've added a similar panel to mine. namely 'compatible = "bananapi,s070wv20-ct16"'
<gediz0x539> asdf28: there's card0 and renderD128 under /dev/dri
<asdf28> legacy DRM?
<asdf28> does that even support KMS?
<gediz0x539> I could not understand why kmscube complained about that. Is sun4i_drm considered legacy?
<gediz0x539> Or did I add something wrong?
<asdf28> i am not experienced with this, but it could have to do something with the mode setting
<asdf28> for example, i tried to run kmscube and retroarch on my test machine
<asdf28> and both would not work
<asdf28> and complained about that they couldn't set a display mode
<asdf28> then, retroarch only worked when i set a value "video_monitor_index = 2"
<asdf28> i wasn't able to find an equivalent setting for kmscube
<asdf28> but it apparently couldn't find the monitor
lurchi_ is now known as lurchi__
<gediz0x539> libv: I could not understand that, sorry
<gediz0x539> asdf28: where did you set "video_monitor_index"?
<libv> gediz0x539: my statement was irrelevant to your problem
<gediz0x539> oh, sorry
<asdf28> gediz0x539 it's not relevant for kmscube
<libv> no, my statement was not helpful
<asdf28> you could also try glmark: https://github.com/glmark2/glmark2
<asdf28> i used this to test DRM and it worked for me
<gediz0x539> I've also tried "glmark2-es2-drm" and got "Error: Can't determine the main graphic card DRM device node"
<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
<gediz0x539> sun4i_drm invokes frontend, backend, tcon
<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)
<gediz0x539> [ 0.128661] simple-framebuffer 5fe89000.framebuffer: format=x8r8g8b8, mode=800x480x32, linelength=3200
<gediz0x539> [ 0.140887] simple-framebuffer 5fe89000.framebuffer: fb0: simplefb registered!
<libv> do you have a line that says: "fbX: switching to sun4i-drm-fb from simple"
<gediz0x539> unfortunately not
<gediz0x539> is it the missing part?
<libv> ok, i was pretty f-ing wrong, and everyone else was pretty right
<gediz0x539> how?
<libv> it is the display driver, sun4i_drm
cnxsoft has quit [Quit: cnxsoft]
<gediz0x539> okay then. I will keep digging that more.
gaston1980 has joined #linux-sunxi
<libv> gediz0x539: pastebin your dts
<gediz0x539> ok
<gediz0x539> http://ix.io/2HR9
<gediz0x539> pastebin is blocked there, sorry.
<gediz0x539> I live in such a cool place.
<libv> any pastebin style thing is ok
<gediz0x539> btw there are some modifications on included dtsi files, like increasing cma size, enabling display-engine
<libv> you can alter such things in your .dts
<libv> you do not need to touch the .dtsi
<gediz0x539> okay. I was just thinking about submitting the dtsi to mainline kernel if I could make it work. so I worked mostly quick and dirty.
<gediz0x539> there were no mali node for a13, for instance
<gediz0x539> I will unify them in a single dts and send it in a few minutes
<libv> heh, yeah, a13 is pretty ancient, and i doubt that too many people are actively using it
<gediz0x539> yep. I'd not judge them.
<libv> gediz0x539: add drm.debug=0x14 to your kernel command line, reboot and pastebin the dmesg
<gediz0x539> I have actually appended "loglevel=7" and "drm.debug=0x1ff" to bootargs in boot.cmd
<gediz0x539> it's the most verbose setting fore drm.debug, right?
<gediz0x539> s/fore/for/
<libv> we do not need all the other bits, we just need the display flags
<gediz0x539> ok I'll adjust it
<libv> oh
<libv> you already have that in there
<libv> hrm
JohnDoe6 has quit [Quit: KVIrc 5.0.1 Aria http://www.kvirc.net/]
JohnDoe_71Rus has joined #linux-sunxi
<JohnDoe_71Rus> libv: i'm still use A13 tablet :)
<libv> JohnDoe_71Rus: :)
<libv> JohnDoe_71Rus: with a recent kernel?
<JohnDoe_71Rus> but I think that his android 4 will soon turn sour
<JohnDoe_71Rus> any certificates expire
<gediz0x539> libv: drm.debug set to "0x14" instead of "0x1ff" https://hastebin.com/iqevubukim.yaml
jstein has quit [Quit: quit]
<JohnDoe_71Rus> it's interesting to have an up-to-date replacement for the ancient android
<libv> gediz0x539: sun4i-drm is not loaded at all
<gediz0x539> maybe its built in to the kernel? not as a separate loadable module
<libv> gediz0x539: defconfig?
<gediz0x539> I mean, maybe because
<libv> i do not understand why everything has to be built in
<libv> it is all built in in sunxi_defconfig
<gediz0x539> idk. with the hope of making it somehow more "sturdy". cargo culting
<libv> i think people just do not want to bother rsyncing modules over when developing
<libv> should not matter though
<gediz0x539> are builtin modules visible on lsmod?
<libv> could CONFIG_DRM_PANEL_SIMPLE be missing?
<libv> s070wv20-ct16 is part of panel_simple
<gediz0x539> Symbol: DRM_PANEL_SIMPLE [=n]
<gediz0x539> oh damn
<libv> not sure whether that is the issue, but it sounds plausible
<libv> it would be nice if we got "unknown panel type, skipping" somewhere
<gediz0x539> there's something slightly similar
<libv> no, that's node traversal
<libv> and not useful
<gediz0x539> okay
<libv> [drm:sun4i_drv_probe [sun4i_drm]] Endpoint is our panel... skipping
<gediz0x539> yeah I was talking about that
<gediz0x539> enabled DRM_PANEL_SIMPLE, recompiling
<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.
apritzel has joined #linux-sunxi
<asdf28> yes me too
<asdf28> it's probably tied to the refresh rate in some way
<gediz0x539> hmm
apritzel has quit [Ping timeout: 240 seconds]
gediz0x539 has quit [Ping timeout: 265 seconds]
gediz0x539 has joined #linux-sunxi
macc24_ has joined #linux-sunxi
gediz0x539 has quit [Ping timeout: 260 seconds]
iamfrankenstein has quit [Quit: iamfrankenstein]
lkcl has quit [Ping timeout: 272 seconds]
embed-3d has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
embed-3d has joined #linux-sunxi
gediz0x539 has joined #linux-sunxi
macc24_ has quit [Ping timeout: 265 seconds]
lkcl has joined #linux-sunxi
macc24 has joined #linux-sunxi
ldevulder__ has joined #linux-sunxi
ldevulder_ has quit [Ping timeout: 246 seconds]
AneoX has quit [Quit: Textual IRC Client: www.textualapp.com]
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 264 seconds]
kaspter has quit [Quit: kaspter]
netlynx has quit [Quit: Ex-Chat]
apritzel has joined #linux-sunxi
JohnDoe_71Rus has quit [Quit: KVIrc 5.0.1 Aria http://www.kvirc.net/]
andy25225 has quit [Ping timeout: 240 seconds]
andy25225 has joined #linux-sunxi
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #linux-sunxi
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #linux-sunxi
Net147 has quit [Read error: Connection reset by peer]
Net147 has joined #linux-sunxi
popolon has joined #linux-sunxi
apritzel has quit [Ping timeout: 240 seconds]
merbanan has quit [Ping timeout: 240 seconds]
tmlind has quit [Remote host closed the connection]
merbanan has joined #linux-sunxi
apritzel has joined #linux-sunxi
gediz0x539 has quit [Ping timeout: 240 seconds]
gediz0x539 has joined #linux-sunxi
cmeerw has quit [Ping timeout: 268 seconds]
gediz0x539 has quit [Ping timeout: 246 seconds]
vagrantc has joined #linux-sunxi
BorgCuba has quit [Quit: Leaving]
t3st3r has quit [Remote host closed the connection]
t3st3r has joined #linux-sunxi