RandR (etc) DriverFunc

[Thomas Winischhofer]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Egbert Eich wrote:
| Thomas Winischhofer writes:
|  > No, you misunderstood me.
|  >
|  > To make it simpler, forget MergedFB mode. Think single head:
|  >
|  > 1) User starts X with virtual screen 1280x1024, and modes 1280x1024,
|  > 1024x768.
|  >
|  > 2) User executes xrandr -s 1 and thereby switches to 1024x768.
|  >
|  > What I want is a way to do that second step during server start, ie not
|  > always start with size #0, but - for example - size #1. The root window
|  > size is always the same, 1280x1024. Just issue a RandR-resize from
|  > within the driver before clients can connect.
|  >
|  > The example in my previous mail was one practical application of this
|  > facility. RandR works execellently with MergedFB already (INCLUDING
|  > xinerama and with non-rectangular layouts).
|  >
|
| How do you deetermine the size with which you want to start?


Either by an option, or by using the largest mode the device supports.
But this is a secondary question.


| Currently you can do this with the order of the modes names in
| the screen section.


Since this is most useful in MergedFB/Twinview mode, I have my MetaModes
anyway. But again, configuration is secondary.


| If you don't have such an order it starts
| with the highest resoltuion because that's (without randr) the
| size of the root window and you don't get panning.


Normally, the server starts with the *first* display mode named in the
Display section, but with the *maximum* virtual (root window) size. So
far, so good.


| But I see now what you mean: since we need to determine the stride
| of the framebuffer at startup time we need to know what the largest
| mode may be. Then we could still choose a smaller one. With randr
| we get two idnependent parameters to configure.
| What I would like more is something where during every mode switch
| all parameters are recalculated - so that you don't have to preserve
| any state. That would allow you to get to every other mode no
| matter what your initial setup was.
| I don't think we can do this with the current driver model.


Exactly.


| I need to check.
| What you could try is to either make xf86RandrSetConfig() public
| and accessible from the driver or try to get the randr screen private
| and call it from there (*pScrPriv->rrSetConfig)(). The only thing
| that you won't get at then is the client notifiation.


After server start, I see no use for this. It's just for STARTING the
server in a different "size". Later, the server should not do this on
its own, but only on client requests. (Would be dangerous if server
could decide to initiate a resize as it can't know if the display
manager is RandR-aware).

I prefer making xf86RandRSetConfig public. "private" should really be
"private" - to RandR, that is. The driver should not (be able to) fiddle
with that structure.


| Depending if an randr aware client has already connected at that
| time you should be fine. I believe that the root window size gets
| changed from within xf86RandrSetConfig() (from reading the code
| very quickly) so any client that comes after that would be fine.


No, the root window size is constant during the server session. RandR
only changes the virtual screen dimensions.

And that's why my proposal is quite easy to implement:

In InitOutput(), add a driver call-back (via DriverFunc) AFTER
xf86RandRInit(). This call-back routine can call xf86RandRSetConfig
(after this symbol has become public), and you are done.

Again, the root window size does not matter in this scenario. It's all
about the virtual screen size.


| This however is a cludge - but with this you are in cludge paradise
| anyway.


I am not sure if this really is a cludge. The driver knows best about
display devices and their capabilities, so it should be able to
determine the ideal default. Of course, the user must be able to
override all this.

And as mentioned, this is a super and much demanded feature for
twinview, as it essentially allows "switching" from single- to dual head
operation during server runtime (without the need to live with massive
panning).

Thomas


- --
Thomas Winischhofer
Vienna/Austria
thomas AT winischhofer DOT net	       *** http://www.winischhofer.net
twini AT xfree86 DOT org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCOrNmzydIRAktyUcRAt6OAKC5zc+ah0lHRHQQrwn1F4kK9j4TlwCgxjvk
MlX/CscnN1AMlgRFvBFqTlc=
=1w1v
-----END PGP SIGNATURE-----