DragonFly BSD
DragonFly users List (threaded) for 2009-11
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Xorg configuration

From: Bill Hacker <wbh@xxxxxxxxxxxxx>
Date: Mon, 02 Nov 2009 02:25:09 +0800

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

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

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


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.



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]