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 126.96.36.199, 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:
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