dix/gpu: remove asserts for output/offload from same slave

We should have no problem allowing output/offload from the same slave,
I asserted here, but in order to implement reverse optimus this makes
perfect sense. (reverse optimus is intel outputting to nvidia).

Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit f0d0d75bfe62553dde353f89e46ff13dd863fbe8)
xf86crtc: don't use scrn->display for gpu screens

scrn->display is a property of the main screen really, and we don't
want to have the GPU screens use it for anything when picking modes
or a front buffer size.

This fixes a bug where when you plugged a display link device, it
would try and allocate a screen the same size as the current running
one (3360x1050 in this case), which was too big for the device. Avoid
doing this and just pick sizes based on whats plugged into this device.

Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 16077b81c502e04d77f81f683e0c213b9fe75393)
dix: allow pixmap dirty helper to be used for non-shared pixmaps

this allows the pixmap dirty helper to be used for reverse optimus,
where the GPU wants to copy from the shared pixmap to its VRAM copy.

[airlied: slave_dst is wrong name now but pointless ABI churn at this point]
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit 8fcb9d91b69abc72ddef31b9f2e8585580c6cad2)
gpu: call CreateScreenResources for GPU screens

I didn't think we needed this before, but after doing some more
work with reverse optimus it seems like it should be called.

Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
(cherry picked from commit f2fd8ec3725a61abbc831f0a9ec28fa2b7020c47)
xfree86: don't enable anything in xf86InitialConfiguration for GPU screens

There's no point in turning on outputs connected to GPU screens during initial
configuration.  Not only does this cause them to just display black, it also
confuses clients when these screens are attached to a master screen and RandR
reports that the outputs are already on.

Also, don't print the warning about no outputs being found on GPU screens,
since that's expected.

Signed-off-by: Aaron Plattner <aplattner@nvidia.com>
Reviewed-by: Dave Airlie <airlied@gmail.com>
(cherry picked from commit dbfeaf70623a83e1a3f3255c94d52e0e04702837)