dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>,
	"Pekka Paalanen" <ppaalanen@gmail.com>
Cc: "Sebastian Wick" <sebastian.wick@redhat.com>,
	"Jonas Ådahl" <jadahl@redhat.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"Vitaly Prosyak" <vitaly.prosyak@amd.com>
Subject: Re: How should "max bpc" KMS property work?
Date: Fri, 20 May 2022 17:20:50 +0200	[thread overview]
Message-ID: <57d16ed5-8bfc-ce29-9250-14e2de18710a@redhat.com> (raw)
In-Reply-To: <YmgyArRaJCh6JkQh@intel.com>

Hi,

On 4/26/22 19:55, Ville Syrjälä wrote:
> On Tue, Apr 26, 2022 at 11:35:02AM +0300, Pekka Paalanen wrote:
>> Hi all,
>>
>> I'm working on setting HDR & WCG video modes in Weston, and I thought
>> setting "max bpc" KMS property on the connector would be a good idea.
>> I'm confused about how it works though.
>>
>> I did some digging in https://gitlab.freedesktop.org/wayland/weston/-/issues/612
>>
>> Summary:
>>
>> - Apparently the property was originally added as a manual workaround
>>   for sink hardware behaving badly with high depth. A simple end user
>>   setting for "max bpc" would suffice for this use.
>>
>> - Drivers will sometimes automatically choose a lower bpc than the "max
>>   bpc" value, but never bigger.
>>
>> - amdgpu seems to (did?) default "max bpc" to 8, meaning that I
>>   definitely want to raise it.
> 
> I've occasionally pondered about doing the same for i915, just to have
> the safest default possible. But I'd hate to lose the deep color testing
> coverage knowing very few people would in practice raise the limit.
> Also the number of systems where deep color doesn't work reliably
> (or can't be made to work by not using a crap cable) seems to be quite
> low.

I got pointed to this thread by Jonas Ådahl while asking some questions
the "max bpc" property related to:

https://gitlab.freedesktop.org/plymouth/plymouth/-/issues/102#note_1382328

The current i915 behavior which you describe here, which if I understand
things correctly is for "max bpc" to default to as high as possible is
causing problems with flickerfree boot in plymouth. Plymouth does a modeset
on the monitor's native resolution in case the BIOS/GOP setup the monitor
in a non native mode. Plymouth does not touch the "max bpc" property when
doing this modeset. Normally this works fine and when the BIOS/GOP has
already configured the monitor at the native resolution the i915 driver
will do a fastset and all is well.

Still the modeset is causing the screen to go black for multiple seconds,
despite the resolution being unchanged. What is happening according to
the on screen mode info from the monitor is that on plymouth's modeset
the link is being configured changes from 8 bpc to 10 bpc.

Is there anyway to avoid this without hardcoding "max bpc" to 8 in
plymouth (which would cause the same problem in the other direction
if the firmware sets up the link for 10bpc I believe) ?

Regards,

Hans


  parent reply	other threads:[~2022-05-20 15:20 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-26  8:35 How should "max bpc" KMS property work? Pekka Paalanen
2022-04-26 17:55 ` Ville Syrjälä
2022-04-27 10:52   ` Pekka Paalanen
2022-04-27 15:02     ` Michel Dänzer
2022-04-27 15:41     ` Harry Wentland
2022-04-27 21:29       ` Sebastian Wick
2022-04-28  7:50         ` Pekka Paalanen
2022-04-28  7:52           ` Simon Ser
2022-04-28 14:50             ` Ville Syrjälä
2022-04-28 19:00               ` Sebastian Wick
2022-05-20 15:20   ` Hans de Goede [this message]
2022-05-23  8:22     ` Pekka Paalanen
2022-05-23 11:54       ` Sebastian Wick
2022-05-24  9:36         ` Hans de Goede
2022-05-24 15:43           ` Ville Syrjälä
2022-05-24 22:03             ` Alex Deucher
2022-05-25  6:04               ` Simon Ser
2022-05-25  7:17                 ` Pekka Paalanen
2022-05-25  8:42               ` Michel Dänzer
2022-05-25  7:28         ` Pekka Paalanen
2022-05-25  8:35           ` Michel Dänzer
2022-05-25  9:23             ` Simon Ser
2022-05-25 10:36               ` Pekka Paalanen
2022-05-30 10:21                 ` Jani Nikula
2022-05-31 17:37                 ` Ville Syrjälä
2022-06-01  7:21                   ` How should "max bpc" and "Colorspace" " Pekka Paalanen
2022-06-01  7:26                     ` Simon Ser
2022-06-01 14:06                     ` Ville Syrjälä
2022-06-01 22:25                       ` Sebastian Wick
2022-06-02  7:47                       ` Pekka Paalanen
2022-06-02 16:40                         ` Ville Syrjälä
2022-06-02 17:08                           ` Sebastian Wick
2022-06-02 17:20                             ` Ville Syrjälä
2022-06-03  7:19                           ` Pekka Paalanen
2022-06-03 16:27                             ` Ville Syrjälä
2022-04-26 19:38 ` How should "max bpc" " Alex Deucher
2022-04-26 19:55   ` Ville Syrjälä

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=57d16ed5-8bfc-ce29-9250-14e2de18710a@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jadahl@redhat.com \
    --cc=ppaalanen@gmail.com \
    --cc=sebastian.wick@redhat.com \
    --cc=ville.syrjala@linux.intel.com \
    --cc=vitaly.prosyak@amd.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox