From: Pekka Paalanen <pekka.paalanen@haloniitty.fi>
To: Harry Wentland <harry.wentland@amd.com>
Cc: "Hamza Mahfooz" <hamza.mahfooz@amd.com>,
amd-gfx@lists.freedesktop.org,
"Mario Limonciello" <mario.limonciello@amd.com>,
"Leo Li" <sunpeng.li@amd.com>,
"Rodrigo Siqueira" <Rodrigo.Siqueira@amd.com>,
"Alex Deucher" <alexander.deucher@amd.com>,
"Christian König" <christian.koenig@amd.com>,
"Pan, Xinhui" <Xinhui.Pan@amd.com>,
"David Airlie" <airlied@gmail.com>,
"Daniel Vetter" <daniel@ffwll.ch>,
"Alex Hung" <alex.hung@amd.com>,
"Srinivasan Shanmugam" <srinivasan.shanmugam@amd.com>,
"Wayne Lin" <wayne.lin@amd.com>,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] drm/amd/display: add panel_power_savings sysfs entry to eDP connectors
Date: Fri, 16 Feb 2024 17:42:42 +0200 [thread overview]
Message-ID: <20240216174242.15d07657@eldfell> (raw)
In-Reply-To: <82280a39-4e1d-41ee-82fb-758ceed953e4@amd.com>
[-- Attachment #1: Type: text/plain, Size: 2572 bytes --]
On Fri, 16 Feb 2024 09:33:47 -0500
Harry Wentland <harry.wentland@amd.com> wrote:
> On 2024-02-16 03:19, Pekka Paalanen wrote:
> > On Fri, 2 Feb 2024 10:28:35 -0500
> > Hamza Mahfooz <hamza.mahfooz@amd.com> wrote:
> >
> >> We want programs besides the compositor to be able to enable or disable
> >> panel power saving features.
> >
> > Could you also explain why, in the commit message, please?
> >
> > It is unexpected for arbitrary programs to be able to override the KMS
> > client, and certainly new ways to do so should not be added without an
> > excellent justification.
> >
> > Maybe debugfs would be more appropriate if the purpose is only testing
> > rather than production environments?
> >
> >> However, since they are currently only
> >> configurable through DRM properties, that isn't possible. So, to remedy
> >> that issue introduce a new "panel_power_savings" sysfs attribute.
> >
> > When the DRM property was added, what was used as the userspace to
> > prove its workings?
> >
>
> I don't think there ever was a userspace implementation and doubt any
> exists today. Part of that is on me. In hindsight, the KMS prop should
> have never gone upstream.
>
> I suggest we drop the KMS prop entirely.
Sounds good. What about the sysfs thing? Should it be a debugfs thing
instead, assuming the below question will be resolved?
> As for the color accuracy topic, I think it is important that compositors
> can have full control over that if needed, while it's also important
> for HW vendors to optimize for power when absolute color accuracy is not
> needed. An average end-user writing code or working on their slides
> would rather have a longer battery life than a perfectly color-accurate
> display. We should probably think of a solution that can support both
> use-cases.
I agree. Maybe this pondering should start from "how would it work from
end user perspective"?
"Automatically" is probably be most desirable answer. Some kind of
desktop settings with options like "save power at the expense of image
quality":
- always
- not if watching movies/gaming
- on battery
- on battery, unless I'm watching movies/gaming
- never
Or maybe there already is something like that, and it only needs to be
plumbed through?
Which would point towards KMS clients needing to control it, which
means a generic KMS prop rather than vendor specific?
Or should the desktop compositor be talking to some daemon instead of
KMS for this? Maybe they already are?
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-02-16 15:42 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-02 15:28 [PATCH v2] drm/amd/display: add panel_power_savings sysfs entry to eDP connectors Hamza Mahfooz
2024-02-02 16:20 ` Mario Limonciello
2024-02-15 17:54 ` Harry Wentland
2024-02-15 18:15 ` Mario Limonciello
2024-02-16 8:58 ` Jani Nikula
2024-02-16 8:19 ` Pekka Paalanen
2024-02-16 13:43 ` Hamza Mahfooz
2024-02-16 14:00 ` Hamza Mahfooz
2024-02-16 14:33 ` Harry Wentland
2024-02-16 15:42 ` Pekka Paalanen [this message]
2024-02-16 16:11 ` Harry Wentland
2024-02-16 16:13 ` Harry Wentland
2024-02-16 16:32 ` Mario Limonciello
2024-02-19 9:05 ` Pekka Paalanen
2024-02-16 10:29 ` Christian König
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=20240216174242.15d07657@eldfell \
--to=pekka.paalanen@haloniitty.fi \
--cc=Rodrigo.Siqueira@amd.com \
--cc=Xinhui.Pan@amd.com \
--cc=airlied@gmail.com \
--cc=alex.hung@amd.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=hamza.mahfooz@amd.com \
--cc=harry.wentland@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=srinivasan.shanmugam@amd.com \
--cc=sunpeng.li@amd.com \
--cc=wayne.lin@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