[PATCH] randr: Add 'set' fields to SetCrtcConfigs request

Cyril Brulebois kibi at debian.org
Thu Feb 24 18:01:17 PST 2011


Hi,

Keith Packard <keithp at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg-devel/attachments/20110225/c03c8666/attachment.pgp>


More information about the xorg-devel mailing list