tile property contents

tile property contents

[Dave Airlie]

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'm not sure any part of the stack should be extracting things and
splitting them out, I'd like to just give the same tile property all
the way through.

Dave.

Re: tile property contents

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 3121 bytes --]

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.

Also exporting the details about tiling presumes that each of the tiles
can work pretty much independently, too. That's not necessarily the case
for dual DSI. For a symmetric left-right split configuration this may be
somewhat true, at least for one of the halves. The second half can't
operate standalone. For an odd-even split I don't think either half can
be made to work standalone. I'm also not sure how left-right split
configurations work in video mode. I can imagine that both are really
needed for the panel to properly sync, since only the right half gets
the HBLANK and VBLANK signals.

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.

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 219 bytes --]

_______________________________________________
xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: tile property contents

[Dave Airlie]

On 14 October 2014 21:40, Thierry Reding <thierry.reding@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.

Re: tile property contents

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 4558 bytes --]

On Wed, Oct 15, 2014 at 06:35:52AM +1000, Dave Airlie wrote:
> On 14 October 2014 21:40, Thierry Reding <thierry.reding@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.

For reference: on Tegra a single CRTC sends pixel data to both DSI
outputs. The DSI outputs can then be programmed to take only the pixels
that they need to display. In the driver that I've submitted for review
a couple of days ago this is done by enslaving the second DSI output so
that it doesn't expose a regular DSI connector. The first DSI output is
then "augmented" to support a maximum of 8 data lanes instead of only 4
data lanes.

It'd be interesting to see if some of that can be extracted into common
code, but for now I've opted to handle it all in the Tegra driver since
it is the only implementation of this mode at this time.

> > 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.

I see. That sounds like it can indeed not be reasonably hidden in the
kernel. Or at least I wouldn't know how, so dealing with it in userspace
seems like a better option.

