franoosh has quit [Remote host closed the connection]
nea999 has joined #linux-rockchip
chewitt has quit [Quit: Zzz..]
raster has joined #linux-rockchip
<mmind00>
naoki: yeah, after a bit of pondering I do agree that this can count as fix for the current cycle, so moved the commit over to the fixes branch
<naoki>
mmind00: thank you so much!
ldevulder has joined #linux-rockchip
ldevulder has quit [Remote host closed the connection]
ldevulder has joined #linux-rockchip
mripard has joined #linux-rockchip
franoosh has joined #linux-rockchip
chewitt has joined #linux-rockchip
<chewitt>
diederik the issue you posted looks exactly the same as I saw with 3588 when I first started poking the RK patchsets
<diederik>
chewitt: Ha! The issue template mentioned I should look at the forum first and there I did find your '12.90' thread. I wondered if I should('ve) reply to that thread instead as I suspected the problems would likely be the same
<diederik>
I have a spare Rock64 and I'll try your 12.90 image on that (the 12.2 is my main media player, so I prefer to keep that operational)
<chewitt>
cool
<chewitt>
in the last year both Alex and Jonas have been a little absent (for good reasons) so people have dropped things that didn't compile
<chewitt>
and i'm not sure whether those drops are valid, or the patch should have been reworked, or .. ?
<diederik>
Problem for me is that I don't understand enough to find out where the problem lies or could lie. Yesterday I tried testing with some additional params, but I don't know what they('re supposed to) do and thus how to interpret any different outcome. (None of them made things work though)
<chewitt>
I'm in the same boat
<chewitt>
I understand enough of the pipeline stuff to be dangerous or annoying with dumb Q's :)
<diederik>
:)
franoosh has quit [Ping timeout: 248 seconds]
<Kwiboo>
chewitt, diederik: those commits does indeed look very suspicious, I will take a closer look at the current patchset, current patchset is based on an older implementation of rkvdec h264 ui10/422 support than what now has landed upstream
<Kwiboo>
I can fully understand if that has caused some minor glitches for the hevc patches :-), I have personally mostly only tested the mainline patch series on top of linux-next on LibreELEC-base, and not current existing patches in the repo ;-)
<diederik>
awesome, thanks :) A patch set (variant) with various/lots of debug statements could be useful?
<chewitt>
Kwiboo I'm still going through ye olde patchset to put names against the individual patches/commits and see who I need to point fingers at
<diederik>
One error I get is this: ``[ffmpeg] V4L2RequestContext: Failed to set 1 control(s): Invalid argument (22)`` but knowing which control and which argument are 'wrong' here, could help find the underlaying cause?
<chewitt>
the control will be format related; hence you end up with the wrong format
<diederik>
probably. But knowing what is exactly expected and what actually happens may point to where the issue is.
<chewitt>
I started to redo the original patch but covering all the devices added since
<chewitt>
but then I remembered what we/me did for Amlogic, which was to key the alsa conf against the driver name instead of the card name
<Kwiboo>
some boards used to select analog audio out instead of hdmi audio as default device, at least back then when rockchip support was new to LibreELEC
<chewitt>
this appears to work, but some alsa conf fu is needed to tame the output
<chewitt>
instead of having e.g. 3 devices listed (on a Rock5b with 2x HDMI outputs) you end up with 8-9
<chewitt>
there are lots of default/sysdefault etc. items
<chewitt>
I'm okay with users needing to visit Kodi settings to set the correct audio device
<chewitt>
but I think there's some juju that can simplify the number of devices that are visible
<chewitt>
(that juju might also be in Kodi ..)
<chewitt>
the PROB-NOT-REQD patches might be useful to defer the problem for a bit while we focus on other things though
<chewitt>
I added some /* comments */ to each patch; mostly stating the obvious
<Kwiboo>
sounds good, and thanks for creating a branch with all relevant patches, I should probably in not too far distant future try to re-spin https://lore.kernel.org/all/20240908132823.3308029-1-jonas@kwiboo.se/ that was an attempt at reducing some of the hdmi related patches, but ended up possible making it even harder to rebase libreelec patches :-D
<chewitt>
Kwiboo P1 is to fix whatever we broke with rebasing of the patchset to restore functionality
<chewitt>
once that's done we can park 3288/3328/339 on a working kernel + patchset and do upstreaming in parallel
<chewitt>
P2 is then to separate the various change-sets into series that can be reworked/tested/etc. and sent to the list
<chewitt>
btw, the two patches that do the vop split don't look to be used anywhere
<chewitt>
i.e. I don't see anything in later patches that seems to target big/lit
<Kwiboo>
chewitt: regarding the vop big/lit split on rk3288, they have different resolution limits, so to ensure hdmi can work with 4k only big vop must be routed to for hdmi use, by default only vop lit was used for hdmi
<chewitt>
I spotted the difference in them
<chewitt>
but only saw some 'HACK' changes that deleted device-tree stuff to force vop selection
<chewitt>
perhaps that's the missing bit :)
<Kwiboo>
by just having them seperate and possible disable vop lit, we could be sure that vop big was used for hdmi, I do recall I worked on an upstream version, possible in one of my many linux tree branches or maybe only in my local tree
<chewitt>
there are too many similarly named branches for me to spot them :)
ungeskriptet has quit [Remote host closed the connection]
<Kwiboo>
hehe, yes my tree has far to many old and very similar branches :-D, I did find some rk3288 vop lit related patch in a local branch, but that commit could not be found at github, so probably not part of a branch that I pushed, main diff compared to LE patch version was to ensure DT backward compatible
ungeskriptet has joined #linux-rockchip
<Kwiboo>
the patch is also surounded by work-in-progress that finally ended up in the dw-hdmi series I linked earlier, so I probably switches focus and worked on the dw-hdmi parts using a different branch and left rest for "future"
<chewitt>
sounds plausible :)
<Kwiboo>
chewitt: I have started a local clean build of latest LE master for rk3399, will see if I can reproduce and fix the 10-bit hevc issue later
<chewitt>
thanks, that would be good
<chewitt>
btw, the other change I am thinking about is reworking the current $DEVICE(s) into ARMv7 and ARMv8 (two only)
<chewitt>
the 'soc' change in uboot_helper can keep the per-chipset filename presentation, which is nice for finding things in lists
<chewitt>
but we end up with only two things to build in CI
<chewitt>
instead of 6x with more on the horizon
<chewitt>
the lose the SoC specific compile optimisation, but I think the gain is marginal and not so important