Nakaori has quit [Remote host closed the connection]
Nakaori has joined #linux-sunxi
Nakaori has quit [Remote host closed the connection]
Nakaori has joined #linux-sunxi
selfbg has quit [Remote host closed the connection]
Nakaori has quit [Remote host closed the connection]
Nakaori has joined #linux-sunxi
Nakaori has quit [Remote host closed the connection]
Nakaori has joined #linux-sunxi
Nakaori has quit [Remote host closed the connection]
Nakaori has joined #linux-sunxi
jbrown has quit [Ping timeout: 252 seconds]
<ndufresne>
jernej, mripard: was on Tritium board (H3)
Nakaori has quit [Remote host closed the connection]
Nakaori has joined #linux-sunxi
<ndufresne>
mripard, the default of using plane ID seems arbitrary, I wonder who came up with that and didn't document it, specially that we have plane types like primary/overlay, which clearly indicates that overlay should be on top by default (if possible on the HW)
<rellla>
Nakaori: you may fix your connection ...
<paulk-leonov>
ndufresne: mhh not sure "overlay on top" makes more sense than the opposite
<paulk-leonov>
and vice-versa
<paulk-leonov>
rellla: some clients can rate-limit these sorts of messages btw
Nakaori has quit [Remote host closed the connection]
<rellla>
ah :)
Nakaori has joined #linux-sunxi
cnxsoft1 has quit [Quit: cnxsoft1]
<ndufresne>
paulk-leonov, *over*lay, not sure what else to say
Nakaori has quit [Remote host closed the connection]
Nakaori has joined #linux-sunxi
<paulk-leonov>
ndufresne: well that's definitely not a workable assumption with display hardware
<paulk-leonov>
as far as I know
<ndufresne>
there was an effort to add a new type of plane, underlay, I have no idea where is this, what was the conclusion
<paulk-leonov>
thing is, primary has a z-index just like any plane
<paulk-leonov>
IMO only cursor should rightfully always be on top
<paulk-leonov>
ndufresne: but e.g. Kodi needs the overlay under, not above
<paulk-leonov>
because overlay has the video and primary has UI and OSD
<ndufresne>
well, it's just a plane that is not primary then, anyway
<ndufresne>
the thing is that the default is ambiguous, since all the zpos are set to 0
jbrown has joined #linux-sunxi
<ndufresne>
if you set a clear default value to zpos, then you give a clear message to userspace instead of doing whatever one random app in the world like ignoring the usability for other
<paulk-leonov>
ndufresne: I see, that seems to be a legit bug
<paulk-leonov>
ndufresne: some new helpers were introduced for zpos recently which sun4i doesn't use yet AFAIK
<paulk-leonov>
could help sorting out this kind of nonsense
<ndufresne>
I'm actually wondering who uses these, I'd like to see if these helpers avoids this abiguity, seems like the driver needs to handle this anyway
<ndufresne>
specially on fixed layout HW
<ndufresne>
paulk-leonov, my argument is mostly that in absence of a doc/specification of the DRM properties, we should extra careful with avoiding this
<ndufresne>
if there has a been a doc, saying that if all zpos are zero, then plane ID defines the order, and tells if bigger means higher or lower, that would all be different story
<ndufresne>
s/are zero/are the same
Nakaori has quit [Remote host closed the connection]
<jernej>
ndufresne: planes in DE2/DE3 are by default in same order as in HW
freemangordon has joined #linux-sunxi
<jernej>
and HW has no notion of primary plane
Nakaori has joined #linux-sunxi
<jernej>
but second plane was selected, because first one is special
<ndufresne>
jernej, not sure I fully understand, it's a bit HW specific comment ;-P
<ndufresne>
but I understand that you should set them all as primary
<ndufresne>
of course, userspace would need support
<jernej>
afaik the can be only one primary?
<ndufresne>
I don't think so
<ndufresne>
note that a bit of this needs to be discovered by the app, using trial and error
<jernej>
DE2 means Display Engine 2 - second generation of display hardware on AW SoC (this is used on H3)
<ndufresne>
ok
<jernej>
and only first plane is capable of displaying YUV formats
<jernej>
so second is was selected as primary
<ndufresne>
anyway, current typing is fair, but then if you don't have a cursor, you should be able to use it, I suppose that works, but writing generic userspace for that seems impossible
<ndufresne>
the plane type seems like not being a HW match anymore ...
<jernej>
ask kwiboo, writing plane selection algorithm was royal pain for Kodi and it's fragile
<ndufresne>
since I've believe Ive seems that on other HW before
Nakaori has quit [Remote host closed the connection]
Nakaori has joined #linux-sunxi
<ndufresne>
jernej, I must admit I've been very lazy on that, I copied the one from kmscube, and backport things when they do updates, but khodi has more requirement
<jernej>
if you check plane capabilities of different SoCs, you see they don't have much in common
<jernej>
for example, i.MX6 is very limited
<jernej>
zpos has been avoided in Kodi
JohnDoe_71Rus has joined #linux-sunxi
<paulk-leonov>
I'm also under the impression that there can only be one primary plane
reinforce has quit [Quit: Leaving.]
<jernej>
because not all DRM drivers/HW support zpos and some older driver even have different name for this property
<paulk-leonov>
"All drivers should provide one primary plane per CRTC (although this requirement may change in the future)"
<paulk-leonov>
I understand that as exactly one plane
<jernej>
me too
<paulk-leonov>
and it's the de-facto standard among DRM drivers too
Nakaori has quit [Remote host closed the connection]
Nakaori has joined #linux-sunxi
<jernej>
primary plane is treated specially
<paulk-leonov>
I kind of like the UI/Video distinction better than overlay/primary
<paulk-leonov>
but anyway
<ndufresne>
it's an anti-documentation ;-P
Nakaori has quit [Remote host closed the connection]
<libv>
ndufresne: kms planes are, like much of kms, halfarsed afterthoughts
Nakaori has joined #linux-sunxi
<libv>
jbarnes wrote it up to make wayland and the open source intel driver competitive against android hw composer on power
<ndufresne>
I think it's on Intel that I notice multiple primary, but eh
<libv>
no z ordering or anything
<ndufresne>
worst is for RPi
<libv>
we also do not have per plane flip events
<ndufresne>
they don't have any limits, but they must have one with kms interface, so they create 49 layer, which in theory should all have primary capabilities
<libv>
which is monumental in the post atomic world
<libv>
as in monumentally bad
<libv>
in 2012 i was tasked to work for my former nokia manager, and he had just built up his team and did not know what to do with me, so i got tasked with making hwcomposer work with planes
<ndufresne>
libv, but it's atomic, so you should be able to abstract this
<ndufresne>
nice, and did you manage to get "something"
<libv>
the first thing i did was write code to test limits on intels pineview (which had multiple useful planes, as it was old hw), and on sandy bridge, my then main machine
<libv>
and it was hilarious how no limits were checked at all
Nakaori has quit [Remote host closed the connection]
<libv>
and on pineview i of course hit z-ordering issues immediately
<jernej>
ndufresne: btw, making underlay/overlay distinction doesn't make sense with planes here, because you can put them in any order you want, e.g. there is no plane which is always lower than primary
<libv>
and yet...
Nakaori has joined #linux-sunxi
<paulk-leonov>
ndufresne: yes don't hold on too much to the overlay/primary terminology
<paulk-leonov>
in many cases both are interchangeable
<libv>
it's a remnant of x86 display engines
<jernej>
but still less confusing that capture/output buffers ;)
<paulk-leonov>
jernej: agreed :p
<paulk-leonov>
AFAIK only cursor can be significantly different
<paulk-leonov>
because of index colors and stuff
<paulk-leonov>
indexed*
<libv>
paulk-leonov, plaes: btw, uwe's lime2 adapter has out of the box working lcd already
<libv>
i should get the adapters tomorrow, so i can finish the csi1 work and start implementing vga on tcon1
<ndufresne>
I don't hold on this, I think the typing is legacy
<ndufresne>
libv, jernej: what I'm asking for is to setup a default zpos that is not ambiguouis
<ndufresne>
in absence of documentation
<paulk-leonov>
libv: niiice
cristian_c has joined #linux-sunxi
<libv>
ndufresne: i read your statement, rolled my eyes, and moved on, so i am not much help there
<libv>
it makes sense to have a good default indeed
<paulk-leonov>
ndufresne: note that on <= A33 there's also a hardware bug where lowest plane can't have alpha
<ndufresne>
yeah, that's all I care about
<paulk-leonov>
or <= A20 or something
<paulk-leonov>
which is quite painful for e.g. Kodi
<jernej>
ndufresne: well, it's not, it's in HW order, which depends on HW capability, but in almost all cases, primary is second one
<jernej>
paulk-leonov: did you see how video playback is in Kodi on A20?
<paulk-leonov>
jernej: didn't keep track, no
<paulk-leonov>
I had to hack around last year
<ndufresne>
jernej, are we talking of the same thing ? the point of adding RO zpos on all driver is so that driver can express the HW specific order
<cristian_c>
I've got a question strictly not related from a developer, but from an user (me) about h3 on orange pi lite
<jernej>
ndufresne: zpos is actually RW in sun4i-drm
<jernej>
you can set it in any order you want
<cristian_c>
I mean: I've tested micro-usb otg port, but it seems not working (host or device)
<jernej>
but yes, default should be non-zero
<paulk-leonov>
jernej: so A20's sort of broken still?
<ndufresne>
jernej, yes, but there is an upstream effort so that when it's not possible, it is at least exposed in RO
<ndufresne>
many HW have fixed layout
<ndufresne>
anyway, to be continued
<cristian_c>
I don't know if this issue is related to kernel or os (armbian)
<jernej>
ndufresne: ok, but that doesn't affect sun4i-drm because supports changing zpos, so it's only a matter of default value
<ndufresne>
jernej, yep
<paulk-leonov>
cristian_c: what kernel version are you using? I sent a fix for that recently.
<ndufresne>
jernej, or doc we we thing the plane ID order is a good idea, I have no opinion on that, I didn't know it was a thing in some dev minds
<jernej>
paulk-leonov: if you have any idea how to fix it, I would be grateful. I don't have no HW or knowledge about DE1
<jernej>
s/no//
<paulk-leonov>
jernej: I'll probably hit the same issue soon on my side anyway, so there's a good chance I'll take a look
jbrown has quit [Remote host closed the connection]
<cristian_c>
paulk-leonov: 4.19.38, but I must check carefully
<paulk-leonov>
cristian_c: that's way outdated
<paulk-leonov>
please update
<paulk-leonov>
if you want some support
<cristian_c>
ok, I check immdiately
<paulk-leonov>
anyway the fix I sent it was in 5.2 (or maybe 5.1 but not earlier)
<jernej>
paulk-leonov: but as I said, issue is visible only when two planes are used
xes has quit [Ping timeout: 258 seconds]
<ElBarto>
libv: what is this board ? (on you pic)
<libv>
intermediate test board for fosdem video-input board
<ElBarto>
ok
<libv>
so we can test the lcd connection, csi1 rgb and vga before going all-in
<ElBarto>
nice
<libv>
on top of a lime2
<libv>
we will be attaching the adafruit tfp401 in this version
<libv>
but this is just to test whether we can get csi1 stable enough at 75Mhz (720p)
Nakaori has quit [Remote host closed the connection]
Nakaori has joined #linux-sunxi
<libv>
if we can, we will go for a full adv7611 board (which also gives us i2s input), with of course vga-out and lcd-out
<libv>
this will vastly improve the portability and affordability of the fosdem video boxes
<libv>
while giving us heaps more control
<plaes>
you have jtag there?
<libv>
plaes: yeah, uwe wanted that for himself, so who are we to say no to that?
<plaes>
:D
<cristian_c>
paulk-leonov: done, unfortunately armbian shows 4.19.38-sunxi as last update available
<libv>
he has 7 boards of this, 2 of which already have been populated, and we will really just be using those to verify things and to bring up the driver support
<cristian_c>
paulk-leonov: probably, I cpuld find a new kernel somewhere else (manual install)
<cristian_c>
*could
jbrown has joined #linux-sunxi
<cristian_c>
ok, config utility shows the -dev branch
Nakaori has quit [Remote host closed the connection]
pmpp has joined #linux-sunxi
Nakaori has joined #linux-sunxi
tomeu has joined #linux-sunxi
<tomeu>
hi! what's the incantation to get into fel mode on pine64 h64?
<tomeu>
got into fel mode right after boot, but apparently boot1 hasn't been initialized
<rellla>
i can try whatever board you want me to :) preferably not the Banana Pi and the Cubietruck because they are in productive use, but changing SD card should not be a problem ...
Nakaori has quit [Remote host closed the connection]
Nakaori has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
netlynx has joined #linux-sunxi
kaspter has quit [Read error: Connection reset by peer]
<KotCzarny>
jerner, would you be interested in making installer image in the vein of h3droid that will present itself with configurator? (since all one needs usually is just swapping uboot and dtb)
<mripard>
ndufresne: so, implementation sort them by plane ID, documentation says that the order is undefined
<JohnDoe_71Rus>
works for me. partially
Nakaori has quit [Remote host closed the connection]