[REGRESSION] 2017 Pixelbook backlight control doesn’t work with 7.1 kernel

[REGRESSION] 2017 Pixelbook backlight control doesn’t work with 7.1 kernel

[Papool Chaudhari]

Device: 2017 Google Pixelbook i5 (Google's own chromebook from 2017)
Backlight: intel_backlight
OS: Arch using KDE Plasma 6.7.2 (Wayland via Kwin)
Firmware Type: RW_LEGACY firmware from MrChromeBox, updated to most
recent version
Internal storage type: SSD

Summary of the Issue
The Pixelbook has pretty much full functionality with linux, except
for two needed tweaks. Once is a chromebook audio script to run, and
the other is backlight.

Adjusting the backlight (using the slider in KDE) does not work
without editing your GRUB file and putting in this line:
GRUB_CMDLINE_LINUX=“i915.enable_dpcd_backlight=1”

This “fix” has worked with any flavor of linux. I have personally
tested in Kubuntu, MX Linux, CachyOS, and now Arch.

The problem now is, something changed with the Linux 7.1 kernel where
this doesn’t work anymore. Still works perfectly on 7.0.x kernel and
below, but any 7.1 (or 7.2rc kernel) does not work and I’ve tried a
million fixes, and nothing works. The million fixes include removing
that line, changing the value to 0, 2, or 3.

Tried this, didn’t work:
GRUB_CMDLINE_LINUX=“i915.enable_dpcd_backlight=1 i915.enable_psr=0
i915.enable_fbc=0” Also tried
GRUB_CMDLINE_LINUX=“acpi_backlight=native”

I have tried the software brightnessctl, making changes with it has no
effect. Also tried the software gammastep, doesn’t work. And other
ones like “colord” (I think that’s what it is called).

I've read the backlight section in arch wiki, nothing there that works
to fix this.

NOTHING changes the brightness if using 7.1 or newer kernel.

Steps to Reproduce
1.) Install RW_LEGACY MrChromebox firmware on Pixelbook and any flavor
of Linux with kernel 7.1 or higher.

2.) Edit GRUB_CMDLINE_LINUX=“i915.enable_dpcd_backlight=1” and update
grub. This is the fix for backlight controls that works for kernel
7.0.x and lower.

3.) With 7.1 kernel or higher, this fix does not work, neither do any
other known fixes for controlling backlight.

Expected Behavior
I should be able to use the slider in KDE for backlight/brightness and
adjust the brightness, just as I can do with any kernel 7.0.x or
lower. I have reached the conclusion that something changed in the 7.1
kernel, but have no idea on how to get this fixed. Or if it is even
possible. Perhaps I am stuck just using 7.0.x and below on this device
until EOL.

Re: [REGRESSION] 2017 Pixelbook backlight control doesn’t work with 7.1 kernel

[Greg KH]

On Wed, Jul 08, 2026 at 02:58:10PM -0600, Papool Chaudhari wrote:
> 3.) With 7.1 kernel or higher, this fix does not work, neither do any
> other known fixes for controlling backlight.

Can you use 'git bisect' to find the offending commit?  Odds are it's a
graphics driver change somewhere...

thanks,

greg k-h

Re: [REGRESSION] 2017 Pixelbook backlight control doesn’t work with 7.1 kernel

[Greg KH]

On Fri, Jul 10, 2026 at 11:09:34PM -0600, Papool Chaudhari wrote:
> Greg,
> 
> I did git bisect and this is the offending commit:
> 
> b3793af3277f65d256d67f9949e760b434ff66dd is the first 'bad' commit
> commit b3793af3277f65d256d67f9949e760b434ff66dd
> Merge: 51cc1c427461 88919bedabb8
> Author: Jiri Kosina <jikos@kernel.org>
> Date: Thu Apr 16 21:08:14 2026 +0200
> 
>    Merge branch 'for-7.1/intel-thc' into for-linus
> 
>    - power management improvements to intel-thc-hid driver (Even Xu)
> 
> drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c | 16
> ++++++++++------
> drivers/hid/intel-thc-hid/intel-thc/intel-thc-dev.c | 47
> +++++++++++++++++++++++++++++++++++++++++++++++
> drivers/hid/intel-thc-hid/intel-thc/intel-thc-hw.h | 4 ++++
> 3 files changed, 61 insertions(+), 6 deletions(-)

Odd that a merge commit is the issue.  ANd if you revert that change,
all is good?

thanks,

greg k-h

Re: [REGRESSION] 2017 Pixelbook backlight control doesn’t work with 7.1 kernel

[Papool Chaudhari]

