LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Werner Sembach <wse@tuxedocomputers.com>
To: "Deucher, Alexander" <alexander.deucher@amd.com>,
	"Pekka Paalanen" <ppaalanen@gmail.com>,
	"amd-gfx list" <amd-gfx@lists.freedesktop.org>,
	"Ville Syrjälä" <ville.syrjala@linux.intel.com>,
	"Intel Graphics Development" <intel-gfx@lists.freedesktop.org>,
	"Maling list - DRI developers" <dri-devel@lists.freedesktop.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: New uAPI for color management proposal and feedback request v2
Date: Tue, 3 Aug 2021 11:38:19 +0200	[thread overview]
Message-ID: <e452775c-5b95-bbfd-e818-f1480f556336@tuxedocomputers.com> (raw)

Greetings,

Original proposal: https://www.mail-archive.com/amd-gfx@lists.freedesktop.org/msg62387.html

Abstract: Add "preferred color format", "active color format", "active bpc", and "active Broadcast RGB" drm properties,
to control color information send to the monitor.

It seems that the "preferred-" properties is not what is actually the most useful for the userspace devs.

Preferable (Note: with only a sample size of 2 people) would be a "force color format" property. If the color format is
not available for the current Monitor and GPU combo. the TEST_ONLY check should fail and the property should not be setable.

This however opens another problem: When a Monitor is disconnected and a new one is connected, the drm properties do not
get resetted. So if the old monitor did allow to set for example ycbcr420, but the new monitor does not support this
color format at all, it will stay permanently black until the drm property is set to a correct value by hand. This is
not an expected behavior imho.

So a discussion questions: Does it make sense that connector properties are keep for different Monitors?

If no: On connecting a new Monitor all atomic drm properties should be reset to a default value.

I have an idea how this could be implemented (correct me if i'm wrong): When an atomic property is attached it get
assigned an inital value. But if I understood the docu correctly, this value is ignored because atomic properties use
the getter and setter methods when their values are read or written. My implementation suggestion would be to iterate
over all attached atomic properties once a new monitor is connected and reset them to this initial value, which should
be unchanged since initialization? This assumes that besides the initial value being unused it's still a sane default
for all drivers.

Kind Regards,

Werner Sembach


             reply	other threads:[~2021-08-03  9:39 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-03  9:38 Werner Sembach [this message]
2021-09-16  9:24 ` Pekka Paalanen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e452775c-5b95-bbfd-e818-f1480f556336@tuxedocomputers.com \
    --to=wse@tuxedocomputers.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ppaalanen@gmail.com \
    --cc=ville.syrjala@linux.intel.com \
    --subject='Re: New uAPI for color management proposal and feedback request v2' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).