linux-kernel - Re: [PATCH v1 2/2] drm/amd/display: Adjust AUX brightness to be a granularity of 100

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <88fec8864f2544df67113bf7282a1b2965a1eabd.camel@manjaro.org>
Date: Mon, 25 Aug 2025 09:02:34 +0200
From: Philip Mueller <philm@...jaro.org>
To: Antheas Kapenekakis <lkml@...heas.dev>, amd-gfx@...ts.freedesktop.org
Cc: dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org, Alex
 Deucher	 <alexander.deucher@....com>, Christian König	
 <christian.koenig@....com>, David Airlie <airlied@...il.com>, Simona Vetter
	 <simona@...ll.ch>, Harry Wentland <harry.wentland@....com>, Rodrigo
 Siqueira	 <siqueira@...lia.com>, Mario Limonciello
 <mario.limonciello@....com>, Peyton Lee <peytolee@....com>, Lang Yu
 <lang.yu@....com>
Subject: Re: [PATCH v1 2/2] drm/amd/display: Adjust AUX brightness to be a
 granularity of 100

On Sun, 2025-08-24 at 21:33 +0200, Antheas Kapenekakis wrote:
> Well Phil managed to fall into the value 332800, which has a 0 minor
> bit. Unfortunate. In hindsight, every 256 hundreds there would be a
> zero anyway.
> 
> Before I made this patch I made a partial refactor of panel-quirks
> where a quirk like this could go to. But I would really prefer not to
> do quirks. Ill send that too.
> 
> Antheas

I was already looking into that OLED issue for several weeks. Changing
granularity might hid the root cause and you might hit the issue less
frequently.

Currently checking [1] which changes the first byte to 3 since when
DP_SOURCE_BACKLIGHT_LEVEL is written to with
the first byte being 0x00 and sometimes 0x01, the panel forcibly
turns off until the device sleeps again.

In the end the panel vendor has to fix it in firmware. If not a quirk
might be better specific for each panel vendor.

I'm still not sure if that refactoring is needed, or a separate quirk
function is more logical to be accepted upstream.

[1]
https://lore.kernel.org/lkml/20250824200202.1744335-5-lkml@antheas.dev/T/#u