<jernej>
we drop A20 from LE, because it required a ton of work and nobody was prepared to do that
<ndufresne>
tone of work, you mean there is tone of downstream kernel patches ?
<jernej>
well, depends what you want
<jernej>
for example, HDMI audio has only initial patch but with a lot of problems
<jernej>
there is thing with primary DRM plane that it can't be smaller than screen resolution (annoying if player chose primary plane for video playback)
<jernej>
patch for this exist, but it has not made in mainline
<jernej>
yet
<jernej>
anyway, my preferred platform is H3 or newer, much easier to work since peripherals are more capable
<jernej>
there are problems with memory bandwith (not sure if A20 or sibling), but full HD is on upper limit
<jernej>
also deinterlacer is somehow part of display pipeline - no chance to have anything useful implemented for this anytime soon
<jernej>
maybe via DRM properties?
<jernej>
but some users would still like to see A20 as viable player and were very disappointed when I dropped A20 and A10 support from LE
<ndufresne>
jernej: all I wanted is to test tiling ;-D
<ndufresne>
I notice that overlay plane is can only scale opaque formats
<ndufresne>
so if I pass BGRA, it will not scale, while if I passe BGRx it wil
<ndufresne>
but haven't used/tested that base plane, as it used by fbcon
<jernej>
I'm not really familiar with A20 display pipeline
<ndufresne>
it's suni4
<ndufresne>
no idea if there is variant withing that branch
<ndufresne>
anyway, all I wanted is something to finish tiling to display integration, but if the decoder can't spit valid images mainline ...
<jernej>
sun4i-drm driver support all socs from A10 to H6 and eventually newer
<jernej>
currently 3 generations of display engine
<jernej>
but first one, used on A20, is a bit weird
<jernej>
composer part is split in two parts, called frontend and backend
<jernej>
and only one can YUV formats
<jernej>
IIRC
<jernej>
ask mripard, he implemented support for this
<jernej>
ndufresne: test LE image from link above, you can check if HW decoding works
<jernej>
but this is older kernel...
<ndufresne>
a bit unreliable, but at least decode in HW clean images in the image you privided
<jernej>
unreliable in what way?
<ndufresne>
this really looks downstream patches never made it, or some regression
<ndufresne>
the UI most likely, it hangs, I had to stop/ play fiew time before it manages to start playing bbb 1080
<jernej>
I didn't have any special patches for Cedrus on A20
<jernej>
try 720p
<jernej>
1080p is probably on upper limit
<ndufresne>
I see, but kind of work, wanted something hard enough so I'm sure it's not falling back to sw without telling ;-D
<jernej>
press "o"
<jernej>
you can see based on codec string if it is SW or HW
<ndufresne>
ok, format drm_prime, I guess this is right
<ndufresne>
and now i see that the CPU get maxed out for few s (about 10s) when I press play
Danct12 has quit [Remote host closed the connection]
<ndufresne>
it's HW decode, but the two cpus are always around 50%, which is pretty high
Danct12 has joined #cedrus
<ndufresne>
anyway
<jernej>
yeah, kodi isn't the most gentle app
<jernej>
lots of background tasks
<jernej>
it may be possible to optimize a bit...
<ndufresne>
jernej: so I pretty reproduce what gediz0x539 reported on A13, but I'm on A20
<ndufresne>
this is using same gst build as I run on H3, and works all right on H3
<jernej>
so, I can't really help here
<jernej>
I don't have A13 nor A10
<ndufresne>
I'm on A20, but I guess it's all the same line ..
<jernej>
yeah, they all have similar display pipeline and VPU variant
<jernej>
btw, A13 is single core cortex A8
<jernej>
while A20 is dual core cortex A7
<ndufresne>
oh well, I don't care enough to spend much time on it, I really just wanted to test something
<ndufresne>
I got plenty of better SoC for my own entertainment ;-D