Hi,
mið., 10. jan. 2024 kl. 13:09 skrifaði Werner Sembach <wse@xxxxxxxxxxxxxxxxxxx>:Hi, Am 10.01.24 um 11:11 schrieb Andri Yngvason:Hi, mið., 10. jan. 2024 kl. 09:27 skrifaði Maxime Ripard <mripard@xxxxxxxxxx>:On Tue, Jan 09, 2024 at 06:11:02PM +0000, Andri Yngvason wrote:From: Werner Sembach <wse@xxxxxxxxxxxxxxxxxxx> Add a new general drm property "preferred color format" which can be used by userspace to tell the graphic drivers to which color format to use. Possible options are: - auto (default/current behaviour) - rgb - ycbcr444 - ycbcr422 (not supported by both amdgpu and i915) - ycbcr420 In theory the auto option should choose the best available option for the current setup, but because of bad internal conversion some monitors look better with rgb and some with ycbcr444.I looked at the patch and I couldn't find what is supposed to happen if you set it to something else than auto, and the driver can't match that. Are we supposed to fallback to the "auto" behaviour, or are we suppose to reject the mode entirely? The combination with the active output format property suggests the former, but we should document it explicitly.It is also my understanding that it should fall back to the "auto" behaviour. I will add this to the documentation.Yes, that was the intention, and then userspace can check, but it wasn't well received: https://gitlab.freedesktop.org/drm/amd/-/issues/476#note_964530 Actually a lot of the thoughts that went into the original patch set can be found in that topic. There was another iteration of the patch set that I never finished and sent to the LKML because I got discouraged by this: https://lore.kernel.org/dri-devel/20210623102923.70877c1a@eldfell/Well, I've implemented this for sway and wlroots now and Simon has reacted positively, so this does appear likely to end up as a feature in wlroots based compositors.I can try to dig it up, but it is completely untested and I don't think I still have the respective TODO list anymore, so I don't know if it is a better or worst starting point than the last iteration I sent to the LKML.You can send the patches to me if you want and I can see if they're useful. I'm really only interested in the color format part though. Alternatively, you can continue your work and post it to LKML and I can focus on the userspace side and testing. By the way, I have an HDMI analyzer that can tell me the actual color format.
Searched for what I still had in my private repo, see attachments, filename is the branch name I used and like I said: I don't know which state these branches are in.
The hacking_ branch was based on 25fe90f43fa312213b653dc1f12fd2d80f855883 from linux-next and the rejected_ one on 132b189b72a94328f17fd70321bfe63e5b4208e9 from drm-tip.
And the rejected_ one is 2 weeks newer.
To pick it up again I would first need to allocate some time for it, ... which could take some time.
With a HDMI analyzer at hand you are better equipped then me
already. I was working with printf statements, Monitor OSD's and
test patterns like
https://media.extron.com/public/technology/landing/vector4k/img/scalfe-444Chroma.png
and http://www.lagom.nl/lcd-test/ while being red blind xD.
Thanks, Andri
Attachment:
hacking_drm_color_management_no_immutable_flag.tar.gz
Description: application/gzip
Attachment:
rejected_drm_color_management.tar.gz
Description: application/gzip
