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.
On Mon, Mar 31, 2014 at 02:04:00PM -0400, Rob Clark wrote:
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:
- single encoder/connector: double up on planes (pipes) and crtcs
(mixers), but still a single connector.
- 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.
I think this here is (mostly) a userspace problem of figuring out how the different outputs are laid out in reality. Only difference is that the hw might (not sure how far those standars really are) provide some definit hints. So imo not a kernel problem really.
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.
I second the idea of exposing plane limits. I've cc'ed a thread on dri-devel where Damien&I discussed this a bit. We probably need a pile of per plane/per pixel format properties like max/min size, stride and a pile of flags for special cases.
For the crtc ganging I wonder whether we even should expose this. For generic userspace it's just yet another random hardware restriction. E.g. in i915 we don't expose the various (and constantly changing between platforms) restrictions on plls. All we do is tell userspace that it didn't work out.
Imo the point of atomic modesets with the test mode is that we can expose this information at least indirectly to userspace. But trying to come up with some explicit scheme for every insane corner case is imo pointless - generic userspace won't ever bothering with them, and if you need special code you might as well bake in the assumptions in userspace. Kinda like current userspace has baked-in assumptions about how a fb backing storage object should look like.
So overall I think we need to have the following pieces: - Plane limits so that fbcon and userspace which can't do tiling can restrict itself appropriately. - When userspace asks for a big mode which needs ganging of some stuff the kernel driver handles all the resource allocation. If your hw allows it it's obviously best if you can freely reassign resources between crtcs, otherwise it'll be really hard for userspace to get anything done without atomic modesets. - Generic userspace slices&dices the logical framebuffer into tiles which fit into the planes.
Or do I miss something big here?
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 ;-))
Like I've said I think the 2nd scenario isn't a kernel issue (maybe we need to expose layout information through read-only properties if it's not available in a standard way). For the first scenario I still have the impression that I'm missing something. -Daniel
On Tue, Apr 1, 2014 at 4:04 AM, Daniel Vetter daniel@ffwll.ch wrote:
On Mon, Mar 31, 2014 at 02:04:00PM -0400, Rob Clark wrote:
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:
- single encoder/connector: double up on planes (pipes) and crtcs
(mixers), but still a single connector.
- 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.
I think this here is (mostly) a userspace problem of figuring out how the different outputs are laid out in reality. Only difference is that the hw might (not sure how far those standars really are) provide some definit hints. So imo not a kernel problem really.
right, that is why I included the link back to the xorg-devel discussion. The second scenario seems pretty similar to that.
(although re-reading what I wrote, I realized I didn't connect those two dots at all)
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.
I second the idea of exposing plane limits. I've cc'ed a thread on dri-devel where Damien&I discussed this a bit. We probably need a pile of per plane/per pixel format properties like max/min size, stride and a pile of flags for special cases.
right, this is pretty much what I had in mind, a bunch of read-only properties
For the crtc ganging I wonder whether we even should expose this. For generic userspace it's just yet another random hardware restriction. E.g. in i915 we don't expose the various (and constantly changing between platforms) restrictions on plls. All we do is tell userspace that it didn't work out.
True.. I guess if it was only one driver that would have to deal with this, that would make sense. Otherwise, I'd be pretty happy to make the kernel a bit simpler and let userspace choose.
I guess you already do some under-the-hood remapping of pipes/crtcs in i915, so maybe this sort of thing is a bit easier for you. I was really hoping not to have to go there.
Imo the point of atomic modesets with the test mode is that we can expose this information at least indirectly to userspace. But trying to come up with some explicit scheme for every insane corner case is imo pointless - generic userspace won't ever bothering with them, and if you need special code you might as well bake in the assumptions in userspace. Kinda like current userspace has baked-in assumptions about how a fb backing storage object should look like.
True, although I expect width limits to not be entirely uncommon. I think I know of at least two or three hw platforms with some sort of "merge" feature for wide displays.
----
but, now that we are on the topic of atomic.. seems like there are two cases for what happens with planes vs ganged crtcs. Either the plane can be shared across the two half-crtcs or not. So maybe I end up having to remap planes under the hood already (in which case, I suppose doing the same for crtcs isn't such a big stretch).
But it means userspace never really knows how many crtcs or planes are actually available. Which is why I wanted a way to return per-plane status from atomic test ;-)
So overall I think we need to have the following pieces:
- Plane limits so that fbcon and userspace which can't do tiling can restrict itself appropriately.
- When userspace asks for a big mode which needs ganging of some stuff the kernel driver handles all the resource allocation. If your hw allows it it's obviously best if you can freely reassign resources between crtcs, otherwise it'll be really hard for userspace to get anything done without atomic modesets.
- Generic userspace slices&dices the logical framebuffer into tiles which fit into the planes.
Or do I miss something big here?
No, not really. I was just trying to get away with pushing some complexity (for case #1) up to userspace instead of doing it in the kernel.
BR, -R
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 ;-))
Like I've said I think the 2nd scenario isn't a kernel issue (maybe we need to expose layout information through read-only properties if it's not available in a standard way). For the first scenario I still have the impression that I'm missing something.
-Daniel
Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Tue, Apr 1, 2014 at 8:40 AM, Rob Clark robdclark@gmail.com wrote:
On Tue, Apr 1, 2014 at 4:04 AM, Daniel Vetter daniel@ffwll.ch wrote:
On Mon, Mar 31, 2014 at 02:04:00PM -0400, Rob Clark wrote:
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:
- single encoder/connector: double up on planes (pipes) and crtcs
(mixers), but still a single connector.
- 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.
I think this here is (mostly) a userspace problem of figuring out how the different outputs are laid out in reality. Only difference is that the hw might (not sure how far those standars really are) provide some definit hints. So imo not a kernel problem really.
right, that is why I included the link back to the xorg-devel discussion. The second scenario seems pretty similar to that.
(although re-reading what I wrote, I realized I didn't connect those two dots at all)
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.
I second the idea of exposing plane limits. I've cc'ed a thread on dri-devel where Damien&I discussed this a bit. We probably need a pile of per plane/per pixel format properties like max/min size, stride and a pile of flags for special cases.
right, this is pretty much what I had in mind, a bunch of read-only properties
For the crtc ganging I wonder whether we even should expose this. For generic userspace it's just yet another random hardware restriction. E.g. in i915 we don't expose the various (and constantly changing between platforms) restrictions on plls. All we do is tell userspace that it didn't work out.
True.. I guess if it was only one driver that would have to deal with this, that would make sense. Otherwise, I'd be pretty happy to make the kernel a bit simpler and let userspace choose.
I guess you already do some under-the-hood remapping of pipes/crtcs in i915, so maybe this sort of thing is a bit easier for you. I was really hoping not to have to go there.
one extra thing to note: SLAVE_CRTC makes things someone usable for userspace that still uses the legacy setcrtc API.. trying to do it all under the hood seems only reasonable for atomic.
What I'm leaning towards is introducing SLAVE_CRTC property, but in the atomic case, let the driver attempt to set that property itself if needed during the atomic->test() step.
BR, -R
Imo the point of atomic modesets with the test mode is that we can expose this information at least indirectly to userspace. But trying to come up with some explicit scheme for every insane corner case is imo pointless - generic userspace won't ever bothering with them, and if you need special code you might as well bake in the assumptions in userspace. Kinda like current userspace has baked-in assumptions about how a fb backing storage object should look like.
True, although I expect width limits to not be entirely uncommon. I think I know of at least two or three hw platforms with some sort of "merge" feature for wide displays.
but, now that we are on the topic of atomic.. seems like there are two cases for what happens with planes vs ganged crtcs. Either the plane can be shared across the two half-crtcs or not. So maybe I end up having to remap planes under the hood already (in which case, I suppose doing the same for crtcs isn't such a big stretch).
But it means userspace never really knows how many crtcs or planes are actually available. Which is why I wanted a way to return per-plane status from atomic test ;-)
So overall I think we need to have the following pieces:
- Plane limits so that fbcon and userspace which can't do tiling can restrict itself appropriately.
- When userspace asks for a big mode which needs ganging of some stuff the kernel driver handles all the resource allocation. If your hw allows it it's obviously best if you can freely reassign resources between crtcs, otherwise it'll be really hard for userspace to get anything done without atomic modesets.
- Generic userspace slices&dices the logical framebuffer into tiles which fit into the planes.
Or do I miss something big here?
No, not really. I was just trying to get away with pushing some complexity (for case #1) up to userspace instead of doing it in the kernel.
BR, -R
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 ;-))
Like I've said I think the 2nd scenario isn't a kernel issue (maybe we need to expose layout information through read-only properties if it's not available in a standard way). For the first scenario I still have the impression that I'm missing something.
-Daniel
Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Tue, Apr 01, 2014 at 08:40:54AM -0400, Rob Clark wrote:
No, not really. I was just trying to get away with pushing some complexity (for case #1) up to userspace instead of doing it in the kernel.
To clarify: I don't think it makes sense to fully abstract this away in the kernel, especially if userspace needs to be aware of the boundary between the crtcs so that it can correctly tile up the logical frambuffer. But I'm not sure whether trying to make that possible with a generic userspace driver is sensible, or whether having a bit of magic glue code in the ddx/wayland/hwc part for e.g. msm is the better option, at least in the short term.
Since if the set of useable planes actually changes we need to push that decision up the stack even further like wayland/hwc currently allow, and maybe there's some things we need to fix at that layer first. Once we've learned that lesson we can push things down again and add a neat little generic kernel interface. At least thus far we've always done a bit of prototyping with driver-specific code to learn a few lessons, e.g. the various pieces of non-standard plane/overlay in i915. -Daniel
On Tue, Apr 1, 2014 at 9:40 AM, Daniel Vetter daniel@ffwll.ch wrote:
On Tue, Apr 01, 2014 at 08:40:54AM -0400, Rob Clark wrote:
No, not really. I was just trying to get away with pushing some complexity (for case #1) up to userspace instead of doing it in the kernel.
To clarify: I don't think it makes sense to fully abstract this away in the kernel, especially if userspace needs to be aware of the boundary between the crtcs so that it can correctly tile up the logical frambuffer. But I'm not sure whether trying to make that possible with a generic userspace driver is sensible, or whether having a bit of magic glue code in the ddx/wayland/hwc part for e.g. msm is the better option, at least in the short term.
Since if the set of useable planes actually changes we need to push that decision up the stack even further like wayland/hwc currently allow, and maybe there's some things we need to fix at that layer first. Once we've learned that lesson we can push things down again and add a neat little generic kernel interface. At least thus far we've always done a bit of prototyping with driver-specific code to learn a few lessons, e.g. the various pieces of non-standard plane/overlay in i915.
right, things like 'STATUS' property for returning per-object status would start as driver custom. (And even 'SLAVE_CRTC'..) Userspace could look for certain property names in the same way that it looks for certain gl extension strings. But should be semi-standardized, so other drivers which need the same thing should use same property names/values/behaviors as much as possible.. which was the point for starting the thread ;-)
BR, -R
-Daniel
Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Tue, Apr 01, 2014 at 09:54:40AM -0400, Rob Clark wrote:
On Tue, Apr 1, 2014 at 9:40 AM, Daniel Vetter daniel@ffwll.ch wrote:
On Tue, Apr 01, 2014 at 08:40:54AM -0400, Rob Clark wrote:
No, not really. I was just trying to get away with pushing some complexity (for case #1) up to userspace instead of doing it in the kernel.
To clarify: I don't think it makes sense to fully abstract this away in the kernel, especially if userspace needs to be aware of the boundary between the crtcs so that it can correctly tile up the logical frambuffer. But I'm not sure whether trying to make that possible with a generic userspace driver is sensible, or whether having a bit of magic glue code in the ddx/wayland/hwc part for e.g. msm is the better option, at least in the short term.
Since if the set of useable planes actually changes we need to push that decision up the stack even further like wayland/hwc currently allow, and maybe there's some things we need to fix at that layer first. Once we've learned that lesson we can push things down again and add a neat little generic kernel interface. At least thus far we've always done a bit of prototyping with driver-specific code to learn a few lessons, e.g. the various pieces of non-standard plane/overlay in i915.
right, things like 'STATUS' property for returning per-object status would start as driver custom. (And even 'SLAVE_CRTC'..) Userspace could look for certain property names in the same way that it looks for certain gl extension strings. But should be semi-standardized, so other drivers which need the same thing should use same property names/values/behaviors as much as possible.. which was the point for starting the thread ;-)
What's the problem with just using two crtcs? With the atomic API you just shovel the state for both down into the driver in one ioctl. This is pretty much what we'll need to do to drive those 4k MST DP displays as well. The driver will then have to do its best to genlock the crtcs if the hardware doesn't do it fully. IIRC that's how we're going to have to do the MST stuff, ie. use the same clock source for both obviously, and try to start all the pipes as fast as possible so that the vblanks line up. And that's going to require more changes to our modesetting codepaths.
So, I don't see a need for any SLAVE_CRTC properties or dynamic remapping of resources. The latter would get nasty when the resources (eg. planes) aren't uniform anyway. Just let userspace figure it out.
On Tue, Apr 1, 2014 at 10:12 AM, Ville Syrjälä ville.syrjala@linux.intel.com wrote:
On Tue, Apr 01, 2014 at 09:54:40AM -0400, Rob Clark wrote:
On Tue, Apr 1, 2014 at 9:40 AM, Daniel Vetter daniel@ffwll.ch wrote:
On Tue, Apr 01, 2014 at 08:40:54AM -0400, Rob Clark wrote:
No, not really. I was just trying to get away with pushing some complexity (for case #1) up to userspace instead of doing it in the kernel.
To clarify: I don't think it makes sense to fully abstract this away in the kernel, especially if userspace needs to be aware of the boundary between the crtcs so that it can correctly tile up the logical frambuffer. But I'm not sure whether trying to make that possible with a generic userspace driver is sensible, or whether having a bit of magic glue code in the ddx/wayland/hwc part for e.g. msm is the better option, at least in the short term.
Since if the set of useable planes actually changes we need to push that decision up the stack even further like wayland/hwc currently allow, and maybe there's some things we need to fix at that layer first. Once we've learned that lesson we can push things down again and add a neat little generic kernel interface. At least thus far we've always done a bit of prototyping with driver-specific code to learn a few lessons, e.g. the various pieces of non-standard plane/overlay in i915.
right, things like 'STATUS' property for returning per-object status would start as driver custom. (And even 'SLAVE_CRTC'..) Userspace could look for certain property names in the same way that it looks for certain gl extension strings. But should be semi-standardized, so other drivers which need the same thing should use same property names/values/behaviors as much as possible.. which was the point for starting the thread ;-)
What's the problem with just using two crtcs? With the atomic API you just shovel the state for both down into the driver in one ioctl. This is pretty much what we'll need to do to drive those 4k MST DP displays as well. The driver will then have to do its best to genlock the crtcs if the hardware doesn't do it fully. IIRC that's how we're going to have to do the MST stuff, ie. use the same clock source for both obviously, and try to start all the pipes as fast as possible so that the vblanks line up. And that's going to require more changes to our modesetting codepaths.
well, two problems: 1) it won't actually work (at least not without some overhaul of kms core and helpers).. encoder only has a single crtc ptr. And anyway, it is useful for the driver to differentiate between which pipe/mixer is primary and which is slave. The SLAVE_CRTC property essentially gives you that 2nd pointer you need. 2) still would be nice to be able to drive 4k displays from x11.. and for the most part there isn't much compelling reason for most ddx's to migrate to atomic ioctl.
BR, -R
So, I don't see a need for any SLAVE_CRTC properties or dynamic remapping of resources. The latter would get nasty when the resources (eg. planes) aren't uniform anyway. Just let userspace figure it out.
-- Ville Syrjälä Intel OTC
On Tue, Apr 01, 2014 at 10:22:07AM -0400, Rob Clark wrote:
On Tue, Apr 1, 2014 at 10:12 AM, Ville Syrjälä ville.syrjala@linux.intel.com wrote:
On Tue, Apr 01, 2014 at 09:54:40AM -0400, Rob Clark wrote:
On Tue, Apr 1, 2014 at 9:40 AM, Daniel Vetter daniel@ffwll.ch wrote:
On Tue, Apr 01, 2014 at 08:40:54AM -0400, Rob Clark wrote:
No, not really. I was just trying to get away with pushing some complexity (for case #1) up to userspace instead of doing it in the kernel.
To clarify: I don't think it makes sense to fully abstract this away in the kernel, especially if userspace needs to be aware of the boundary between the crtcs so that it can correctly tile up the logical frambuffer. But I'm not sure whether trying to make that possible with a generic userspace driver is sensible, or whether having a bit of magic glue code in the ddx/wayland/hwc part for e.g. msm is the better option, at least in the short term.
Since if the set of useable planes actually changes we need to push that decision up the stack even further like wayland/hwc currently allow, and maybe there's some things we need to fix at that layer first. Once we've learned that lesson we can push things down again and add a neat little generic kernel interface. At least thus far we've always done a bit of prototyping with driver-specific code to learn a few lessons, e.g. the various pieces of non-standard plane/overlay in i915.
right, things like 'STATUS' property for returning per-object status would start as driver custom. (And even 'SLAVE_CRTC'..) Userspace could look for certain property names in the same way that it looks for certain gl extension strings. But should be semi-standardized, so other drivers which need the same thing should use same property names/values/behaviors as much as possible.. which was the point for starting the thread ;-)
What's the problem with just using two crtcs? With the atomic API you just shovel the state for both down into the driver in one ioctl. This is pretty much what we'll need to do to drive those 4k MST DP displays as well. The driver will then have to do its best to genlock the crtcs if the hardware doesn't do it fully. IIRC that's how we're going to have to do the MST stuff, ie. use the same clock source for both obviously, and try to start all the pipes as fast as possible so that the vblanks line up. And that's going to require more changes to our modesetting codepaths.
well, two problems:
- it won't actually work (at least not without some overhaul of kms
core and helpers).. encoder only has a single crtc ptr. And anyway, it is useful for the driver to differentiate between which pipe/mixer is primary and which is slave.
What does primary/slave mean here? That seems like a rather hardware specific notion.
The SLAVE_CRTC property essentially gives you that 2nd pointer you need.
Would seem easier to add the pointer. Or even better: just expose the display as two connectors and then you don't have to change anything. It's just like having multiple displays positioned next to each other today.
- still would be nice to be able to drive 4k displays from x11.. and
for the most part there isn't much compelling reason for most ddx's to migrate to atomic ioctl.
Someone might argue that 4k support is a compelling reason ;)
On Tue, Apr 1, 2014 at 10:42 AM, Ville Syrjälä ville.syrjala@linux.intel.com wrote:
On Tue, Apr 01, 2014 at 10:22:07AM -0400, Rob Clark wrote:
On Tue, Apr 1, 2014 at 10:12 AM, Ville Syrjälä ville.syrjala@linux.intel.com wrote:
On Tue, Apr 01, 2014 at 09:54:40AM -0400, Rob Clark wrote:
On Tue, Apr 1, 2014 at 9:40 AM, Daniel Vetter daniel@ffwll.ch wrote:
On Tue, Apr 01, 2014 at 08:40:54AM -0400, Rob Clark wrote:
No, not really. I was just trying to get away with pushing some complexity (for case #1) up to userspace instead of doing it in the kernel.
To clarify: I don't think it makes sense to fully abstract this away in the kernel, especially if userspace needs to be aware of the boundary between the crtcs so that it can correctly tile up the logical frambuffer. But I'm not sure whether trying to make that possible with a generic userspace driver is sensible, or whether having a bit of magic glue code in the ddx/wayland/hwc part for e.g. msm is the better option, at least in the short term.
Since if the set of useable planes actually changes we need to push that decision up the stack even further like wayland/hwc currently allow, and maybe there's some things we need to fix at that layer first. Once we've learned that lesson we can push things down again and add a neat little generic kernel interface. At least thus far we've always done a bit of prototyping with driver-specific code to learn a few lessons, e.g. the various pieces of non-standard plane/overlay in i915.
right, things like 'STATUS' property for returning per-object status would start as driver custom. (And even 'SLAVE_CRTC'..) Userspace could look for certain property names in the same way that it looks for certain gl extension strings. But should be semi-standardized, so other drivers which need the same thing should use same property names/values/behaviors as much as possible.. which was the point for starting the thread ;-)
What's the problem with just using two crtcs? With the atomic API you just shovel the state for both down into the driver in one ioctl. This is pretty much what we'll need to do to drive those 4k MST DP displays as well. The driver will then have to do its best to genlock the crtcs if the hardware doesn't do it fully. IIRC that's how we're going to have to do the MST stuff, ie. use the same clock source for both obviously, and try to start all the pipes as fast as possible so that the vblanks line up. And that's going to require more changes to our modesetting codepaths.
well, two problems:
- it won't actually work (at least not without some overhaul of kms
core and helpers).. encoder only has a single crtc ptr. And anyway, it is useful for the driver to differentiate between which pipe/mixer is primary and which is slave.
What does primary/slave mean here? That seems like a rather hardware specific notion.
it could be.. you might need to configure the mixers differently (like setting a MERGE bit/bitfield in one of them).
But it seems easier for a driver to ignore that differentiation if it doesn't have to care about it, than the other way around
The SLAVE_CRTC property essentially gives you that 2nd pointer you need.
Would seem easier to add the pointer. Or even better: just expose the display as two connectors and then you don't have to change anything. It's just like having multiple displays positioned next to each other today.
this is specifically for the case where you have two crtcs, one encoder. I don't want to make the driver jump through hoops with a dummy encoder/connector for this..
- still would be nice to be able to drive 4k displays from x11.. and
for the most part there isn't much compelling reason for most ddx's to migrate to atomic ioctl.
Someone might argue that 4k support is a compelling reason ;)
well, yeah, we could put an semi-artificial restriction like that to force people to move to the new ioctl. But I'd rather not.
BR, -R
-- Ville Syrjälä Intel OTC
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Rob Clark -
Ville Syrjälä