notify-osd is infinitly called

Thank you for your bug report.

Can you attach a copy of the file at $HOME/.cache/notify-osd.log?

Thanks

Do you press and hold the VolumeUp/Down key or press it only once?

Pedro, regarding Ara's request... copy $HOME/.cache/notify-osd.log right after the bug hits. Preferably from a remote system you logged into to your Toshiba U300 if you can. This is needed since notify-osd.log is recreated each time notify-osd is started (e.g. when you log into your desktop-session ... rather upon the arrival of the first notification).

Steps:
1.) Log into you desktop-session on your Toshiba U300
2.) Log in remotely via ssh into your Toshiba U300 form another machine (using the same user-id you use locally for you desktop-session on your Toshiba U300)
3.) Trigger the bug within the desktop-session on your Toshiba U300
4.) From your remote session copy notify-osd.log to a save place, e.g. using: cp $HOME/.cache/notify-osd.log $HOME/Desktop/notify-osd.log
5.) Restart your Toshiba U300
6.) Attach the file $HOME/Desktop/notify-osd.log from your Toshiba U300 to this bug-report.

Marco,

More details:

(1) After mv notify-osd notify-osd__ I verified that the problem "almost no
keyboard" and "infinilty show a sound volume notification" is still alive
but this time showing and hidden a small notification window (white
background).

(2) File $HOME/.cache/notify-osd.log
doesn not contain information about this bug (only few "Autho Eth0"
messages).

(3) If I do "suspend" (keyboard allows me to do that) the problem seems to
disappear.

(4) The Toshiba U300 "sound volume button" is in fact a wheel we can circle
(with no mchanical begin/end).

(5) The slightest touch in this wheel causes the problem.

(6) Since notigy-osd was not working I tried "system monitor" to check what
program was consuming CPU but I didn't find any "alive". All of them were in
sleep mode.

(7) Using again notify-osd no usefull information is written to
.cache/notify-osd.log. But in that case a back backgroud notification
appears on the top right corner, blinking eternaly. Nothing was written to
the log file.

Where should I check more ?

Thank
Pedro

2009/5/15 Mirco Müller <email address hidden>

> Pedro, regarding Ara's request... copy $HOME/.cache/notify-osd.log right
> after the bug hits. Preferably from a remote system you logged into to
> your Toshiba U300 if you can. This is needed since notify-osd.log is
> recreated each time notify-osd is started (e.g. when you log into your
> desktop-session ... rather upon the arrival of the first notification).
>
> Steps:
> 1.) Log into you desktop-session on your Toshiba U300
> 2.) Log in remotely via ssh into your Toshiba U300 form another machine
> (using the same user-id you use locally for you desktop-session on your
> Toshiba U300)
> 3.) Trigger the bug within the desktop-session on your Toshiba U300
> 4.) From your remote session copy notify-osd.log to a save place, e.g.
> using: cp $HOME/.cache/notify-osd.log $HOME/Desktop/notify-osd.log
> 5.) Restart your Toshiba U300
> 6.) Attach the file $HOME/Desktop/notify-osd.log from your Toshiba U300 to
> this bug-report.
>
> --
> notify-osd is infinitly called
> https://bugs.launchpad.net/bugs/376554
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in “notify-osd” source package in Ubuntu: Incomplete
>
> Bug description:
> Binary package hint: notify-osd
>
> I have a Toshiba U300 with a volume sound button at left. If I touch it a
> notification appears at the top right corner. I think that notification is
> produced by "notify-osd".
>
> This event doesn't stop ! It consumes all CPU and keyboard is almost
> "dead".
>
> The notification window keeps going on and off constantly.
>
> I have removed the
>
> ProblemType: Bug
> Architecture: i386
> DistroRelease: Ubuntu 9.04
> ExecutablePath: /usr/bin/yelp
> Package: yelp 2.25.1-0ubuntu5
> ProcEnviron:
> PATH=(custom, user)
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> SourcePackage: yelp
> Uname: Linux 2.6.28-11-generic i686
>

More details:

(1) After mv notify-osd notify-osd__ I verified that the problem "almost no keyboard" and "infinilty show a sound volume notification" is still alive but this time showing and hidden a small notification window (white background).

(2) File $HOME/.cache/notify-osd.log
doesn not contain information about this bug (only few "Autho Eth0" messages).

(3) If I do "suspend" (keyboard allows me to do that) the problem seems to disappear.

(4) The Toshiba U300 "sound volume button" is in fact a wheel we can circle (with no mchanical begin/end).

(5) The slightest touch in this wheel causes the problem.

(6) Since notigy-osd was not working I tried "system monitor" to check what program was consuming CPU but I didn't find any "alive". All of them were in sleep mode.

(7) Using again notify-osd no usefull information is written to .cache/notify-osd.log. But in that case a back backgroud notification appears on the top right corner, blinking eternaly. Nothing was written to the log file.

Where should I check more ?

In my opinion you're suffering form the missing blur- and surface-caching in the currently shipping version of notify-osd. The continuous triggering of notify-osd via the volume-wheel of your laptop might very well be a hardware issue (according to bug #271706) of you laptop, but the spike in CPU-load is probably not. We're currently working on improved and optimized rendering performace of notify-osd.

@Muller: I doubt that is the problem since it persists when logging into a gnome-stracciatella session, where the usual notification-daemon is used in place of notify-osd. Other behavior, e.g. the cpu load you note, is also not typical of the cause you suggest. Something else appears to be the problem.

@molecule-eye , Mirco Müller

Please have a look at bug - which this is a duplicate of:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/271706

The behaviour we're seeing there with the U300 is a symptom of the volume dial being not in compliance with the PS/2 keyboard standard. Basically, after an odd number of twists, the wheel leaves the kernel input driver thinking that the "volume-down" or "volume up" is still active.

Particularily, this attachment confirms this (showkey log, which is based on /dev/console - which produces output form way before evdev even sees it):
http://launchpadlibrarian.net/27809229/mykeylog-U300.txt

This causes the kernel evdev input interface to message X endlessly that the button/state is "down" - forcing an endless volume repeat, logically started by the hardware (for incompliance with standards), which is then propagated by the kernel via evdex to X, which will finally make a repetition make it all the way to your application

I am currently working with an evdev developer for testing as well as the kernel keyboard input driver creator and maintainer to try to come up with a viable solution for systems with these incompliant hardwares that don't always return a "button release" code. (yes, granted the U300 has a wheel, but it still communicates with the PS/2 interface with the codes of a regular button ;D).

We'll be working on this via the above mentioned:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/271706

Please track the issue there.