<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]
<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]