From: Pekka Paalanen <ppaalanen@gmail.com>
To: Hans de Goede <hdegoede@redhat.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: Mon, 23 May 2022 11:22:46 +0300 [thread overview]
Message-ID: <20220523112246.056ddc99@eldfell> (raw)
In-Reply-To: <57d16ed5-8bfc-ce29-9250-14e2de18710a@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2305 bytes --]
On Fri, 20 May 2022 17:20:50 +0200
Hans de Goede <hdegoede@redhat.com> wrote:
> 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) ?
Hi Hans,
there was an attempt to get much of the current link state information
delivered to userspace, but I've forgot most about it.
I did find https://lkml.org/lkml/2021/6/18/294 linked from
https://gitlab.freedesktop.org/drm/amd/-/issues/476#note_963469 .
I said the same in the Plymouth Gitlab issue you linked to.
Personally, I would need to know all current link details for
(professional) color management: am I still driving the monitor with
the same signal as I did when I measured the monitor one reboot ago?
If not, I cannot trust the color output and need to measure again.
Nice to see there would be other uses for knowing which might be higher
priority to the larger community.
Would it be proper to initialize 'max bpc' to the link depth used by
boot-up firmware? I guess it could make things more reliable and solve
the Plymouth blanking issue, but not the professional color management
use cases.
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-05-23 8:23 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
2022-05-23 8:22 ` Pekka Paalanen [this message]
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=20220523112246.056ddc99@eldfell \
--to=ppaalanen@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=hdegoede@redhat.com \
--cc=jadahl@redhat.com \
--cc=sebastian.wick@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.