Hello,
I just added UPower support into ksmserver. This meaning that Suspend/Hibernate will be available even if HAL is not present.
To enable it, pass -DWITH_UPOWER to cmake. If HAL support is activated too, UPOWER will be preffered.
On Wednesday 15 February 2012 04:47:16 Serghei Amelian wrote:
I just added UPower support into ksmserver. This meaning that Suspend/Hibernate will be available even if HAL is not present.
To enable it, pass -DWITH_UPOWER to cmake. If HAL support is activated too, UPOWER will be preffered.
Great. I wonder if it portable to kde.
On Wednesday 15 February 2012 02:03:30 Ilya Chernykh wrote:
On Wednesday 15 February 2012 04:47:16 Serghei Amelian wrote:
I just added UPower support into ksmserver. This meaning that Suspend/Hibernate will be available even if HAL is not present.
To enable it, pass -DWITH_UPOWER to cmake. If HAL support is activated too, UPOWER will be preffered.
Great. I wonder if it portable to kde.
I think is it. You need just to replace dbus-1-tqt classes to dbus-qt3. Check http://people.freedesktop.org/~krake/dbus-1-qt3/api-docs/
On Wed, Feb 15, 2012 at 1:47 AM, Serghei Amelian serghei@thel.ro wrote:
Hello,
I just added UPower support into ksmserver. This meaning that Suspend/Hibernate will be available even if HAL is not present.
To enable it, pass -DWITH_UPOWER to cmake. If HAL support is activated too, UPOWER will be preffered.
-- Serghei.
Great news! What other elements of trinity rely on hal?
On Wednesday 15 February 2012 02:53:44 Pawel Soltys wrote:
On Wed, Feb 15, 2012 at 1:47 AM, Serghei Amelian serghei@thel.ro wrote:
Hello,
I just added UPower support into ksmserver. This meaning that Suspend/Hibernate will be available even if HAL is not present.
To enable it, pass -DWITH_UPOWER to cmake. If HAL support is activated too, UPOWER will be preffered.
-- Serghei.
Great news! What other elements of trinity rely on hal?
Media manager, I think.
On Tuesday 14 February 2012 07:47:16 pm Serghei Amelian wrote:
Hello,
I just added UPower support into ksmserver. This meaning that Suspend/Hibernate will be available even if HAL is not present.
To enable it, pass -DWITH_UPOWER to cmake. If HAL support is activated too, UPOWER will be preffered.
Will this build with 3.5.13?
I think you did udev for 3.5.13 awhile back, right? (it was either udev or udisks)
If possible, I want to do my packages without HAL altogether :-)
On Wednesday 15 February 2012 04:13:15 Kristopher John Gamrat wrote:
On Tuesday 14 February 2012 07:47:16 pm Serghei Amelian wrote:
Hello,
I just added UPower support into ksmserver. This meaning that Suspend/Hibernate will be available even if HAL is not present.
To enable it, pass -DWITH_UPOWER to cmake. If HAL support is activated too, UPOWER will be preffered.
Will this build with 3.5.13?
I think you did udev for 3.5.13 awhile back, right? (it was either udev or udisks)
If possible, I want to do my packages without HAL altogether :-)
Sure, can be backported.
On Feb 15, 2012 3:24 AM, "Serghei Amelian" serghei@thel.ro wrote:
On Wednesday 15 February 2012 04:13:15 Kristopher John Gamrat wrote:
Will this build with 3.5.13?
I think you did udev for 3.5.13 awhile back, right? (it was either udev
or
udisks)
If possible, I want to do my packages without HAL altogether :-)
Sure, can be backported.
When I eventually get to doing it,I'll have to poll you for assistance, I'm still stuck in "stupid newbie" state on my programming skills ;-) (nothing like being forced to do something to kick start my learning lol)
-- Kris
On Wednesday 15 February 2012 21:28:29 Kristopher Gamrat wrote:
[...]
Sure, can be backported.
When I eventually get to doing it,I'll have to poll you for assistance, I'm still stuck in "stupid newbie" state on my programming skills ;-) (nothing like being forced to do something to kick start my learning lol)
No problem, changes are actually pretty simple.
-- Kris
On 15 February 2012 14:34, Serghei Amelian serghei@thel.ro wrote:
On Wednesday 15 February 2012 21:28:29 Kristopher Gamrat wrote:
[...]
Sure, can be backported.
When I eventually get to doing it,I'll have to poll you for assistance, I'm still stuck in "stupid newbie" state on my programming skills ;-) (nothing like being forced to do something to kick start my learning lol)
No problem, changes are actually pretty simple.
-- Kris
-- Serghei.
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
can we get a link to the sources? I'd like to incorporate it into my work on the shutdown dialog.
Calvin
On Thursday 16 February 2012 16:29:09 Calvin Morrison wrote:
[...]
can we get a link to the sources? I'd like to incorporate it into my work on the shutdown dialog.
http://git.trinitydesktop.org/cgit/tdebase/tree/ksmserver/shutdowndlg.cpp
On Thursday 16 February 2012 18:38:02 Serghei Amelian wrote:
can we get a link to the sources? I'd like to incorporate it into my work on the shutdown dialog.
http://git.trinitydesktop.org/cgit/tdebase/tree/ksmserver/shutdowndlg.cpp
Is there a link to patch somewhere?
On Thursday 16 February 2012 18:01:37 you wrote:
On Thursday 16 February 2012 18:38:02 Serghei Amelian wrote:
can we get a link to the sources? I'd like to incorporate it into my work on the shutdown dialog.
http://git.trinitydesktop.org/cgit/tdebase/tree/ksmserver/shutdowndlg.cpp
Is there a link to patch somewhere?
Oh I see it now
On 16 February 2012 09:02, Ilya Chernykh anixxsus@gmail.com wrote:
On Thursday 16 February 2012 18:01:37 you wrote:
On Thursday 16 February 2012 18:38:02 Serghei Amelian wrote:
can we get a link to the sources? I'd like to incorporate it into my work on the shutdown dialog.
http://git.trinitydesktop.org/cgit/tdebase/tree/ksmserver/shutdowndlg.cpp
Is there a link to patch somewhere?
Oh I see it now
Serghei,
Should we instead create functions to check if we can shutdown, hibernate, sleep etc, and also functions to execute those commands via ksmserver? That way one could easily call ksmserver via dcop to do one of those actions.
Also it would allow us to separate the shutdowndialog and the actual shutdown code. This would be good for my work for kicker regarding the logout menu option I proposed yesterday. That way I can easily integrate it with DCOP instead of basically all the upower/hal code.
What do you think?
On Thursday 16 February 2012 17:10:27 Calvin Morrison wrote: [...]
Serghei,
Should we instead create functions to check if we can shutdown, hibernate, sleep etc, and also functions to execute those commands via ksmserver? That way one could easily call ksmserver via dcop to do one of those actions.
Also it would allow us to separate the shutdowndialog and the actual shutdown code. This would be good for my work for kicker regarding the logout menu option I proposed yesterday. That way I can easily integrate it with DCOP instead of basically all the upower/hal code.
What do you think?
I think is possible, I didn't programmed with DCOP yet.
On 16 February 2012 10:19, Serghei Amelian serghei@thel.ro wrote:
On Thursday 16 February 2012 17:10:27 Calvin Morrison wrote: [...]
Serghei,
Should we instead create functions to check if we can shutdown, hibernate, sleep etc, and also functions to execute those commands via ksmserver? That way one could easily call ksmserver via dcop to do one of those actions.
Also it would allow us to separate the shutdowndialog and the actual shutdown code. This would be good for my work for kicker regarding the logout menu option I proposed yesterday. That way I can easily integrate it with DCOP instead of basically all the upower/hal code.
What do you think?
I think is possible, I didn't programmed with DCOP yet.
-- Serghei.
I think this is a preferable way.
On Thursday 16 February 2012 16:01:37 Ilya Chernykh wrote:
On Thursday 16 February 2012 18:38:02 Serghei Amelian wrote:
can we get a link to the sources? I'd like to incorporate it into my work on the shutdown dialog.
http://git.trinitydesktop.org/cgit/tdebase/tree/ksmserver/shutdowndlg.cpp
Is there a link to patch somewhere?
I think the patch is a mess, because qtcreator made automatically some cleanup in source file. Howewer, upower code is embraced between "#ifdef WITH_UPOWER" directives.
On Thursday 16 February 2012 19:16:05 Serghei Amelian wrote:
can we get a link to the sources? I'd like to incorporate it into my work on the shutdown dialog.
http://git.trinitydesktop.org/cgit/tdebase/tree/ksmserver/shutdowndlg.cpp
Is there a link to patch somewhere?
I think the patch is a mess, because qtcreator made automatically some cleanup in source file. Howewer, upower code is embraced between "#ifdef WITH_UPOWER" directives.
Indeed. I removed manually the hunks that only dealt with formatting, but still a lot of the patch is adding spaces.
On Thursday 16 February 2012 19:16:05 Serghei Amelian wrote:
can we get a link to the sources? I'd like to incorporate it into my work on the shutdown dialog.
http://git.trinitydesktop.org/cgit/tdebase/tree/ksmserver/shutdowndlg.cpp
Is there a link to patch somewhere?
I think the patch is a mess, because qtcreator made automatically some cleanup in source file. Howewer, upower code is embraced between "#ifdef WITH_UPOWER" directives.
lol, the patch cannot be applied here. My /ksmserver/shutdowndlg.cpp has only 287 lines, while your patch changes the lines with numbers 700-1000.
On Thursday 16 February 2012 17:18:49 Ilya Chernykh wrote:
On Thursday 16 February 2012 19:16:05 Serghei Amelian wrote:
can we get a link to the sources? I'd like to incorporate it into my work on the shutdown dialog.
http://git.trinitydesktop.org/cgit/tdebase/tree/ksmserver/shutdowndlg .cpp
Is there a link to patch somewhere?
I think the patch is a mess, because qtcreator made automatically some cleanup in source file. Howewer, upower code is embraced between "#ifdef WITH_UPOWER" directives.
lol, the patch cannot be applied here. My /ksmserver/shutdowndlg.cpp has only 287 lines, while your patch changes the lines with numbers 700-1000.
Don't waste your time with the patch, just copy/paste the code :)
On Thursday 16 February 2012 19:16:05 Serghei Amelian wrote:
can we get a link to the sources? I'd like to incorporate it into my work on the shutdown dialog.
http://git.trinitydesktop.org/cgit/tdebase/tree/ksmserver/shutdowndlg.cpp
Is there a link to patch somewhere?
I think the patch is a mess, because qtcreator made automatically some cleanup in source file. Howewer, upower code is embraced between "#ifdef WITH_UPOWER" directives.
Also I wonder whether the patch affects all KDE places where one can shutdown the computer or only the shutdown dialog. I.e. whether it would work for hibernating from a menu such as kickoff.
On 16 February 2012 10:23, Ilya Chernykh anixxsus@gmail.com wrote:
On Thursday 16 February 2012 19:16:05 Serghei Amelian wrote:
can we get a link to the sources? I'd like to incorporate it into my work on the shutdown dialog.
http://git.trinitydesktop.org/cgit/tdebase/tree/ksmserver/shutdowndlg.cpp
Is there a link to patch somewhere?
I think the patch is a mess, because qtcreator made automatically some cleanup in source file. Howewer, upower code is embraced between "#ifdef WITH_UPOWER" directives.
Also I wonder whether the patch affects all KDE places where one can shutdown the computer or only the shutdown dialog. I.e. whether it would work for hibernating from a menu such as kickoff.
Ilya, no I don't think so - if you look it calls hal directly. I am sure similar calls could be made.
Relevant files to kickoff: kdebase/kicker/ui/k_new_menu.cpp
#ifdef KDELIBS_SUSE int supported = -1; bool suspend_ram, suspend_disk, standby;
liblazy_hal_get_property_bool(HAL_UDI_COMPUTER, "power_management.can_suspend", &supported); if (supported == 1) suspend_ram = true; else suspend_ram = false; liblazy_hal_get_property_bool(HAL_UDI_COMPUTER, "power_management.can_standby", &supported); if (supported == 1) standby = true; else standby = false; liblazy_hal_get_property_bool(HAL_UDI_COMPUTER, "power_management.can_hibernate", &supported); if (supported == 1) suspend_disk = true; else suspend_disk = false;
it's acessing it directly.
On 16 February 2012 10:23, Ilya Chernykh anixxsus@gmail.com wrote:
On Thursday 16 February 2012 19:16:05 Serghei Amelian wrote:
can we get a link to the sources? I'd like to incorporate it into my work on the shutdown dialog.
http://git.trinitydesktop.org/cgit/tdebase/tree/ksmserver/shutdowndlg.cpp
Is there a link to patch somewhere?
I think the patch is a mess, because qtcreator made automatically some cleanup in source file. Howewer, upower code is embraced between "#ifdef WITH_UPOWER" directives.
Also I wonder whether the patch affects all KDE places where one can shutdown the computer or only the shutdown dialog. I.e. whether it would work for hibernating from a menu such as kickoff.
Which is also why I said we should have a DCOP interface to do this. that way Kickoff/Kicker could directly call it without having to interface with HAL/Udev
On Thursday 16 February 2012 17:23:05 Ilya Chernykh wrote:
On Thursday 16 February 2012 19:16:05 Serghei Amelian wrote:
can we get a link to the sources? I'd like to incorporate it into my work on the shutdown dialog.
http://git.trinitydesktop.org/cgit/tdebase/tree/ksmserver/shutdowndlg .cpp
Is there a link to patch somewhere?
I think the patch is a mess, because qtcreator made automatically some cleanup in source file. Howewer, upower code is embraced between "#ifdef WITH_UPOWER" directives.
Also I wonder whether the patch affects all KDE places where one can shutdown the computer or only the shutdown dialog. I.e. whether it would work for hibernating from a menu such as kickoff.
Right now is implemented only on ksmserver. Calvin propose to make a dcop interface to it, and in this case will be accesibile everywhere.
On Thursday 16 February 2012 20:27:19 Serghei Amelian wrote:
I think the patch is a mess, because qtcreator made automatically some cleanup in source file. Howewer, upower code is embraced between "#ifdef WITH_UPOWER" directives.
Also I wonder whether the patch affects all KDE places where one can shutdown the computer or only the shutdown dialog. I.e. whether it would work for hibernating from a menu such as kickoff.
Right now is implemented only on ksmserver. Calvin propose to make a dcop interface to it, and in this case will be accesibile everywhere.
Currently kickoff detects well if kpowersave is running. I thought you patched kpowersave to work through upower instead of hal. Would not it be a better solution?
Previously it used its own daemon, then it was ported to hal, why not to port it to upower? Hybernate/suspend dialog circumventing kpowersave is not good I think.
Currently kickoff detects well if kpowersave is running. I thought you patched kpowersave to work through upower instead of hal.
Err what? I don't see kpowersave referenced anywhere in our kickoff branch. It actually detects from hal directly. I don't know where you got that idea.
Would not it be a better solution?
Nope, kpowersave does exactly what kickoff does, communicate via hal.
the best solution is to implement a interface for all programs to access via dcop, that way we can use hal or udev or whatever backend and not have to rewrite the system every time
Previously it used its own daemon, then it was ported to hal, why not to port it to upower?
previously what did? ksmserver?
Hybernate/suspend dialog circumventing kpowersave is not good I think.
Kpowersave works the same way, via hal.
Calvin
On Thursday 16 February 2012 20:48:28 Calvin Morrison wrote:
Currently kickoff detects well if kpowersave is running. I thought you patched kpowersave to work through upower instead of hal.
Err what? I don't see kpowersave referenced anywhere in our kickoff branch. It actually detects from hal directly. I don't know where you got that idea.
If kpowersave is not installed, the suspend/hybernate buttons are unavailable.
} else QToolTip::add( btnReboot, i18n( "<qt><h3>Restart Computer</h3><p>Log out of the current session and restart the computer</p></qt>" ) );
DCOPRef kpowersave( "kpowersave", "KPowersaveIface" ); DCOPReply reply = kpowersave.call( "allowed_sleepingStates" ); if( reply.isValid()) { QStringList supported = reply; suspend_ram = supported.contains( "suspendToRAM" ); suspend_disk = supported.contains( "suspendToDisk" ); standby = supported.contains( "standBy" ); } else { int supported = -1; liblazy_hal_get_property_bool(HAL_UDI_COMPUTER, "power_management.can_suspend", &supported); if (supported == 1)
===
void KSMShutdownDlg::slotSuspend() { int error = 0; DCOPRef kpowersave( "kpowersave", "KPowersaveIface" ); DCOPReply reply = kpowersave.call( "allowed_sleepingStates" ); if( reply.isValid()) { bool ok; // so that screen locking can take place extern Time qt_x_time; XUngrabKeyboard( qt_xdisplay(), qt_x_time ); XUngrabPointer( qt_xdisplay(), qt_x_time ); XSync( qt_xdisplay(), False ); if( suspend_disk ) ok = kpowersave.call( "do_suspendToDisk" ); else if( suspend_ram ) ok = kpowersave.call( "do_suspendToRAM" ); else ok = kpowersave.call( "do_standBy" ); error = ok ? 0 : 1; } else {
int wake = 0; DBusMessage *reply;
===
void KSMShutdownDlg::slotSuspend(int id) { int error = 0;
DCOPRef kpowersave( "kpowersave", "KPowersaveIface" ); DCOPReply reply = kpowersave.call( "allowed_sleepingStates" ); if( reply.isValid()) { bool ok; extern Time qt_x_time; XUngrabKeyboard( qt_xdisplay(), qt_x_time ); XUngrabPointer( qt_xdisplay(), qt_x_time ); XSync( qt_xdisplay(), False ); if( suspend_disk && id == 1 ) ok = kpowersave.call( "do_suspendToDisk" ); else if( suspend_ram && id == 2 ) ok = kpowersave.call( "do_suspendToRAM" ); else if( standby && id == 3 ) ok = kpowersave.call( "do_standBy" ); else return; error = ok ? 0 : 1; } else {
Would not it be a better solution?
Nope, kpowersave does exactly what kickoff does, communicate via hal.
kickoff and the shutdown dialog, and the k-munu and the kicker panel applet with the power buttons all call kpowersave to detect whether suspend and hybernate are available. kpowersave on the other hand either calls hal or its own daemon.
the best solution is to implement a interface for all programs to access via dcop, that way we can use hal or udev or whatever backend and not have to rewrite the system every time
They all ask kpowersave. Once somebody patches kpowersave, all kde components wioll know whether hybernate|suspend is available.
Previously it used its own daemon, then it was ported to hal, why not to port it to upower?
previously what did? ksmserver?
kpowersave
Hybernate/suspend dialog circumventing kpowersave is not good I think.
Kpowersave works the same way, via hal.
Not necessary.
On Thursday 16 February 2012 17:42:49 Ilya Chernykh wrote:
On Thursday 16 February 2012 20:27:19 Serghei Amelian wrote:
I think the patch is a mess, because qtcreator made automatically some cleanup in source file. Howewer, upower code is embraced between "#ifdef WITH_UPOWER" directives.
Also I wonder whether the patch affects all KDE places where one can shutdown the computer or only the shutdown dialog. I.e. whether it would work for hibernating from a menu such as kickoff.
Right now is implemented only on ksmserver. Calvin propose to make a dcop interface to it, and in this case will be accesibile everywhere.
Currently kickoff detects well if kpowersave is running. I thought you patched kpowersave to work through upower instead of hal. Would not it be a better solution?
Previously it used its own daemon, then it was ported to hal, why not to port it to upower? Hybernate/suspend dialog circumventing kpowersave is not good I think.
Actually I start to develop a replacement for kpowersave, but is not so simple to migrate everything from hal to upower. For example, upower do not offer any method to query/set CPU governors. We need to implement our own server as a wrapper over cpufreq (maybe named ucpufreq).
Now I consider to create something like ksmserver, which will handle all things related to power, and will expose a DCOP API to user applications.
On Thursday 16 February 2012 20:55:10 Serghei Amelian wrote:
Actually I start to develop a replacement for kpowersave, but is not so simple to migrate everything from hal to upower. For example, upower do not offer any method to query/set CPU governors. We need to implement our own server as a wrapper over cpufreq (maybe named ucpufreq).
Now I consider to create something like ksmserver, which will handle all things related to power, and will expose a DCOP API to user applications.
Then all the aaplications that currently call kpowersave should be rewritten.
On Thursday 16 February 2012 18:03:06 Ilya Chernykh wrote:
On Thursday 16 February 2012 20:55:10 Serghei Amelian wrote:
Actually I start to develop a replacement for kpowersave, but is not so simple to migrate everything from hal to upower. For example, upower do not offer any method to query/set CPU governors. We need to implement our own server as a wrapper over cpufreq (maybe named ucpufreq).
Now I consider to create something like ksmserver, which will handle all things related to power, and will expose a DCOP API to user applications.
Then all the aaplications that currently call kpowersave should be rewritten.
kpowersave is not part of kde, so I don't think that there are many apps wich use its dcop interface.
On Thursday 16 February 2012 20:55:10 Serghei Amelian wrote:
Now I consider to create something like ksmserver, which will handle all things related to power, and will expose a DCOP API to user applications.
Now kpowersave does the thing, i.e. the DCOP API.
On Thursday 16 February 2012 18:04:13 Ilya Chernykh wrote:
On Thursday 16 February 2012 20:55:10 Serghei Amelian wrote:
Now I consider to create something like ksmserver, which will handle all things related to power, and will expose a DCOP API to user applications.
Now kpowersave does the thing, i.e. the DCOP API.
Right. But kpowersave still using HAL. Also, kpowersave is an applet, if is not started, cannot be used. I think a service is much better.
On Thursday 16 February 2012 21:07:02 Serghei Amelian wrote:
Now I consider to create something like ksmserver, which will handle all things related to power, and will expose a DCOP API to user applications.
Now kpowersave does the thing, i.e. the DCOP API.
Right. But kpowersave still using HAL. Also, kpowersave is an applet, if is not started, cannot be used. I think a service is much better.
Anyway, the patch we are discussing now only affects one dialog, am I wrong? The users who use kickoff, for example, or kbfx or another menu replacement still will not be able to hybernate and/or suspend.
On Thursday 16 February 2012 18:30:47 Ilya Chernykh wrote:
On Thursday 16 February 2012 21:07:02 Serghei Amelian wrote:
Now I consider to create something like ksmserver, which will handle all things related to power, and will expose a DCOP API to user applications.
Now kpowersave does the thing, i.e. the DCOP API.
Right. But kpowersave still using HAL. Also, kpowersave is an applet, if is not started, cannot be used. I think a service is much better.
Anyway, the patch we are discussing now only affects one dialog, am I wrong? The users who use kickoff, for example, or kbfx or another menu replacement still will not be able to hybernate and/or suspend.
Yes, you right.
On 16 February 2012 12:07, Serghei Amelian serghei@thel.ro wrote:
On Thursday 16 February 2012 18:04:13 Ilya Chernykh wrote:
On Thursday 16 February 2012 20:55:10 Serghei Amelian wrote:
Now I consider to create something like ksmserver, which will handle all things related to power, and will expose a DCOP API to user applications.
Now kpowersave does the thing, i.e. the DCOP API.
Right. But kpowersave still using HAL. Also, kpowersave is an applet, if is not started, cannot be used. I think a service is much better.
-- Serghei.
kpowersave does have a interface already though look at it's public interface:
QCStringList interfaces() QCStringList functions() bool lockScreen() bool do_setScheme(TQString) bool do_setCPUFreqPolicy(TQString) bool do_suspendToDisk() bool do_suspendToRAM() bool do_standBy() bool do_brightnessDown(int percentageStep) bool do_brightnessUp(int percentageStep) void disableAutosuspend(bool) void showDetailedDialog() bool openConfigureDialog() bool currentSchemeManagesDPMS() int brightnessGet() TQString currentScheme() TQString currentCPUFreqPolicy() TQStringList allowed_sleepingStates() TQStringList listSchemes() TQStringList listCPUFreqPolicies()
basically we need all of that, in a daemon.
Right?
Calvin
On Thursday 16 February 2012 19:08:35 Calvin Morrison wrote: [...]
kpowersave does have a interface already though look at it's public interface:
QCStringList interfaces() QCStringList functions() bool lockScreen() bool do_setScheme(TQString) bool do_setCPUFreqPolicy(TQString) bool do_suspendToDisk() bool do_suspendToRAM() bool do_standBy() bool do_brightnessDown(int percentageStep) bool do_brightnessUp(int percentageStep) void disableAutosuspend(bool) void showDetailedDialog() bool openConfigureDialog() bool currentSchemeManagesDPMS() int brightnessGet() TQString currentScheme() TQString currentCPUFreqPolicy() TQStringList allowed_sleepingStates() TQStringList listSchemes() TQStringList listCPUFreqPolicies()
basically we need all of that, in a daemon.
A trinity service, yes. There is only one problem, because we haven't something like ucpufreq, accesibile via dbus, this service (or a part of it) will need to run as root.
Right?
Calvin
On Thursday 16 February 2012 21:11:49 Serghei Amelian wrote:
kpowersave does have a interface already though look at it's public interface:
QCStringList interfaces() QCStringList functions() bool lockScreen() bool do_setScheme(TQString) bool do_setCPUFreqPolicy(TQString) bool do_suspendToDisk() bool do_suspendToRAM() bool do_standBy() bool do_brightnessDown(int percentageStep) bool do_brightnessUp(int percentageStep) void disableAutosuspend(bool) void showDetailedDialog() bool openConfigureDialog() bool currentSchemeManagesDPMS() int brightnessGet() TQString currentScheme() TQString currentCPUFreqPolicy() TQStringList allowed_sleepingStates() TQStringList listSchemes() TQStringList listCPUFreqPolicies()
basically we need all of that, in a daemon.
A trinity service, yes. There is only one problem, because we haven't something like ucpufreq, accesibile via dbus, this service (or a part of it) will need to run as root.
I suggest to implement that interface in a way compatible with kpoersave (or easily converted from it).
On 16 February 2012 09:38, Serghei Amelian serghei@thel.ro wrote:
On Thursday 16 February 2012 16:29:09 Calvin Morrison wrote:
[...]
can we get a link to the sources? I'd like to incorporate it into my work on the shutdown dialog.
http://git.trinitydesktop.org/cgit/tdebase/tree/ksmserver/shutdowndlg.cpp
-- Serghei.
Thank you. I didn't notice the commit :-)
Calvin
-
Calvin Morrison -
Ilya Chernykh -
Kristopher Gamrat -
Kristopher John Gamrat
-
Pawel Soltys -
Serghei Amelian