VESA driver hack to support modes larger than the startup mode

[T. Perkins]

The goal:

  Use the VESA driver and start at a resolution of 1024x768 with a
  higher resolution being available using 'xrandr -s 1280x1024'.

  This matches what the VMware driver is able to do.

Why we want this:

  Our data center uses a "switch" that allows one physical monitor to
  be used with many rack mounted computers.

  The KVM switch (Keyboard Video Mouse switch) uses dongles to send
  the video signal over Cat5 cabling.  The dongles are connected in
  series and relay switches in each dongle are used to address a
  particular machine.

  Video bandwidth varies depending on the length of the cable (as
  controlled by the relays) and the solution does not support
  DDC/EDID.

  The VESA driver is preferred by us as it works with all machines and
  having the best video performance is not too important to us.

  The smaller resolution of 1024x768 is the best startup default as it
  works for machines that have the lowest video bandwidth.  This
  resolution must be manually configured in xorg.conf because a system
  with no xorg.conf will use the highest resolution it finds in the
  VESA BIOS (which for some hardware is much too large).

  We want to be able to 'xrandr -s 1280x1024' (and back to 1024x768)
  just to see if the higher resolution is OK (some machines have
  sufficient video bandwidth for this mode).  This quick test would be
  better that having to quit X and edit xorg.conf by hand.

  Some machines boot from the network (PXE) and have no permanent
  storage, so we can not edit xorg.conf one time and leave it that
  way.

The hoped for solution:

  From our xorg.conf:

    Modes "1024x768" "1280x1024"

  We had hoped that just adding a second mode would do the trick.

  Alas, the virtual display is calculated to accommodate the larger
  resolution and the machine starts in 1024x768 but it's a viewport
  into a virtual display of 1280x1024.  This is the documented
  behavior, but it'd not what we want.  Adding this:

    Virtual 1024 768

  Fixes the "viewport" problem, but the larger mode becomes
  unavailable (xrandr does not list it).  Also, xrandr can not be used
  to add it later as it errors with:

    "screen cannot be larger than 1024x768"

The attempted hack:

  We noticed that another driver behaved differently.  The VMware
  driver (in a virtual machine, forget about our KVM switch for now)
  will start at 1024x768 when configured in xorg.conf, but xrandr will
  list lots of larger modes (that we did not specify) and xrandr can
  be used to switch to them.

  Upon inspection of the VMware driver's source code, near the end of
  VMWAREScreenInit() (what ScreenInit() points to), we see in
  vmware.c:

     /*
      * We explicitly add a set of default modes because the X server will
      * not include modes larger than the initial one.
      */
    {
       unsigned int i;
       unsigned int numModes = sizeof (VMWAREDefaultModes) / sizeof *(VMWAREDefaultModes);
       char name[10];
       for (i = 0; i < numModes; i++) {
          const VMWAREDefaultMode *mode = &VMWAREDefaultModes[i];

          /* Only modes that fit the hardware maximums should be added.  */
          if (mode->width <= pVMWARE->maxWidth && mode->height <= pVMWARE->maxHeight) {
             snprintf(name, 10, "%dx%d", mode->width, mode->height);
             VMWAREAddDisplayMode(pScrn, name, mode->width, mode->height);
          }
       }
    }

  Since the VMware driver exhibits our desired behaviour (start at a
  lower rez and allow xrandr switching to a higher rez without virtual
  display viewport wierdness), we tried to hack that same idea into
  the VESA driver.

  Our hack (please see attached), successfully allows xrandr switching
  to the higher rez and the monitor's info panel confirms that the rez
  and timing are correct.

  The problem seems to be that the virtual display size is not being
  updated to match the higher resolution and appears to be stuck at
  the lower rez.  This results in an unhappy X display that looks like
  there is corrupt video memory in the areas outside the original
  resolution.

Assistance required:

  We are not skilled X hackers and it's nice that we've even been able
  to get this far without really knowing what we're doing...  :^)

  We are hoping that there is a way to get the virtual display size to
  update with the video mode change (a la the VMware driver).

  It would be great if someone could please explain how this might be
  done.  It's not clear to us why this is working for the VMware
  driver...

  Also, if we can get this working in the VESA driver, would this be
  acceptable (if given some polish vs. using one hard-coded mode) as a
  patch?  If the current behaviour is deemed to be desirable, maybe we
  could create a new VESA driver specific option that would cause the
  driver to add higher modes if specified?

  We like that X can run without a conf file these days, but if a conf
  file is being used, it would be nice to have the flexibility to
  start at a lower rez and still support switching to a higher rez
  (like our MS Windows machines).

Thanks for your consideration!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: add_vesa_mode.diff
Type: text/x-diff
Size: 4003 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20150702/712d81d8/attachment-0001.diff>