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 1.2.99.4, 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. Thanks, Ander _______________________________________________ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