I tried reverting commit b3793af3277f65d256d67f9949e760b434ff66dd on
top of v7.1, but the resulting kernel completely hangs at 'Loading
initial ramdisk'. Even when adding 'nomodeset' via GRUB, the crash
happens so early that no kernel text or console output is ever
printed. It appears this Intel THC merge cannot be cleanly isolated or
reverted on v7.1 without causing an immediate early boot failure on
this hardware.

Papool S. Chaudhari
PRA Law
14011 Pebble Hills Blvd. Ste 105
PMB #1003
El Paso, Texas 79938
(214) 702-1150
Papool@ChaudhariLaw.com


On Fri, Jul 10, 2026 at 11:32 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Fri, Jul 10, 2026 at 11:09:34PM -0600, Papool Chaudhari wrote:
> > Greg,
> >
> > I did git bisect and this is the offending commit:
> >
> > b3793af3277f65d256d67f9949e760b434ff66dd is the first 'bad' commit
> > commit b3793af3277f65d256d67f9949e760b434ff66dd
> > Merge: 51cc1c427461 88919bedabb8
> > Author: Jiri Kosina <jikos@kernel.org>
> > Date: Thu Apr 16 21:08:14 2026 +0200
> >
> >    Merge branch 'for-7.1/intel-thc' into for-linus
> >
> >    - power management improvements to intel-thc-hid driver (Even Xu)
> >
> > drivers/hid/intel-thc-hid/intel-quickspi/pci-quickspi.c | 16
> > ++++++++++------
> > drivers/hid/intel-thc-hid/intel-thc/intel-thc-dev.c | 47
> > +++++++++++++++++++++++++++++++++++++++++++++++
> > drivers/hid/intel-thc-hid/intel-thc/intel-thc-hw.h | 4 ++++
> > 3 files changed, 61 insertions(+), 6 deletions(-)
>
> Odd that a merge commit is the issue.  ANd if you revert that change,
> all is good?
>
> thanks,
>
> greg k-h

Re: [REGRESSION] 2017 Pixelbook backlight control doesn’t work with 7.1 kernel

[Greg KH]

On Sat, Jul 11, 2026 at 01:11:06AM -0600, Papool Chaudhari wrote:
> I tried reverting commit b3793af3277f65d256d67f9949e760b434ff66dd on
> top of v7.1, but the resulting kernel completely hangs at 'Loading
> initial ramdisk'. Even when adding 'nomodeset' via GRUB, the crash
> happens so early that no kernel text or console output is ever
> printed. It appears this Intel THC merge cannot be cleanly isolated or
> reverted on v7.1 without causing an immediate early boot failure on
> this hardware.

A merge point is usually not a good place to revert, as that can be
"odd".  I also don't really see a diff at this point in time, so can you
try both sides of the merge to see if they both work, or not?

thanks,

greg k-h

Re: [REGRESSION] 2017 Pixelbook backlight control doesn’t work with 7.1 kernel

[Greg KH]

On Sat, Jul 11, 2026 at 12:38:02PM -0600, Papool Chaudhari wrote:
> I tested both parent commits of the merge
> b3793af3277f65d256d67f9949e760b434ff66dd on my 2017 i5 Pixelbook (Eve)
> as requested, and unfortunately, neither side is bootable:
> 
> Side A (51cc1c427461): Fails to boot. Completely hangs early at
> "Loading initial ram disk".
> 
> Side B (88919bedabb8): Fails to boot. Hangs at the exact same early
> "Loading initial ram disk" stage.

That sounds like a different issue than the backlight, right?

Why not disable the ramdisk entirely for doing kernel build testing like
this?  It's not normally required unless you have some encrypted
partitions/disks.

thanks,

greg k-h

Re: [REGRESSION] 2017 Pixelbook backlight control doesn’t work with 7.1 kernel

[Thorsten Leemhuis]

On 7/12/26 07:50, Greg KH wrote:
> On Sat, Jul 11, 2026 at 12:38:02PM -0600, Papool Chaudhari wrote:
>> I tested both parent commits of the merge
>> b3793af3277f65d256d67f9949e760b434ff66dd on my 2017 i5 Pixelbook (Eve)
>> as requested, and unfortunately, neither side is bootable:
>>
>> Side A (51cc1c427461): Fails to boot. Completely hangs early at
>> "Loading initial ram disk".
>>
>> Side B (88919bedabb8): Fails to boot. Hangs at the exact same early
>> "Loading initial ram disk" stage.
> 
> That sounds like a different issue than the backlight, right?
> 
> Why not disable the ramdisk entirely for doing kernel build testing like
> this?  It's not normally required unless you have some encrypted
> partitions/disks.
I also wonder if something went sideways with your build env and causes
this, like some odd .config thing. Might be worth building a newer
kernel once more that was known to work at least mostly in the past and
check if that still works.

Ciao, Thorsten