Re: output setup and configuration, what lives where?

[Dave Airlie <airlied gmail com>]

On 13 October 2014 17:34, drago01 <drago01 gmail com> wrote:
> On Mon, Oct 13, 2014 at 8:53 AM, Dave Airlie <airlied gmail com> wrote:
> > Hey,
> >
> > So I've been looking at 4K monitors that require DP MST and present as
> > two screens with some tiling info in the EDID extensions, and I've
> > been taking a look at how to integrate these with gnome.
> >
> > Just to clear things up, I tried to hide these in the kernel, the side
> > effects were too messy to cover up, and stuff broke in wierd ways, so
> > I've decided to follow Windows and push this up a few levels.
> >
> > So I've built a kernel property to describe tiles, and passed it
> > through X to test, and hacked on mutter 3.10, so
> >
> > a) windows maximize properly
> > b) initial mutter configuration picks a sane config.
> >
> > (cgit.freedesktop.org/~airlied/mutter - will eventually have it).
> >
> > Now the question is what else needs changing for this, I know I should
> > probably start to target master or least F21 versions and I'll
> > probably get to that,
> >
> > I'm getting the feeling at least,
> > gnome-desktop
> > and
> > gnome-control-center
> >
> > will need work, control-center will probably need design work so the
> > UI doesn't suck for this use-case.
> >
> > I'm just not sure how things like monitors.xml fit in, who writes this
> > file, who reads it,
>
> The file is handled by mutter i.e it reads and writes it see:
> https://git.gnome.org/browse/mutter/tree/src/backends/meta-monitor-config.c
> (or https://git.gnome.org/browse/mutter/tree/src/core/monitor-config.c?h=gnome-3-10
> in 3.10).
>
> > is there
> > some stuff talking over dbus here,
>
> Mutter exposes the settings over dbus and works as an abstraction
> layer over xrandr / kms (on wayland).
>
> > does gnome-session-daemon get
> > involved anywhere etc, so pointers/answers etc all appreciated.
>
> gnome-desktop now uses the dbus api exposed by mutter instead of
> xrandr directly. gnome-settings-daemon just uses gnome-desktop
>
> So you have to
>
> 1) Update mutter to expose it via dbus
> 2) Extend GnomeRR in gnome-desktop to expose it to clients like g-s-d
> and control-center
> 3) Add UI for control-center that actually uses it (should talk to
> designers about it).

Okay I've taken a first go at getting mutter/g-d/g-c-c working,

http://cgit.freedesktop.org/~airlied/gnome-desktop/log/?h=tile-monitor-1
http://cgit.freedesktop.org/~airlied/gnome-control-center/log/?h=tile-monitor-1
http://cgit.freedesktop.org/~airlied/mutter/log/?h=tile-monitor-1

Essentially the kernel/X.org (not a promise) exposes a TILE property,
on the kms connector/randr outputs, with the tiling info in it.

mutter uses the tile info to construct a logical monitor from a group
of crtcs, this lets things like window maximise work, panel on the
whole monitor etc. it also exposes the tile property over dbus.

gnome-desktop currently just exposes the tile property and parses it

then the displays applet handles tiling etc.

I've tried to avoid making UI changes, and just have the UI just look
like one big monitor. The only real UI hack is replacing the useless
1920x2160 half-tile mode with the complete 3840x2160 mode,
so the user can select something sane. I've tested these on my
kernel/X hacks, and I can use the control panel to change modes
between single and multi-tile modes (1920x1080 -> 3840x2160)
to rotate etc.

I sort of think we can probably hide a lot of the stuff from the
control panel inside gnome-rr, and I might take a look at that
approach next.

I don't think we can hide all of this in mutter in a nice way,
since the crtc assignments are done by gnome-rr, so once
we start limiting the number of crtcs mutter exposes depending
on the hotplugged monitor, I expect things could get confused.

Dave.