Re: tile property contents
On 12/02/2014 07:04 PM, Dave Airlie wrote: On 3 December 2014 at 10:01, Aaron Plattner aplatt...@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
Re: tile property contents
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
On 3 December 2014 at 10:01, Aaron Plattner aplatt...@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
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 ___ 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
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@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
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 arit...@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 ___ 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
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@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel ___ 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
On Wed, Oct 22, 2014 at 11:20:09PM +0200, Daniel Vetter wrote: On Wed, Oct 22, 2014 at 8:34 AM, Andy Ritger arit...@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. * 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@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
On Wed, Oct 22, 2014 at 8:34 AM, Andy Ritger arit...@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 ___ 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
On Wed, Oct 15, 2014 at 06:35:52AM +1000, Dave Airlie wrote: On 14 October 2014 21:40, Thierry Reding thierry.red...@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 pgpKnD7IcEtWl.pgp Description: PGP signature ___ 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
Hi, On 15 October 2014 10:29, Thierry Reding thierry.red...@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 ___ 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
On Wed, Oct 15, 2014 at 12:04:38PM +0200, Daniel Stone wrote: Hi, On 15 October 2014 10:29, Thierry Reding thierry.red...@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 pgpaDd_sF80zM.pgp Description: PGP signature ___ 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
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 pgpFkgA5qHddG.pgp Description: PGP signature ___ 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
On 14 October 2014 21:40, Thierry Reding thierry.red...@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. ___ 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
tile property contents
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@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
