Alessandro Ghersi:
Last year patches were integrated into the mainline kernel that sent additional hotkeys via the input layer (using the eeepc-laptop module) rather than as ACPI events for the EeePCs that were out of the time (you can see this in Bug #232170 and this was mentioned by Olivier). At that point, my EeePC 900's hotkeys for wireless toggling, brightness and volume all worked without additional scripts as the hotkey events were being sent a standardised way and GNOME was configured to respond to them out of the box. For "standard" hotkeys it is better for events to be sent directly via the input layer rather than as ACPI events (which may in turn need redirecting to input events or special dedicated scripts) as it gives a more consistent experience with less quirks.
There are some features that eeepc-acpi-scripts does (such as switching between the slow and fast modes (using SHE) depending on whether you are on battery or not) which will never be added out-of-the-box. An additional function of these scripts appears to be to work around bugs in a particular wireless driver when suspending. However, it might be by now that the original bugs in those drivers have been fixed in the kernel thus eliminating the need for the workarounds and just confusing matters on new setups.
Of course there may be new EeePC models whose hotkeys do not work out of the box. However, eeepc-acpi-scripts does not seem to provide support for hotkeys aside from wireless, brightness and volume so if keys aside from those are not working this package would not help (but if ACPI events were being sent it would help. However it sounds like laptop vendors are moving away from sending hotkeys as ACPI events and towards things like WMI).
I can see these scripts being invaluable if you are on an old kernel but many of the functions it provides are directly supported by the kernel in modern distros (since 2.6.28 I would guess). Further, this bug will continue to attract comments because if a new EeePC comes out whose hotkeys do not work a Google search will often turn up this bug report when really this bug is for the original range of EeePCs whose issues have been long fixed.
Alessandro Ghersi:
Last year patches were integrated into the mainline kernel that sent additional hotkeys via the input layer (using the eeepc-laptop module) rather than as ACPI events for the EeePCs that were out of the time (you can see this in Bug #232170 and this was mentioned by Olivier). At that point, my EeePC 900's hotkeys for wireless toggling, brightness and volume all worked without additional scripts as the hotkey events were being sent a standardised way and GNOME was configured to respond to them out of the box. For "standard" hotkeys it is better for events to be sent directly via the input layer rather than as ACPI events (which may in turn need redirecting to input events or special dedicated scripts) as it gives a more consistent experience with less quirks.
There are some features that eeepc-acpi-scripts does (such as switching between the slow and fast modes (using SHE) depending on whether you are on battery or not) which will never be added out-of-the-box. An additional function of these scripts appears to be to work around bugs in a particular wireless driver when suspending. However, it might be by now that the original bugs in those drivers have been fixed in the kernel thus eliminating the need for the workarounds and just confusing matters on new setups.
Of course there may be new EeePC models whose hotkeys do not work out of the box. However, eeepc-acpi-scripts does not seem to provide support for hotkeys aside from wireless, brightness and volume so if keys aside from those are not working this package would not help (but if ACPI events were being sent it would help. However it sounds like laptop vendors are moving away from sending hotkeys as ACPI events and towards things like WMI).
I can see these scripts being invaluable if you are on an old kernel but many of the functions it provides are directly supported by the kernel in modern distros (since 2.6.28 I would guess). Further, this bug will continue to attract comments because if a new EeePC comes out whose hotkeys do not work a Google search will often turn up this bug report when really this bug is for the original range of EeePCs whose issues have been long fixed.