You are not logged in.
Hello,
I started using XFCE with Kwin which is really nice, but after resume, there are sometimes artefacts or even bigger screen errors which force me to restart kwin with
kwin --replace.
(Probably because of my old Nvidia G210 card...)
As replacing kwin is really fast, i like to do this automatically on each resume.
According to https://wiki.archlinux.org/index.php/Po … vice_files , I tried that:
/etc/systemd/system/resume@.service containing
[Unit]
Description=User resume actions
After=suspend.target
[Service]
User=%I
Type=simple
Environment=DISPLAY=:0
ExecStart=/usr/bin/kwin --replace
[Install]
WantedBy=suspend.targetThis works (after enabling of course) after the FIRST resume, but not later. I understand why (as kwin is running and doesn't terminate, the service is still running and doesn't terminate, so at the next resume it isn't started again), but I don't know how to prevent this. I tried changing the type to "forking" or "oneshot", but that didn't work either.
Do you have an idea how I can get this running?
(And even better: Only running, when kwin is already running, so it isn't started in other sessions. I tried with ExecStartPre=/usr/bin/killall kwin, but that didn't work either...)
Thanks!
Last edited by Carl Karl (2014-08-06 05:39:27)
Offline
You could put "DISPLAY=:0 kwin --replace" in a sleep script. https://wiki.archlinux.org/index.php/Po … stem-sleep
Offline
I hesitated doing that because sleep-scripts are executed by root AFAIK. Wouldn't it be a problem if the window-manager is executed by root instead of the user?
Offline
Right. You should run "DISPLAY=:0 su youruser -c "kwin --replace"" instead.
Offline
Thanks, that works! :-D
Last step of fine tuning: In order not to mess up things if I run another session, I would like to only replace kwin when it was running before.
I tried that by entering a script in the sleep-script:
#!/bin/sh
case $1 in
post)
DISPLAY=:0 su carl -c "/path/to/script/replacekwinifrunning.sh"
;;
esacwith replacekwinifrunning.sh:
#!/bin/bash
if [ "$(pidof kwin)" ]
then
echo "process was found"
kwin --replace &
else
echo "process not found"
fithe script itself is working, but it being called by the sleep-script isn't. (Symptom: kwin isn't replaced after resume.)
Any idea for that?
Offline
Try moving "DISPLAY=:0" from before "su" to before "kwin --replace &".
Offline
Great, that works, BUT
1. After that, the network is down and won't get up again
2. kwin is crashing after some minutes (the sleep-script seems to be terminated after some time...)
3. the session is stuck, can't be suspended or rebooted anymore.
So OK, thanks for your help, now I think restarting kwin by a keyboard-hotkey when needed is more efficient than finding a solution for all that, that doesn't seem to end anywhere... ;-)
Offline
Take a look at systemd service types on the wiki. You might be able to take advantage of the one shot service type.
Last edited by runical (2014-08-05 18:11:29)
Offline
@runical:
I did, and as described in this thread, a solution for the initial problem was found, but it only caused more problems.
But maybe I should mark this as "solved" anyway...
Offline
I saw that there was a problem still, which is why I pointed to the service file types. The oneshot service type executes a command and quits the service after that, meaning that the service is no longer running once you resume. It should solve the "It works only once" problem. You might have to write a shell script that forks kwin (which you already did, it seems), but that shouldn't be too much trouble.
It's worth a shot in my opinion, but it is up to you ![]()
Offline
Carl said he had tried oneshot.
Offline
Oh, whoops. Seems my "I can't read for shit" was kicking in again. Sorry for the fuzz then.
EDIT: Indeed, I see it now. Just skimmed over it I guess... Sorry again.
Last edited by runical (2014-08-06 20:23:38)
Offline
Thanks for your efforts, I found something better:
kwin isn't causing that kind of problems, if I use the lts kernel. (See https://bugzilla.novell.com/show_bug.cgi?id=889660#c9 ) Maybe this information also helps someone who stumbles upon this thread by a related search...
Last edited by Carl Karl (2014-08-07 04:40:03)
Offline
Downgrading may be a suitable workaround for now, but it is not a solution.
Offline
@ANOKNUSA:
You're right, and the existence of that bug report shows, that someone is already caring about it. As I don't have a glue about kernel development, there is nothing at least I can do more I suppose.
Offline
My point was that you shouldn't declare a software problem "solved" if the "solution" is uninstalling the software. That's like saying you fixed a broken radio by throwing it in the trash and getting a different one. The thread should remain open until the issue is resolved.
Offline
@ANOKNUSA:
Oh, in this case, the term in [ ] would have to be complicated:
The initial problem was solved, but led to a bunch of other problems. (#4 - #7)
Afterwards, I found a workaround, and now, I even changed the nvidia card for an ati card I had left...
So the correct status would be something like:
[Solved, but led to other problems, found workaround, but o.p. doesn't care anymore, because he changed hardware]
Better? ;-)
Offline