RandR (etc) DriverFunc

[Egbert Eich]

Thomas Winischhofer writes:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1
 > 
 > Egbert Eich wrote:
 > | Andy Ritger writes:
 > |  >
 > |  > Sorry I didn't get a chance to respond to this yesterday, Thomas
 > |  > and Egbert.
 > |  >
 > |  > This is a good point, Thomas.
 > |  >
 > |  > In the SetConfig case, it's nice for the driver to be notified
 > |  > when the size is changed, even if the rotation is not changing (eg,
 > |  > to reallocate vidmem for the root window's new resolution), though
 > |  > I'd say it's not crucial (atleast for the NVIDIA driver).
 > |
 > | Hm, when we change the size we call setMode() in the driver
 > | anyway. Doesn't this suffice?
 > | Currently we don't reallocate vidmem as we don't ever change the
 > | size of the video memory. This is not really supported in our
 > | model. This shortcoming needs to be resolved when reworking the
 > | driver.
 > 
 > 
 > While we are at it (size, namely):
 > 
 > I would love a driver-callback to set the "initial" randr size after
 > screeninit().
 > 
 > Currently, RandR is initialized after the driver's ScreenInit(). So the
 > driver MUST return the real virtual sizes when exiting from ScreenInit()
 > in order to make the server allocate the (correct) maximum root window size.
 > 
 > So the server always starts with size #0 (as seen through
 > xrandr-semantics). However, there is no way to start the server with
 > size #1.
 > 
 > What would that be good for?
 > 
 > Simple: I would like to be able to start the server in MergedFB
 > (TwinView) mode, but with only one head attached and a clone-mode as the
 > startup mode, and then let the user attach (or switch on) the second
 > head, switch to a non-clone mode and thereby - essentially - switch from
 > single-head to dual-head operation.
 > 
 > Currently this is impossible because there is no way to issue a
 > RandR-resize from within the driver after ScreenInit() but before
 > quitting InitOutput(). The RandR part would be server-side only (hence
 > pretty simple) because the server is in the setup-phase where no clients
 > need to be notified.
 > 
 > Hence, I need
 > 
 > 1) a call-back which is called AFTER xf86RandRInit() in Initoutput() in
 > order to issue a resize (to the startup mode-size) at this point,
 > 
 > 2) a RandR-symbol accessible from the driver to actually issue a resize.
 > 
 > Comments?
 > 

This gets ugly. You are suggesting to change the root window size
(ie double it) and share this root window between two different
displays (which have a different viewport).
I don't know if this works well. As I read randr it is tightly coupled
to the mode setting on a head. That means root_window_size == mode_size.
One needs to see how this semantics can be extended. Let me think about
how this can be done - without adding another wart to an extension
which is already not doing exactly what we want.

Cheers,
	Egbert.