[issue1161] pkgsrc xorg-driver-ati has regression with rs48x (Xpress 200, 1100, 1150) chipsets

Joe "Floid" Kanowitz sinknull at crater.dragonflybsd.org
Thu Nov 6 23:06:20 PST 2008

Joe "Floid" Kanowitz <jkanowitz at snet.net> added the comment:

I had the opportunity to test the xorg-driver-ati git "master" tonight.  It does
fix the nasty regression and probably works better than ever with the rs48x
series.  Unlike 6.9.0, the monitor is detected, it actually picks up the
1440x900 mode from the DDC/EDID data now, and life is good.  Hopefully the xorg
crew will receive, or have already received, the requisite documentation from
AMD/ATI and that will help make the support for these chips a little more robust.

(If I understand correctly, they've already received most of the docs for the
AMD 690/RS600 family and later IGP chips, and those are newer chips with
newer-generation graphics cores that probably aren't bitten by *this* particular

Anyhow, now that xorg has gone modular, building the driver went surprisingly
smoothly subject to this short list of dependencies (above and beyond what will
be pulled in by installing the usual xorg packages):


In particular, devel/xorg-util-macros is less-than-obvious but the driver's
versioning defines will be left hanging without it.  You'll have to figure out
enough git to be dangerous because there's no other way to obtain a snapshot
(anyone want to add a 'Just give me a .tgz' feature to gitweb?).

It's easy to overlook the proper git:// URI when stuck in 80x25, even though
it's at the top of every xorg gitweb page.  Here it is for anyone else searching:


Of course, using the provided install script will put the drivers under
/usr/local/lib/ and you'll have to move them into the appropriate places under
pkg/lib/ manually.

. ..

Again, this was xorg's bug and the 6.9.0 driver is the latest release at this
time, so every xorg-using platform is probably impacted equally.  I'm mentioning
it here because "What hardware works?" seems to be a popular question, and if
you're me, you might've thought this particular chip family was well-supported
by now.  At least it should be in the next xorg release... and I'll mark this as
"done-cbb" until then. :)


status: unread -> done-cbb

DragonFly issue tracker <bugs at lists.dragonflybsd.org>

More information about the Bugs mailing list