Just for my understanding, is it typical for each of these panels to be
standalone (own housing, ...) or are there monitors that actually take
two connectors and each of them drives a different part of the same
panel? A quick search on the internet indicates that the former is more
common (I haven't actually been able to find an example of the latter).

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: tile property contents

[Daniel Stone]

[-- Attachment #1.1: Type: text/plain, Size: 676 bytes --]

Hi,

On 15 October 2014 10:29, Thierry Reding <thierry.reding@gmail.com> wrote:

> Just for my understanding, is it typical for each of these panels to be
> standalone (own housing, ...) or are there monitors that actually take
> two connectors and each of them drives a different part of the same
> panel? A quick search on the internet indicates that the former is more
> common (I haven't actually been able to find an example of the latter).
>

You're in luck, because people are actually just that insane:
http://www.anandtech.com/show/8496/dell-previews-27inch-5k-ultrasharp-monitor-5120x2880

Two separate DP1.2 connectors, each using MST, for a 2x2 tile.

Cheers,
Dan

[-- Attachment #1.2: Type: text/html, Size: 1334 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: tile property contents

[Thierry Reding]

[-- Attachment #1.1: Type: text/plain, Size: 794 bytes --]

On Wed, Oct 15, 2014 at 12:04:38PM +0200, Daniel Stone wrote:
> Hi,
> 
> On 15 October 2014 10:29, Thierry Reding <thierry.reding@gmail.com> wrote:
> 
> > Just for my understanding, is it typical for each of these panels to be
> > standalone (own housing, ...) or are there monitors that actually take
> > two connectors and each of them drives a different part of the same
> > panel? A quick search on the internet indicates that the former is more
> > common (I haven't actually been able to find an example of the latter).
> >
> 
> You're in luck, because people are actually just that insane:
> http://www.anandtech.com/show/8496/dell-previews-27inch-5k-ultrasharp-monitor-5120x2880
> 
> Two separate DP1.2 connectors, each using MST, for a 2x2 tile.

Oh my...

Thierry

[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: tile property contents

[Andy Ritger]

I assume the TILE property described below would be per-connector?

It looks like this would handle the DP MST tiled display case.

At the risk of trying to solve too much at once:

There are also configurations where users configure multiple heads to
drive power walls that they want to be treated as one logical monitor,
similar to the DP MST tiled display case.  Normally, those powerwall
configurations don't have any layout information from the monitors
themselves, and the layout is configured by the user.

Would it be appropriate for users to be able to set the TILE property
in that sort of scenario?

For the sake of generality, I wonder if max[hv]tiles and [hv]_tile_loc
should be expressed in pixels rather than tiles?  Sometimes, the tiles
in those powerwalls may not all have the same resolution, or may be
configured with overlap.  I suppose that would make the TILE configuration
specific to the current modetimings on each tile...

Thanks,
- Andy


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'm not sure any part of the stack should be extracting things and
> splitting them out, I'd like to just give the same tile property all
> the way through.
> 
> Dave.
> _______________________________________________
> xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
_______________________________________________
xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: tile property contents

[Daniel Vetter]

On Wed, Oct 22, 2014 at 8:34 AM, Andy Ritger <aritger@nvidia.com> wrote:
> I assume the TILE property described below would be per-connector?
>
> It looks like this would handle the DP MST tiled display case.
>
> At the risk of trying to solve too much at once:
>
> There are also configurations where users configure multiple heads to
> drive power walls that they want to be treated as one logical monitor,
> similar to the DP MST tiled display case.  Normally, those powerwall
> configurations don't have any layout information from the monitors
> themselves, and the layout is configured by the user.
>
> Would it be appropriate for users to be able to set the TILE property
> in that sort of scenario?
>
> For the sake of generality, I wonder if max[hv]tiles and [hv]_tile_loc
> should be expressed in pixels rather than tiles?  Sometimes, the tiles
> in those powerwalls may not all have the same resolution, or may be
> configured with overlap.  I suppose that would make the TILE configuration
> specific to the current modetimings on each tile...

Why can't users just set that mode?

And if this is about the initial configuration problem then we (at
intel) are working on some way to load a dt blob as a firmware image
which would contain the entire kms state, and which we'd apply in an
atomic modeset at driver load. Everyone else (boot splash, X, ...)
will then just inherit that config. That should give you even
flicker-free screen walls if you want to ;-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: tile property contents

[Andy Ritger]

On Wed, Oct 22, 2014 at 11:20:09PM +0200, Daniel Vetter wrote:
> On Wed, Oct 22, 2014 at 8:34 AM, Andy Ritger <aritger-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:
> > I assume the TILE property described below would be per-connector?
> >
> > It looks like this would handle the DP MST tiled display case.
> >
> > At the risk of trying to solve too much at once:
> >
> > There are also configurations where users configure multiple heads to
> > drive power walls that they want to be treated as one logical monitor,
> > similar to the DP MST tiled display case.  Normally, those powerwall
> > configurations don't have any layout information from the monitors
> > themselves, and the layout is configured by the user.
> >
> > Would it be appropriate for users to be able to set the TILE property
> > in that sort of scenario?
> >
> > For the sake of generality, I wonder if max[hv]tiles and [hv]_tile_loc
> > should be expressed in pixels rather than tiles?  Sometimes, the tiles
> > in those powerwalls may not all have the same resolution, or may be
> > configured with overlap.  I suppose that would make the TILE configuration
> > specific to the current modetimings on each tile...
> 
> Why can't users just set that mode?

Sure, users can set the mode, but:

* Part of what the TILE property conveys is how monitors should be grouped
  for purposes of window maximization.  Users don't have a great way to
  express that today, that I'm aware of.

* Users might configure the mode they want, but then gnome-settings-daemon
  may come along later and decide it knows better than the user how things
  should be configured.  One scenario where this comes up is:
    (a) user meticulously configures his power wall
    (b) user hotplugs another monitor
  I've definitely seen cases where window managers will try to be clever
  in response to a hotplug, and clobber the user's current configuration.
  If the TILE property conveyed how some set of monitors was supposed
  to be grouped, that would hopefully give window managers additional
  information, such that they would know to keep that group intact.

> And if this is about the initial configuration problem then we (at
> intel) are working on some way to load a dt blob as a firmware image
> which would contain the entire kms state, and which we'd apply in an
> atomic modeset at driver load. Everyone else (boot splash, X, ...)
> will then just inherit that config. That should give you even
> flicker-free screen walls if you want to ;-)

Neat :)

> Cheers, Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: tile property contents

[Daniel Vetter]

On Wed, Oct 22, 2014 at 04:03:21PM -0700, Andy Ritger wrote:
> On Wed, Oct 22, 2014 at 11:20:09PM +0200, Daniel Vetter wrote:
> > On Wed, Oct 22, 2014 at 8:34 AM, Andy Ritger <aritger@nvidia.com> wrote:
> > > I assume the TILE property described below would be per-connector?
> > >
> > > It looks like this would handle the DP MST tiled display case.
> > >
> > > At the risk of trying to solve too much at once:
> > >
> > > There are also configurations where users configure multiple heads to
> > > drive power walls that they want to be treated as one logical monitor,
> > > similar to the DP MST tiled display case.  Normally, those powerwall
> > > configurations don't have any layout information from the monitors
> > > themselves, and the layout is configured by the user.
> > >
> > > Would it be appropriate for users to be able to set the TILE property
> > > in that sort of scenario?
> > >
> > > For the sake of generality, I wonder if max[hv]tiles and [hv]_tile_loc
> > > should be expressed in pixels rather than tiles?  Sometimes, the tiles
> > > in those powerwalls may not all have the same resolution, or may be
> > > configured with overlap.  I suppose that would make the TILE configuration
> > > specific to the current modetimings on each tile...
> > 
> > Why can't users just set that mode?
> 
> Sure, users can set the mode, but:
> 
> * Part of what the TILE property conveys is how monitors should be grouped
>   for purposes of window maximization.  Users don't have a great way to
>   express that today, that I'm aware of.

My understanding for why we want the TILE property is to avoid to
duplicate displayId parsing over every bit of userspace (and the fbcon
stuff in the kernel) interested in it. Imo the proper way for userspace is
to always just inherit whatever modeset config is already there.

> * Users might configure the mode they want, but then gnome-settings-daemon
>   may come along later and decide it knows better than the user how things
>   should be configured.  One scenario where this comes up is:
>     (a) user meticulously configures his power wall
>     (b) user hotplugs another monitor
>   I've definitely seen cases where window managers will try to be clever
>   in response to a hotplug, and clobber the user's current configuration.
>   If the TILE property conveyed how some set of monitors was supposed
>   to be grouped, that would hopefully give window managers additional
>   information, such that they would know to keep that group intact.

Well, imnsho gnome display control center is a bit too opiniated about
automatic modeset changes. If their assumption is that they always know
perfectly what the user wants upon hotplug I really don't want to work
around this in the kernel. Since for everything else than a laptop +
beamer gnome panel always pisses me off ;-)

I think gnome should just ask the user what it wants if there's more than
2 physical displays (treating a tiled 4k screen as one ofc), since there's
really no way at all to tell.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: tile property contents

[Dave Airlie]

>> > > There are also configurations where users configure multiple heads to
>> > > drive power walls that they want to be treated as one logical monitor,
>> > > similar to the DP MST tiled display case.  Normally, those powerwall
>> > > configurations don't have any layout information from the monitors
>> > > themselves, and the layout is configured by the user.
>> > >
>> > > Would it be appropriate for users to be able to set the TILE property
>> > > in that sort of scenario?
>> > >
>> > > For the sake of generality, I wonder if max[hv]tiles and [hv]_tile_loc
>> > > should be expressed in pixels rather than tiles?  Sometimes, the tiles
>> > > in those powerwalls may not all have the same resolution, or may be
>> > > configured with overlap.  I suppose that would make the TILE configuration
>> > > specific to the current modetimings on each tile...
>> >
>> > Why can't users just set that mode?
>>
>> Sure, users can set the mode, but:
>>
>> * Part of what the TILE property conveys is how monitors should be grouped
>>   for purposes of window maximization.  Users don't have a great way to
>>   express that today, that I'm aware of.
>
> My understanding for why we want the TILE property is to avoid to
> duplicate displayId parsing over every bit of userspace (and the fbcon
> stuff in the kernel) interested in it. Imo the proper way for userspace is
> to always just inherit whatever modeset config is already there.

Andy's idea is good, I'd considered it before, the problem being how
to expose it nicely,

not sure if you'd want persistent via /sys or dynamic setting of the
property by user for that session, so we could do it like xrandr
modes.

Daniel you are missing the nice case of using TILE for non-displayid
monitors once the infrastructure is in place.

Having it so you can create user defined tile groups to allow users to
configure arbitrary walls is a useful thing, that you can't do any
other way.

>
>> * Users might configure the mode they want, but then gnome-settings-daemon
>>   may come along later and decide it knows better than the user how things
>>   should be configured.  One scenario where this comes up is:
>>     (a) user meticulously configures his power wall
>>     (b) user hotplugs another monitor
>>   I've definitely seen cases where window managers will try to be clever
>>   in response to a hotplug, and clobber the user's current configuration.
>>   If the TILE property conveyed how some set of monitors was supposed
>>   to be grouped, that would hopefully give window managers additional
>>   information, such that they would know to keep that group intact.
>
> Well, imnsho gnome display control center is a bit too opiniated about
> automatic modeset changes. If their assumption is that they always know
> perfectly what the user wants upon hotplug I really don't want to work
> around this in the kernel. Since for everything else than a laptop +
> beamer gnome panel always pisses me off ;-)
>
> I think gnome should just ask the user what it wants if there's more than
> 2 physical displays (treating a tiled 4k screen as one ofc), since there's
> really no way at all to tell.

Well its not just a GNOME problem either, once things like SDL respect
tIle properrty,
we can create arbitary tile walls that the whole stack will respect,
instead of hacks
like fake xinerama.

Dave.
_______________________________________________
xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel

Re: tile property contents

[Daniel Vetter]

On Fri, Oct 24, 2014 at 05:25:58PM +1000, Dave Airlie wrote:
> >> > > There are also configurations where users configure multiple heads to
> >> > > drive power walls that they want to be treated as one logical monitor,
> >> > > similar to the DP MST tiled display case.  Normally, those powerwall
> >> > > configurations don't have any layout information from the monitors
> >> > > themselves, and the layout is configured by the user.
> >> > >
> >> > > Would it be appropriate for users to be able to set the TILE property
> >> > > in that sort of scenario?
> >> > >
> >> > > For the sake of generality, I wonder if max[hv]tiles and [hv]_tile_loc
> >> > > should be expressed in pixels rather than tiles?  Sometimes, the tiles
> >> > > in those powerwalls may not all have the same resolution, or may be
> >> > > configured with overlap.  I suppose that would make the TILE configuration
> >> > > specific to the current modetimings on each tile...
> >> >
> >> > Why can't users just set that mode?
> >>
> >> Sure, users can set the mode, but:
> >>
> >> * Part of what the TILE property conveys is how monitors should be grouped
> >>   for purposes of window maximization.  Users don't have a great way to
> >>   express that today, that I'm aware of.
> >
> > My understanding for why we want the TILE property is to avoid to
> > duplicate displayId parsing over every bit of userspace (and the fbcon
> > stuff in the kernel) interested in it. Imo the proper way for userspace is
> > to always just inherit whatever modeset config is already there.
> 
> Andy's idea is good, I'd considered it before, the problem being how
> to expose it nicely,
> 
> not sure if you'd want persistent via /sys or dynamic setting of the
> property by user for that session, so we could do it like xrandr
> modes.
> 
> Daniel you are missing the nice case of using TILE for non-displayid
> monitors once the infrastructure is in place.
> 
> Having it so you can create user defined tile groups to allow users to
> configure arbitrary walls is a useful thing, that you can't do any
> other way.
> 
> >
> >> * Users might configure the mode they want, but then gnome-settings-daemon
> >>   may come along later and decide it knows better than the user how things
> >>   should be configured.  One scenario where this comes up is:
> >>     (a) user meticulously configures his power wall
> >>     (b) user hotplugs another monitor
> >>   I've definitely seen cases where window managers will try to be clever
> >>   in response to a hotplug, and clobber the user's current configuration.
> >>   If the TILE property conveyed how some set of monitors was supposed
> >>   to be grouped, that would hopefully give window managers additional
> >>   information, such that they would know to keep that group intact.
> >
> > Well, imnsho gnome display control center is a bit too opiniated about
> > automatic modeset changes. If their assumption is that they always know
> > perfectly what the user wants upon hotplug I really don't want to work
> > around this in the kernel. Since for everything else than a laptop +
> > beamer gnome panel always pisses me off ;-)
> >
> > I think gnome should just ask the user what it wants if there's more than
> > 2 physical displays (treating a tiled 4k screen as one ofc), since there's
> > really no way at all to tell.
> 
> Well its not just a GNOME problem either, once things like SDL respect
> tIle properrty,
> we can create arbitary tile walls that the whole stack will respect,
> instead of hacks
> like fake xinerama.

Hm yeah if we want tile walls als logical displays for full-screening and
all that then this makes indeed sense. I didn't really consider that part,
was probably thrown off by Andy's comments that some tile walls aren't
pixel aligned which would look funky for full-screen apps I guess.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch

Re: tile property contents

[Aaron Plattner]

On 10/13/2014 08:23 PM, 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,

Nifty.  Is there a randrproto.txt spec for this planned?

> The other fields:
> tileid: a group id assigned by the kernel to all tiles in the same

What format does this ID need to be in?  It looks like monitors are 
identified by (vendor id, product id, serial number) tuples in the 
DisplayID extension block so it would make sense to just concatenate 
that into one giant number as the tileid.  Having to centrally manage 
these (in the kernel??) seems like overkill.

> 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.

I don't know whether the other flags would be useful, but one important 
one is the "native resolution" field.  At least one monitor I've seen 
fails to work if you drive the normal EDID "preferred" timings on both 
tiles.

> 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'm not sure any part of the stack should be extracting things and
> splitting them out, I'd like to just give the same tile property all
> the way through.
>
> Dave.
> _______________________________________________
> 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
>


-- 
Aaron
_______________________________________________
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

Re: tile property contents

[Dave Airlie]

On 3 December 2014 at 10:01, Aaron Plattner <aplattner@nvidia.com> wrote:
> On 10/13/2014 08:23 PM, 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,
>
>
> Nifty.  Is there a randrproto.txt spec for this planned?
>

Well for KMS its a kernel property and is documented there,
I suppose randrproto should also contain the info.
>
> What format does this ID need to be in?  It looks like monitors are
> identified by (vendor id, product id, serial number) tuples in the DisplayID
> extension block so it would make sense to just concatenate that into one
> giant number as the tileid.  Having to centrally manage these (in the
> kernel??) seems like overkill.

I don't mind, but central management is what we've done, it wasn't a lot
of work, you could munge the vendor/product/serial, but maybe
DisplayId won't be the only game in town in the future and I'd hate
to tie things to it.

>> 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.
>
>
> I don't know whether the other flags would be useful, but one important one
> is the "native resolution" field.  At least one monitor I've seen fails to
> work if you drive the normal EDID "preferred" timings on both tiles.

I think the last two fields are copied from that, the tile w/h, I can't see
any mention of a specific native res flag.

Dave.
_______________________________________________
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

Re: tile property contents

[Aaron Plattner]

On 12/02/2014 07:04 PM, Dave Airlie wrote:
> On 3 December 2014 at 10:01, Aaron Plattner <aplattner@nvidia.com> wrote:
>> On 10/13/2014 08:23 PM, 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,
>>
>>
>> Nifty.  Is there a randrproto.txt spec for this planned?
>>
>
> Well for KMS its a kernel property and is documented there,
> I suppose randrproto should also contain the info.
>>
>> What format does this ID need to be in?  It looks like monitors are
>> identified by (vendor id, product id, serial number) tuples in the DisplayID
>> extension block so it would make sense to just concatenate that into one
>> giant number as the tileid.  Having to centrally manage these (in the
>> kernel??) seems like overkill.
>
> I don't mind, but central management is what we've done, it wasn't a lot
> of work, you could munge the vendor/product/serial, but maybe
> DisplayId won't be the only game in town in the future and I'd hate
> to tie things to it.

Alright.  At least for now, we can just centrally manage group IDs in 
our X driver until we move that stuff to the kernel.

>>> 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.
>>
>>
>> I don't know whether the other flags would be useful, but one important one
>> is the "native resolution" field.  At least one monitor I've seen fails to
>> work if you drive the normal EDID "preferred" timings on both tiles.
>
> I think the last two fields are copied from that, the tile w/h, I can't see
> any mention of a specific native res flag.

Oh, got it.  I was confused by this because our DisplayID parsing 
library calls this field 'native_resolution'.

-- 
Aaron
_______________________________________________
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