[RFC] attempting to hide 30" monitor in kernel (raw)

[Daniel Vetter]

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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch