narmstrong changed the topic of #linux-amlogic to: Amlogic mainline kernel development discussion - our wiki http://linux-meson.com/ - ml linux-amlogic@lists.infradead.org - official channel moved from Freenode - publicly logged on https://libera.irclog.whitequark.org/linux-amlogic
Consolatis has quit [Ping timeout: 260 seconds]
Consolatis has joined #linux-amlogic
Ballerburg9005 has quit [Ping timeout: 255 seconds]
camus has joined #linux-amlogic
buzzmarshall has quit [Quit: Konversation terminated!]
Danct12 has joined #linux-amlogic
Danct12 has quit [Remote host closed the connection]
Danct12 has joined #linux-amlogic
repk_ has quit [Ping timeout: 255 seconds]
repk_ has joined #linux-amlogic
tdebrouw has joined #linux-amlogic
ldevulder_ is now known as ldevulder
<narmstrong> steev: yep the 1366x768 is tricky for every vendors, I didn't find a way to handle such quirk except by rejecting it
tolszak has joined #linux-amlogic
<Danct12> 1366x768 should be illegal :)
Danct12 has quit [Remote host closed the connection]
cmeerw[m] has quit [Quit: You have been kicked for being idle]
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #linux-amlogic
<tolszak> narmstrong: Any idea why cfg/meson-hdmi.scc is enabled without X11 and wayland?
<tolszak> narmstrong: That was the cause the kernel stalled on my customized image
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #linux-amlogic
<Cheaterman> Bliblibli buddiez I hope y'all doing goodie
<Cheaterman> I need "hdmitx=forcergb" but it's from vendor kernel not mainline/tobetter
<Cheaterman> If someone knows how to make it work please do tell :-)
<narmstrong> tolszak: it should if screen is in the MACHINE_FEATURES
<narmstrong> Cheaterman: what kernel do you use ?
<Cheaterman> That's extremely interesting, thanks a lot narmstrong
<Cheaterman> I'll either apply this manually or use another source
<Cheaterman> Right now I'm using this
<Cheaterman> Oh uh
<Cheaterman> I have this commit apparently
<Cheaterman> It's worth noting my symptoms are consistent with the forcergb thing people keep reporting on forums (and it has a mention on wiki too)
<Cheaterman> apparently the consensus is that it's buggy TV firmware that erroneously reports YUV444 support?
<Cheaterman> (sounds especially weird given no other device than the N2+ exhibits this behavior)
<Cheaterman> People say I could use dvi mode to force RGB output but I don't want that (need HDMI audio support)
<Cheaterman> That type of stuff
<Cheaterman> https://forum.odroid.com/viewtopic.php?t=22383 this one being the first I found
<Cheaterman> But I tried grepping hdmitx and forcergb in the source before using that cmdline, turns out it was a good precaution to take
<narmstrong> Spoiler: it doesn't exist because HDMI spec mandates proper YUV444 support by default
<Cheaterman> narmstrong: Yeah that's also been my understanding
<narmstrong> It could be implemented with a `content type`DRM KMS connector property to prioritize RGB first
<Cheaterman> How do I hack my way around the issue for now? :-)
<Cheaterman> If the lowest common denominator is going to be RGB, I don't mind forcing it for real
<narmstrong> buy a proper screen that follows the HDMI spec :-)
<Cheaterman> That's not going to be an option if said screen works fine with _all_ other devices :-)
<Cheaterman> It's just not the kind of pedantry I want to debate with my clients
<Cheaterman> (as in - N2+ driver might be accurate, but doesn't mean it shouldn't work with quirky devices if all other appliances do)
<narmstrong> you can hack dw_hdmi.c and move the YUV after the RGB modes in the output bus formats
<Cheaterman> Thanks, that sounds like exactly what I want - as "wrong" as it is given HDMI spec though
<Cheaterman> (as you said, my understanding is, the actual lowest common denominator _should_ be YUV?)
<narmstrong> HDMI is a TV spec, but people uses it for desktop displays like DVI should be used
<narmstrong> But DVI doesn't support audio transport
<Cheaterman> Yes ; especially problematic given DVI's lowest common denominator is RGB (makes sense for computers) while HDMI is YUV (which makes sense for movies), right?
<narmstrong> so they identify as an HDMI sink but sets bad bits in the EDID
<Cheaterman> I see ; hence we decode those bits and be like "oh yuv support letsgo" but we're wrong because that screen is misleading us?
<narmstrong> yep
<Cheaterman> makes a lot of sense, that's also what people seem to say on forums
<Cheaterman> the only part that surprises me is that said buggy screens generally work with other devices
<narmstrong> Since the dw_hdmi is a generic driver, it should follow spec...
<Cheaterman> TV decoders, other computers, you name it
<Cheaterman> I see
<narmstrong> Virtually no other devices outputs YUV on HDMI
<Cheaterman> as in, we can't go quirks-first, no matter the reality of the situation?
<Cheaterman> although a cmdline flag to toggle it would still be pretty convenient IMHO
<narmstrong> the proper way is the `content type` property and by default output RGB because reality sucks
<Cheaterman> I see - so there is a "proper" (sad...) fix
<Cheaterman> (as in, I guess that's what other drivers do?)
<narmstrong> it what intel does, and what other should do but other (rockchip) does this only on their off-tree kernels, they haven't pushed it upstream yet
<Cheaterman> I see, it actually kind of makes sense in some sort of sad twisted way - people don't wanna push spec-violating code to mainline
<narmstrong> something has been done for the RPI4 side because YUV output is necessary when you target 4k60
<Cheaterman> Ah interesting
<Cheaterman> narmstrong: I can't seem to find the reordering that I need to do in meson_dw_hdmi.c
<Cheaterman> or .h
<Cheaterman> but in meson_overlay.c there's « /* TOFIX DRM_FORMAT_RGB888 should be supported */
<Cheaterman> Is that perhaps relevant? RGB is literally not part of the formats in that switch
<Cheaterman> Or perhaps I'm looking at the entirely wrong place
<narmstrong> look in drivers/gpu/drm/bridges/synopsys/dw_hdmi.c <= this is the HDMI transceiver driver
<Cheaterman> Ah thanks a lot, was totally looking in the wrong place indeed
<Cheaterman> Ah
<Cheaterman> it's dw-hdmi :-D that's why I was confused (and so was `find`)
<Cheaterman> I think I found it, might be the ifs in config_AVI
<Cheaterman> I'll try reordering those and rebuilding
Ballerburg9005 has joined #linux-amlogic
<Cheaterman> Also I find it a bit ironic that HDMI spec mandates YUV support but there's still a bitflag to test it, meanwhile devices be like "yeah the spec mandates it so let's hardcode that bit to true"
<Cheaterman> while they don't support it at all
<Cheaterman> but as you said, that's just the ugly reality
<Cheaterman> Screen reports YUV422 apparently, and does so _exclusively_
<Cheaterman> checked with some silly printk
<Cheaterman> I'll try "true ||" before my rgb test
<Cheaterman> to force RGB mode
<Cheaterman> LOL red is the new black
<Cheaterman> That was _not_ a good idea
<Cheaterman> narmstrong: Could it be that we got it the wrong way around, an in fact the patch that you merged is causing issues?
ldevulder_ has joined #linux-amlogic
ldevulder has quit [Ping timeout: 252 seconds]
<Cheaterman> narmstrong: ARGH
<Cheaterman> That last thing was correct
buzzmarshall has joined #linux-amlogic
<Cheaterman> So the patch is broken here somehow
ldevulder_ has quit [Remote host closed the connection]
<narmstrong> nop, the patch is correct, it corrects YUV422, but it seems your monitor doesn't handle YU422
<narmstrong> so the fix is still the same, prioritize RGB before YUV422 & YUV444
<narmstrong> or simply remove YUV422 & YUV444 so it's never selected....
ldevulder has joined #linux-amlogic
Ballerburg9005 has quit [Ping timeout: 246 seconds]
camus has quit [Quit: camus]
camus has joined #linux-amlogic
vagrantc has joined #linux-amlogic
Ballerburg9005 has joined #linux-amlogic
camus has quit [Ping timeout: 240 seconds]
<vagrantc> 18
<vagrantc> hah
<Cheaterman> narmstrong: Then I'm misunderstanding how to do that ; because I tried using printk() to show the results of the functions used in this area: https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c#L1798
<Cheaterman> it says YUV422 ; I tried forcing frame.colorspace to different values here (including RGB) by reordering the tests and replacing the one I cared about with "true"
<Cheaterman> nothing helped - I got all sorts of strange colors but not correct ones
<Cheaterman> The only thing that helped for me somehow is reverting the patch
<Cheaterman> but maybe frame.colorspace isn't the only issue? I thought what you meant was reordering the if's there ; but in practice it seems like the only condition that evaluates to "true" for my monitor is "hdmi_bus_fmt_is_yuv422(hdmi->hdmi_data.enc_out_bus_format)"
<Cheaterman> So reordering alone isn't going to help
<Cheaterman> Hence, perhaps I'm misunderstanding what you meant
<Cheaterman> Forcing frame.colorspace to RGB made the blacks become red - my tty was on a red background for example - that's why I said "red is the new black" above
<Cheaterman> It's worth noting I'm by no means a color expert and I'm not making any measurements ; when I say "correct colors" what I mean is "more correct" - reds are reds, turquoise is turqoise
<Cheaterman> as opposed to reds being green or purple or black, and turquoise being green or yellow
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #linux-amlogic
gabes9 has joined #linux-amlogic
gabes has quit [Ping timeout: 240 seconds]
gabes9 is now known as gabes
GNUtoo has quit [Remote host closed the connection]
GNUtoo has joined #linux-amlogic
tolszak has quit [Remote host closed the connection]
anessen97 has joined #linux-amlogic
tdebrouw has quit [Quit: Leaving.]