This bug is also reported for Ubuntu on Launchpad https://bugs.launchpad.net/ubuntu/+source/hal-info/+bug/415023

A lot of users are affected by this bug!

I have this problem on my MIS WIND U100, and have seen similar reports from many other WIND users.

On an MSI Wind with Ubuntu Linux, the screen keeps flickering for a couple of minutes. According to bug report415023 quoted above, this is due to what's described in this bug report. 
I don't know if this is a gnome bug or an ubuntu bug. Also, it's not a big deal, if you're prepared to wait 3 minutes before you can start using your laptop, unless you're an epileptic, in which case I do think it's a serious problem.

(In reply to comment #3)
> On an MSI Wind with Ubuntu Linux, the screen keeps flickering for a couple of
> minutes. According to bug report415023 quoted above, this is due to what's
> described in this bug report. 
> I don't know if this is a gnome bug or an ubuntu bug. Also, it's not a big
> deal, if you're prepared to wait 3 minutes before you can start using your
> laptop, unless you're an epileptic, in which case I do think it's a serious
> problem.

This bug has also appeared for people on Fedora and other projects. See also the Ubuntu bug thread wherein this is mentioned.

I would call this a serious problem as it is highly, highly irritating

The problem is so serious that most who are affected by this bug are switching to guidance-power-manager. Most of us would gladly help if we knew how. This is definitely a bug in gnome-power-manager as switching to guidance-power-manager does not exhibit the same behavior.

(In reply to comment #5)
> The problem is so serious that most who are affected by this bug are switching
> to guidance-power-manager. Most of us would gladly help if we knew how. This is
> definitely a bug in gnome-power-manager as switching to guidance-power-manager
> does not exhibit the same behavior.

Then guidance power manager must be using HAL, rather than X. If it's doing that, then it's going to be obsolete when the HAL brightness code is removed.

If you want this bug fixed, then it would be best to actually write patches, preferably that involve the Xorg developers (adding a property to a Xrandr device, which can be set in the ddx driver automatically) or just to extend the HAL DMI property as a bodge.

I've not got hardware to test his issue so it's very hard for me to write the functionality. Remember, open source is a participatory sport, not a spectator sport.

(In reply to comment #6)

> If you want this bug fixed, then it would be best to actually write patches,
>...
> Remember, open source is a participatory sport, not a spectator
> sport.

Yes, so true, but not all of us can write patches for gnome or xorg easily.

(In reply to comment #6)
> Then guidance power manager must be using HAL, rather than X. If it's doing
> that, then it's going to be obsolete when the HAL brightness code is removed.
> 
> If you want this bug fixed, then it would be best to actually write patches,
> preferably that involve the Xorg developers (adding a property to a Xrandr
> device, which can be set in the ddx driver automatically) or just to extend the
> HAL DMI property as a bodge.
> 
> I've not got hardware to test his issue so it's very hard for me to write the
> functionality. Remember, open source is a participatory sport, not a spectator
> sport.

Why not make it configurable whether to use the xrandr or hal backend, or provide a setting to disable g-p-m handling of brightness altogether? That should be fairly easy to implement and allow people to work around this and other issues until somebody finds it worthwhile to implement some indicator in Xorg (note that I am not going to do it as I have absolutely no time and don't use GNOME any more on my laptop). It would also sustainable when in three years someone decides to depreciate xrandr and implement its functionality in some other place breaking things all over again (remember the same problems with flickering displays a couple of years ago leading to this HAL functionality?).

Created attachment 149495 [details] [review]
Detect MSI Wind U100 and ignore brightness key event

Here is an ugly patch that parse /sys/devices/virtual/dmi/id/board_{vendor,name} and check that they begin by "MICRO-STAR INTERNATIONAL CO., LTD" and "U-100" respectively (those are the values extracted from my MSI Wind U100). If a MSI Wind U100 is detected, the bightness key events are ignored.

I directly added the parsing of sysfs entries in gnome-power-manager as it was really easier for me to do (codebase of gnome-power-manager is really easier to dive into than that of xorg / xrandr).

Created attachment 149505 [details] [review]
Updated version of the patch

Here is an updated version of the patch to handle different version of the BIOS (board name is different on some MSI Wind U100). The principle of the patch is still ugly (parsing sysfs entries) but the implementation is less so (using standard glib functions instead of unix ones).

What's wrong with using the HAL property brightness_in_hardware? See http://hal.freedesktop.org/quirk/quirk-backlight-index.html for details.

gnome-power-manager use XRandR to manage the brightness, not HAL that is deprecated. So this property cannot be used (see comment #6).

(In reply to comment #11)
> What's wrong with using the HAL property brightness_in_hardware? See
> http://hal.freedesktop.org/quirk/quirk-backlight-index.html for details.

Well I filed this bug because g-p-m prefers handling brightness setting through  xrandr when available which does not read this HAL property. Since there is no equivalent property in xrandr and there seems to be no configuration option in g-p-m to turn off brightness handling this is a regression over the older HAL backend. And this will not only cause problems with MSI Winds but also with of other laptops which handle brightness setting this way as soon as their graphics drivers gain xrandr support for it, you know the problems it has caused in the past leading to the introduction of this very HAL property.

i can confirm that sylvain's patch solves the problem on my msi wind u100. if somebody wants to triage on ubuntu there is a binary package on the ubuntu bugtracker, http://kamisama.free.fr/transfert/gnome-power-manager_2.28.1-0ubuntu1local1_i386.deb

For the binary package, please prefer the one accessible from my ppa : https://launchpad.net/~sdefresne/+archive/ppa

I'm coming back here to get some pointer on how to correctly address this issue.

First, I'd like to reformulate slightly what the bug currently is : gnome-power-manager is trying to remove its dependency on HAL (migrating to devkit), and use xrandr 1.3 brightness control when it is supported by the kernel (as is the case on intel GMA500 hardware). On top of that, some laptop have broken BIOSes that both handle the brightness control key event and forward them to user space via the kernel. To address thoses broken BIOSes, HAL exposed a property laptop_panel.brightness_in_hardware, but it is not used when using xrandr, and is deprecated.

As most BIOSes cannot be modified without the help of the OEM, keeping a database of bugged BIOSes is required, so that gnome-power-manager can work-around the issue by ignoring the brightness key press event (as was the case when using HAL and the property was set). Moreover, this database cannot be maintained in the gnome-power-manager package as such a workaround will probably required by others daemon managing brightness (KDE, XFCE, ...).

Now, for my request of pointer to try to address the issue while avoiding duplication of effort. Should the detection and reporting of broken BIOSes be handled by xrandr (this is what we are using to configure the brightness, but is only really concerned with the graphic driver, and thus maybe not the best place), by devkit (replacement of HAL if I understand correctly), or somewhere else ? Where should I ask to get an answer (I can't find a mailing list for xrandr, nor devicekit) ?

BTW, this bug is affecting more than the MSI Wind -- see  https://bugs.launchpad.net/ubuntu/+source/hal-info/+bug/453748 -- and is not specific to gnome-power-manager -- see https://bugs.launchpad.net/ubuntu/+source/linux/+bug/415023 --

This problem affecting various laptops is very well known as it lead to the introduction of the HAL brightness_in_hardware property in 2006 [1]. With the removal of HAL from the distributions this will also break the KDE and XFCE power managers affecting a lot more laptops. It actually wouldn't be such a pain if g-p-m had a setting allowing to turn off brightness handling manually, but right now the only workaround is to patch it.
I have asked your question two months ago on the g-p-m list [2]. Somebody already pointed out last year that the new xrandr backend is going to break this again [3]. It is basically because of the idiocy of depreciating HAL without having an adequate replacement for its functionality that we now have to deal with this again.
I think if you are willing to do something about it, you should take this to xorg-devel@lists.x.org and try to work out a more general solution which all power managers can use.

[1] http://lists.freedesktop.org/archives/hal/2006-May/005242.html
[2] http://mail.gnome.org/archives/gnome-power-manager-list/2009-October/msg00004.html
[3] http://mail.gnome.org/archives/gnome-power-manager-list/2008-June/msg00017.html

Mail sent to xorg-devel@lists.x.org : http://article.gmane.org/gmane.comp.freedesktop.xorg.devel/4153

There is solution to add the key to Gconf that will prevent g-p-m of using xrandr when brightness handled in hardware.

Look at patch here:
https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/527157/+attachment/1716645/+files/14-brightness-in-hardware.patch