Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
(Nearly) full tickless operation in 3.10
I don't know, it sounds about equally as capable as the open source intel driver for my X3100
based Thinkpad T61. The 2D performance is terrible and running any OpenGL applications
immediately freezes the entire computer.
Plenty of work ahead
Posted Dec 2, 2007 0:24 UTC (Sun) by drag (subscriber, #31333)
What version of drivers are you using?
Mine is stable with acceptable 3D support and good 2D acceleration. It also suspends to ram
several times a day and this has worked better then my old Ibook.. with either OS X or Linux
on it. Compiz-fusion works well also, the only major problem is that EXA support isn't fast
enough for large videos with 32bit graphics, so I run 16bit. Oh and OpenGL applications still
are ugly when running on compiz.. but their performance isn't affected in a noticable way.
That and it's xrandr support allows me to hotplug external monitors and configure X to use
them on the fly, which is a new experiance for with with open source drivers.
BTW, this is with Debian Unstable/testing on a Dell 1420n.
Posted Dec 2, 2007 0:31 UTC (Sun) by jwb (guest, #15467)
Whatever they shipped in Gutsy still can't render anything worth a damn with OpenGL. Even
something pedestrian like Google Earth looks like junk on the GMA X3100.
I am fairly upset that I bought this Intel graphics chip 14 months ago on the strength of the
idea that a GPL driver would be a good thing. In practice, the lack of public documentation
means that the GPL driver is held hostage to the whims of Keith Packard, and it seems that the
things Keith is interested in working on do not include correct output.
I give him props for the randr 1.2 stuff, but even that isn't particularly hot in practice.
With whatever version is in Ubuntu Gutsy, rotating my display locks up the hardware.
Posted Dec 2, 2007 2:55 UTC (Sun) by dberkholz (subscriber, #23346)
Sounds like you're held to the whims of Ubuntu, then, since you haven't tried the latest
driver to see whether your problems are fixed. Have you reported your problems on a bug?
Posted Dec 2, 2007 3:09 UTC (Sun) by jwb (guest, #15467)
True, to an extent, and bug reports are mostly ignored if you are not using the git head
revision of the driver, xorg, and mesa. That's a common method that open source developers
use to pass the buck back to the bug reporter, but that's a subject for another post.
bug reports in open source projects
Posted Dec 3, 2007 10:49 UTC (Mon) by DonDiego (subscriber, #24141)
I really cannot speak for x.org, but given the low signal to noise ratio of bug reports in
general I must say I mostly ignore bug reports that are not against Subversion HEAD as well.
Spend some time tracing a bug report only to find out that it's fixed already when I have about
100 things on my ToDo list and only time for about 5? Not to mention that 99 of those things
are more fun than validating bug reports? No, I really cannot be bothered to throw away my
unpaid free time like that ...
Posted Dec 3, 2007 15:01 UTC (Mon) by alankila (subscriber, #47141)
Also remember that if you do not have the HEAD revision of the software compiled, then you
can't even test any fixes. So you not only do not know for sure whether the bug still exists,
you also can't tell whether its fixed by any changes made.
Actually it's possible
Posted Dec 3, 2007 15:48 UTC (Mon) by khim (subscriber, #9252)
Someone must do the following work:
1. Compile driver with some fixes just for you.
2. Package it for particular distribution - usually including distribution-specific patches
3. Send this binary to you and explain how to use it
4. Repeat the process starting from 1.
WAAAY to much work to do this for free. There are companies which will offer this level of support - but usually it's quite expensive. You should pay one way or another: either by buying expensive support contract or wasting sizable amount of time playing with HEAD drivers...
It's still better then situation in Windows world where you can only submit bugreport and hope that someone sometime will read it and you'll get your fix half-year later...
Posted Dec 3, 2007 15:35 UTC (Mon) by jond (subscriber, #37669)
Running HEAD seems to me to be a fair way for a developer to ensure that the reporter is
willing to invest at least a little bit of time towards diagnosing the problem and not just
fire-and-forget bug reporting, which is not really of use to anyone.
Posted Dec 3, 2007 18:08 UTC (Mon) by jwb (guest, #15467)
Building the tip of mesa and xorg is a major undertaking which is likely to break every
package on any given system. Nevermind the minor fact that frequently the tip is in an
unbuildable or incompatible state.
For my own code, I follow the policy of taking a bug report seriously unless I have reason to
believe that it has been fixed in a newer revision.
I believe there was a long and thoughtful post on linux-kernel regarding this very issue
recently, where the author (a major kernel developer) concluded that it's counterproductive to
insist on testing with latest-test-rc-mm.
Posted Dec 3, 2007 19:57 UTC (Mon) by drag (subscriber, #31333)
Stable kernel interfaces be damned.
Both the X.org Intel drivers and DRI driver and libraries can be compiled out-of-tree and be
I've done that before when trying out different features that are only avialable via cvs.
(like texture/memory management features for the 915tex driver). Especially with the DRI
libraries. Using LD_PRELOAD tricks it's very possible to change between 3D driver versions
while running a single X session.
There is almost no need to ever have to overwrite anything provided by your distribution. The
whole X server can be compiled seperately from distro-provided stuff if you like. If the CVS
breaks everything then just go back to what is provided by your distribution.
Worst case is that you have to compile a custom kernel to take advantage of some features
because of patches to DRM or AGPGART stuff.
Soo... If you actually care about trying out patches and filing usefull bug reports then there
is nothing that is stopping you. Especially about 3D drivers.
Remember almost all of it, except for the DRM or AGP stuff, is userspace. Not much at all
depends in any way on the kernel (unlike your proprietary drivers) your using and you can use
different LD tricks and chroots to run any of it like any other application.
And remember now that X is now _modular_. The drivers themselves can be compiled seperately
from X. If your using a relatively recent version of X you can try out the latest 2D Intel
driver by just copying over the existing intel_drv.so file! If your worried about breakage
then just keep a backup to copy back.
This is a little out of date:
For example a most of the stuff has moved away from CVS to Git, but for the most part it still
applies. This tells you how to compile and run latest versions of Mesa libs, and DRI without
Have you never had more then one version of a program or libraries installed on your computer
If your using Gutsy and the Intel stuff is crapping out on you then bitch to Ubuntu for
shipping something broken. On my Debian Unstable/Testing is is pretty stable, not perfect, but
it works well. A freind at work has a X3000 chipset and is using Fedora Core 8 and it runs
Compiz pretty well except for the 2D and 3D overlay problem/ugliness.
Posted Dec 3, 2007 19:26 UTC (Mon) by dvdeug (subscriber, #10998)
I've had the feeling with way too many projects that they're more willing to make cute new
features rather than actually fixing the bugs that are giving me trouble. File-and-forget bug
handling or making unreasonable demands on me just accentuate that feeling. Demanding that I
exchange a mostly-working program for a program that may not even compile or work remotely
correctly is absurd for anyone who actually has to use the program in question on the system
I see the reasoning behind it, but OSS already has a preception, often true, of not worrying
about the hard unfun stuff that users need. Stating that you're going to ignore bug reports
unless they follow a development version just stress that feeling.
Posted Dec 4, 2007 17:05 UTC (Tue) by jsbarnes (guest, #4096)
Have you tried filing bugs for the issues you see in Gutsy? We worked a
lot with the Ubuntu team on the 2.2 driver release, fixing many Ubuntu
reported problems in the process. And we try to be responsive to bug
reports in general (and I generally don't ask people to test newer
versions unless I have reason to think the bug is fixed there and I want
Posted Dec 2, 2007 2:59 UTC (Sun) by k8to (subscriber, #15413)
I can't really speak as to any hostage holding, but I can say that the intel 3d support has
not really impressed me, under Linux. The performance under windows is notably better,
delivering framerates in 2-3 times better range, without video glitches, and while the
stability of Windows has its ups and downs, the Linux OpenGL experience with my GMA X3000
usually locks the machine solid.
The experience of this driver has actually driven me to use Windows again to get certain work
done after around ten years of Linux as my sole working platform.
I suspect there is simply not enough manpower in the arena of the video drivers on Linux.
Posted Dec 2, 2007 17:32 UTC (Sun) by mmarq (guest, #2332)
"" The experience of this driver has actually driven me to use Windows again to get certain
done after around ten years of Linux as my sole working platform.
I suspect there is simply not enough manpower in the arena of the video drivers on Linux. ""
Nevertheless i still use Linux... try the proprietary offerings... I've being "crying to the
winds" in this forum for more than half a decade!!...
In my opinion its not manpower its the *will* and a workable method and organization(
concentrated efforts, because reverse engineering would be still in the menu ) to obviate the
lack of a long in time stable API or ABI of the driver model.
Worst that can happen its the various distros driving different implementations as a marketing
differentiation point!... akin to our favorite "Bill" selling *rope*, openly and without
shame, at the entrances of RH, Novell, Canonical... LF... headquarters ( rope for people to
hang themselfs )...
( for crying out loud why isn't DKMS official tree code ?... or am i being out for too long
If the *will* is there, than it only misses a good development method and organization for it
to take off good... because the hardware manufactores wont do it "really" for free for OSS( no
matter what they claim)... for them is just a matter of dumping development, maintenance and
support costs to the community.
If the *will* is there and the method and organization, then 'we' can talk about Linux desktop
really taking off and spreading like wild fire, otherwise, we better talk about santa claus!
Posted Dec 3, 2007 18:34 UTC (Mon) by elanthis (guest, #6227)
"for crying out loud why isn't DKMS official tree code"
Because upstream kernel developers think that out-of-tree kernel code is disgusting and awful
and evil, and DKMS is unnecessary for in-tree code.
They don't mind the idea that, in order to use new hardware or use a newer driver, you need to
upgrade your entire fucking kernel, along with without user-space libraries and daemons and
tools occassionally get broken by those updates (hal, udev, and anything that uses the fluid
Not sure it's really worth it to whine about the kernel like that, though. It's the same deal
for a Linux distribution as a whole. Want a newer version of FooApp? Upgrade your whole
fucking OS to the next release, and then you also get all those undesired changes to your
desktop and other apps along with all the new bugs and breakage you didn't have to put up with
Linux (both the kernel and the family of OSes) has always been based on one of two models: the
"compile shit directly from version control on a daily basis" model and the "you get a fixed
set of software snapshots in your OS appliance" model. If you dislike both of those models,
use a different OS.
Posted Dec 3, 2007 20:39 UTC (Mon) by drag (subscriber, #31333)
Plus DKMS isn't a big deal when it comes to open source drivers.
The only thing that matters in terms of kernel would be things like DRM or AGPGART stuff. DRI
and Xorg XAA/EXA drivers have no dependancy on the kernel beyond that.
It's fairly trivial to manage multiple versions of the Intel driver or have compiled a Mesa
tree and DRI stuff outside your distribution-provided stuff.
It's even possible to switch between multiple versions of DRI drivers within the same X
session. It just requires LD_LIBRARY_PATH tricks to point applications at a different path.
It's not that hard at all.
With the 2D drivers you just copy over the *_drv.so file, and keep backups of the originals so
you can go back if it breaks something.
Occasionally you'll run into kernel-level dependancies for a new texture memory management
change or something like that. But for the most part they can be compiled into modules.
Posted Dec 15, 2007 19:09 UTC (Sat) by anton (guest, #25547)
[...] intel 3d support has not really impressed me, under
Linux. The performance under windows is notably better, delivering
framerates in 2-3 times better range [...]
Posted Dec 2, 2007 5:21 UTC (Sun) by leoc (subscriber, #39773)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds