ume-launcher stop working after a suspend

I can confirm this bug on the same device.

After a resume, can you still run glxgears?

Also, please do not change bug status/importance/assignees, as the netbook-remix-team will be doing the triaging, thanks.

Yes, I'm able to run glxgears after suspend.
If i kill ume-launcher and start it again everything works.

If it's possible to start it in a non-graphical shell I can write a simple script that kills it on suspend and restart it on resume.

Same bug confirmed on HTC Shift.

Type this into the terminal:

sudo ln /usr/bin/ume-launcher /etc/pm/sleep.d/ume-launcher

That's just a workaround though, not a solution. It simply restarts ume-launcher every time you resume.

Also, is anyone else getting errors about the kbd and aux modules when they resume? It shows up really quickly and looks like a POST screen right after hitting the power switch to wake up the eeepc. I'm trying to find a way to fix that so if anyone has gotten rid of it please tell me.

Thanks

I'm not sure if this is the same bug or a different one.
On the same device (Asus EeePC 701) after a suspend the focus of the cursor is about 5cm above where the cursor is. That is, when the cursor is near the bottom of the screen, the icon above it is selected and can be clicked.
As above, glxgears runs fine, and killing and then restarting ume-launcher, or logging out and logging in, fixes the issue.
The workaround above doesn't seem to make a difference.

I can confirm the behaviour reported by Steven H above. Not only is the focus somewhere above the mouse pointer after a suspend, but also after coming back from using the terminals on Ctrl-Alt-f1 etc.

I find that the patch here:
http://launchpadlibrarian.net/15187604/ume-launcher-800x480-fix-iconsize.patch

Fixes this problem, as well as making the icons nice and macroscopic.

Actually, it doesn't fix it every time, and I can't work out why.

During tests while trying to fix this, I've found that most of the time, the launcher will only freeze on the first suspend/resume cycle. If I:

* Switch off ume-launcher autostart
* Restart
* Suspend/resume
* Start launcher
* suspend/resume

It doesn't stop working properly.

And yes, the launcher doesn't crash, it's input area is about 400px vertically down from where it should be :-/

I've written a simple shell script that kills ume-launcher on suspend and starts it again on resume. Obviously this is just a workaround.

I've put some "sleep" commands inside this script because otherwise X will crash (I don't know why) on resume.

This script should be put in /etc/pm/sleep.d or /usr/lib/pm-utils/sleep.d

Regarding spiregrain's and Neil's comments, like suspends, only the first virtual console switch triggers the bug. The launcher will also work fine if you first switch to a virtual console, switch back, *then* start the launcher. Further virtual console switches don't affect it.

I Confirm this bug on my EeePC 900.

So I looked further into this:

* Any clutter app running on first-switch is affected.
* Clutter 0.8 is also affected (using tests/test-actors)
* Clutter-gtk 0.6 is also affected (i.e. hooking more closely into GTK+'s event structure didn't magically fix this)
* OpenGL in general does not seem affected (glchess worked OK)
* The 'internal clutter symptom' that leads to this behavior is in _clutter_do_pick(), where the code asks glReadPixels the same question it does pre-switch, but gets a different answer post-switch: It paints the stage white, and each actor paints its own sillouette. Pre-switch, things are reported as the right color. But post-switch, the top ~400 pixels report black and below that line, they report what should have been painted at the top.
* I'm not sure where the confusion that causes glReadPixels to screw up is. Are we painting sillouettes bad? Is the GL draw buffer corrupted?

It may be useful to mention that the restart scripts contributed above would not work correctly. That's because the launcher should not be launched outside of the gnome session environment.

The only problem with that script is that it disables the "Log Off" button. Ok, it's not the right solution but it makes the launcher works. I'm just saying that until this bug is fixed in clutter we have to live with it.

So the problem is starting the launcher inside the gnome session environment. We can write a simple program that register itself to the dbus hal event for "suspend" and then it stops the launcher and starts it again when the system resumes. That program can be started inside the gnome session environment. Is this the right approach?

Yes, the dbus approach sounds perfect to me. I think that the cold restart could cause more problems than Log-off not working. For example, a gnome program launched after the restart would not be able to communicate correctly with already running programs (for example the screensaver process, the bluetooth server, nautilus windows etc)

Notice that I am a netbook remix user with no knowledge of the Gnome internals, so this is just an opinion...

The only other time I've seen this is on a system with a very weak graphics card which was running out of texture memory, and therefore paging the memory and the performance went right down.

I'll try and add some environmental variables where we can tweak the launcher's memory use and see if it makes a difference.

