role of crtcs in modesetting interfaces and possible abstraction away from userspace

role of crtcs in modesetting interfaces and possible abstraction away from userspace

[Dave Airlie]

Hi,

So I've been attempting to hide the 30" Dell MST monitors in the
kernel, and ran into a number of problems,
but the major one is how to steal a crtc and get away with it.

The standard scenario I have is

CRTC 0: eDP monitor connected

hotplug 30" monitor, userspace decides to configure things as

CRTC 1: DP-4 - 30" monitor
CRTC 2: eDP-1

But since we lack atomic it does this in two steps, so when I get the
first modeset to set the 30" monitor up
I go and use CRTC-2 as the secondary crtc, as CRTC-0 is in use still,
then I have to fail the second modeset,
and things end up with me crying.

So this led me to wonder why we expose CRTCs at all, and KMS does it
because randr did it, but I've no idea
why randr did it (Keith??).

>From my POV I don't think the modesetting interface needs to take
crtcs, just connectors and modes,
so I'm wondering going forward for atomic should we even accept crtcs
in the interface, just a list of rectangles,
connectors per rectangle, etc.

Now I'm at the point of trying to work out if I can make DP MST
monitors a possibility before we get atomic,

Myself and Ben discussed this here and he suggested we should make the
userspace crtc ids pretty much
meaningless and not have them tied to actual hw crtcs, so we can
reroute things underneath userspace
without changing it.

Any input is welcome!

Dave.

Re: role of crtcs in modesetting interfaces and possible abstraction away from userspace

[Keith Packard]

[-- Attachment #1.1: Type: text/plain, Size: 5419 bytes --]

Dave Airlie <airlied@gmail.com> writes:

> Hi,
>
> So I've been attempting to hide the 30" Dell MST monitors in the
> kernel, and ran into a number of problems,
> but the major one is how to steal a crtc and get away with it.
>
> The standard scenario I have is
>
> CRTC 0: eDP monitor connected
>
> hotplug 30" monitor, userspace decides to configure things as
>
> CRTC 1: DP-4 - 30" monitor
> CRTC 2: eDP-1
>
> But since we lack atomic it does this in two steps, so when I get the
> first modeset to set the 30" monitor up
> I go and use CRTC-2 as the secondary crtc, as CRTC-0 is in use still,
> then I have to fail the second modeset,
> and things end up with me crying.
>
> So this led me to wonder why we expose CRTCs at all, and KMS does it
> because randr did it, but I've no idea
> why randr did it (Keith??).

Mostly because X has almost always exposed the hardware at as low a
level as possible and left clients to sort things out. Given that we had
no experience with this whole structure before RandR got implemented,
and that we've been running like this for eight years without terrible
trouble, it doesn't seem like an utter failure...

For this particular issue, we've got two choices:

 1) Describe the situation through the protocol and let applications
     sort it out

 2) Hide physical CRTCs from applications and create virtual CRTCs
    for applications.

One reason for exposing physical CRTCs to applications is to let them
figure out the full allocation plan before starting the process, so as
to minimize screen flicker given an API which doesn't let you specify
the whole configuration in one go.

If we hide them, then the kernel may need to shut down monitors while it
shuffles things around to match application requests.

> From my POV I don't think the modesetting interface needs to take
> crtcs, just connectors and modes,

I'm fine with making the X server need to be smarter about kernel CRTC
allocation, pushing the problem out of the kernel and up into the window
system. That seems like the simplest change in the kernel API to me.

Making X hide real CRTCs from clients seems like a fairly simple plan;
that would also offer us an opportunity to add 'virtual' CRTCs for use
by VNC or other software-defined display surfaces.

> so I'm wondering going forward for atomic should we even accept crtcs
> in the interface, just a list of rectangles,
> connectors per rectangle, etc.

Having a list of CRTCs means that the application would have a chance of
figuring out some of the impossible configurations before asking the
kernel; you couldn't light up two single-link monitors and a double-link
monitor if you only had three CRTCs.

> Now I'm at the point of trying to work out if I can make DP MST
> monitors a possibility before we get atomic,

I think fixing X to hide the physical CRTCs and only advertise virtual
ones should be pretty easy to manage; that would leave the kernel API
alone, at least for now.

> Ben and I discussed this here and he suggested we should make the
> userspace crtc ids pretty much meaningless and not have them tied to
> actual hw crtcs, so we can reroute things underneath userspace without
> changing it.

It's clear that we need this kind of redirection at some level in the
stack; what's unclear to me is whether this should be done in the kernel
or up in userspace.

With atomic mode setting in the kernel, I think you're probably right in
proposing to eliminate explicit CRTC allocation from that. I do think
you'll want to indicate the number of available CRTCs in the display
engine, and the number of CRTCs each monitor consumes. Do you know if
there are some of these monitors that can display lower resolution modes
with only a single CRTC? Or is the hardware so separate that you end up
always using multiple CRTCs to drive them?

For the current incremental mode setting API, I think it'd work either
way.

Pushing the problem out to user space is always tempting, and I don't
think it would be hard to teach the X server to manage this. That would
also eliminate the need to construct fake EDID data within the kernel;
the X server could do whatever it liked in building suitable video mode
lists given complete information about the monitor. Plus, I can see how
we'd offer an atomic RandR request that could operate on top of the
current API while minimizing flashing. Hiding CRTCs from the X server
would make this difficult, as the kernel wouldn't have the full set of
configuration information available without the atomic mode kernel API.

Solving this in the kernel would make the X piece simpler, although the
kernel would now be constructing fake EDID data to advertise the
combined set of modes up to X, and you'd end up with more flashing if
the kernel allocated the 'wrong' CRTC to any of the displays and needed
to disable/re-enable things to get a new configuration working.

Without RandR additions, the two solutions are effectively identical.
Somewhere you have to guess which CRTCs to use during incremental mode
setting, and sometimes you're just going to guess wrong and have to
correct that later on.

I'd pick whichever was simpler to implement and expect this to all be
resolved in the glorious atomic mode setting future we've been promised
for so long.

-- 
keith.packard@intel.com

[-- Attachment #1.2: Type: application/pgp-signature, Size: 810 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: role of crtcs in modesetting interfaces and possible abstraction away from userspace

[Dave Airlie]

On 9 September 2014 10:43, Dave Airlie <airlied@gmail.com> wrote:
> Hi,
>
> So I've been attempting to hide the 30" Dell MST monitors in the
> kernel, and ran into a number of problems,
> but the major one is how to steal a crtc and get away with it.
>
> The standard scenario I have is
>
> CRTC 0: eDP monitor connected
>
> hotplug 30" monitor, userspace decides to configure things as
>
> CRTC 1: DP-4 - 30" monitor
> CRTC 2: eDP-1
>
> But since we lack atomic it does this in two steps, so when I get the
> first modeset to set the 30" monitor up
> I go and use CRTC-2 as the secondary crtc, as CRTC-0 is in use still,
> then I have to fail the second modeset,
> and things end up with me crying.
>
> So this led me to wonder why we expose CRTCs at all, and KMS does it
> because randr did it, but I've no idea
> why randr did it (Keith??).
>
> From my POV I don't think the modesetting interface needs to take
> crtcs, just connectors and modes,
> so I'm wondering going forward for atomic should we even accept crtcs
> in the interface, just a list of rectangles,
> connectors per rectangle, etc.
>
> Now I'm at the point of trying to work out if I can make DP MST
> monitors a possibility before we get atomic,
>
> Myself and Ben discussed this here and he suggested we should make the
> userspace crtc ids pretty much
> meaningless and not have them tied to actual hw crtcs, so we can
> reroute things underneath userspace
> without changing it.

The only caveat we came up with is due to page_flip requiring indices
we can't probably move things around as much as I'd like,

I'm not sure if we have same problems further up!

Dave.

Re: role of crtcs in modesetting interfaces and possible abstraction away from userspace

[Ville Syrjälä]

On Tue, Sep 09, 2014 at 10:43:35AM +1000, Dave Airlie wrote:
> Hi,
> 
> So I've been attempting to hide the 30" Dell MST monitors in the
> kernel, and ran into a number of problems,
> but the major one is how to steal a crtc and get away with it.
> 
> The standard scenario I have is
> 
> CRTC 0: eDP monitor connected
> 
> hotplug 30" monitor, userspace decides to configure things as
> 
> CRTC 1: DP-4 - 30" monitor
> CRTC 2: eDP-1
> 
> But since we lack atomic it does this in two steps, so when I get the
> first modeset to set the 30" monitor up
> I go and use CRTC-2 as the secondary crtc, as CRTC-0 is in use still,
> then I have to fail the second modeset,
> and things end up with me crying.
> 
> So this led me to wonder why we expose CRTCs at all, and KMS does it
> because randr did it, but I've no idea
> why randr did it (Keith??).
> 
> >From my POV I don't think the modesetting interface needs to take
> crtcs, just connectors and modes,
> so I'm wondering going forward for atomic should we even accept crtcs
> in the interface, just a list of rectangles,
> connectors per rectangle, etc.

Not all CRTCs are created equal so the user probably wants know what
features to expect from a particular CRTC. Now, often that may have
something to do with the planes, but there are other hardware features
that we want to expose as CRTC properties. If we make all CRTCs appear
uniform to userspace the user may not know beforehand that certain
features can only be used on a subset of CRTCs. Also if the driver
would initially pick the wrong CRTC, and later the user would enable
one of those special features, we'd have to do a full modeset to switch
hardware CRTCs which would mean a nasty screen blink for the user.

So no, I don't think this is a good idea given real world hardware
constraints.

-- 
Ville Syrjälä
Intel OTC

Re: role of crtcs in modesetting interfaces and possible abstraction away from userspace

[Rob Clark]

On Tue, Sep 9, 2014 at 4:16 AM, Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
> On Tue, Sep 09, 2014 at 10:43:35AM +1000, Dave Airlie wrote:
>> Hi,
>>
>> So I've been attempting to hide the 30" Dell MST monitors in the
>> kernel, and ran into a number of problems,
>> but the major one is how to steal a crtc and get away with it.
>>
>> The standard scenario I have is
>>
>> CRTC 0: eDP monitor connected
>>
>> hotplug 30" monitor, userspace decides to configure things as
>>
>> CRTC 1: DP-4 - 30" monitor
>> CRTC 2: eDP-1
>>
>> But since we lack atomic it does this in two steps, so when I get the
>> first modeset to set the 30" monitor up
>> I go and use CRTC-2 as the secondary crtc, as CRTC-0 is in use still,
>> then I have to fail the second modeset,
>> and things end up with me crying.
>>
>> So this led me to wonder why we expose CRTCs at all, and KMS does it
>> because randr did it, but I've no idea
>> why randr did it (Keith??).
>>
>> >From my POV I don't think the modesetting interface needs to take
>> crtcs, just connectors and modes,
>> so I'm wondering going forward for atomic should we even accept crtcs
>> in the interface, just a list of rectangles,
>> connectors per rectangle, etc.
>
> Not all CRTCs are created equal so the user probably wants know what
> features to expect from a particular CRTC. Now, often that may have
> something to do with the planes, but there are other hardware features
> that we want to expose as CRTC properties. If we make all CRTCs appear
> uniform to userspace the user may not know beforehand that certain
> features can only be used on a subset of CRTCs. Also if the driver
> would initially pick the wrong CRTC, and later the user would enable
> one of those special features, we'd have to do a full modeset to switch
> hardware CRTCs which would mean a nasty screen blink for the user.

first off, I tend to think with the trend towards various different
wayland compositors doing kms directly, making it easier for userspace
sounds pretty attractive.  Ie. would you rather fix a bug w/ picking
the right crtc for the job in N compositors, or 1 kernel driver?

But that said, it seems like the real problem w/ kernel picking the
right crtc is going to be with non-atomic modeset.  And for pre-atomic
(future legacy) xrandr, I'm not entirely sure how userspace is
supposed to do a better job at this than the kernel could.  It would
also need up front knowledge of all the modes that would be picked.
So you've just pushed non-atomic suck in the kernel to non-atomic suck
in x11.  Doesn't sound like that fixes anything.

But, I think there is maybe a way to have our cake and eat it too.. to
leave extra flexibility for highly customized/specialized userspace,
we could just allow for some PICK_ANY_CRTC_FOR_ME type value which
would let 99% of userspace push the decision to the kernel, while
still allowing for the special cases where userspace knows better.

BR,
-R

> So no, I don't think this is a good idea given real world hardware
> constraints.
>
> --
> Ville Syrjälä
> Intel OTC
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: role of crtcs in modesetting interfaces and possible abstraction away from userspace

[Aaron Plattner]

On 09/08/2014 11:37 PM, Keith Packard wrote:
> With atomic mode setting in the kernel, I think you're probably right in
> proposing to eliminate explicit CRTC allocation from that. I do think
> you'll want to indicate the number of available CRTCs in the display
> engine, and the number of CRTCs each monitor consumes. Do you know if
> there are some of these monitors that can display lower resolution modes
> with only a single CRTC? Or is the hardware so separate that you end up
> always using multiple CRTCs to drive them?

The one I tried definitely can; indeed it has to because the VBIOS 
doesn't know how to set up MST and drives the port in DP 1.1 mode.  I'm 
sure someone will build a monitor that only turns on half of the display 
if you do that, but I'd be kind of surprised if someone made one that 
just doesn't work if you use a DP 1.1-only GPU.

-- 
Aaron

Re: role of crtcs in modesetting interfaces and possible abstraction away from userspace

[Ville Syrjälä]

On Tue, Sep 09, 2014 at 07:22:49PM -0400, Rob Clark wrote:
> On Tue, Sep 9, 2014 at 4:16 AM, Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> > On Tue, Sep 09, 2014 at 10:43:35AM +1000, Dave Airlie wrote:
> >> Hi,
> >>
> >> So I've been attempting to hide the 30" Dell MST monitors in the
> >> kernel, and ran into a number of problems,
> >> but the major one is how to steal a crtc and get away with it.
> >>
> >> The standard scenario I have is
> >>
> >> CRTC 0: eDP monitor connected
> >>
> >> hotplug 30" monitor, userspace decides to configure things as
> >>
> >> CRTC 1: DP-4 - 30" monitor
> >> CRTC 2: eDP-1
> >>
> >> But since we lack atomic it does this in two steps, so when I get the
> >> first modeset to set the 30" monitor up
> >> I go and use CRTC-2 as the secondary crtc, as CRTC-0 is in use still,
> >> then I have to fail the second modeset,
> >> and things end up with me crying.
> >>
> >> So this led me to wonder why we expose CRTCs at all, and KMS does it
> >> because randr did it, but I've no idea
> >> why randr did it (Keith??).
> >>
> >> >From my POV I don't think the modesetting interface needs to take
> >> crtcs, just connectors and modes,
> >> so I'm wondering going forward for atomic should we even accept crtcs
> >> in the interface, just a list of rectangles,
> >> connectors per rectangle, etc.
> >
> > Not all CRTCs are created equal so the user probably wants know what
> > features to expect from a particular CRTC. Now, often that may have
> > something to do with the planes, but there are other hardware features
> > that we want to expose as CRTC properties. If we make all CRTCs appear
> > uniform to userspace the user may not know beforehand that certain
> > features can only be used on a subset of CRTCs. Also if the driver
> > would initially pick the wrong CRTC, and later the user would enable
> > one of those special features, we'd have to do a full modeset to switch
> > hardware CRTCs which would mean a nasty screen blink for the user.
> 
> first off, I tend to think with the trend towards various different
> wayland compositors doing kms directly, making it easier for userspace
> sounds pretty attractive.  Ie. would you rather fix a bug w/ picking
> the right crtc for the job in N compositors, or 1 kernel driver?
> 
> But that said, it seems like the real problem w/ kernel picking the
> right crtc is going to be with non-atomic modeset.  And for pre-atomic
> (future legacy) xrandr, I'm not entirely sure how userspace is
> supposed to do a better job at this than the kernel could.  It would
> also need up front knowledge of all the modes that would be picked.
> So you've just pushed non-atomic suck in the kernel to non-atomic suck
> in x11.  Doesn't sound like that fixes anything.

I disagree. User space can be in a much better position to pick the
crtc, especially in more product oriented scenarios. Eg. a tablet/phone
where user space knows that it should use the more capable crtc for the
internal display and less capable one for the external display. The
reason for this could be that it will be presenting video in a window
on the internal display and fullscreen on the external display.

> 
> But, I think there is maybe a way to have our cake and eat it too.. to
> leave extra flexibility for highly customized/specialized userspace,
> we could just allow for some PICK_ANY_CRTC_FOR_ME type value which
> would let 99% of userspace push the decision to the kernel, while
> still allowing for the special cases where userspace knows better.

Then you get to figure out how to deal with all/some of the properties
effectively changing values when the crtc changes. I guess you could
just specifiy that this will happen and it's up to userspace to provide
the full state if it wants to avoid unexpected property values.

-- 
Ville Syrjälä
Intel OTC

Re: role of crtcs in modesetting interfaces and possible abstraction away from userspace

[Rob Clark]

On Wed, Sep 10, 2014 at 4:20 AM, Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
> On Tue, Sep 09, 2014 at 07:22:49PM -0400, Rob Clark wrote:
>> On Tue, Sep 9, 2014 at 4:16 AM, Ville Syrjälä
>> <ville.syrjala@linux.intel.com> wrote:
>> > On Tue, Sep 09, 2014 at 10:43:35AM +1000, Dave Airlie wrote:
>> >> Hi,
>> >>
>> >> So I've been attempting to hide the 30" Dell MST monitors in the
>> >> kernel, and ran into a number of problems,
>> >> but the major one is how to steal a crtc and get away with it.
>> >>
>> >> The standard scenario I have is
>> >>
>> >> CRTC 0: eDP monitor connected
>> >>
>> >> hotplug 30" monitor, userspace decides to configure things as
>> >>
>> >> CRTC 1: DP-4 - 30" monitor
>> >> CRTC 2: eDP-1
>> >>
>> >> But since we lack atomic it does this in two steps, so when I get the
>> >> first modeset to set the 30" monitor up
>> >> I go and use CRTC-2 as the secondary crtc, as CRTC-0 is in use still,
>> >> then I have to fail the second modeset,
>> >> and things end up with me crying.
>> >>
>> >> So this led me to wonder why we expose CRTCs at all, and KMS does it
>> >> because randr did it, but I've no idea
>> >> why randr did it (Keith??).
>> >>
>> >> >From my POV I don't think the modesetting interface needs to take
>> >> crtcs, just connectors and modes,
>> >> so I'm wondering going forward for atomic should we even accept crtcs
>> >> in the interface, just a list of rectangles,
>> >> connectors per rectangle, etc.
>> >
>> > Not all CRTCs are created equal so the user probably wants know what
>> > features to expect from a particular CRTC. Now, often that may have
>> > something to do with the planes, but there are other hardware features
>> > that we want to expose as CRTC properties. If we make all CRTCs appear
>> > uniform to userspace the user may not know beforehand that certain
>> > features can only be used on a subset of CRTCs. Also if the driver
>> > would initially pick the wrong CRTC, and later the user would enable
>> > one of those special features, we'd have to do a full modeset to switch
>> > hardware CRTCs which would mean a nasty screen blink for the user.
>>
>> first off, I tend to think with the trend towards various different
>> wayland compositors doing kms directly, making it easier for userspace
>> sounds pretty attractive.  Ie. would you rather fix a bug w/ picking
>> the right crtc for the job in N compositors, or 1 kernel driver?
>>
>> But that said, it seems like the real problem w/ kernel picking the
>> right crtc is going to be with non-atomic modeset.  And for pre-atomic
>> (future legacy) xrandr, I'm not entirely sure how userspace is
>> supposed to do a better job at this than the kernel could.  It would
>> also need up front knowledge of all the modes that would be picked.
>> So you've just pushed non-atomic suck in the kernel to non-atomic suck
>> in x11.  Doesn't sound like that fixes anything.
>
> I disagree. User space can be in a much better position to pick the
> crtc, especially in more product oriented scenarios. Eg. a tablet/phone
> where user space knows that it should use the more capable crtc for the
> internal display and less capable one for the external display. The
> reason for this could be that it will be presenting video in a window
> on the internal display and fullscreen on the external display.

Sure, but this is a pretty special case from an upstream perspective.
But giving userspace the choice of picking explicitly or letting
kernel pick, I think we can accommodate both the weird special cases,
as well as the common case.

Not quite sure how it would work from atomic ioctl standpoint, where
userspace needs to set (potentially) multiple properties on several
unchosen crtc's, but I think we could have userspace pick virtual crtc
id's, ie.

  #define VIRT_CRTC 0x40000000

then user uses (VIRT_CRTC | 1), (VIRT_CRTC | 2), and so on.. then
kernel somehow resolves those into actual crtc id's..

>>
>> But, I think there is maybe a way to have our cake and eat it too.. to
>> leave extra flexibility for highly customized/specialized userspace,
>> we could just allow for some PICK_ANY_CRTC_FOR_ME type value which
>> would let 99% of userspace push the decision to the kernel, while
>> still allowing for the special cases where userspace knows better.
>
> Then you get to figure out how to deal with all/some of the properties
> effectively changing values when the crtc changes. I guess you could
> just specifiy that this will happen and it's up to userspace to provide
> the full state if it wants to avoid unexpected property values.

Well, we still need to define what the semantics are for unspecified
property values, esp. if different ctrc's had different properties.  I
think "preserve" for pageflip and "reset to default" for modeset would
be the sane choice, although it is a bit awkward with both crammed
into the same ioctl.  Probably we end up adding a flag to control the
behaviour.

But yeah, playing switch-a-roo under the hood, we have to sort out
those details.  But at least it would happen only at modeset where
userspace probably wants to use the hypothetical
RESET_UNSPECIFIED_TO_DEFAULT flag..

BR,
-R


> --
> Ville Syrjälä
> Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: role of crtcs in modesetting interfaces and possible abstraction away from userspace

[David Herrmann]

Hi

On Tue, Sep 9, 2014 at 10:16 AM, Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
> On Tue, Sep 09, 2014 at 10:43:35AM +1000, Dave Airlie wrote:
>> From my POV I don't think the modesetting interface needs to take
>> crtcs, just connectors and modes,
>> so I'm wondering going forward for atomic should we even accept crtcs
>> in the interface, just a list of rectangles,
>> connectors per rectangle, etc.
>
> Not all CRTCs are created equal so the user probably wants know what
> features to expect from a particular CRTC. Now, often that may have
> something to do with the planes, but there are other hardware features
> that we want to expose as CRTC properties. If we make all CRTCs appear
> uniform to userspace the user may not know beforehand that certain
> features can only be used on a subset of CRTCs. Also if the driver
> would initially pick the wrong CRTC, and later the user would enable
> one of those special features, we'd have to do a full modeset to switch
> hardware CRTCs which would mean a nasty screen blink for the user.

I agree with Ville here. For generic DRM usage, it's irrelevant which
CRTC is used, but for special use-cases you want more capable CRTCs
for the display you use for compositing. Sure, this might be solved
with simple "hints" you pass to the kernel, but those hints pretty
soon become what we now have as CRTCs. And re-configuration requires
expensive deep modesets so cannot be done on-the-fly by the kernel
once user-space allocates resources for a given output.

However, the way we pick CRTCs and encoders today is already
problematic. If you write gpu-specific drivers, you know the hardware
perfectly, but generic drivers already need to do trial-and-error.
Especially, if you want "clone" mode, you have no control which
encoder is picked by the kernel, so you don't know which one is left
after the first mode-set, so you cannot know which CRTCs are available
for the other connectors.
No driver exposed such restricted and backwards interfaces so far, and
the CRTC->encoder->connector graph is almost always a tree. But you
can't be sure, if you write generic drivers.. so for all stuff I did
so far, I already use "connectors" as primary objects and re-evaluate
after each single modeset. So it wouldn't change much if CRTCs aren't
exposed at all.

I also agree with Keith: Somewhere in the stack, there has to be a
layer that adds "screens", which are possibly composed of multiple
connectors. If we do this in user-space (like we all do so far), we
can support setups where multiple real displays are composed into a
single large screen *AND* setups, where one display is internally
represented by multiple displays. If we do it in the kernel, we might
possible require a second such layer in user-space..

Long story short: I'm totally fine with exposing split hardware as
multiple connectors..

Thanks
David
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: role of crtcs in modesetting interfaces and possible abstraction away from userspace

[Alex Deucher]

On Mon, Sep 8, 2014 at 8:43 PM, Dave Airlie <airlied@gmail.com> wrote:
> Hi,
>
> So I've been attempting to hide the 30" Dell MST monitors in the
> kernel, and ran into a number of problems,
> but the major one is how to steal a crtc and get away with it.
>
> The standard scenario I have is
>
> CRTC 0: eDP monitor connected
>
> hotplug 30" monitor, userspace decides to configure things as
>
> CRTC 1: DP-4 - 30" monitor
> CRTC 2: eDP-1
>
> But since we lack atomic it does this in two steps, so when I get the
> first modeset to set the 30" monitor up
> I go and use CRTC-2 as the secondary crtc, as CRTC-0 is in use still,
> then I have to fail the second modeset,
> and things end up with me crying.
>
> So this led me to wonder why we expose CRTCs at all, and KMS does it
> because randr did it, but I've no idea
> why randr did it (Keith??).
>
> From my POV I don't think the modesetting interface needs to take
> crtcs, just connectors and modes,
> so I'm wondering going forward for atomic should we even accept crtcs
> in the interface, just a list of rectangles,
> connectors per rectangle, etc.
>
> Now I'm at the point of trying to work out if I can make DP MST
> monitors a possibility before we get atomic,
>
> Myself and Ben discussed this here and he suggested we should make the
> userspace crtc ids pretty much
> meaningless and not have them tied to actual hw crtcs, so we can
> reroute things underneath userspace
> without changing it.
>
> Any input is welcome!

What about exposing monitors as a modesetting object?  They could have
a required_crtc_num attribute or something like that.  I guess it's a
little late since we already did dynamic connectors for MST and I
guess it would be complicated to integrate cleanly with the way we do
things today.

E.g., you could have:

crtc -> encoder -> connector -> monitor

or

crtc -                                         -> monitor
        \                                      /
crtc -  --> encoder -> connector -> monitor
        /                                     \
crtc -                                        -> monitor

or

crtc -
        \
crtc -  --> encoder -> connector -> monitor


etc.

Alex