AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Tomasz Pakuła" <tomasz.pakula.oficjalny@gmail.com>
To: "Jani Nikula" <jani.nikula@linux.intel.com>,
	"Daniel Stone" <daniel@fooishbar.org>,
	"Michel Dänzer" <michel.daenzer@mailbox.org>
Cc: 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:47:06 +0100	[thread overview]
Message-ID: <de91cf5d1e282f12cb902a9c4b87ed074338b71b.camel@gmail.com> (raw)
In-Reply-To: <34863839c6d54e911597192bba6a54c3b9c97b75@intel.com>

On Tue, 2026-01-20 at 13:45 +0200, Jani Nikula wrote:
> 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.

Hmm, looking at the wp_content_type_v1 enum, I see it was probably based
on the CTA-861 Content Type information than can be supplied to the AVI
info frame? The values are identical. This surely could be plumbed into
drm_connector and basically directly set in the AVI info frame.

But, ALLM is something different and overrides the content type info. It
should be separate information, probably a simple switch to inform
drm_connector if it should be used. I don't know if ALLM setting should
always be exposed and let the drivers determine if it can be used, or
should it appear dynamically based on EDID though that's a consideration
for desktop environments.

In this case, ALLM of course would always take precedence and as far as
it's activation, it maybe would only be disabled when presenting
fullscreen photos/video? Content type notwithstanding.

Now, from a perspective of someone that actually uses PCs connected to
TVs and dip his toes into more TV topics, there should be a way to force
ALLM to be always on, no matter the content. I'd even advocate for it to
be the default because a long standing truth is that all the special
modes we have in our TVs and Monitors are garbage. They mess up the
picture, boost it to high heavens and some mode forcibly turn on motion-
smoothing.

With a PCs, we always expect the content to already be sent in high
quality, and even HTPC users prefer any post-process to be done on the
PC itself. Moreover, mode picture mode switching causes jarring
transitions and in same cases, toggling game mode can even blank a
screen for a moment, though it's rare.

We at least got Filmmaker mode as a crux, that often still need little
fine tuning, but doesn't make a mess of the picture. Oftentimes TVs will
detect PCs and disable most processing outright and content types can
have little to no effect. Again, like always with TVs, YMMV.

Game mode, sometimes merged with PC mode doesn't suck, and usually gives
the picture that's the closest to what the media actually is (be it
vide, HDR video, photo) and closest to selected color gamut standards
like bt.709, DCI-P3, bt.2020. In many ways, it will provide best picture
quality already, but maybe marketing departments wouldn't agree.

I can assure you, that as soon as the TV starts changing modes based on
the content, and there isn't a way to disable it, people will complain
hard.

All in all, if there will be a way to obtain all this information and
set appropriate info in AVI/HF-VSDB, then I'm sure it will be plumbed
through but for now, I think just having ALLM forced is a good idea. 

Maybe, just maybe a property in sysfs/module setting could be used to
disable this if there's a big need.

There's another thing though. amdgpu already sets the IT content type
bit which already disables most if not all post-processing in sink
devices (or at least should). TVs often detect this as "PC" mode.
Sometimes ALLM is then needed to expose features like higher refresh
rate and VRR, thus the aforementioned mode change to update the exposed
EDID.

Oh, and ALLM only toggles the game mode if the game mode setting on the
TV is actually auto, with other values "off" and "on". It's just nice to
not have to manually turn it on.

Tomasz

  reply	other threads:[~2026-01-20 14:32 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
2026-01-20 12:47         ` Tomasz Pakuła [this message]
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=de91cf5d1e282f12cb902a9c4b87ed074338b71b.camel@gmail.com \
    --to=tomasz.pakula.oficjalny@gmail.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=jani.nikula@linux.intel.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=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