tile property contents

[Dave Airlie]

On 14 October 2014 21:40, Thierry Reding <thierry.reding at gmail.com> wrote:
> On Tue, Oct 14, 2014 at 01:23:22PM +1000, Dave Airlie wrote:
>> Hi,
>>
>> So I've been hacking on mutter and the gnome pieces for tiling, and
>> I've at least fixed mutter locally so maximise windows works and the
>> heads are in the right order.
>>
>> Now I've strung all the pieces together using a single KMS property
>> that X.org propogates, and mutter picks up and propagates over dbus as
>> well,
>>
>> Currently I've ascii encoded the property into a blob,
>>
>> <ver>:<tileid>:<flags>:<maxhtiles>:<maxvtiles>:<h_tile_loc>:<v_tile_loc>:<tile_w>:<tile_h>
>>
>> I'm thinking of dropping the version field and just exposing TILE2
>> property if we need it later to add more values,
>>
>> The other fields:
>> tileid: a group id assigned by the kernel to all tiles in the same
>> group - unique per group
>> flags: bit 0 : single monitor enclosure
>> maxhtiles: total number of horiz tiles
>> maxvtiles: total number of vert tiles
>> h_tile_loc: horiz location of this output in tile group
>> v_tile_loc: vert location of this output in tile group
>> tile_w: width of this tile
>> tile_h: height of this tile.
>>
>> Now we extract all of these from the DisplayID v1.3 block, and I'm
>> wondering if maybe I shouldn't just export the whole DisplayID tiling
>> info block instead, it however encodes a few other pieces of
>> information, including bezel info, and some flags specifying behaviour
>> in some cases.
>>
>> The former could be more suitable for cases where DisplayID isn't
>> available (Dual DSI panels?) but I'm worried abuot exposing too little
>> at this point making TILE useless when the next monitor comes out.
>
> I don't think this is a good fit to describe dual DSI panels in the
> first place. While one of the modes (left-right split) could probably be
> described using the above, the other mode (odd-even split) is more
> difficult. In the latter mode, one controller will provide the odd lines
> and the other controller will provide the even lines.

Okay I'm happy with dual-DSI panels that you can hide those in the
kernel, they don't seem hotpluggable,

so if you have one in your device-tree, you can probably just never
expose the second crtc/encoder in the mode groups,
and keep them for the kernel to use as slaves for the panel.


> One other thing that worries me about this is that we defer handling of
> these complex configurations to userspace. I suppose this is fine, and
> in fact the only way, if there is no knowledge about the tile layout in
> kernel space. But if we know precisely how these various tiles are
> connected, wouldn't we be better off abstracting this away within the
> kernel and expose a single connector that is the union of all the tiles?
> After all that's what the kernel is, an abstraction between hardware and
> userspace.
>

We can't do that for the MST panels, because the abstractions is too
leaky, stealing crtcs dynamically at runtime, is screwed up and
getting pageflipping across crtcs without userspace knowing is also a
large pit of fail.

Dave.