This feature may affect several users.
I propose we had this bug to the v14.0.0 release list even though this is not strictly a FTBFS.
Francois, Tim, Slavek, what's your opinion?

(In reply to Michele Calgaro from comment #1)
> This feature may affect several users.
> I propose we had this bug to the v14.0.0 release list even though this is
> not strictly a FTBFS.
> Francois, Tim, Slavek, what's your opinion?

Yes, this should block R14 (as should all major regressions).  Worst case we can probably partially revert the commit to restore functionality.

When I saw the patch 3c9d481f for tdelibs, I was very clear that this will cause to return the problem with closing lid (I tested it two days to get it confirmed).

I have a very clear idea of ​​how to fix this problem in a "better way".

As stated in bug 1597 comment 29, the problem has its origin in the fact that the lid open / close is surveyed as the status of the switches on input event device. But the ordinary user does not have permission to read /dev/input/event*. Therefore, it was added to tde_dbus_hardwarecontrol interface org.trinitydesktop.hardwarecontrol.InputEvents with methods GetProvidedSwitches and GetActiveSwitches. But this solution worked only because it was constantly refreshed whole device tree in tdehw-lib. And this is the cause of bug 1992 => not good way.

In tdeeventdevice.cpp starting at line 127, you can see that TDEEventDevice is ready to monitor input events. But for tracking this events trying to use the /dev/input/event* - see tdehardwaredevices.cpp, line 3290. And this is not possible due to permissions.

My idea is to add into tde_dbus_hardwarecontrol ability to track events on the event input devices. For example, add method WatchActiveSwitches, which would activate a monitoring of specific device (using select) and the events on this device would emit dbus signal.

But I am afraid that my programming skills are not yet sufficient to implement this solution.

(In reply to Slávek Banko from comment #3)
> When I saw the patch 3c9d481f for tdelibs, I was very clear that this will
> cause to return the problem with closing lid (I tested it two days to get it
> confirmed).
> 
> I have a very clear idea of ​​how to fix this problem in a "better way".
> 
> As stated in bug 1597 comment 29, the problem has its origin in the fact
> that the lid open / close is surveyed as the status of the switches on input
> event device. But the ordinary user does not have permission to read
> /dev/input/event*. Therefore, it was added to tde_dbus_hardwarecontrol
> interface org.trinitydesktop.hardwarecontrol.InputEvents with methods
> GetProvidedSwitches and GetActiveSwitches. But this solution worked only
> because it was constantly refreshed whole device tree in tdehw-lib. And this
> is the cause of bug 1992 => not good way.
> 
> In tdeeventdevice.cpp starting at line 127, you can see that TDEEventDevice
> is ready to monitor input events. But for tracking this events trying to use
> the /dev/input/event* - see tdehardwaredevices.cpp, line 3290. And this is
> not possible due to permissions.
> 
> My idea is to add into tde_dbus_hardwarecontrol ability to track events on
> the event input devices. For example, add method WatchActiveSwitches, which
> would activate a monitoring of specific device (using select) and the events
> on this device would emit dbus signal.
> 
> But I am afraid that my programming skills are not yet sufficient to
> implement this solution.


OK, if I understand what you explain, we have again a problem of polling files to get hardware status changes (same kind of issue as battery polling).

When using systemd, maybe systemd can send notifications to tdepowersave (via dbus) to notify hardware changes ?

Also, I wonder what kind of magic was used by the HAL daemon to get hardware status, because I don't remember having these problems in 3.5.x .

Created attachment 2054 [details]
tdelibs - optimize reading switches on input event devices

I made several optimizations: 

1) load switches moved from tdehardwaredevices to tdeeventdevice.

This allows the load switches standalone - without depending on the renewal of the whole tree, and regardless of how the detection of switches and their activate state.


2) The load of switches is not performed during the creation / update device tree, but only when it is really needed.

Because reading of switches from each input event device is a two dbus call, this change represents a significant saving dbus calls.


3) to tdeeventdevice added a new signal - switchChanged.

This makes it possible to monitor only one device, independently of the entire tree. 


4) The above changes offer the possibility to add other ways of monitoring the input event devices. For example, adding methods and signals to tde_dbus_hardwarecontrol as described in the comment 3, monitoring signals from uPower or systemd...

As a simple / basic method is now used timer that is activated at the moment of connection to signal switchChanged. Period of timer is for now 2.5 seconds. 

On my test notebook, where is 8 input event devices, this represents a reduction of 16 permanent dbus dbus calls to 1 call during initialization (detection of provided switches) and 1 repeated dbus call (to detect active switches).

Created attachment 2055 [details]
tdepowersave - watch lidclose signal

One-line patch which simply by connecting the signal switchChanged on lidclose event device restores response to the closing of the lid.

(In reply to Francois Andriot from comment #4)
> OK, if I understand what you explain, we have again a problem of polling
> files to get hardware status changes (same kind of issue as battery polling).
> 
> When using systemd, maybe systemd can send notifications to tdepowersave
> (via dbus) to notify hardware changes ?
> 
> Also, I wonder what kind of magic was used by the HAL daemon to get hardware
> status, because I don't remember having these problems in 3.5.x .

HAL could benefit from the fact that it operates under the root, so can watch /dev/input/event* - like I intended solution with tde_dbus_hardwarecontrol.

Please test if the proposed solution with a timer is sufficient for now.

It looks like it works on my laptop.

Well, the solution works, comments are not, it seems, it's time to push patches.

Please go ahead Slavek.

Comment on attachment 2054 [details]
tdelibs - optimize reading switches on input event devices

With a little adjustment pushed to GIT in hash 2c730f70.

Comment on attachment 2055 [details]
tdepowersave - watch lidclose signal

Pushed to GIT in hash a3a78dc5.