[conspire] error debugging
rick at linuxmafia.com
Mon Oct 8 13:36:58 PDT 2012
Quoting Ruben Safir (ruben at mrbrklyn.com):
> See - that is the reading between the lines skills. I figured that the
> video installation problem was directly related to gthumbs crashing.
Yr. welcome. Yes, that was indeed the point I was trying to make
(reading between the lines so you don't end up solving the wrong
Generally speaking, I would venture that any time you are seriously
considering recompiling entire desktop environment suites, you should
seriously consider the likelihood that you're solving the wrong problem.
> Darn if I know who to get openGl to work. This is the lap top with a A$
> Vision AMD chip.
'AMD Vision' is a marketing term. I would _guess_ that what you have is
one of these (but this page covers a lot of territory).
Are you saying that you do _not_ have OpenGL working in X11? I posted
the way you determine the answer to that question, upthread.
Some quick searching suggests what might be your problem:
Video Accelerator / Smooth, Vivid HD Video: If you're using Linux and
looking to take advantage of the Fusion's UVD3 engine (it's basically
the same Unified Video Decoder as found in recent Radeon HD GPUs too),
you need to be using the proprietary AMD Catalyst Linux driver. If you
are using the open-source driver, for now and the foreseeable future the
UVD3 engine is rendered useless. AMD has not provided open-source
support or public documentation on any generation of the UVD engine due
to fear it may compromise their Digital Rights Management support under
other operating systems (Microsoft Windows). It is unlikely this lack of
open-source accelerated video support for AMD hardware will change
Some people seem to have excellent luck with just buying a laptop with
no concern in advance for driver availability/quality, and just hoping
for the best, but I personally have never relied on that. My policy of
never buying something I hadn't researched in advance has Worked for
Me[tm] -- and my policy of assuming that hardware thrust on me without
prior research may be problematic.
Tangentially related: My longtime friend Duncan MacKinnon visted Chez
Moen over the weekend, and brought with him (to work on) some
Linux-based hardware systems with astonishingly ancient software. These
are industrial manufacturing systems that need to run long-discontinued
proprietary application software and continue to support a really
antique serial-port dongle. Duncan needed to resurrect them with
some replacement (but not _new_) hardware components, so I let him use
some of my PATA hard drives, ethernet NICs, and video cards.
We booted them up, and they all had a version 2.0.33 kernel. And
astonishingly, we were able to make them work with my NICs and video
cards. Why? Because my box of spare/unused cards contains the fruit of
about fifteen years of winnowing -- throwing out both the most obsolete
_and_ favouring hardware of golden compatibility and support
characteristics. The NICs were:
Several Tulip-based PCI cards, two of them real-DEC, and one clone
One or two 3Com 3C905TX PCI cards
The video cards were a couple of Matrox G200 cards, if memory serves.
I am delighted that Duncan was able to get real and immediate value out
of very old cards -- but not on balanced all that surprised (even given
an absurdly ancient custom Linux distro based on a 1997 kernel): My
policy of gravitating towards utterly hassle-free,
maximum-compatibility hardware continued to give dividends, and Duncan
got to benefit.
And, if I wanted to make sure a new video-hardware acquisition had
hassle-free support for OpenGL, I would do that through research prior
More information about the conspire