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
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



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