I tested your workaround on some machines from different vendors, which used to have this super+p issue. I confirm that it can fix the problem.
The comment above is contrary to Daniel's comment in #55. James may be right that whichever starts later gets to grab the event.
I am not sure if there is any side effect to start gnome-settings-daemon in the "Application" phase, which seems to be a bit late. Since we only want to start g-s-d after compiz, which is started in "WindowManager" phase. timchen119 suggested to start it in the "Panel" phase, which is the next phase after "WindowManager" phase. So I also tested machines with that line changed to:
Thank you, James!
I tested your workaround on some machines from different vendors, which used to have this super+p issue. I confirm that it can fix the problem.
The comment above is contrary to Daniel's comment in #55. James may be right that whichever starts later gets to grab the event.
I am not sure if there is any side effect to start gnome-settings- daemon in the "Application" phase, which seems to be a bit late. Since we only want to start g-s-d after compiz, which is started in "WindowManager" phase. timchen119 suggested to start it in the "Panel" phase, which is the next phase after "WindowManager" phase. So I also tested machines with that line changed to:
X-GNOME- Autostart- Phase=Panel
So far everything works fine.
--- /live.gnome. org/SessionMana gement/ GnomeSession
For a list of GNOME session phase:
https:/