Created attachment 32457 [details]
grep . /sys/devices/virtual/dmi/id/*
As requested in bug 20963 #c89, I am opening a new bug.
Using KMS my backlight keys stopped working. Disabling KMS via "nomodeset" kernel parameter makes them working again.
My /sys/class/backlight is empty
This is a Macbook4,1 with:
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)
Attaching the acpidump and the output of "grep . /sys/devices/virtual/dmi/id/*"
Created attachment 32458 [details]
This is a stock Ubuntu installation (karmic):
Linux spaetz-macbook 2.6.31-17-generic #54-Ubuntu SMP Thu Dec 10 17:01:44 UTC 2009 x86_64 GNU/Linux
xorg-video-intel driver: 2.9.0-1ubuntu2
Let me know if there is more I can do.
I guess ACPI backlight isn't supported on MacBook (you'd need to build in the ACPI video driver)? Not sure what the right backlight driver is for that platform. Any ideas Yakui?
(In reply to comment #3)
> I guess ACPI backlight isn't supported on MacBook (you'd need to build in the
> ACPI video driver)? Not sure what the right backlight driver is for that
> platform. Any ideas Yakui?
I look at the acpidump on this box and there is no _BCL/_BCM/_BQC object, which is required by ACPI video driver. As there is no generic ACPI backlight or platform backlight interface, we will have no way to create backlight property.
In fact Grep submitted a patch, which used the legacy control method to create the platform backlight interface. But we don't know why it is shipped by upstream kernel.
How about pushing the patch to upstream kernel?
This looks similar to:
I am also hitting this bug on my MacBook3,1 and OpenSUSE Factory. If any other information would be helpful just let me know.
Created attachment 33549 [details] [review]
Add DMI_MATCH information for early MacBook models
The attached patch adds backlight support for older MacBooks using intel graphics (list of models from wikipedia...). I believe a second patch would be required for xorg-video-intel to actually let X use the mbp_backlight, but backlight control does work (on my MacBook3,1) with echo 12 > /sys/class/backlight/mbp_backlight/brightness.
(Note: Only tested with MacBook3,1)
Created attachment 33550 [details] [review]
Add mbp_backlight support
The attached patch lets X use the mbp_backlight backlight class.
(Again, only tested on my Macbook3,1)
Would that patch be acceptable? It would be nice to be get my brightness keys back...
A cleaned up version of my kernel patch is now in Richard Purdie's linux-rpurdie-backlight branch:
So it should be pulled into Linus' tree soon.
Okay, my kernel patch is currently in 2.6.34-rc2, but my one line diff to xf86-video-intel is still required to get X to play with /sys/class/backlight/mbp_backlight.
Should I open a new bug? It would be nice to hear from one of the intel guys....
*** Bug 27484 has been marked as a duplicate of this bug. ***
The kernel patch needs a small fix for MacBook1,1.
When the MacBook1,1 came out Apple was still named Apple Computer.
I am not sure if this applies to older MacBook2,1 versions aswell.
I submitted the fix to Richard Purdie and LKML: http://lkml.org/lkml/2010/3/23/412
and http://email@example.com/msg09304.html the MacBook2,1 should report as Apple Inc. while the MacBook1,1 is as you reported.
I guess I made a faulty assumption thinking the system manufacturer wouldn't change :(
*** Bug 27885 has been marked as a duplicate of this bug. ***
I can confirm that with a recent mbp_nividia_bl and the xorg-driver-video-intel one-liner from comment #7, backlight works again on my MacBook 4,1 with KMS.
Julien Cristau pointed out that the one-liner had been overlooked for too long, and so I've pushed the patch upstream.
Is everything now in place for backlight to work on all MacBooks (and 4.1 in particular)?
(In reply to comment #16)
> Is everything now in place for backlight to work on all MacBooks (and 4.1 in
Support in the kernel module is upstream, and you just pushed the needed change for the x.org driver, so everything is in place (until all of this changes again ;)
(In reply to comment #17)
> Support in the kernel module is upstream, and you just pushed the needed change
> for the x.org driver, so everything is in place (until all of this changes
> again ;)
closing accordingly. thanks.