lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <de91cf5d1e282f12cb902a9c4b87ed074338b71b.camel@gmail.com>
Date: Tue, 20 Jan 2026 13:47:06 +0100
From: Tomasz Pakuła <tomasz.pakula.oficjalny@...il.com>
To: Jani Nikula <jani.nikula@...ux.intel.com>, Daniel Stone
	 <daniel@...ishbar.org>, Michel Dänzer
	 <michel.daenzer@...lbox.org>
Cc: alexander.deucher@....com, harry.wentland@....com, sunpeng.li@....com, 
	maarten.lankhorst@...ux.intel.com, mripard@...nel.org, tzimmermann@...e.de,
 	airlied@...il.com, simona@...ll.ch, siqueira@...lia.com, 
	dri-devel@...ts.freedesktop.org, amd-gfx@...ts.freedesktop.org, 
	linux-kernel@...r.kernel.org, bernhard.berger@...il.com, 
	ville.syrjala@...ux.intel.com
Subject: Re: [PATCH 15/17] drm/amd/display: Trigger ALLM if it's available

On Tue, 2026-01-20 at 13:45 +0200, Jani Nikula wrote:
> On Tue, 20 Jan 2026, Daniel Stone <daniel@...ishbar.org> wrote:
> > Hi,
> > 
> > On Tue, 20 Jan 2026 at 10:33, Michel Dänzer <michel.daenzer@...lbox.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