Subject: mir/xrandr compatibility lib

From: Bryce Harrington <[email-masked]>
Date: Mon, 8 Apr 2013 12:20:38 -0700

I'm looking into making a wrapper lib for mir that provides a few basic
xrandr operations via mir.  I think I understand what's needed but want
to get your sanity check before I get too far into it.

This mir/randr compatibility library ("mirandr?") will provide the
header file X11/extensions/Xrandr.h, but stripped down to only the RANDR
1.0 routines and structure definitions.  That should be adequate for
applications and is a reasonably achievable subset (i.e. no multi-head
layout operations, properties, or other advanced stuff).  Since
libXrandr is in C, this will need to be in C as well.

The library will provide mir implementations of these commonly needed
RANDR 1.0 calls:

  XRRGetScreenInfo()
  XRRSetScreenConfig()
  XRRQueryVersion()    // Just returns 1.0
  XRRQueryExtension()  // Stub; just return true

The getter call (retrieving read-only information) is the immediate
priority.  The setter routine may be more involved to get right so
implementaton will be left to phase 2.

There are also a number of accessors and constructor/destructor routines
for the various structs.  These are entirely local (they don't make any
server calls) so will be reused as-is.

The implementation of XRRGetScreenInfo() will essentially just set up a
mir connection, grab the display info, and reformat it into the Xrandr
structures.  So, borrowing logic from the demo client, it'd look
something like:

    MirConnection* connection{nullptr};
    mir_wait_for(mir_connect(mir_test_socket, __PRETTY_FUNCTION__,
                 connection_callback, &connection));
    MirDisplayInfo info;
    mir_connection_get_display_info(connection, &info);

    // Create XRRScreenConfiguration structure
    // Copy info.width, info.height to structure

    mir_connection_release(connection);
    // return structure

How's this all sound so far?

Bryce

---

From: Bryce Harrington <[email-masked]>
Date: Tue, 9 Apr 2013 14:59:17 -0700

> libXrandr is in C, this will need to be in C as well.

For now, pushed some preliminary bits to:
  https://code.launchpad.net/~bryce/+junk/mirandr
 
> -- 
> Mir-devel mailing list
> [email-masked]
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/mir-devel

---

From: Robert Ancell <[email-masked]>
Date: Wed, 10 Apr 2013 11:12:32 +1200

> How's this all sound so far?
This sounds good - this is a stepping stone before apps/toolkits become
Mir aware right?

Will this still require a recompile of the application using xrandr or
is there some linking magic to make this a drop in replacement when
running under Mir?

--Robert

---

From: Bryce Harrington <[email-masked]>
Date: Tue, 9 Apr 2013 18:30:19 -0700

> This sounds good - this is a stepping stone before apps/toolkits become

Right.

> is there some linking magic to make this a drop in replacement when

Static linking should be straightforward.  The package will provide a
.so version as well, which I'd expect to be swappable with libXrandr.so,
or whatever other linking magic people are doing.

The caveat is that this is only shooting for RANDR level 1.0 - that's
the same minimal RANDR support that -nvidia provided until just
recently.

Apps that need more than RANDR 1.0 probably would be early targets to
make Mir aware.  The RANDR 1.2+ operations are more advanced (e.g. CRTC
fiddling, properties, etc.) and may be too clunky to do within an
adapter.

Grepping XRR in gtk+3.0 it needs a few of the RANDR 1.2 functions, so
perhaps those can either be simulated or stubbed out.  Guess we can
investigate that more when things are further along.

Bryce