From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 05BF1423A65 for ; Tue, 20 Jan 2026 12:47:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.52 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768913233; cv=none; b=Uv+VXRUYUV5JTdvmpICzVAOGTXpW8Wk1/9sAfTJV1CYRD3ehqNsiHQhnG4F9MAAIzTXg7aH63utdny4Rae5MfjBuW9heTPieVmMTPclVyPDnJumrYF7kBXqjlw5SL5A6hhpYBHky6KwH27XW6BxwxpQRtUXes1Dg+Bo6+XNqexY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768913233; c=relaxed/simple; bh=b2YlJZiAZT7kTnDMLrP5TooRkttJj7D7VhWFPs2HhFs=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=W7yk8W9Zo56+q65YJD5KZe4lXdPLRx0c5erg8yvUghg1hSbJViogZ0JPgBM4Pqa7JsyMp615ptNZfALDM3N5S5xgW9jGEFRMQ/qnSrZpODRZZUts397fGjfvclVoIZbFqqty1SD5XJg+YGC5jaIi1Yq4j+kTTLrbwCyhAFdI8TE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=JuYJFKFZ; arc=none smtp.client-ip=209.85.208.52 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="JuYJFKFZ" Received: by mail-ed1-f52.google.com with SMTP id 4fb4d7f45d1cf-64b686e7d04so723579a12.3 for ; Tue, 20 Jan 2026 04:47:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768913230; x=1769518030; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding :disposition-notification-to:references:in-reply-to:date:cc:to:from :subject:message-id:from:to:cc:subject:date:message-id:reply-to; bh=b2YlJZiAZT7kTnDMLrP5TooRkttJj7D7VhWFPs2HhFs=; b=JuYJFKFZbxR0ju7UHVz/lVhhRxericYr5uIP/C18HcFQgc/QDiIYXMAAH3dM7zRTUx HiSF53QXYjTHBu/XULYjm9RXAJ/XiGnnAsCpBYPDQMGzuJORNd54FrdXDsS53+Y9Y0rs jcwCHppjLF+iMj9NvUIInNGS4jCHXZjSN700IS/PruyxEKVpymwzgTMgDmzcLAa9W93M i/V2+0skz8aMbAu7iqua4wS819mRjC0tNl4FJE8/CkgvnNssKfcvkltWW9Nyt2i6nIKb TWBw1komcvyoqpirJdJ7noCqpr+L06V1eHXYIkhT7TY2jAHktiYpPPAHtv4x9XO4k270 87Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768913230; x=1769518030; h=mime-version:user-agent:content-transfer-encoding :disposition-notification-to:references:in-reply-to:date:cc:to:from :subject:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=b2YlJZiAZT7kTnDMLrP5TooRkttJj7D7VhWFPs2HhFs=; b=Wn+f34hjhCF+T5Sj/Doc+TNFlCC7JT9gVBCUmPqnEW1WVW/fj4earyETfqgtDzRHnG OzKaYdFPlD50u3eUOifLibHUiMAF2wHn5eLsOGPObl8pXDTDW2jjZhf7YrcDRT2cfmWw eOy4p2yVupL/4nV5hnzF6KaBMQRfbO4wr88auAg5BcjejhPBu7tjVUBtIadvmiLU/uxP lYTTKvjqh+9Ru9tPb8E7BJOB0jZBHw7OSLmaosmYhtZ8aDjfCh3N3qHKzK3WiefPBf7J rR9M9WPf7KYSyOlBKwJmQ1+1fcziXXsCwnmb96nYJcyvxEgobB8ok0AbzT+iXfz5YA85 XzRg== X-Forwarded-Encrypted: i=1; AJvYcCUP5MRQaGg8sqqfAceoeMlcyVhv9UgA7/Q0F57B8Hs0HHI5Y2rz3CP8h6X3flqGVtLIBKn+PfK1uFn9Hgc=@vger.kernel.org X-Gm-Message-State: AOJu0YySZfCI9gR4CQkIUL72f7kl8xrfFs90m4KZkfFafkfDPn14bLyA RlCuXaj1YX5XReW1VCcg1CAYwStfRpB08K0jcOJW6M2nu7aUD3fd0mK1 X-Gm-Gg: AZuq6aKJEoaygWy3IQsdMubgsUjHB3OECGW68B7o4pbU1V/fsp1SMPjOMKfMYTs9wJ8 mcdeAfZiv8y427ztr1AUez4eQVBvVIXLrGvr+x2gN8YV2KdFnvc5nhzRijp1+1ioZ0RfmJhneGS +3zPVh0/JRTWtJTratI+rNL4BHTI12vSc83odrC4ru+lXiLsqcCUi9BwT2a7YTaJ6zc5PNEmBmd j76Xxl6Ies/jC7NCHb5XTW5AlwveYfV0uGAyAhKqMdqkS1MQIMWq+EoJIRN1gZyzPf/GtNl5X9i eVopv0X100bbevh/3s3H/CjDOZ6FiRljk4YWY55V4IpagP+A8RsrcJF3TvFRxejub9zyumh5jk8 GVTiDHu7NV7tFuQSOvhXS4MmoblvA82IMzOEGc6Pc5G01j9EXTVpXsvDR/32SHyU7YF94uBxlNf XhQlDakQqkW+8wM92BZ5xYCa0bWCLwQEu1UmdCoeTZH2KvbKMw4FGRkAuz/kIYOKnn9u5afbKfM NCw76BAtw== X-Received: by 2002:a05:6402:27cf:b0:64d:4623:8475 with SMTP id 4fb4d7f45d1cf-654524cf67cmr6634369a12.2.1768913229909; Tue, 20 Jan 2026 04:47:09 -0800 (PST) Received: from [192.168.1.239] (87-205-5-123.static.ip.netia.com.pl. [87.205.5.123]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-658029e060asm1309600a12.21.2026.01.20.04.47.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Jan 2026 04:47:09 -0800 (PST) Message-ID: Subject: Re: [PATCH 15/17] drm/amd/display: Trigger ALLM if it's available From: Tomasz =?UTF-8?Q?Paku=C5=82a?= To: Jani Nikula , Daniel Stone , Michel =?ISO-8859-1?Q?D=E4nzer?= 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 Date: Tue, 20 Jan 2026 13:47:06 +0100 In-Reply-To: <34863839c6d54e911597192bba6a54c3b9c97b75@intel.com> References: <20260119011146.62302-1-tomasz.pakula.oficjalny@gmail.com> <20260119011146.62302-16-tomasz.pakula.oficjalny@gmail.com> <82645a06-2d15-48fe-a250-56d736d636da@mailbox.org> <34863839c6d54e911597192bba6a54c3b9c97b75@intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.2 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Tue, 2026-01-20 at 13:45 +0200, Jani Nikula wrote: > On Tue, 20 Jan 2026, Daniel Stone wrote: > > Hi, > >=20 > > On Tue, 20 Jan 2026 at 10:33, Michel D=C3=A4nzer wrote: > > > On 1/19/26 02:11, Tomasz Paku=C5=82a wrote: > > > > [Why] > > > > ALLM automatically puts TVs into low latency modes (gaming modes) w= hich > > > > we basically always want for PC use, be it gaming, or using precise > > > > inputs like mice and keyboards. > > >=20 > > > How about e.g. video playback though? > > >=20 > > > It might make sense to let the Wayland compositor control this, e.g. = via the Wayland content type hint protocol. > >=20 > > Yes, I think this should be a connector property. We'll happily > > implement support for Weston as the uAPI vehicle. >=20 > Content type might be a useful policy hint also for content adaptive > brightness control and the like. >=20 > 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. >=20 > 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.=20 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