I thought I'd kick off a thread to better discuss how to deal with "large" displays which need multiple crtcs/planes merged to deal without output larger than a certain width. What I have in mind basically amounts to driver-custom-properties and shouldn't really need much/anything in the way of drm core or helper support[1]. There may of course be some room to make helpers/core more aware of crtc ganging if it turns out to be something that many drivers are doing in the same way. But to start with my bigger concern is getting the userspace interface right. This is semi-related to a thread started earlier by Aaron Plattner on xorg-devel: http://lists.freedesktop.org/archives/xorg-devel/2014-January/039984.html As I see it, there are really two different scenarios: 1) single encoder/connector: double up on planes (pipes) and crtcs (mixers), but still a single connector. 2) double up entire pipe.. this scenario is more like what Aaron mentioned. This could mean using multiple DVI or HDMI connectors, or multiple DSI channels. In the DSI case, I'm not entirely sure yet the implications for a dsi panel driver, but I think it needs to be a bit aware. ------------------- For the first scenario, the approach I am leaning towards is a 'SLAVE_CRTC'[2] property on the crtc. The idea being that userspace could pick an otherwise unused CRTC, and assign it as a slave in order to enable higher resolutions. The primary crtc could use the slave's mixer and primary plane. The existing encoder->possible_crtcs would be used by userspace to figure out which crtc(s) it could pick to use as a slave. The property approach seems like it should fit in nicely with the plans for atomic. The driver can decide whether a given mode is possible during the atomic 'test' step based on the proposed SLAVE_CRTC value. We do possibly get funny edge cases where a CRTC isn't yet available but will be after next vblank, but this is basically the same scenario with have already with moving planes between crtcs (and where an EBUSY or similar return value from atomic would make sense). For non-primary planes, it may be sufficient to expose max width/height dimensions and let userspace figure out when it needs to use multiple planes for a single layer. For the second scenario, I am less sure. We could of course also have some sort of 'SLAVE_CONNECTOR' property (since encoders themselves don't currently have/need properties). But this probably depends on the outcome of the xorg/xrandr userspace discussion. Anyways, I'd of course be interested to hear from others who will have to tackle the same problem in their own drivers, whether the 'SLAVE_CRTC' approach works for them or not, etc. It looks like the first scenario is something I'll get to deal with pretty soon now (ie. approximately as soon as I buy myself a 4k DP monitor ;-)) BR, -R [1] assuming it is acceptable for initial modeset for fbcon picking a lower resolution which can be supported without a slave encoder. Most/all phones/tablets disable fbcon, so this doesn't seem like it should be a problem.. [2] if anyone envisions scenarios where we need to gang more than 2 crtcs, we could invert the property, and have 'PRIMARY_CRTC' property that gets set on each of the slaves. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
