Re: [REGRESSION] Please revert 1191285ecb42 from 7.1.y

Re: [REGRESSION] Please revert 1191285ecb42 from 7.1.y

[Thorsten Leemhuis]

[CCing a few people and lists]

/me just wanted to send a revert request himself, but then saw that
there was one to join in

On 8/11/26 04:29, Greg KH wrote:
> On Mon, Aug 10, 2026 at 03:17:43PM +0200, Sergio Callegari wrote:
>> after having looked a bit more thoroughly into the matter, and having gone
>> through the relevant commits that introduced and subsequently modified the
>> AMD backlight brightness code paths, I would like to suggest reverting
>> commit
>>
>> 1191285ecb4233e5bf907da7e9394d7999055566

For the record, that is f1b5d8f9cc54ae ("drm/amd/display: Fix backlight
max_brightness to match exported range") [v7.2-rc4, v7.1.6
(1191285ecb4233), v6.18.42 (490ceacd2162de)]

And yes, 6.18.y seems affected, too, according to a comment in the
ticket linked below.

>> from the 7.1 stable series.
> 
> It needs to be reverted in Linus's tree first, otherwise the regression
> will be hit when you update to 7.2.
Normally I'd agree, but according to one reporter that problem does not
happen with 7.2-rc:
https://gitlab.freedesktop.org/drm/amd/-/work_items/5562#note_3603131

So it seems it's some missing backport or something like that. But it
seems nobody yet has mentioned which other change(s) might be be
missing, unless I missed it (which is quite possible).

Quite a few people are affected, as can be seen by all the duplicated
Alex marked for the ticket linked above.

Given all that I wonder if dropping that commit for now might be the
best move.

Ciao, Thorsten

Re: [REGRESSION] Please revert 1191285ecb42 from 7.1.y

[Sergio Callegari]

On 11/08/2026 07:24, Thorsten Leemhuis wrote:
 >
 > And yes, 6.18.y seems affected, too, according to a comment in the
 > ticket linked below.
 >

