Back in XFree86 1.18, with the same hardware and monitor as now, using
the VESA driver, my system could run in 1600x1200 mode. The VESA driver actually worked better than the driver for my specific graphics hardware.

Unfortunately, ever since "upgrading" to 1.20, Driver "vesa" rejects
all modes above 640x480.

Comparing the log files, the differences that look central to this issue
(to me) are these:

Both match on the same modes initially:

1.18:[ 69.005] *Mode: 111 (640x480)
1.18:[ 69.014] *Mode: 114 (800x600)
1.18:[ 69.021] *Mode: 117 (1024x768)
1.18:[ 69.027] *Mode: 11a (1280x1024)
1.18:[ 69.031] *Mode: 11d (1600x1200)

1.20:[ 15884.546] *Mode: 111 (640x480)
1.20:[ 15884.553] *Mode: 114 (800x600)
1.20:[ 15884.557] *Mode: 117 (1024x768)
1.20:[ 15884.562] *Mode: 11a (1280x1024)
1.20:[ 15884.565] *Mode: 11d (1600x1200)

Version 1.18 was happy with all of them:
[ 69.040] (--) VESA(0): Virtual size is 1600x1200 (pitch 1600)
[ 69.040] (**) VESA(0): *Built-in mode "1600x1200"
[ 69.040] (**) VESA(0): Built-in mode "1280x1024"
[ 69.040] (**) VESA(0): Built-in mode "1024x768"
[ 69.040] (**) VESA(0): Built-in mode "800x600"
[ 69.040] (**) VESA(0): Built-in mode "640x480"

but 1.20.* isn't:
[ 15884.567] (II) VESA(0): Not using built-in mode "1600x1200" (no mode of this name)
[ 15884.567] (II) VESA(0): Not using built-in mode "1280x1024" (no mode of this name)
[ 15884.567] (II) VESA(0): Not using built-in mode "1024x768" (no mode of this name)
[ 15884.567] (II) VESA(0): Not using built-in mode "800x600" (no mode of this name)
[ 15884.582] (II) VESA(0): Virtual size is 640x480 (pitch 640)
[ 15884.582] (**) VESA(0): Built-in mode "640x480"

I've spent hours, both back in the day and yesterday, trying various
config file things to get it to work, with no success so far.

* I tried adding ModeLine entries (with distinctive names) in Section
"Monitor" and referenced those modes in Section "Screen" > SubSection
"Display" > Modes. The log shows "no mode of this name" for the modes
I defined, so it appears that Driver "vesa" ignores my Modeline entries.

* Similarly, I tried creating Section "Modes" with the Modeline entries
and UseModes in the Monitor section. As before, the log file shows no
indication of processing those Modeline entries.

* Combining the above with Option "DefaultModes" "no" in the Monitor
section also had no effect: the log file showed it continued to use its
built-in modes and ignored my Modeline modes. The man page says this
option requires RandR 1.2 or later. In case it's relevant, the log
files say:

1.18: [ 75.406] (==) RandR enabled
1.20: [ 15890.854] (II) Initializing extension RANDR

and the monitor reports EDID version 1.3 information.

So, under 1.20 with the VESA driver, the best I get is 640x480.
[I've been using a different driver which at least gets me 1280x1024,
but I'd prefer 1600x1200 if that's doable.)

Short of me getting and reading the source code, any ideas what's wrong
and/or how I might fix it?

Thanks!
-WBE

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Winston <wbe@ubeblock.psr.com.invalid> wrote:

Back in XFree86 1.18,

That's a long way back. XFree86 2.0 was released on the 24th of
October 1993. That, and the fact that XFree86 1.18 doesn't seem to
have ever existed, hints that I think you mean Xorg.

with the same hardware and monitor as now, using
the VESA driver, my system could run in 1600x1200 mode. The VESA driver actually worked better than the driver for my specific graphics hardware.

Unfortunately, ever since "upgrading" to 1.20, Driver "vesa" rejects
all modes above 640x480.

Xorg-server 21.1 is the current version (they changed the version
number system). Maybe try upgrading to that instead in case the
problem has already been fixed?

[snip]

So, under 1.20 with the VESA driver, the best I get is 640x480.
[I've been using a different driver which at least gets me 1280x1024,
but I'd prefer 1600x1200 if that's doable.)

Short of me getting and reading the source code, any ideas what's wrong and/or how I might fix it?

Just a stab in the dark: I believe the Xorg server now has the
ability to run without root privileges. If you're running it that
way, perhaps try running it as root instead, in case it hasn't got
access to something that it uses to establish whether the graphics
chipset or monitor are capable of resolutions above the 640x480
minimum.

--
__ __
#_ < |\| |< _#

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I previously posted:

Back in XFree86 1.18,

not@telling.you.invalid (Computer Nerd Kev) kindly replied:

That's a long way back. XFree86 2.0 was released on the 24th of
October 1993. That, and the fact that XFree86 1.18 doesn't seem to
have ever existed, hints that I think you mean Xorg.

