Linux 4.18-rc3 Kernel Released

[bridgman]

It should be quite possible to add some logic to amdgpu_dm.c that simply checks if the connector is HDMI and the resolution is 4K and sets bpc = 8 if those are true in less than 6 lines. I suspect that support for YCbCr 4:2:2 and 4:2:0 would require a whole lot more.

Ahh, you're talking about a quick workaround (which would prevent anyone from using 4K/30/10 on HDMI 2.0 even if they wanted to) rather than fixing the problem properly - which I *think* needs to be done in the X server but not 100% sure.

That probably explains why you are expecting a fix more quickly than we would expect to deliver it. I'm not saying there is anything wrong with your thinking, but I expect it is different from the way the developers are approaching the problem.

I agree that if a better solution can not be found reasonably quickly then something like what you suggested might be all we can get into 4.18; just don't think it should be the first approach on the list.

4.17 works fine, it's just a problem with 4.18 that showed up some commits before 4.18rc1. Isn't in a release yet. Perhaps it won't be if we all scream total scandal and or bloody murder before 4.18 ships? I know about that story about some boy who cried wolf and all but screaming total scandal still works (for now).

Screaming total scandal or bloody murder doesn't accomplish anything. Submitting a good bug ticket and responding to the developers (which you have done) is what makes things happen. Anything else on top of that might make you feel better, but that's about it.

If you take two comparable problems (the difficulty of the problem is what really affects fix time, and bisectable regressions are generally the easiest to deal with), file comparable bug tickets and respond comparably to the developers, but scream bloody murder about one and quietly sacrifice a goat to the other, on average you will find that fix times are pretty similar.

[faldzip]

What if someone prefer 10-bit over 60Hz? Then implementing your changes, xiando, would be a total scandal for him.

[xiando]

I'm not saying there is anything wrong with your thinking, but I expect it is different from the way the developers are approaching the problem.

I agree that if a better solution can not be found reasonably quickly then something like what you suggested might be all we can get into 4.18; just don't think it should be the first approach on the list.

If there's a better solution then that's great. And there are some, one good option could be to make xfce4-display-settings and similar tools for other desktops support color depth and not just resolution and refresh rate (and rotation and reflection). That would allow everyone could just configure accordingly. Not even seeing xrandr support for it in the manual page, though, so putting this in place will probably take some time.

The RX 570 with 3xDP I ordered will probably arrive tomorrow, so that'll be my personal "quick fix". I suspect others with 4k displays, specially those who have one that's just got HDMI ports, would appreciate it if some either quick or solid fix makes it into the 4.18 release that goes to distributions.

Anything else on top of that might make you feel better, but that's about it.

It did. Thank you.

What if someone prefer 10-bit over 60Hz? Then implementing your changes, xiando, would be a total scandal for him.

That would be someone else's scandal.

[FireBurn]

I'd say going from 60Hz -> 30Hz is a regression, where as adding 10bpc support is adding a new feature. I've reverted the commit locally - the whole point of getting Raven was to output via HDMI 2.0 to my TV. This isn't a scandal - it's a regression and it's being treated as such

[M@GOid]

10 bit color monitors are not a cheap thing, specially 4k ones. I have a hard time thinking someone making the extra effort to buying a 4k, 10bit monitor to plug it over HDMI. So defaulting 8bit mode when connected via HDMI looks like a sane decision to me.

[Vistaus]

This total scandal

[agd5f]

According to https://bugs.freedesktop.org/show_bug.cgi?id=83226 it looks like the radeon driver supports colorspace switching between RGB and YUV. I imagine if it works on that driver, Xorg has the ability to do it, but I'm not 100% aware of why it isn't implemented in amdgpu.

The driver can handle it just fine and the modes are exposed via the kernel modesetting interfaces. The surface format is independent from the display pipeline and the display pipe can handle the colorspace and bpc. The problem is the xserver currently does not expose YUV modes and the xserver mode structure has no concept of bpc or colorspace so there is no way to manually add the modes or select between them.

[xiando]

10 bit color monitors are not a cheap thing, specially 4k ones. I have a hard time thinking someone making the extra effort to buying a 4k, 10bit monitor to plug it over HDMI. So defaulting 8bit mode when connected via HDMI looks like a sane decision to me.

You are wrong. I understand why you'd think that but most modern monitors sold today actually do support 10-bit (data link, not the same as displaying 10-bit HDR). All my 4k's do and my other system's 1440p does as well. It is actually really common to support 10-bit and most monitors produced the last few years do. And another random person who posted earlier in this thread happens to have a 10-bit monitor which only has HDMI inputs.

I believe this is why you're thinking they are not cheap and common: Monitors and TV's advertised as "HDR" and "10-bit" really are very expensive. And those are probably rare. Modern monitors that tell the data link that they support 10-bit RGB are not rare, they are the rule not the exception. I didn't even know all my 4K's support 10-bit, nor did I know my 1440p does. Two of my 4K's are IPS, one is a TN. That TN panel with it's washed out TN-colors barely qualifies as a 6-bit display by marketing standards - yet it advertises to the graphics card that it's 10-bit. "Supporting" 10-bit for the data link (very common) is not the same as being able to actually display 10-bit HDR correctly (not common, and also has to do with brightness, contrast, etc).

The problem is the xserver currently does not expose YUV modes and the xserver mode structure has no concept of bpc or colorspace so there is no way to manually add the modes or select between them.

Thank you for your explanation. I suspected as much from no such options in any of the common tools (xrandr, xfce4-display-manager and so on). Fixing this is probably way out of the scope of driver development...

[dwagner]

it doesn't call back to 4k 60Hz 8-bit when 4k 60Hz 10-bit fails.

This total scandal is documented in freedesktop bug 106959 and is caused by linux.git commit e03fd3f300f6184c1264186a4c815e93bf658abb

While I think that "total scandal" is exaggerated, I understand your frustration, as I have experienced a similar unnecessary regression preventing 4k @60Hz via HDMI before - see https://bugs.freedesktop.org/show_bug.cgi?id=102820#c6

If you create some "automatic setting" or default value, please always consider that there are probably people with different preferences out there, and having some kernel cmdline option to state a different preference prevents a lot of frustration.

[dwagner]

I suspect that support for YCbCr 4:2:2 and 4:2:0 would require a whole lot more.

And I suspect you would not like the looks of it. Computer desktops are a use case where having different resolutions for luminance and chrominance really sucks - basically every colored line on colored ground looks shitty in everything but 4:4:4.

For movies, YCbCr 4:2:0 looks ok, but then you rarely need > 30 Hz refresh rate on the wire.