Yes, my bad I only mentioned 7.1.6 to be quick. My actual concern is 
that the troublesome commit got to the LTS kernels, which I think is the 
biggest issue right now. People may find their display completely black 
or almost black as soon as their DE starts. Getting to the conclusion 
that they need to /reduce/ the brightness to recover is not totally 
obvious and is not applicable at all if you have a system that is 
touchscreen only (since you won't be able to see where to press).

 >> It needs to be reverted in Linus's tree first, otherwise the regression
 >> will be hit when you update to 7.2.

Indeed, but I think the biggest issue is with the LTS kernels right now.

 > Normally I'd agree, but according to one reporter that problem does not
 > happen with 7.2-rc:
 > https://gitlab.freedesktop.org/drm/amd/-/work_items/5562#note_3603131

I'll see if I can try myself the 7.2 RCn series. From my superficial 
analysis of the commits that brought us to the current situation, the 
troublesome commit actually tried to patch on a true issue, namely that 
the user facing brightness data is not mapped symmetrically to the 
hardware data, but that the correct solution involves some more thorough 
rework of the brightness coordinate system. So there may well be some 
larger activity on it on upstream.
 >
 > Given all that I wonder if dropping that commit for now might be the
 > best move.

Personally, I think that dropping on the stable series would be 
beneficial, unless upstream can now offer a correct solution to pick. 
Behavior you get by dropping is not 100% ideal but certainly not as bad 
as what you get with the problematic commit.

Best,
Sergio

Re: [REGRESSION] Please revert 1191285ecb42 from 7.1.y

[Greg KH]

On Tue, Aug 11, 2026 at 09:28:52AM +0200, Sergio Callegari wrote:
> On 11/08/2026 07:24, Thorsten Leemhuis wrote:
> >
> > And yes, 6.18.y seems affected, too, according to a comment in the
> > ticket linked below.
> >
> 
> Yes, my bad I only mentioned 7.1.6 to be quick. My actual concern is that
> the troublesome commit got to the LTS kernels, which I think is the biggest
> issue right now. People may find their display completely black or almost
> black as soon as their DE starts. Getting to the conclusion that they need
> to /reduce/ the brightness to recover is not totally obvious and is not
> applicable at all if you have a system that is touchscreen only (since you
> won't be able to see where to press).
> 
> >> It needs to be reverted in Linus's tree first, otherwise the regression
> >> will be hit when you update to 7.2.
> 
> Indeed, but I think the biggest issue is with the LTS kernels right now.
> 
> > Normally I'd agree, but according to one reporter that problem does not
> > happen with 7.2-rc:
> > https://gitlab.freedesktop.org/drm/amd/-/work_items/5562#note_3603131
> 
> I'll see if I can try myself the 7.2 RCn series. From my superficial
> analysis of the commits that brought us to the current situation, the
> troublesome commit actually tried to patch on a true issue, namely that the
> user facing brightness data is not mapped symmetrically to the hardware
> data, but that the correct solution involves some more thorough rework of
> the brightness coordinate system. So there may well be some larger activity
> on it on upstream.
> >
> > Given all that I wonder if dropping that commit for now might be the
> > best move.
> 
> Personally, I think that dropping on the stable series would be beneficial,
> unless upstream can now offer a correct solution to pick. Behavior you get
> by dropping is not 100% ideal but certainly not as bad as what you get with
> the problematic commit.

We aim to be "bug compatible" with Linus's branch, otherwise the
"pressure" to fix those bugs goes down.  But I defer to the maintainers
of the code involved if it is being worked on, and they want it
reverted, great, we can do that.  Otherwise we prefer to leave it as-is.

thanks,

greg k-h

Re: [REGRESSION] Please revert 1191285ecb42 from 7.1.y

[Sergio Callegari]

On 11/08/2026 10:08, Greg KH wrote:
> We aim to be "bug compatible" with Linus's branch, otherwise the
> "pressure" to fix those bugs goes down.  But I defer to the maintainers
> of the code involved if it is being worked on, and they want it
> reverted, great, we can do that.  Otherwise we prefer to leave it as-is.

I understand. Sorry for asking about things that might be obvious to 
most people here. My expectation was that only a selected subset of the 
patches on the Linus' tree were to enter in stable, so do we really need 
to have stable "bug compatible" wrt this bug? The original behavior was 
not free of issues, but they were rather minor (a reporting issue). Now 
we have this very bad behavior where the display remains dark.

To make the matter worse, on systems that have encrypted root the screen 
remains dark also on that password prompt (observed with plymouth).

In any case, I managed testing 7.2.0RC7 and it is fine again.

Looks like the Linus' tree has more changes wrt backlight, and the 
interesting ones are probably those in the cumulative fix 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=973fd9493ec21f12e760fbbedeb7b0b2317c02f4.

Best,

Sergio

Re: [REGRESSION] Please revert 1191285ecb42 from 7.1.y

[Alex Deucher]

On Tue, Aug 11, 2026 at 11:25 AM Sergio Callegari
<sergio.callegari@gmail.com> wrote:
>
> On 11/08/2026 10:08, Greg KH wrote:
> > We aim to be "bug compatible" with Linus's branch, otherwise the
> > "pressure" to fix those bugs goes down.  But I defer to the maintainers
> > of the code involved if it is being worked on, and they want it
> > reverted, great, we can do that.  Otherwise we prefer to leave it as-is.
>
> I understand. Sorry for asking about things that might be obvious to
> most people here. My expectation was that only a selected subset of the
> patches on the Linus' tree were to enter in stable, so do we really need
> to have stable "bug compatible" wrt this bug? The original behavior was
> not free of issues, but they were rather minor (a reporting issue). Now
> we have this very bad behavior where the display remains dark.
>
> To make the matter worse, on systems that have encrypted root the screen
> remains dark also on that password prompt (observed with plymouth).
>
> In any case, I managed testing 7.2.0RC7 and it is fine again.
>
> Looks like the Linus' tree has more changes wrt backlight, and the
> interesting ones are probably those in the cumulative fix
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=973fd9493ec21f12e760fbbedeb7b0b2317c02f4.
>

Thanks for testing.  It sounds like we should revert the change from
stable.  There must be some dependency we are missing in stable.

Alex

> Best,
>
> Sergio
>
>

Re: [REGRESSION] Please revert 1191285ecb42 from 7.1.y

[Greg KH]

On Tue, Aug 11, 2026 at 01:25:14PM -0400, Alex Deucher wrote:
> On Tue, Aug 11, 2026 at 11:25 AM Sergio Callegari
> <sergio.callegari@gmail.com> wrote:
> >
> > On 11/08/2026 10:08, Greg KH wrote:
> > > We aim to be "bug compatible" with Linus's branch, otherwise the
> > > "pressure" to fix those bugs goes down.  But I defer to the maintainers
> > > of the code involved if it is being worked on, and they want it
> > > reverted, great, we can do that.  Otherwise we prefer to leave it as-is.
> >
> > I understand. Sorry for asking about things that might be obvious to
> > most people here. My expectation was that only a selected subset of the
> > patches on the Linus' tree were to enter in stable, so do we really need
> > to have stable "bug compatible" wrt this bug? The original behavior was
> > not free of issues, but they were rather minor (a reporting issue). Now
> > we have this very bad behavior where the display remains dark.
> >
> > To make the matter worse, on systems that have encrypted root the screen
> > remains dark also on that password prompt (observed with plymouth).
> >
> > In any case, I managed testing 7.2.0RC7 and it is fine again.
> >
> > Looks like the Linus' tree has more changes wrt backlight, and the
> > interesting ones are probably those in the cumulative fix
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=973fd9493ec21f12e760fbbedeb7b0b2317c02f4.
> >
> 
> Thanks for testing.  It sounds like we should revert the change from
> stable.  There must be some dependency we are missing in stable.

Great, can someone send a revert?

thanks,

greg k-h

Re: [REGRESSION] Please revert 1191285ecb42 from 7.1.y

[Alex Deucher]

On Tue, Aug 11, 2026 at 8:13 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Tue, Aug 11, 2026 at 01:25:14PM -0400, Alex Deucher wrote:
> > On Tue, Aug 11, 2026 at 11:25 AM Sergio Callegari
> > <sergio.callegari@gmail.com> wrote:
> > >
> > > On 11/08/2026 10:08, Greg KH wrote:
> > > > We aim to be "bug compatible" with Linus's branch, otherwise the
> > > > "pressure" to fix those bugs goes down.  But I defer to the maintainers
> > > > of the code involved if it is being worked on, and they want it
> > > > reverted, great, we can do that.  Otherwise we prefer to leave it as-is.
> > >
> > > I understand. Sorry for asking about things that might be obvious to
> > > most people here. My expectation was that only a selected subset of the
> > > patches on the Linus' tree were to enter in stable, so do we really need
> > > to have stable "bug compatible" wrt this bug? The original behavior was
> > > not free of issues, but they were rather minor (a reporting issue). Now
> > > we have this very bad behavior where the display remains dark.
> > >
> > > To make the matter worse, on systems that have encrypted root the screen
> > > remains dark also on that password prompt (observed with plymouth).
> > >
> > > In any case, I managed testing 7.2.0RC7 and it is fine again.
> > >
> > > Looks like the Linus' tree has more changes wrt backlight, and the
> > > interesting ones are probably those in the cumulative fix
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=973fd9493ec21f12e760fbbedeb7b0b2317c02f4.
> > >
> >
> > Thanks for testing.  It sounds like we should revert the change from
> > stable.  There must be some dependency we are missing in stable.
>
> Great, can someone send a revert?
>

Just sent.  Thanks.

Alex

> thanks,
>
> greg k-h