Comment 18 for bug 357673

Actually, what is needed is proper OSD based on passive notifications _FOR_ OSD (and NOT a hideous hack based on keypress notifications like what exists right now for thinkpad brightness OSD).

Don't make a mistake of believing that there exists OSD support in the current scenario. There is none. It is just a jury-rig.

OSD support means events engineered to work as OSD notifications, without any side-effects on the rest of the system, nor on the input layer, etc. It means a layered approach, where you have OSD event sources (HAL, applications) and sinks (an applet that display the on-screen notifications). This is how the rest of the notification system (e.g. used to notify of new mail) already works, so it is not anything new.

HAL should monitor the kernel interfaces (sysfs backlight, ALSA mixers, etc) and issue OSD events through DBUS. Applets would not get terribly confused doing both active and passive work (which they, invariably, screw up): they would just do OSD (which is always passive in any sane design).

Stuff like gnome.*mixer would only generate DBUS OSD notification events, and the on-screen-display functionality would be in a separate component. This gives you a choice of which active producers of OSD events you want, and of which OSD applet you want to display the events. It is also very cross-desktop-environment-friendly.

I already offered to help kernel-side to fix and/or extend the kernel interfaces lacking event-based triggers, so that polling is not required, and the offer stands. But there is no need to wait for anything kernel-side, polling-based solutions can be deployed _now_.

I strongly suggest we start walking that path, after the short-term fixes are in.