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)