Hi, Keith Packard <kei...@keithp.com> (24/02/2011): > As release manager, this seems like the right solution. However, > it's a larger change than adding the new fix-ups, which doesn't > exactly make me less nervous.
not that I'm advocating last-minute pushes, I gave it a try anyway. > If you want to try out the RandR 1.4 bits, you can use: > > git://people.freedesktop.org/~keithp/xserver randr-fixes > > To test the RandR 1.4 bits, you'll need: > > git://anongit.freedesktop.org/xorg/proto/randrproto master > > git://people.freedesktop.org/~keithp/libXrandr randr-1.4 > > git://people.freedesktop.org/~keithp/xrandr randr-1.4 > > Please report success or failure from any testing. Short story: build ok, runtime nok. Longer story: (I'm assuming you're going to add version checks at the end, which seems to be the standard way when patches are floating around; without those, xrandr 1.4 would fail to build without libxrandr << 1.4, for example. That said:) Building was OK. Basic rotations or mode changes on LVDS1 were OK. Dual screen wasn't. I plugged a VGA monitor on my laptop (with an Intel chipset, from the 94x series: 8086:27a2). Default: xrandr --auto and: xrandr --output VGA1 --same-as LVDS1 are OK. That doesn't work right: xrandr --output VGA1 --right-of LVDS1 My pointer now appears on both LVDS1 and VGA1, at the same (relative I'd say?) position: - when the pointer sits in the corner of an output, it sits on the same corner of the other output. - needless to say, when the pointer reaches the right border of the left screen, it also reaches the right border of the right screen, and disappears in a galaxy (not too) far away. For my tests, I tried to avoid running into combinatorial explosion, so I kept 1.4-aware libxrandr the whole time. * server + xrandr = ok → hurrah! * server + xrandr-1.4 = nok → X Error of failed request [see below] * server-1.4 + xrandr = ok → no (evident) regression * server-1.4 + xrandr-1.4 = nok → double pointer effect. The X Error is: | $ xrandr --output VGA1 --right-of LVDS1 | X Error of failed request: BadLength (poly request too large or internal Xlib length error) | Major opcode of failed request: 149 (RANDR) | Minor opcode of failed request: 36 () | Serial number of failed request: 34 | Current serial number in output stream: 34 The 4th case is pretty annoying, and was detailed above. The 2nd case worries me a bit. Shouldn't one be able to use library/binary newer than the server, and expect those to figure out what the server can do and how‽ Feeling doubtful, KiBi.
signature.asc
Description: Digital signature
_______________________________________________ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel