Steps to reproduce:
1. on at least my HP tx2000, remove the power cord
2. note that the brightness change box appears
3. note that it freezes and that GPM is frozen


Stack trace:

+ Trace 212367

Other information:
This is because we get a bogus value for the current brightness from X on this hardware, and there's no handling for such cases in GPM. We try decreasing from the current brightness value of 40610610 (!) to 127, with a sleep in between, making this loop go on effectively for ever. 

gpm_backlight_brightness_evaluate_and_set(), which calls
gpm_brightness_set(), which calls
gpm_brightness_xrandr_set(), which calls
gpm_brightness_xrandr_foreach_screen(), which calls
gpm_brightness_xrandr_foreach_resource()


gpm_brightness_xrandr_foreach_resource()  calls
gpm_brightness_xrandr_output_get_internal(), which returns cur (current brightness?) which is ***totally broken on this hardware (40610610)***.
(gpm_brightness_xrandr_output_get_internal() had made calls to XRRGetOutputProperty() in a loop.
The first call did not succeed, but the second "does", but the value it gets for prop from _XRead32() (which adjusts 40612122 from _XRead() > "memcpy()" is an int*))

Then, gpm_brightness_xrandr_foreach_resource() calls
gpm_brightness_xrandr_output_set(), 
where, with cur=40610610, shared_value_abs = 127
348			for (i=cur; i>=shared_value_abs; i--) {
349				ret = gpm_brightness_xrandr_output_set_internal (brightness, output, i);
(gdb) l
350				if (!ret) {
351					break;
352				}
353				if (cur != shared_value_abs) {
354					g_usleep (1000 * GPM_BRIGHTNESS_DIM_INTERVAL);
355				}
356			}

Which, as you can see, going down from 40610610 with that sleep in there basically leaves GNOME Power Manager frozen indefinitely.  

I'm not sure if it matters, but this is on a 64-bit AMD Turion x2 processor with 64-bit Fedora 10.

Yay.