when watching the dbus with the monitor and clicked "Configure Devices ..." the monitor shows dbus requests org.trinitydesktop.hardwarecontrol.InputEvents.GetProvidedSwitches
stop tdehwdevicetray (or restart) to stop the messages
Screenshots
<!--
This is a comment.
Please fill in the required fields below.
The comments provide instructions on how to do so.
Note: You do not need to remove comments.
-->
## Basic information
- TDE version: R14.1
- Distribution: Debian Buster
- Hardware: amd64
<!--
Use SL/* labels to set the severity level.
Please do not set a milestone.
-->
## Description
when watching the dbus with the monitor and clicked "Configure Devices ..." the monitor shows dbus requests org.trinitydesktop.hardwarecontrol.InputEvents.GetProvidedSwitches
```
method call time=1612556697.165586 sender=:1.1352 -> destination=org.trinitydesktop.hardwarecontrol serial=351 path=/org/trinitydesktop/hardwarecontrol; interface=org.trinitydesktop.hardwarecontrol.InputEvents; member=GetProvidedSwitches
string "/dev/input/event3"
method return time=1612556697.174122 sender=:1.38 -> destination=:1.1352 serial=3509 reply_serial=351
array [
uint32 0
]
method call time=1612556697.174594 sender=:1.1352 -> destination=org.trinitydesktop.hardwarecontrol serial=352 path=/org/trinitydesktop/hardwarecontrol; interface=org.trinitydesktop.hardwarecontrol.InputEvents; member=GetProvidedSwitches
string "/dev/input/event4"
method return time=1612556697.182150 sender=:1.38 -> destination=:1.1352 serial=3510 reply_serial=352
array [
uint32 0
]
```
## Steps to reproduce
1. start dbus-monitor --system as root
2. right click on tdehwdevicetray
3. click "Configure Devices ..."
4. above dbus message loop forever
5. stop tdehwdevicetray (or restart) to stop the messages
## Screenshots
<!-- If it seems useful, please provide provide one or more screenshots. -->
The problem here is that when an application requests updated data from tdehwlib – such as TCC when displaying hardware information, tdepowersave to monitor battery status, processors, LID switch – it activates regular checking of all this data. And because the input switches cannot be read directly, but it is necessary to use dbus communication, this leads to regular dbus communication to determine the status of the switches. This is also related to TDE/tde#44.
More changes to tdehwlib will be needed. For example, it would be useful here for regular checks to be activated only for specific data when a subscriber connects and to be stopped when disconnected. Another improvement could be that to monitor the status of input switches, there would be no regular check in tdehwlib, but internally in tde_dbus_hardwarecontrol, which would send a signal in case of a change.
At the same time, there is a plan for tdehwlib to serve as a separate TDE daemon instead of activating separate instances as well as separate timers in individual applications.
As you can see, some adjustments will be possible in the current implementation, some adjustments are like longer-term tasks.
The problem here is that when an application requests updated data from tdehwlib – such as TCC when displaying hardware information, tdepowersave to monitor battery status, processors, LID switch – it activates regular checking of all this data. And because the input switches cannot be read directly, but it is necessary to use dbus communication, this leads to regular dbus communication to determine the status of the switches. This is also related to TDE/tde#44.
More changes to tdehwlib will be needed. For example, it would be useful here for regular checks to be activated only for specific data when a subscriber connects and to be stopped when disconnected. Another improvement could be that to monitor the status of input switches, there would be no regular check in tdehwlib, but internally in `tde_dbus_hardwarecontrol`, which would send a signal in case of a change.
At the same time, there is a plan for tdehwlib to serve as a separate TDE daemon instead of activating separate instances as well as separate timers in individual applications.
As you can see, some adjustments will be possible in the current implementation, some adjustments are like longer-term tasks.
OK,
thank you for the explanation. I did not want to bring this "bigger picture" into the discussion yet, but related to the other topic we are discussin in the mail, it fits also my view of a service where all those sub-services can doc and work.
I can imagine someting like the bluetoothd service with ObjectManager and the discussed Properties in the hardwarecontrol this can be achieved.
I would keep this here to remind me of the discussion and if you can help me create a list where all these interfaces need their proxies, would be great.
or may be it is better to move to tdehwlib and list tdehwdevicetray among others
OK,
thank you for the explanation. I did not want to bring this "bigger picture" into the discussion yet, but related to the other topic we are discussin in the mail, it fits also my view of a service where all those sub-services can doc and work.
I can imagine someting like the bluetoothd service with ObjectManager and the discussed Properties in the hardwarecontrol this can be achieved.
I would keep this here to remind me of the discussion and if you can help me create a list where all these interfaces need their proxies, would be great.
or may be it is better to move to tdehwlib and list tdehwdevicetray among others
Basic information
Description
when watching the dbus with the monitor and clicked "Configure Devices ..." the monitor shows dbus requests org.trinitydesktop.hardwarecontrol.InputEvents.GetProvidedSwitches
Steps to reproduce
Screenshots
The problem here is that when an application requests updated data from tdehwlib – such as TCC when displaying hardware information, tdepowersave to monitor battery status, processors, LID switch – it activates regular checking of all this data. And because the input switches cannot be read directly, but it is necessary to use dbus communication, this leads to regular dbus communication to determine the status of the switches. This is also related to TDE/tde#44.
More changes to tdehwlib will be needed. For example, it would be useful here for regular checks to be activated only for specific data when a subscriber connects and to be stopped when disconnected. Another improvement could be that to monitor the status of input switches, there would be no regular check in tdehwlib, but internally in
tde_dbus_hardwarecontrol, which would send a signal in case of a change.At the same time, there is a plan for tdehwlib to serve as a separate TDE daemon instead of activating separate instances as well as separate timers in individual applications.
As you can see, some adjustments will be possible in the current implementation, some adjustments are like longer-term tasks.
OK,
thank you for the explanation. I did not want to bring this "bigger picture" into the discussion yet, but related to the other topic we are discussin in the mail, it fits also my view of a service where all those sub-services can doc and work.
I can imagine someting like the bluetoothd service with ObjectManager and the discussed Properties in the hardwarecontrol this can be achieved.
I would keep this here to remind me of the discussion and if you can help me create a list where all these interfaces need their proxies, would be great.
or may be it is better to move to tdehwlib and list tdehwdevicetray among others