Keyboard backlight driver for Oct 2005 PowerBooks
PATCH 1/1 Keyboard backlight driver for Oct 2005 PowerBooks
This driver provides an interface to the keyboard backlight on Oct 2005 PowerBooks, which have the backlight behind the PMU. This driver doesn't support the I²C variant used in earlier PowerBooks.
---
drivers/macintosh/Kconfig +8 -0
@@ -99,6 +99,14 @@ config ADB_PMU_LED_IDE This option makes the front LED default to the IDE trigger so that it blinks on IDE activity. +config ADB_PMU_ALS_LED + bool "Support for keyboard backlight" + depends on ADB_PMU + select NEW_LEDS + select LEDS_CLASS + help + Support for the keyboard backlight on Oct 2005 PowerBooks. + config PMAC_SMU bool "Support for SMU based PowerMacs" depends on PPC_PMAC64
drivers/macintosh/Makefile +1 -0
@@ -13,6 +13,7 @@ obj-$(CONFIG_ANSLCD) += ans-lcd.o obj-$(CONFIG_ADB_PMU) += via-pmu.o via-pmu-event.o obj-$(CONFIG_ADB_PMU_LED) += via-pmu-led.o +obj-$(CONFIG_ADB_PMU_ALS_LED) += via-pmu-als-led.o obj-$(CONFIG_PMAC_BACKLIGHT) += via-pmu-backlight.o obj-$(CONFIG_ADB_CUDA) += via-cuda.o obj-$(CONFIG_PMAC_APM_EMU) += apm_emu.o
drivers/macintosh/via-pmu-als-led.c +107 -0
107 lines not on this page · raw message
Quoted 5 lines · Michael Hanselmann
This driver provides an interface to the keyboard backlight on Oct 2005 PowerBooks, which have the backlight behind the PMU. This driver doesn't support the I²C variant used in earlier PowerBooks.
Signed-off-by Michael Hanselmann <[email protected]>
Why would we need a driver ? Userland can emit PMU commands directly... At least, if we do a driver, it should provide a common interface to both PMU and i2c based LMUs
Ben.
Quoted 1 line · Benjamin Herrenschmidt
Why would we need a driver ? Userland can emit PMU commands directly...
Drivers are there to abstract hardware. Userland shouldn't know about hardware specific commands (PMU commands in this case).
It would make it much simpler for programs to use these devices, because not each of them has to implement everything needed to locate the device and control it.
pbbuttonsd supports both the I²C and PMU variant. The code is a mess there and a generic driver would help to clean it up. And yes, I'm partly responsible for it, since I supplied the original patch for the PMU keyboard backlight support in pbbuttonsd.
Maybe controlling the keyboard backlight could be moved to its own program anyway, because the algorithm used by pbbuttonsd isn't appealing to all people. But those are just ideas.
Oh, and using the LED class allows users to attach it to some trigger. Maybe someone wants to use it as the IDE LED. :-)
Quoted 2 lines
At least, if we do a driver, it should provide a common interface to both PMU and i2c based LMUs
Yeah, I figured after sending it. You'll hear again from me once I got my hands on an I²C backlight. Something like the AMS driver would be nice.
Quoted 5 lines · Michael Hanselmann
Quoted 1 line · Benjamin Herrenschmidt
Why would we need a driver ? Userland can emit PMU commands directly...
Drivers are there to abstract hardware. Userland shouldn't know about hardware specific commands (PMU commands in this case).
This is a bit of a broad statement :) If I were to follow you, thinks like USB scanner or printer drivers should all be in the kernel :) Well... they happen not to be.
Only drivers providing services to the kernel itself (block, network, ...) or doing things like direct DMA, interrupts, etc... that aren't useable from an exposed userland interfaces need to be in the kernel.
Quoted 3 lines
It would make it much simpler for programs to use these devices, because not each of them has to implement everything needed to locate the device and control it.
Then the best is to do a library.
Quoted 8 lines
pbbuttonsd supports both the I²C and PMU variant. The code is a mess there and a generic driver would help to clean it up. And yes, I'm partly responsible for it, since I supplied the original patch for the PMU keyboard backlight support in pbbuttonsd.
Maybe controlling the keyboard backlight could be moved to its own program anyway, because the algorithm used by pbbuttonsd isn't appealing to all people. But those are just ideas.
Yeah, separate program or library would do the trick just fine. Also, your driver doesn't handle reading the light sensors, does it ?
Quoted 2 lines
Oh, and using the LED class allows users to attach it to some trigger. Maybe someone wants to use it as the IDE LED. :-)
That would be just insane :)
Quoted 6 lines
Quoted 2 lines
At least, if we do a driver, it should provide a common interface to both PMU and i2c based LMUs
Yeah, I figured after sending it. You'll hear again from me once I got my hands on an I²C backlight. Something like the AMS driver would be nice.
I still think this has little to do in the kernel ...
Ben.
Quoted 6 lines · Benjamin Herrenschmidt
Quoted 2 lines
Drivers are there to abstract hardware. Userland shouldn't know about hardware specific commands (PMU commands in this case).
This is a bit of a broad statement :) If I were to follow you, thinks like USB scanner or printer drivers should all be in the kernel :) Well... they happen not to be.
True. But then again, a printer driver does little more than configuring a single PWM value.
If there wasn't an I²C variant, we could even export these things as PMU sub-devices. But there is one and a driver could easily hide these differences from userland, because they simply don't matter there.
Quoted 1 line
Then the best is to do a library.
There was some effort ongoing on that a few months ago (at least on IRC). Was there anything coming out of it?
Quoted 2 lines
Yeah, separate program or library would do the trick just fine. Also, your driver doesn't handle reading the light sensors, does it ?
No, it doesn't. The light sensor is a different device and doesn't belong into a LED driver. I plan to do a driver for it separately.
So the target is to have one driver for backlight and one for sensors, each handling the I²C and PMU variants. MacBooks have some other variant, which could be included, theoretically. Lacking the hardware, I can't do that, tough.
The main reason I did not do all at once is that I feared a discussion like we have it now. I'm not going to invest much time for unused code anymore like I did with the ctrl+click patch.
Greets,
Michael