RandR 1.1 and 1.3 compatibility.

Ander Conselvan de Oliveira ander at c3sl.ufpr.br
Wed Feb 4 07:08:21 PST 2009

Em Tuesday 03 February 2009 20:16:59 Colin Guthrie escreveu:
> 'Twas brillig, and Ander Conselvan de Oliveira at 03/02/09 18:21 did
> gyre and gimble:
> > Hi,
> >
> > I'm having a problem with xrandr, X server from 1.6 branch and
> > drivers that only support RandR 1.1. The server reports it supports
> > version 1.3 of the extension, so xrandr tries to get panning information
> > but the call to XRRGetPanning fails because rrGetPanning private screen
> > function is not implemented and returns BarCrtc.
> >
> > Tricking xrandr to believe the server does not support version 1.3 of the
> > extension solves the problem but I guess there should be a better way to
> > handle this. Any ideas?
> Perhaps related to:
> http://bugs.freedesktop.org/show_bug.cgi?id=19337

Not quite. This bug is about X server startup. The problem I have seems 
related to a missing compatibility layer. For instance, changing 
ProcRRGetPanning to return a xRRGetPanningReply with left, top, width and 
height set to zero is enough to make an unmodified xrandr work. But 
RRSetPanning won't work.

OTOH, the problem is related to the assumption (in xrandr tool) that if the 
server supports RandR 1.3, a call to XRRGetPanning will succeed. In the case 
of RandR 1.1 driver, if will fail with a BadCrtc error, but the program will 
be aborted since it does set a custom error handler.

I want to know what is the correct way to fix it. Should xrandr be patched to 
handle a failure in GetPanning and disable randr 1.3 support or the server 
should act like panning is support in some way, event if the driver does not.


More information about the xorg mailing list