On Tue, Sep 09, 2014 at 04:28:05PM +1000, Dave Airlie wrote:
All these are on top of rc3 (also in my drm-mst-hide-monitor branch).
So after talking to Keith and Daniel in Chicago I decided to give another go at hiding the horror that is 30" 4k dual-panel MST monitors in the kernel.
Also this hw is not going away, if anything it seems to be getting worse with Dell promising a 5k monitor, requiring 2 MST ports.
There's also dual-channel dsi and similar stuff which is the same. At least on some platforms where you need 2 crtcs to drive both channels.
The first two patches aren't really part of this series, I should probably put them in -fixes anyways. (i.e. ignore them)
So this series, contains the functionality changes required to hide tiled crtc underneath a master crtc, and to keep track of them for modeset and pageflipping and cursors (not finished).
It also allows EDID patching to fake the super-mode, along with hiding the sub-connectors.
Patch 9 is probably the biggest hack here due to lack of atomic modesetting, and how userspace picks crtcs.
Patch 10 is pageflip so hacky as well, and 11 is just bogus cursor handling, I just wanted to see the cursor in some form for now.
Mostly I'm looking for some high-level review of the concepts of this and how much harder it'll make life going forward.
So thinking about this some more I see piles of issues:
- It obviously looks and works fairly badly without atomic. And it's not just the crtc stealing, but we also need to steal planes. Which isn't a problem on i915, but on SoC platforms there's often just a set of universal planes for all crtcs, and if we also want to fix the dual channel dsi mess with this those matter.
- It will be a lot of work to virtualize the crtcs properly. You ducttape over the pageflip issues, but there's a lot more:
We need to consistently pick the leading crtc for pageflips and timestamps since otherwise the timestamps will be all over the place. Which will upset timing applications and result in video judder.
We need to virtualize all the planes which runs into all the same issues as virtualizing crtcs: We might run out of them when userspace doesn't expect it, or we might not even be able to seamlessly stitch them together over the two crtcs. E.g. older intel chips only had 1 special purpose video overlay shared between all crtcs, so you just can't virtualize that one for 2 crtcs.
There's probably more I've forgotten, but in any case a proper compositor already knows how to deal with all this. Second-guessing the compositor in the kernel is imo not the right approach and will result in major design headaches going forward.
So yeah this approach has a lot of appeal since faking it means existing userspace will keep on working. But I also think the troubles for non-X userspace (which actually wants to use planes properly) isn't worth it. And also for simple X compositors the illusion falls appart quickly with the crtc stealing and timestamp troubles for pageflips/vblanks. So let's look at the differnt issues with the split screen stuff again, and I think most are fairly easy to solve:
- fbdev configuration: We can just move the tiling detection into the fbdev helpers and it should resolve a lot of the troubles since fbdev emulation can explicitly assign crtcs.
- X initial configuration: Decent drivers (sna does it, dunno about the others) already goes to great lengths to faithfully inherit the kernel's setup. Ofc there's stupid xdm which club the driver/kernel right away with a modeset, but imo not trusting the initial setup the kernel has done is a bug. Both from a fastboot perspective and from a "users don't want to spec quirks in 3 billion different config places if kernel cmdline works well enough" pov.
- X compositor real screen size detection: I guess there's no way around to add a new "real screen" rectangles on top of the Xrandr crtc rects. Either the xinerama hack or something new in Xrandr, and then also teaching all compositors about it. Xinerama might fare better since some compositors already use it.
This is obviously the crux since it means we won't have nice 4/5k support from the start until compositors are all updated. But I really don't see a quick way around this.
- Sharing the tile layout detection code: Imo the kernel should expose tile-id, tile-x and tile-y on connectors when they are part of a tiled screen. For dual channel dsi drivers can fill them from DT or vbt or similar. And for dp mst I think your hack is going in the right direction - if we always probe _all_ dp mst slaves on a given master dp port we should be able to fill out the tile properties correctly. Of course that means a bit excessive amounts of reprobing, but that's just a good excuse to finally have decent edid and output state caching in general.
Or we just need to add an atomic probe ioctl which gives you the output state for _all_ connectors at the same time ...
Ok, that's my dump, let's see how much sense it still makes once coffee kicks in ;-)
Cheers, Daniel