https://bugzilla.novell.com/show_bug.cgi?id=302539#c7
--- Comment #7 from Danny Kukawka
Afaik though there are not a variety of suspend/resume buttons and things like pm-utils take care of hardware specific issues underneath.
No, that's not correct. There are also 2 different types of suspend buttons atm. There are the buttons which produce events via ACPI and also buttons which go trough the input layer. Both need be handled by the userspace. And it's also not handled by pm-utils but by g-p-m/powersave/kpowersave. It's the same as for brightness button events. In this case it's also the job of e.g. g-p-m to react on the button events to change the brightness. It's not the job of HAL (for g-p-m it mean also: call GetBrightness() if needed, but don't poll it).
The button is already abstracted in hal as you mention with /org/freedesktop/Hal/devices/ipw_wlan_switch so why would a user space daemon either poll it or wait for a signal change?
This interface is not the abstraction of the button itself. It's a abstraction of the rfkill status. This is something different. While e.g. the button/switch can disable the hardware (and there is no way to enable it again trough sysfs/software if this is a real switch) the rfkill can be also set by software via sysfs to enable/disable the wireless. It's not the job of HAL to monitor and react on such events. NM is the perfect place to handle these events. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.