On 14 October 2014 21:40, Thierry Reding <thierry.reding@xxxxxxxxx> 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. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
