From: Jani Nikula <jani.nikula@linux.intel.com>
To: "Daniel Stone" <daniel@fooishbar.org>,
"Michel Dänzer" <michel.daenzer@mailbox.org>
Cc: "Tomasz Pakuła" <tomasz.pakula.oficjalny@gmail.com>,
alexander.deucher@amd.com, harry.wentland@amd.com,
sunpeng.li@amd.com, maarten.lankhorst@linux.intel.com,
mripard@kernel.org, tzimmermann@suse.de, airlied@gmail.com,
simona@ffwll.ch, siqueira@igalia.com,
dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org,
linux-kernel@vger.kernel.org, bernhard.berger@gmail.com,
ville.syrjala@linux.intel.com
Subject: Re: [PATCH 15/17] drm/amd/display: Trigger ALLM if it's available
Date: Tue, 20 Jan 2026 13:45:57 +0200 [thread overview]
Message-ID: <34863839c6d54e911597192bba6a54c3b9c97b75@intel.com> (raw)
In-Reply-To: <CAPj87rPyt2+cWjM7KmpRzY4sBgaUzZBOS3FJoxF+PjkijapTag@mail.gmail.com>
On Tue, 20 Jan 2026, Daniel Stone <daniel@fooishbar.org> wrote:
> Hi,
>
> On Tue, 20 Jan 2026 at 10:33, Michel Dänzer <michel.daenzer@mailbox.org> wrote:
>> On 1/19/26 02:11, Tomasz Pakuła wrote:
>> > [Why]
>> > ALLM automatically puts TVs into low latency modes (gaming modes) which
>> > we basically always want for PC use, be it gaming, or using precise
>> > inputs like mice and keyboards.
>>
>> How about e.g. video playback though?
>>
>> It might make sense to let the Wayland compositor control this, e.g. via the Wayland content type hint protocol.
>
> Yes, I think this should be a connector property. We'll happily
> implement support for Weston as the uAPI vehicle.
Content type might be a useful policy hint also for content adaptive
brightness control and the like.
Ville and I have also tossed around ideas for passing the "power mode"
to the DRM drivers (e.g. Performance, Balanced, Power Saver). There are
various cases where the drivers need to make policy decisions that would
be better decided by userspace. However, it gets complicated and
unweildy if all of them are individual knobs. A power mode input might
be useful in making the latency decisions too.
BR,
Jani.
--
Jani Nikula, Intel
next prev parent reply other threads:[~2026-01-20 11:46 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-19 1:11 [PATCH 00/17] drm/amd: VRR fixes, HDMI Gaming Features Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 01/17] drm/amd/display: Return if DisplayID not found in parse_amd_vsdb() Tomasz Pakuła
2026-01-19 13:23 ` Jani Nikula
2026-01-20 12:07 ` Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 02/17] drm/amd/display: Refactor amdgpu_dm_update_freesync_caps() Tomasz Pakuła
2026-01-19 8:23 ` kernel test robot
2026-01-19 1:11 ` [PATCH 03/17] drm/amd/display: Check for VRR range in CEA AMD vsdb Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 04/17] drm/amd/display: Use bigger VRR range if found in " Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 05/17] drm/amd/display: Refactor PCON VRR compatibility check Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 06/17] drm/amd/display: Add PCON VRR ID check override Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 07/17] drm/amd/display: Add CH7218 PCON ID Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 08/17] drm/edid: Parse more info from HDMI Forum vsdb Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 09/17] drm/amd/display: Rename PCON adaptive sync types Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 10/17] drm/amd/display: Enable HDMI VRR over PCON Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 11/17] drm/amd/display: Support HDMI VRRmax=0 Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 12/17] drm/amd/display: Build HDMI vsif in correct slot Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 13/17] drm/amd/display: Save HDMI gaming info to edid caps Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 14/17] drm/amd/display: Restore ALLM support in HDMI vsif Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 15/17] drm/amd/display: Trigger ALLM if it's available Tomasz Pakuła
2026-01-20 10:33 ` Michel Dänzer
2026-01-20 11:23 ` Daniel Stone
2026-01-20 11:45 ` Jani Nikula [this message]
2026-01-20 12:47 ` Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 16/17] drm/amd/display: Reintroduce VTEM info frame Tomasz Pakuła
2026-01-19 1:11 ` [PATCH 17/17] drm/amd/display: Enable HDMI VRR Tomasz Pakuła
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=34863839c6d54e911597192bba6a54c3b9c97b75@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=bernhard.berger@gmail.com \
--cc=daniel@fooishbar.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=harry.wentland@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=michel.daenzer@mailbox.org \
--cc=mripard@kernel.org \
--cc=simona@ffwll.ch \
--cc=siqueira@igalia.com \
--cc=sunpeng.li@amd.com \
--cc=tomasz.pakula.oficjalny@gmail.com \
--cc=tzimmermann@suse.de \
--cc=ville.syrjala@linux.intel.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
all inboxes | Powered by JetHome®