I have released version 0.16-20070904 of thinkpad-acpi through the sourceforge.net release system. Patches are available for 2.6.20, 2.6.21 and 2.6.22 at: http://sourceforge.net/project/showfiles.php?group_id=117042&package_id=230205 git users can get it directly from tags in: git://repo.or.cz/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git Work in the nvram polling stuff is ongoing, but it is still not in this release. This release contains code to bring thinkpad-acpi backports in sync with the features scheduled for 2.6.23. Since the changes are sort of hard to understand without extensive comments, I will reproduce the full git changelog below. More information is in the driver documentation. You should be able to just tack in this version of thinkpad-acpi, forget about input devices, and have it just work with HAL. However, better functionality through thinkpad-acpi's input devices will still require an updated HAL (which, AFAIK, doesn't exist yet). Enjoy! -- "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 Author: Henrique de Moraes Holschuh <hmh@xxxxxxxxxx> Date: Tue Sep 4 11:03:11 2007 -0300 ACPI: thinkpad-acpi: bump up version to 0.16 Name it thinkpad-acpi version 0.16 to avoid any confusion with some 0.15 thinkpad-acpi development snapshots and backports that had input layer support, but no hotkey_report_mode support. Author: Henrique de Moraes Holschuh <hmh@xxxxxxxxxx> Date: Sun Sep 2 00:28:52 2007 -0300 ACPI: thinkpad-acpi: hotkey_report_mode read-write support ACPI core can send events over netlink in 2.6.23 and later, and thinkpad-acpi will use a different strategy to keep backwards compatibility with older userspace, without the need for the Kconfig option CONFIG_THINKPAD_ACPI_INPUT_ENABLED. Hotkey events are always sent to the input devices, and never sent to the ACPI netlink event interface. A new module parameter is added: hotkey_report_mode, that selects whether events are sent to the (now) legacy ACPI procfs event socket: 0 default mode; 1 - issue hot key events over procfs; 2 - do not issue hot key events over procfs. The default mode is "issue hot key events" in 2.6.23 and later. It is "runtime selectable" in driver backports to kernels that lack the ACPI netlink even interface. The way hot keys are being reported is available through the sysfs attribute hotkey_report_mode. This sysfs attribute is read-only on 2.6.23, but it is read write on the backports to earlier kernels if no module parameter was used to set hotkey_report_mode. Hot key handling will be unconditionally enabled at driver load, along with the best possible mask. This follows the Windows behaviour. Users can modify hot key handling state it at runtime, or at load time by using the hotkey=disable module parameter. Userspace guidelines (using HAL as an example): Old HAL: It will just work, as long as the user doesn't set hotkey_report_mode=2. Old HAL will get the events (including hot key presses) from the ACPI procfs event interface, and it will ignore the input devices. New HAL (one that supports ACPI events over netlink): New HAL must be able to work through ACPI netlink + thinkpad-acpi (and ACPI core) input devices, because that's what the ACPI interface has been migrated to. It likely will need to still be able to work using procfs ACPI events when netlink is not available, to support 2.6.22 and earlier kernels. This is not particular to thinkpad-acpi. HAL should be able to work with procfs ACPI events + thinkpad-acpi input devices if it wants to support enhanced functionality for thinkpad-acpi in earlier kernels than 2.6.23, provided through thinkpad-acpi backports. HAL must be able to work in the way old HAL does, using only the ACPI procfs event interface, if it wants to be usable in 2.6.22 and earlier kernels. Again, this is not particular to thinkpad-acpi. When the ACPI netlink event interface is available, New HAL must use the ACPI netlink event interface + thinkpad-acpi input devices. In that case, don't bother with the stuff below. When ACPI netlink event reporting is **not** available: 1. If no hotkey_report_mode sysfs attribute is available from thinkpad-acpi: work as old HAL did (i.e. just get events through procfs, *ignore the thinkpad-acpi input devices, if any, for maximum compatibilty with older thinkpad-acpi backports*). This is compatible with previous thinkpad-acpi releases in mainline, and also with ibm-acpi. 2. If the hotkey_report_mode sysfs attribute is available from thinkpad-acpi, check if it is set to 2. If (and only if!) it is not 2, try to set it to 2 to avoid receiving duplicate events from the thinkpad-acpi input devices and ACPI procfs event interface. If no error is returned, HAL should work using the ACPI procfs event interface, and thinkpad-acpi input devices. If a write to hotkey_report_mode receives -EPERM or -EACCES, work as old HAL did (just procfs, no thinkpad-acpi input devices). Note that thinkpad-acpi with hotkey_report_mode set to 2 really doesn't care if netlink or procfs is used, and delivers exactly the same functionality over both... but since procfs ACPI interfaces are going away eventually, HAL really is to switch to netlink when it is available. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
