Re: Xorg configuration

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

Saifi Khan wrote:
> On Sun, 1 Nov 2009, Bill Hacker wrote:
>
> > Not sure it is germane but 'something' in xorg went at least temporarily
> > pear-shaped on the latest FreeBSD step-ups (7.1 -> 7.2 as well as 8 RC1) and
> > one other *BSD w/r Intel VGA driver vs VESA autoselection and loading.
> >
> > Symptom was an i9XX that was previously automagically handled w/o need of a
> > conf file stalling with 'unable' vs prior art falling back to VESA if all else
> > failed.
> >
> > Taming it with conf file entries quickly became tedious, and was of no
> > interest in a constantly-changing workshop of portable storage devices, so
> > I've simply backleveled until the Xorg community recover their automagicality.
> >
> > NB: These are changes in the Xorg 'containership' - not the host OS, have been
> > extent for quite a while now, BUT AFAIK not relevant to other-than i8XX / i9xx
> > Intel VGA.
>
> On one of my laptops, i'm running FreeBSD freebsd
> 8.0-CURRENT-200906 and it has a Intel 945GM chipset.
>
> Xorg 1.6.x is running absolutely fine !
>
> Tested it with both KDE 3.5.10 and DWM.
>
> There were some xorg.conf changes between Xorg server 1.5.x and
> 1.6.x
>
> Can you please highlight the specific issues ?
>
>
> thanks
> Saifi.

Lenovo Asian-market G400 3000 laptop of January 2008 vintage:

Intel T2130 CPU, 1.86 GHz unicore hyperthreading as if dual-core

2 GB RAM

Intel 82945GM rev 0X03 video

Same issue surfaced in both FreeBSD 7.2-RELEASE and 8-RC1,'neither updated 
beyond original iso. Was not a problem in 7.1-RELEASE, though it had been 
updated several times (not always with updates to installed Xorg & sputniks).

The log (and CLI artifacts) showed a hang on attempt to load an Intel VGA 
driver, whose specific idenity I did not take note of - only that it was neither 
on box nor in the ports tree.

I'm not expecting Xorg to have all possible vendor-specific drivers all the 
time, or even most of the time - but it *used to* drop into generic VESA ELSE 
vendor-BIOS specific VESA instead of hanging.

Given that a HDD here may be attached to any of several machines - which vary on 
kbd and mouse as well as VGA and display res, VESA is preferred over otherwise 
wrong-for-all-but-one conf files. Finding a hardware-specific driver is 
serendipitous, but only if the attempt doesn't create more pain than gain.

As stipulated, the problem appears to have been transient:

*newer* Xorg seems to be fine:

- I have 1.6.4 RC 1 on OpenBSD-4.6 - initially reports Intel 82945GM,
jumps through a few hoops, (very few), uses 'built in 'Intel VESA at correct 
1280 x 800 native resolution.

*older* Xorg was at least hang-free:

- I have 1.4.2 'usable' if suboptimal on NetBSD 5.0.1 - initially reports Intel 
Mobile 945GM/GMS.GME, & 943/940GML Express, plays with itself for a while, 
finally settles on VESA VBE BIOS mode for the (correct) Intel 82945GM chipset, 
but with incorrect native resolution (1024 x 1068 vs actual 1280 X 800) for the 
Samsung panel in use.

Unreleated, but the Haiku OS, nails it precisely on the first go, and displays 
as sharply as if it were OS X - something the X-Window System has a hard time 
matching, (at least on the various apps) regardless of KDE, Gnome or my usual - 
Xfce4.

An exercise for others where DragonFly is w/r Xorg version at the moment - I've 
presently got Haiku in the partition where I usually put DragonFly, so have 
neither dmesg nor Xorg.0.log handy OR saved.

Best,

Bill