There are a few very nice things in the works, and some that a few will
think are not that nice.
This is your chance to comment on them before I finish writing them and send
them to upstream. Use it wisely ;-)
First, the ones I don't expect to be a problem:
1. UWB rfkill control (done, needs testing, will be pushed out soon)
2. Fan control status retained over suspend/hibernation (tested, will be
pushed out very soon)
3. Preserve rfkill state of *some* radios across shutdown. This is valid
for bluetooth, and might just work for WWAN too. If you turn the thinkpad
off with the radio working, it will boot with the radio working. If you
turn the thinkpad off with the radio disabled, it will boot with the radio
disabled. (done, needs testing, will be pushed out soon)
Then the ones that are very nice, but are available only on fairly recent
ThinkPad BIOSes:
4. New HKEY notifications for overtemperature on the mainboard and battery!
Thanks to some official help, the driver will know when your thinkpad is
about to melt down or go out of juice, and will warn you accordingly through
syslog and an ACPI event (that HAL can trap and do something with).
5. New HKEY notifications for wakeup due to critical battery drain.
Again, thanks to that unnamed official help! I am still not sure what I can
do besides logging an alarm and issuing an ACPI event... and I really want
to do something, as it is doubtful there will be anyone around to listen to
the kernel cries if the machine woke up almost out-of-battery.
Before anyone asks, yes, initiating hibernate to S5 (*not* S4, so it
wouldn't work on boxes that need platform mode instead of shutdown mode)
would also work... if one could actually do that from the kernel side.
6. A small patch that helps with Intel GPU opregion support (needs the stuff
that is in the drm tree in linux-next).
Then the ones that some people might not like:
1. EC write access will be moved from "experimental" (which it isn't!) to a
new "dangerous" mode. And it will be documented (it isn't, right now). The
driver will bitch on the logs, and taint the kernel when you use this
facility for the first time, just to make sure nobody will go distributing
scripts that use this facility anymore (instead of asking for whatever
functionality he really needs to be added properly to the driver).
EC read access ("ecdump") will remain as-is (needs just "experimental"),
nobody ever reported it blowing up anything, and we have enough warnings
telling people to not use it on scripts, etc.
2. I will be restricting access to all LEDs but the ThinkLight, "power" and
"standby".
One will need to jump through some loops (probably including modifying the
kernel source code and enabling some Kconfig options) to unrescrict access
to the two battery, two bay and two dock leds (not every thinkpad has two
bay or two dock leds). So, if you *really* have a good reason to mess with
those LEDs that convey important information and are already handled by the
firmware, you will still be able to do it.
On the positive side, the driver will let one access extra LEDs on the new
thinkpads when in "LEDs unrestricted mode" (i.e. if you do the dance above).
This includes at least three new LEDs, of which two are the X60-style
red/green dock leds (that are, of course, going to be restricted).
I *guess* the the third new LED might be the LED on the thinkvantage key.
If I get any reports confirming this, I will add unrestricted access to it.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
ibm-acpi-devel mailing list
ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
