You are not logged in.
When I close my laptop lid and my laptop goes to sleep using pm-suspend from acpi, my xset options is reset. I have this line in .xinitrc:
xset r rate 200 100
This mean I have a really high repeat rate before closing the lid, and this becomes really slow and unfamilliar when opening it. This problem appeared recently, but I do not remember when and how.
I a script /etc/acpi/scripts/lid which look like this:
#!/bin/sh
if grep closed /proc/acpi/button/lid/LID/state >/dev/null ; then
pm-suspend
fi
It was some time ago that a friend of mine helped me write this file, and some other things somewhere else (I think), to make the laptop capable of going to sleep. So I do not really remember what we wrote where other than this script.
Does anyone have a clue how to solve this?
Offline
It's funny that you're getting that behavior, I'm not. But it's easy to work around. Just make a script in /etc/pm/sleep.d/NNxset, replacing NN with some numbers. The script should be executable, and should look like this:
#!/bin/sh
case "$1" in
thaw|resume)
xset ..add your arguments to restore xset here..
;;
esac
OK, I'm going to put that out there but as I compose this I realize this isn't going to work. What if X isn't running? --- Well, you could just do:
xset ..arguments.. 2>/dev/null || true
to fix that. You redirect stderr so that the error isn't logged by pm-utils. You do the "|| true" so that the script doesn't exit with an error code. I think that may abort processing of later scripts in the same directory.
But the real problem is: don't you have to run xset WITHIN your X session? And how do you achieve that from a pm-utils script. Huh, that's a stumper. I'm interested in any solutions people may come up with for that....even if this particular xset issue gets fixed in some other way.
EDIT: Different window managers may provide hooks for this, even if there's no good general solution. For instance, awesome has awesome-client, which enables you to pipe lua code to a running awesome session. That needs a bit of assistance if you're calling it from a system daemon (at least it used to, I'm not sure if the wrapper script I wrote is still necessary). And then the lua code you pipe to it would have to run a shell command "xset ..arguments.."---but then that shell command would be executed from inside the X session. Involves many layers, but it works.
Interesting question is whether there's a wm-independent way to do this.
Last edited by Profjim (2010-04-14 10:58:03)
Offline
#!/bin/sh case "$1" in thaw|resume) xset ..add your arguments to restore xset here.. ;; esac
...
But the real problem is: don't you have to run xset WITHIN your X session? And how do you achieve that from a pm-utils script. Huh, that's a stumper. I'm interested in any solutions people may come up with for that....even if this particular xset issue gets fixed in some other way.
It should be sufficient to set the DISPLAY environment variable prior to invoking xset in the script.
#!/bin/sh
DISPLAY=":0"
case "$1" in
thaw|resume)
xset ..add your arguments to restore xset here..
;;
esac
If there might be several X displays running, it should not be too difficult to extend this to accomodate them.
Offline
Oh ok. But you'd probably need to do
export DISPLAY=":0"
or:
DISPLAY=":0" xset ..add args here..
wouldn't you?
Offline
Oops - yes. You would need to export DISPLAY before calling xset.
Offline