There has been a lot of noise lately about the fact that xorg-x11-7.1 was put into ~arch before nvidia and ati drivers have versions that work with it.
I don’t think any open source project should be forced to hold back their development simply because some hardware company refuses to release open source drivers or at least specifications.
If you need binary drivers and are running ~arch, simply mask the new xorg until ati and/or nvidia get off their asses and catch up. In case you don’t know how to mask it (though you really should if you are going to be running ~arch) simply put the following in /etc/portage/package.mask
>=x11-base/xorg-server-1.0.99
>=x11-base/xorg-x11-7.1
>=x11-drivers/xf86-video-nsc-2.8.1
>=x11-drivers/xf86-video-s3virge-1.9.1
>=x11-drivers/xf86-video-i128-1.2.0
>=x11-drivers/xf86-video-trident-1.2.1
>=x11-drivers/xf86-video-neomagic-1.1.1
>=x11-drivers/xf86-video-cirrus-1.1.0
>=x11-drivers/xf86-input-evdev-1.1.2-r1
>=x11-drivers/xf86-video-v4l-0.1.1
>=x11-drivers/xf86-video-vesa-1.2.0
>=x11-drivers/xf86-video-tga-1.1.0
>=x11-drivers/xf86-video-s3-0.4.1
>=x11-drivers/xf86-video-tdfx-1.2.1
>=x11-drivers/xf86-video-glint-1.1.1
>=x11-drivers/xf86-input-void-1.1.0
>=x11-drivers/xf86-video-i740-1.1.0
>=x11-drivers/xf86-video-dummy-0.2.0
>=x11-drivers/xf86-input-keyboard-1.1.0
>=x11-drivers/xf86-video-imstt-1.1.0
>=x11-drivers/xf86-video-savage-2.1.1
>=x11-drivers/xf86-video-siliconmotion-1.4.1
>=x11-drivers/xf86-video-ark-0.6.0
>=x11-drivers/xf86-video-ati-6.6.0
>=x11-drivers/xf86-video-mga-1.4.1
>=x11-drivers/xf86-video-sis-0.9.1
>=x11-drivers/xf86-video-tseng-1.1.0
>=x11-drivers/xf86-input-joystick-1.1.0
>=x11-drivers/xf86-video-vga-4.1.0
>=x11-drivers/xf86-video-cyrix-1.1.0
>=x11-drivers/xf86-video-chips-1.1.1
>=x11-drivers/xf86-video-apm-1.1.1
>=x11-drivers/xf86-video-rendition-4.1.0
>=x11-drivers/xf86-input-mouse-1.1.1
>=x11-drivers/xf86-video-i810-1.6.0
>=x11-drivers/xf86-video-via-0.2.1-r1
>=x11-drivers/xf86-video-nv-1.1.2
>=x11-drivers/xf86-video-voodoo-1.1.0
>=media-libs/mesa-6.5
>=x11-apps/mesa-progs-6.5
It is enough to mask:
>=x11-base/xorg-server-1.0.99
because that is what is incompatible with the nvidia/ati proprietary drivers.
The other stuff you listed either depends on that, or doesn’t conflict with earlier versions of xorg-server.
The problem with your argument is that you’re assuming that an open source nVidia driver would be automatically compatible with the API changes in X.org X11 7.1. The chances would certainly be increased, but it wouldn’t be a given, especially if the driver is developed outside the X project (quite possible now that it’s modularized) and follows its own release schedule.
So now that you can’t really blame it on its closed nature with any level of certainty, the fact remains that a large number of users rely on it and Gentoo should do its best to keep things working for them. I’m not sure masking stuff manually is as easy as it should be.
Thanks for posting this info. Was trying to do my first emerge -Du world in a month or so, and wasn’t quite sure how to handle this blockage.
Pellaeon:
The open source “nv” driver is currently still under the control of X.org, and they do update the driver with every release. Also, the change in this case was an ABI change, meaning that it’s likely a simple recompile would fix it. Even when there is also an API change, and if the “nv” driver weren’t maintained by X.org, we (Gentoo) would still be able to write a patch porting the driver to the new API. With any closed source code, there is nothing we can do other than wait for the company to get around to updating it.
The closed nature of the driver is the only reason why it won’t work with the latest X.org, if it were open source we could fix it ourselves. If you want to see a fairly good argument about open vs closed code and why open source projects should not bend around backwards to help closed code stay compatible, take a look at /usr/src/linux/Documentation/stable_api_nonsense.txt. This is written in a kernel perspective, but it applies to X.org in the same way.
Kevin, I mask everything that deps on the new xorg-x11 to avoid the upgrade/downgrade cycles that sometimes crop up.
Hi,
thanks for your post. It helped.
>I don’t think any open source project should be forced to hold back >their development simply because some hardware company refuses to >release open source drivers or at least specifications.
I can’t agree with that. It is not the issue whether some one is forced to do something in this case. With this action hardware companies are maybe also forced now to release their drivers earlier. Is that okay? I guess they have reasons for for their later driver delivery.
The point is that an emerge -uD world leaves an incurrupt system on my machine and my xserver is not running correct anymore. That is just an error and don’t looks like high-quality. Well shit happens it is okay but please don’t try to legitimate it.
I think for the next time it would be better to put it into ~arch after nvidia/ati has driver for it.
There is no reason why the company needs a fully updated driver, they simply need to recompile the current driver against the current X.org release.
nVidia and ATI are dragging their feet most likely because they simply don’t care all that much about the open source world, it represents a small percentage of their market hence they don’t see a reason to put a lot of work into supporting it.
Also, the new X.org release currently affects ~arch users, who (should) know they are running packages that may break. If you want a system that never breaks, you should not be running ~arch. There is also the fact the open source drivers still work, there is no reason that they can’t use the “nv” driver if they absolutely must run a full ~arch system. This was not an “error”, the X team knew full well that there were no proprietary drivers for the new X release when they unmasked it.
I just commented out nvidia in the make.conf video cards section.. oh wait.. I also switched to the nv driver.. and I’m also typing this message on the same machine.. just booted to windows… š
I think it wouldn’t be that much harder to have a more in-depth requirements list, something other than a “hard block”, or hard upgrade…
I should be able to specify my world file, my make.conf, and be done with it.
So, yes.. it was good that we got bit while it was in ~arch. Next, we need to find a way to make ourselves not get bit again.
We should very rarely come across a block because of a newer version loosing compatibility. We should have a note: can’t upgrade these packages until fat-arse over there gets off his butt, upgrade everything else? y/n
Oh wait… portage will not be interactive by design… and I’m thinking of Debian apt or BSD ports…
interactive ain’t bad… it should just take place in one sitting and build… download the options list, go through a wizard, have the wizard check for things that will break, then download and compile everything.
-AP
Maybe it’s just me, but it seems inelegant to *unmask* all those Xorg deps and then *remask* the 7.1 ones. Why not just put Patrick’s list of atoms in package.keywords (with “>=” changed to “
bleh — I mean “>=” changed to “<“.
> I don’t think any open source project should be forced to hold back their
> development simply because some hardware company refuses to release open source
> drivers or at least specifications.
Then perhaps Xorg, et al. might concentrate their efforts on providing open source drivers that are as fast as their closed source counterparts.
>> insert your favorite meaningless, mealy-mouthed open source advocacy here
> Then perhaps Xorg, et al. might concentrate their efforts on
> providing open source drivers that are as fast as their
> closed source counterparts.
Video card companies don’t provide any documentation on writing drivers. It’s almost impossible to write a good video driver, the only reason the r300 project got anywhere is because they had a starting point (older, supported ATI cards). The “nv” driver is little better than binary code and was written by nvidia.
We would have excellent open source drivers, if companies actually provided documentation on how to write decent drivers.
> Then perhaps Xorg, et al. might concentrate their efforts on
> providing open source drivers that are as fast as their
> closed source counterparts.
Sure, everyone would love to, dig in if you can help. Obviously some kind of info about how the hardware works would be helpful, or even some old driver code.
*other whining about breakage*
Don’t run ~arch then, you should know the risks. If you didn’t before, you do now…
There is nothing I can do than to agree with Patrick McLean’s comments!!!!
BTW, thanks for the info on what packages to mask.
For some reason this post has been getting a lot of comment spam lately so I am closing comments here.