pull request: output slave

[Dave Airlie]

some comments inline, I've removed anything I agree with and have
fixed up patches

> (Hrm, would also be nice if this patch created provider objects for the
> screens so that we could test the protocol support here)

the ddx has to create them at CreateScreenResources time, just like
crtc/outputs, the startup ordering demands it :)



>
>>       dix/pixmap: track dirty pixmaps in server. (v3)
>
> There are bunch of spurious whitespace fixes in dix/pixmap.c
>
> Fails to check DamageCreate return value for NULL
>
> PixmapSyncDirtyHelper might be made faster by clipping to the
> dirty_region instead of iterating over the boxes in it?

I've added a comment for now to investigate this later.
>
> Setting SourceValidate to NULL is going to pick up the software cursor,
> I assume this is intentional? A comment might be nice here. Of course,
> a cleaner fix would be to just have the cursor code drive a cursor on
> the monitor separately; that way, we'd get hw cursors on the 'main'
> screen and only have a sw cursor on the output provider.

I'll spend some quality time with cursors again, every attempt at
doing anything else has hit some deep seated layering issues.

>
>>       randr: hook up output slave to screen resources return
>
> Calling RRModesForScreen twice is ugly, but it's probably less code than
> creating a separate function to compute the needed values.
>
> It seems like rrGetMultiScreenResources would work fine for screens
> without connected output providers. If so, please just replace the old
> function instead of copying it. It'll get more testing that way anyways.

I'll put this as a TODO, I've got to fix up the primary stuff for
multi-gpu first.
>
>>       randr: add output source setup
>
> Reviewed-by: Keith Packard <keithp at keithp.com>
>
>>       xf86: add output source setting callback
>
> Not sure you need to mess with the RootClip of the current master screen
> when disconnecting the output; you'll get a screen flash as a result.
>
> Otherwise:
>
> Reviewed-by: Keith Packard <keithp at keithp.com>
>
>>       xf86/cursor: fallback to sw cursor if we have slaves present.
>
> Would be better to draw the cursor on the slave than have it rendered to
> the master and copied to the slave? As you say, all providers can draw X stuff.

I've gone back and forward, and mostly there is layering and SIGIO
issues all over the place when I played with this seriously, so I
wanted to address it again in the future, but for now just do what
works best.

I'll resend, you can tack in r-b's for the cursor ones if you think
doing it later is best.

Dave.