Actually I meant "gnome power manager" instead of "gnome settings daemon". They are both affected by this problem

Created attachment 126678 [details] [review]
Patch to fix the bug

This patch will detect the version of RandR and use
XRRGetScreenResourcesCurrent when available.

Created attachment 126753 [details] [review]
Patch to fix the bug at compilation time

With my previous patch compilation fails if RandR 1.3 is not available since the new function doesn't exist in 1.2.

This new patch is even simpler and checks the availability of RandR 1.3 at
compilation time

2009-01-19  Richard Hughes  <richard@hughsie.com>

	* src/gpm-brightness-xrandr.c:
	(gpm_brightness_xrandr_update_cache):
	According to the following bug report the gnome settings daemon causes
	high CPU usage with libxrandr 1.2.99.2 or higher:
	https://bugs.edge.launchpad.net/ubuntu/+source/libxrandr/+bug/307306

	The problem is that it calls XRRGetScreenResources() (which is an rather
	expensive call) instead of XRRGetScreenResourcesCurrent() which is
	cheaper and doesn't cause hardware to be reprobed.

	While I agree that listening to events which represent changes in output
	properties is ideal, calling XRRGetScreenResources each time a property
	(e.g. the backlight) changes is really expensive and (if RandR 1.3 is
	available) this can be avoided.

	Patch from Alberto Milone <albertomilone@alice.it>, many thanks.

Created attachment 126770 [details] [review]
Patch to fix the bug at compilation time based on randr.h

This patch relies on randr.h i.e. on the RandR procol rather than on the xserver itself. This will prevent us from adding the xserver development libraries as build dependencies (thus preserving the previous behaviour).

2009-01-19  Richard Hughes  <richard@hughsie.com>

	* src/gpm-brightness-xrandr.c:
	(gpm_brightness_xrandr_update_cache):
	This patch relies on randr.h i.e. on the RandR procol rather than on the
	xserver itself. This will prevent us from adding the xserver development
	libraries as build dependencies (thus preserving the previous behaviour).

	Patch from Alberto Milone <albertomilone@alice.it>, many thanks.

You still need to check the version of the extension at runtime, otherwise you
will fail if communicating with an older server.

Created attachment 137397 [details] [review]
Fixed version of 79-randr13-speed-fix.patch

From:
https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/372468

The following is by the original reporter "mdw" on launchpad.



Binary package hint: gnome-power-manager

This is gnome-power-manager 2.24.2-2ubuntu8 (jaunty).

[crybaby ~]gnome-power-manager --no-daemon --sync
The program 'gnome-power-manager' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadRequest (invalid request code or no such operation)'.
  (Details: serial 187 error_code 1 request_code 154 minor_code 25)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)

A little playing with gdb shows that it's caused by a call to XRRGetScreenResourcesCurrent in gpm_brightness_xrandr_update_cache (src/gpm-brightness-xrandr.c), added by debian/patches/79-randr13-speed-fix.patch as part of #307306.

But the fix is wrong, as mentioned in further discussion on that bug: the call is guarded by #ifdef but that only helps if the code is compiled against an old client library (which can anyway be prevented by appropriate Build-Depends). The problem is that my X server doesn't provide Xrandr 1.3, because I'm holding it back (because of the Intel graphics driver bug warned of in the Jaunty release notes).

I've attached a fixed version of the patch which (a) stores the server's Xrandr version number, and (b) checks it before calling the offending function, falling back to XRRGetScreenResources.