Re: [PATCH 5/7] drm/uAPI: Add "preferred color format" drm property as setting for userspace

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

Am 10.01.24 um 14:42 schrieb Andri Yngvason:
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


[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux