Bumping to Major because I added the report to the R14 etherpad road map.

Created attachment 1485 [details]
'power.sh' from ACPID under CentOS 6

This is in fact a problem with the CentOS distribution itself, but it MAY happen on other too.

It looks like the ACPID daemon is receiving the "power button pressed" too, and when it happens, runs a script called "power.sh".

This script is doing some stuff to determine if any user is logged interactively on the computer AND he has any known powermanager running. If the test is negative, it shut downs the computer without asking.

Among the "known" power managers are gnome-power-manager, and kpowersave.
But the renamed "tdepowersave" is not in the list !!! That's why the computer shut downs immediatly when I press power button, even before TDE has a chance to suspend to ram or any other action...

I'm afraid this hardcoded "kpowersave" program name may be present in other distirbutions too.

Even when disabled the ACPID actions, so my computer does not shutdown :-) it looks like TDEPowerSave never receives any "Power Button Pressed" event. So when pressing the power button, nothing happens at all.

Darrel is right.

This problem is due to the system intercepting the power button ACPI event before it even reaches tdepowersave.  Debian and Ubuntu handle this by moving /etc/acpi/powerbtn.sh out of the /etc/acpi directory when tdepowersave is installed, other distributions likely use a different script but the fix should be the same.

For more details on the Debian version of this problem (which does not occur when the tdepowersave-trinity package is installed on Debian or Ubuntu), see http://anothersysadmin.wordpress.com/2007/07/10/disable-the-power-button-event-in-debian/

The best thing to do is to file bug reports upstream to get tdepowersave recognized as a valid power manager, OR to divert the offending ACPI event handler script out of the way entirely (Debian-style).

(En réponse au commentaire 4)
> Darrel is right.
> 
> This problem is due to the system intercepting the power button ACPI event
> before it even reaches tdepowersave.  Debian and Ubuntu handle this by moving
> /etc/acpi/powerbtn.sh out of the /etc/acpi directory when tdepowersave is
> installed, other distributions likely use a different script but the fix should
> be the same.
> 
> For more details on the Debian version of this problem (which does not occur
> when the tdepowersave-trinity package is installed on Debian or Ubuntu), see
> http://anothersysadmin.wordpress.com/2007/07/10/disable-the-power-button-event-in-debian/
> 
> The best thing to do is to file bug reports upstream to get tdepowersave
> recognized as a valid power manager, OR to divert the offending ACPI event
> handler script out of the way entirely (Debian-style).

I understand the problem, but for testing purpose, I've already moved out the acpid script out of the way, then tried again.
The result is now that NOTHING happens at all when pushing the power button. I've tried to add some debug/verbosity messages in tdepowersave code, and it looks like the application never receives the "power button pressed" signal, so I guess there is a problem in tdehwlib. Maybe it's a SYSFS file naming issue, as I already saw for the battery level issue (see bug 1514).

Sorry about not addressing your test in my reply above--I noticed your comment after I posted mine. :-)

Can you open the TDE Hardware Device Manager (TDEControl-->Peripherals-->Hardware Device Manager), expand the Platform Event category, then look for anything resembling either "ACPI Power Button" (if using the latest GIT) or "Generic Button Device"?  I need to know if TDE is even recognizing the ACPI power button as a valid event device, and this is the fastest way I know of to check.

Thanks!

OK, I think I see some of the problem.  Since HAL is no longer available, there is no way to detect ACPI button events as a normal user.  As my test machine runs with the root account (bad practice I know, but it saves some time during development!), I have read access to the various /dev/input/event* nodes, therefore the ACPI buttons (power, sleep, hibernate) work just fine with tdepowersave.

The proper workaround is probably to extend the TDE hardware DBUS daemon to broadcast ACPI button press events to any listening DBUS applications (e.g. any applications using the TDE hardware library).  Before I do this, comments are welcome as I may have overlooked an existing DBUS service that already does this!

I have also noticed that once tdepowersave suspends or hibernates, that it ignores all incoming ACPI button events afterwards.  This is probably related to the autosuspend-once problem detailed above.

The autosuspend-once problem should be fixed in GIT hash f956245 (tdepowersave).  I still need to work on the ACPI button event handling for normal users.

This should be fixed in GIT hash acd6cbd (tdepowersave).  You also need to update your tdebase installation to the latest GIT in order for the ACPI buttons to work when the lock screen is active.

Francois, is this problem resolved?

I did not try again under Centos6 because the affected computer now runs opensuse 12.3 :-)

On recent distributions such as opensuse 12.3, I've noticed that the power functions are handled by SYSTEMD itself, so we have again the problem that systemd catches the "power button press event" and triggers its own action, regardless of what TDEpowersave (tries to) do.

I explored some informations because on newer Ubuntu is also used systemd => the same problem as on OpenSUSE 12.3

I'll try to prepare something...

I explored information about solutions for systemd. I found that dbus function for the "Inhibit" returns dbus type UnixFD. And to check the session is used dbus type ObjectPath.

But tdepowersave currently uses dbus-tqt that does not have support for type ObjectPath. And if the code will be rewritten to use dbus-1-tqt, then this currently does not have support for type UnixFd.

It seems that there is a need for more work.

(In reply to comment #13)
> I explored information about solutions for systemd. I found that dbus function
> for the "Inhibit" returns dbus type UnixFD. And to check the session is used
> dbus type ObjectPath.
> 
> But tdepowersave currently uses dbus-tqt that does not have support for type
> ObjectPath. And if the code will be rewritten to use dbus-1-tqt, then this
> currently does not have support for type UnixFd.
> 
> It seems that there is a need for more work.

It looks like UnixFD is just an int or int equivalent (http://dbus.freedesktop.org/doc/dbus-python/api/dbus.types.UnixFd-class.html); this shouldn't be too hard to add to dbus-1-tqt.

How hard would it be to port tdepowersave to dbus-1-tqt?

(Odpověď na komentář #14)
> (In reply to comment #13)
> > I explored information about solutions for systemd. I found that dbus function
> > for the "Inhibit" returns dbus type UnixFD. And to check the session is used
> > dbus type ObjectPath.
> > 
> > But tdepowersave currently uses dbus-tqt that does not have support for type
> > ObjectPath. And if the code will be rewritten to use dbus-1-tqt, then this
> > currently does not have support for type UnixFd.
> > 
> > It seems that there is a need for more work.
> 
> It looks like UnixFD is just an int or int equivalent
> (http://dbus.freedesktop.org/doc/dbus-python/api/dbus.types.UnixFd-class.html);
> this shouldn't be too hard to add to dbus-1-tqt.
> 
> How hard would it be to port tdepowersave to dbus-1-tqt?

The problem seems to be a bit more complicated. Applications that want to use UnixFd would probably have to do a "dup" to each application manages its own file handle. That's why I currently working on solution with an object that will cover this behavior.

For inspiration I look into:
http://qt-project.org/doc/qt-5.0/qtdbus/qdbusunixfiledescriptor.html

I have it mostly ready. Currently I examining whether each instance of the object TQT_DBusUnixFd should use exclusive file handle, or whether to allow sharing, as uses in equivalent class in Qt4.x and 5.x.


The assessment of the complexity of porting tdepowersave to use dbus-1-tqt I did not examine for now. However, by eliminating the use for communication with HAL, I suppose it should not be too difficult.

Created attachment 1644 [details]
dbus-1-tqt : add support for data type UnixFD

After some time I saved time for completion support for UnixFD data type in dbus-1-tqt. Because it is a larger piece of code, please revise it before I'll push it into GIT.

So far no code that would use the newly added support for data type UnixFD => not yet tested functionality.

(In reply to comment #16)
> Created attachment 1644 [details]
> dbus-1-tqt : add support for data type UnixFD
> 
> After some time I saved time for completion support for UnixFD data type in
> dbus-1-tqt. Because it is a larger piece of code, please revise it before I'll
> push it into GIT.
> 
> So far no code that would use the newly added support for data type UnixFD =>
> not yet tested functionality.

Looks good to me!  Go ahead and commit, then if it needs patching for functionality later those patches can be committed separately.

Comment on attachment 1644 [details]
dbus-1-tqt : add support for data type UnixFD

Tim, thank you.

Pushed to GIT in hash 9a134f56.

I have been giving this some thought, and I suspect that the actual DBUS power manager registration calls should be handled through the TDE hardware library itself, e.g. through two new methods in the root system device class called registerPowerManager and unregisterPowerManager.  This would be fast to implement, as the TDE hardware library already uses dbus-1-tqt.

Is there a document anywhere that explains the DBUS calls required to override the default power button handlers?

I'm not sure if this is a good idea to add tdehw library or not.

What I was looking for, registration power manager depends on what the system uses. Registration, which kpowersave / tdepowersave done now is probably obsolete. One option on current systems is a simple operations in acpid => script that looking for power managers in running proceses. For this is on Debian and Ubuntu workaround that moves script out of way. Another thing is the registration for systemd (for example on Ubuntu 13.10) - that's what I want to work on. A further should power manager to see if the user is currently active on console (consolekit dbus signals) => in case for switching between users on one computer.

Besides, I noticed that tdepowersave not respond to close the laptop lid. I have not examined (for now) whether it is related to this bug report or is it a separate issue.

So what is the modern way of intercepting the power button events?

(In reply to comment #21)
> So what is the modern way of intercepting the power button events?

No one knows?

(Odpověď na komentář #21)
> So what is the modern way of intercepting the power button events?

So far, I investigate the problem.
Unfortunately, I had little time to devote to it.

It appears that systemd could be a uniform solution, wherein register the power manager. However, this is still on the way to distributions. On Debian Wheezy is still used acpi scripts that "ugly" looking for a well-known power manager. Unfortunately, this are on path other than solved in Diverts. Do I have to verify the role of ConsoleKit / PolicyKit.

I will do further work on this.

I'm out of my league trying to help with this, other than some final testing. That said:

>However, this is still on the way to distributions.
Uh-huh. I predict Slackware will be the last major distro to adopt systemd. Might be inevitable some day the way RH controls the upstream sources, but that day is a long way away. Thus I hope any solution adopted does not require systemd.

It seems that the problem has several parts:

1) Prevent the system in its standard action.
Here may encounter three situations:

1a) The system does not react to power events => this is the easiest case
No more need to be addressed.

1b) Is used acpid => this is the most complicated case.

ACPI script has hard-coded list of names of power-managers. According to this list distinguishes whether the power-manager is running and power will be ignored. See /usr/share/acpi-support/policy-funcs. For v3.5.13.x advantage was that kpowersave name is listed. But for the R14 would have to be modify policy-funcs script - to add tdepowersave to this list.

Modifying the script /usr/share/acpi-support/policy-funcs probably will have to be addressed specifically in packages of individual distributions. Incidentally, Debian/Ubuntu package deal with script /etc/acpi/powerbtn.sh, but this script is probably outdated => solution has no effect.

1c) Is used systemd => this probably will be the most elegant solution.

Systemd provides a dbus method Inhibit (org.freedesktop.login1.Inhibit). By this method could be tdepowersave registered as power-manager who will take over the processing of power events. For this purpose, was to dbus-1-tqt added support for dbus type UnixFD. Adding systemd support to tdepowersave I will prepare.

2) Catching events.

Currently tdepowersave responds to power-events as pressing the buttons => as keystrokes. However, closing the lid is not processed as keystroke and therefore tdepowersave not respond to this event => reaction configured at lid closing does not work.

3) Events handling.
It seems that the processing events as pushing buttons may not be sufficient.

I tested on Debian Wheezy = system with acpid. Script /usr/share/acpi-support/policy-funcs is modified to accept tdepowersave. For power button I set tdepowersave to opening logout dialog. During the session, the response is correct - acpi system identified the active power-manager, shutdown not occur, logout dialog is opened and on Cancel is possible to continue in work. However, when in logout dialog instead of Turn off I select End session, I was logged out, but then acpi on system started to respond to all previous presses of power button - a message that the system will go to shutdown appears several times. And the system is turned off. As if all acpi events remained only deferred.

Handling events on a system with systemd I could not test yet - support for systemd in tdepowersave is not ready at this time.

I would like to see the appropriate systemd registration methods added to the TDE hardware library, with tdepowersave calling those methods as I mentioned earlier.

Other than that, I say focus on systemd for now and worry about acpid later.

Created attachment 1910 [details]
Add SystemD support and cleanup old code

For a long time I had unfinished patch. In the last week I was intensely devoted to the completion the patch. And here is the result.

First, I performed the cleaning of unused methods, removed obsolete PolicyKit code and eliminate all code that uses dbus-tqt. Then I'm using dbus-1-tqt newly implemented code for handling session for ConsoleKit and also for SystemD. For SystemD is now also set 'Inhibit' to prevent systemic response to poweroff / sleep buttons. All dbus communication is now within dbusInterface.

Note: dbus-1-tqt must be version containing commit 89be8025. Otherwise, you may experience crashes or hangs TDEpowersave.

Please, test it.

Now it is a question whether it is useful to move part of systemd handling (only Inhibit?) into tdehw library?

Created attachment 1915 [details]
Add SystemD support and cleanup old code (1)

Added monitoring restart of D-Bus daemon. 
Fixed repeated registration systemd inhibit.

Comment on attachment 1915 [details]
Add SystemD support and cleanup old code (1)

Pushed to GIT in hash c68a1bac.

Support tdepowersave in acpi scripts need to be addressed at the distribution level. For Debian and Ubuntu added in GIT hash 06cd84e3 (tde-packaging).

Created attachment 1953 [details]
tdelibs : fix input events switches detection

Over the past weekend, I made ​​efforts to search the issue of not responding to the lid closing. After a long testing I found that the problem is simple - read the state of the switches on /dev/input/event* fails because the ordinary user does not have permission.

I have prepared a solution in the way that I added into tde_dbus_hardwarecontrol interface org.trinitydesktop.hardwarecontrol.InputEvents with methods GetProvidedSwitches and GetActiveSwitches. Into tdehw-lib I added using this interface. And tdepowesave then responds to close the lid!

Please your opinions on this solution. Please your opinion to the name of the interface - is InputEvents apposite?

Please test it before I push patch to the GIT.

Works for me on Mageia 4 (without the patch, closing the lid does nothing).

Comment on attachment 1953 [details]
tdelibs : fix input events switches detection

Pushed to GIT in hash a7e4c6b5.

I believe that this bug message we may now be considered solved.
If there will be other related problems, please reopen it.