You're right. My confusion comes from seeing names like xf86-video-*, xf86-input-*, libXxf86*, etc. combined with Xorg stuff. It's Xorg
server, but xf86-video-vesa.

Xorg-server 21.1 is the current version (they changed the version
number system). Maybe try upgrading to that instead in case the
problem has already been fixed?

Each time a new Xorg or xf86-video-vesa came out, I hoped it'd be fixed,
but so far not. I'll certainly give 21.1 a try. I wouldn't be
surprised, though, if the problem is in xf86-video-vesa or something new
needed in the xorg.conf config file, rather than in the Xorg server.

Just a stab in the dark: I believe the Xorg server now has the
ability to run without root privileges.

Oh? Neat. That'd be great.

If you're running it that way,

Nope. ps says Xorg is running as root.

... in case it hasn't got access to something that it uses to
establish whether the graphics chipset or monitor are capable of
resolutions above the 640x480 minimum.

As I posted, the log file shows it obtaining the monitor and graphic
modes just as successfully as it did in 1.18, and the same built-in
modes match initially, but when it later goes to choose the "best" mode,
it (for some value of "it") rejects all the modes except 640x480 with
"(no mode of this name)".

Note: this isn't a problem when using the xf86-video-{graphics chip}
driver, but that driver has never supported 1600x1200.

Thanks for the reply,
-WBE

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Winston <wbe@ubeblock.psr.com.invalid> wrote:

I previously posted:

Back in XFree86 1.18,

not@telling.you.invalid (Computer Nerd Kev) kindly replied:

That's a long way back. XFree86 2.0 was released on the 24th of
October 1993. That, and the fact that XFree86 1.18 doesn't seem to
have ever existed, hints that I think you mean Xorg.

You're right. My confusion comes from seeing names like xf86-video-*, xf86-input-*, libXxf86*, etc. combined with Xorg stuff. It's Xorg
server, but xf86-video-vesa.

XFree86 was based on Xorg, then later Xorg became based on XFree86,
so that's where the naming confusion comes from.

Just a stab in the dark: I believe the Xorg server now has the
ability to run without root privileges.

Oh? Neat. That'd be great.

Success depends on the driver used, in my experience (1x Intel
driver worked, 1x ATI driver didn't until server run as root).

If you're running it that way,

Nope. ps says Xorg is running as root.

... in case it hasn't got access to something that it uses to
establish whether the graphics chipset or monitor are capable of
resolutions above the 640x480 minimum.

As I posted, the log file shows it obtaining the monitor and graphic
modes just as successfully as it did in 1.18, and the same built-in
modes match initially, but when it later goes to choose the "best" mode,
it (for some value of "it") rejects all the modes except 640x480 with
"(no mode of this name)".

I suspect the modes are getting "pruned" during the VESA driver's initialisation.

Invalid modes are then taken off the modes list using the
xf86PruneDriverModes function, and the "no mode of this name"
message seems to come from a check against that modes list.

The comment describing the xf86ValidateModes function (called via VBEValidateModes in vesa.c) might provide a clue about settings that
affect the mode validation:

/*
* xf86ValidateModes
*
* This function takes a set of mode names, modes and limiting conditions,
* and selects a set of modes and parameters based on those conditions.
*
* This function takes the following parameters:
* scrp ScrnInfoPtr
* availModes the list of modes available for the monitor
* modeNames (optional) list of mode names that the screen is requesting
* clockRanges a list of clock ranges
* linePitches (optional) a list of line pitches
* minPitch (optional) minimum line pitch (in pixels)
* maxPitch (optional) maximum line pitch (in pixels)
* pitchInc (mandatory) pitch increment (in bits)
* minHeight (optional) minimum virtual height (in pixels)
* maxHeight (optional) maximum virtual height (in pixels)
* virtualX (optional) virtual width requested (in pixels)
* virtualY (optional) virtual height requested (in pixels)
* apertureSize size of video aperture (in bytes)
* strategy how to decide which mode to use from multiple modes with
* the same name
*
* In addition, the following fields from the ScrnInfoRec are used:
* clocks a list of discrete clocks
* numClocks number of discrete clocks
* progClock clock is programmable
* monitor pointer to structure for monitor section
* fbFormat format of the framebuffer
* videoRam video memory size
* xInc horizontal timing increment (defaults to 8 pixels)
*
* The function fills in the following ScrnInfoRec fields:
* modePool A subset of the modes available to the monitor which
* are compatible with the driver.
* modes one mode entry for each of the requested modes, with the
* status field filled in to indicate if the mode has been
* accepted or not.
* virtualX the resulting virtual width
* virtualY the resulting virtual height
* displayWidth the resulting line pitch
*
* The function's return value is the number of matching modes found, or -1
* if an unrecoverable error was encountered.
*/
from: hw/xfree86/common/xf86Mode.c

I'm just guessing though. I've been messing with X drivers lately,
but the internals of X are still at least 90% mystery to me.

--
__ __
#_ < |\| |< _#

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)