Confirmed, on hardy on an eeepc 1000h... the focus on ume-launcher is a good 400px above the mouse after a suspend. I also have the messages mcastner mentioned appearing after a suspend... no big deal there though. Let's hope this bug gets fixed in clutter, it's really irritating right now.

If you upgrade to the latest launcher, please swap the earlier suspend/resume script for the new one I am attaching.

I've added some code in the latest launcher which monitors a directory in /tmp so it can be notified by the script when the computer is coming out of suspend.

At the moment the launcher uses this information to restart, but as it is restarting in te user's environment, the full functionality of the launcher is still there.

I understand that this isn't a proper fix, and we're still trying to figure out exactly what's going on in Clutter, but it's better than before :-).

Hi Neil J. Patel ,

I have tested your fix in EeePC 701 with Ubuntu Hardy. It is working. However , the script don't handle hibernate and thaw. I have modified a bit and added into my project of Ubuntu EeePC Configuration Package:

http://bazaar.launchpad.net/%7Ebenlau/ubuntu-eeepc-config/trunk/annotate/19?file_id=01umelauncher-20080730130252-miulfqdic241ml4i-4

Thanks Ben :-).

Some more info:

This bug happens due to an error in the drivers when calling glReadPixels(). The VT switch seems to fill the buffer with junk and therefore Clutter's picking mechanism does not work.

Something happens in the first suspend/resume cycle that seems to prevent the bug occurring again until the system is powered down.

I can confirm this bug in Acer Aspire One :(

Confirmed on Asus Eee 901.

Solution provided by Ben Lau works pretty well on my Aspire One.

The problem seems to have disappeared with the last upgrade in Hardy to version 0.5ubuntu7. At least to my test.

This problem has not disappeared for me. I still have to kill and restart ume-launcher when i resume from standby. I have the latest ume-launcher available from the repository installed.

Sorry, just found out what happened. ume-launcher is not working.

1) ume-launcher automatically launched from the session: hibernate/suspend shows the issue, all icons respond with an offset of 400 pixels.

2) ume-laucher launched from a shell: problem doesn't appear to me.

I was in a situation of 2) and assume that I had hibernated the laptop in 1).

Sorry for the confusion.

attached is the latest script that works around the issue, with suspend|hiberate and resume|thaw.
Please note, there is still an issue when switching to a virtual terminal, or switching users and logging back in as the same user. Anyone have ideas how to fix these cases?

leaving status as In Progress until we can fix the root problem

Since updating ume-launcher from the repository today, this problem appears to be fixed on my Eee 901. Currently installed version is 0.5ubuntu8.
I resumed from suspend and the mouse worked properly with the icons in ume-launcher with no 400 pixel offset.

Stephen, could you test again? I've been bitten by a false positive before:

1) Check that ume-launcher is launched from properties, not console.
2) Test with 2 suspend cycles.

Just to make sure. This reliably gives me the problem.

Thanks,
João Miguel Neves

the workaround is now implemented in a different (more general) way that does not require the 1-Launcher.sh script in /etc/pm/sleed.d anymore. Instead, ume-launcher listens for ConsoleKit.Session "ActiveChanged" dbus signal, which gets fired on suspend/resume and when switching to a virtual terminal, which the script workaround did not handle. You should be able to remove the script and use 0.5ubuntu8 (or greater) which has the dbus code in it. Please let us know if it's not working correctly.

I've added new code in the launcher which connects to the ConsoleKit daemon to be notified when the system resumes from suspend or, more generally, when the current session is made inactive. On the session becoming active again, the launcher restarts.

We're still waiting for a fix in the Intel drivers, but this is the most elegant way to do the workaround imo.

Testing is appreciated :-)

I've done a bunch of suspend/resume cycles now and the launcher has not failed yet :)

I have an Eee900 and have just installed the latest updates. I am now running ume-launcher 0.5ubuntu12 and have not received any problems after a several suspend and resume cycles.

The ume-launcher is behaving very well, sound recovers (although the volume control applet occasionally crashes) and I have not had any problems with wireless. I am still pinned on kernel linux-eeepc 2.6.24.19.21

also working for me on a msi wind (oem akoya mini). thanks neil!

marking 1.0.1 to implement the change to only restart the after the first resume, no each resume.

ume-launcher (0.6.8) hardy; urgency=low

  * ume-launcher stop working after a suspend (LP: #237761)
    - Final tweak to the suspend/resume handling code:
      - Only restart on suspend/resume once, as the bug on Intel drivers only
        happens on the first cycle.
      - When started with the --no-restart flag, don't init() D-Bus at all

 -- Neil J. Patel <email address hidden> Wed, 22 Oct 2008 17:51:33 +0100

Just to complete this report, when the launcher does restart, it maintains state, so you are presented at the category you last opened instead of the favourites.