If you experienced problems with the NVIDIA driver 173.14.09 you might want to give version 173.14.12 a try.

The driver is available on Hardy in the hardy-proposed repository (you will have to install it through EnvyNG, if you haven’t already done so) and should now work with Xen kernels too (thanks to a little trick which I backported from Intrepid).

The name of the package for Intrepid is nvidia-glx-173.

Release Highlights:
Added support for GeForce 8600 GS.
Fixed a problem with missing rendering in OpenGL Workstation Overlays.
Fixed a problem with running some SDL applications and virtual terminal switching.
Fixed a potential crash in nvidia-settings when saving to the X configuration file.
Improved error recovery paths in the case of corruption of the commands sent to the GPU.

Please test the driver (for Hardy) and report your experience with the driver in this bugreport.

NOTE: the driver has been uploaded today but should be available tomorrow.

Posted by admin | August 4, 2008 6:36 pm
Filed under: Envy,Planet,Ubuntu,Uncategorized
Comments (18) |


As promised in my previous posts, in this blog post I will deal with a project I’m working on which implements this blueprint.

Bryce Harrington (the mentor of this blueprint), Colin Watson (the approver) and I talked about this at the UDS in Prague. The blueprint is based on Bryce’s original idea to improve the Screen Resolution panel. The work was divided into 2 phases:

Phase 1 (which is a higher priority) is about providing the Screen Resolution panel with the capability to set the virtual resolution in the xorg.conf when, put simply, 2 or more screens don’t fit the framebuffer. Currently the Screen Resolution panel doesn’t succeed in such case since the drivers are not able to reallocate the framebuffer yet. A simple GUI should allow users to set the required virtual resolution and write the settings to the xorg.conf through PolicyKit.

Phase 2 is about adding an “Advanced settings” button to the Screen Resolution panel so as to allow advanced users to edit the xorg.conf through a simple GUI. The aim of such program is not to set up multiple screens layouts but only to make it easier for users to add, edit and remove options without having to know which section an option, say, DontZap, belongs to, or to switch to a different driver. A more detailed explanation of the use cases is available here.

In Prague we agreed that this project couldn’t become reality without an xorg.conf parser/writer and some other tools. For this reason I started the X-Kit project:

X-Kit

Components:

    * XorgParser: a simple, transparent and easy to extend xorg parser.
    * XorgValidator: a program which uses X-parser, tries to make sense of xorg.conf and operates accordingly.
    * Xorg Options Data Store: a program which translates the content of the manual of the xorg.conf into an XML file.
    * Xorg Options Editor GTK: a simple GTK GUI to the xorg.conf.
    * Xorg Options Editor KDE: a simple GTK GUI to the xorg.conf.

NOTE: all the code is in Python

Aim:

    * a desktop agnostic kit to manipulate the xorg.conf (and whatever will replace the xorg.conf in the future).

Advantages of XorgParser:

    * Simple API.
    * Easy to extend.

Current Status:

    * XorgParser: version 0.3 is available. You can get the code from my bazaar branch or from my PPA
    * XorgValidator: there is already some code in place which I haven’t released yet.
    * Xorg Options Data Store: the program is complete, works well and will be released soon.
    * Xorg Options Editor GTK (aka Phase 2): the program is almost complete and will be released soon. You can have a look at this screencast to see how it works.
    * Xorg Options Editor KDE: not started yet
    * Phase1: the Python part is complete and, as you can see in this screencast, it works well. The screencast, however, doesn’t reflect the current status of phase 1 but still gives an idea of how this will work in practice.

For further details on the project, please have a look at the wiki.

A special thanks to Bryce Harrington and Martin Pitt whose feedback on the parser was extremely important.

Posted by admin | July 25, 2008 4:33 pm
Filed under: GNU/Linux,Planet,Python,Ubuntu,UDS
Comments (17) |


What is ready

  • Currently there are 4 flavours of the NVIDIA driver: 177, 173, 96, 71.

    They are all compatible with Xen and work only with 2.6.26 kernels (no 2.6.24, sorry).

    They all use DKMS therefore you will have to keep the linux-headers installed.

    CUDA is now supported by default (drivers 173, 177).

    The packages can replace each other without any need to remove one driver before installing the other. All it takes is a simple “sudo apt-get install nvidia-glx-VERSION”.

  • NOTE: these drivers won’t be backported to Hardy. The “-envy” flavour in multiverse will be kept updated on Hardy.

Problems

    xorg-server 1.5

    The xserver was updated to version 1.5, which broke the ABI compatibility. As a result, drivers 96 and 71 (and fglrx) dont’ work with the new xserver and unfortunately the -IgnoreABI option of Xorg doesn’t solve the problem. This is something that only NVIDIA can solve. (177 and 173 work well)

    Dist-upgrades

    Currently when you dist-upgrade from Hardy to Intrepid, there is no way to update an old driver, say, nvidia-glx-new, to a driver with the new name scheme, say, nvidia-glx-173. You will have to install the driver manually with, for example, “sudo apt-get install nvidia-glx-173″ (there’s no need to uninstall the previous driver, since it will be replaced by the new one).

    Currently we can’t rely on dependencies to make dist-upgrades smooth. If you compare the situation in Hardy with the one in Intrepid and especially if you think that NVIDIA could add and remove the support for more models to/from their drivers in the future, you will see why relying on dependencies wouldn’t be the best choice now.

    SITUATION IN HARDY:

    nvidia-glx-new (169.12):
    Geforce 5xxx, 6xxx, 7xxx, and a few models of the 8xxx series

    nvidia-glx-new-envy (173.14.09):
    Geforce 5xxx, 6xxx, 7xxx, and a few models of the 8xxx series

    nvidia-glx, nvidia-glx-envy (96.43.05) in Hardy is a legacy driver which supports:
    Geforce 2xxx, 3xxx, 4xxx, 5xxx, 6xxx, 7xxx up to 7800

    nvidia-glx-legacy, nvidia-glx-legacy-envy (71.86.04) is another legacy driver which supports:
    RIVA TNT/2, Vanta/Vanta LT, GeForce 256, GeForce DDR, GeForce2, Quadro2
    Pro

    SITUATION IN INTREPID:

    nvidia-glx-177 (177.13):
    Geforce 6xxx, 7xxx, 8xxx, 9xxx, GeForce GTX 260, GeForce GTX 280

    nvidia-glx-173 (173.14.09):
    Geforce 5xxx, 6xxx, 7xxx, 8xxx, 9xxx

    nvidia-glx-96 (96.43.05):
    Geforce 2xxx, 3xxx, 4xxx, 5xxx

    nvidia-glx-71 (71.86.04):
    RIVA TNT/2, Vanta/Vanta LT, GeForce 256, GeForce DDR, GeForce2, Quadro2 Pro

    As Martin Pitt suggested, we could have metapackages for each card series so that, for example, if NVIDIA decides to drop the support for GeForce 6xxx from driver 177, we can make the metapackage depend on driver 173 instead of 177. This is something which we might do in the next future when the hardware database for Jockey is ready. In the meantime we have no way to see which card series a card belongs to by relying only on its pci-id. Therefore we are working on an alternative solution (see the “Plans” paragraph).

    nvidia-xconfig

    Please be careful if you’re planning to use nvidia-xconfig. Xorg-server 1.4.99.901 removed support for the RgbPath option but nvidia-xconfig will add the following line to the “Files” section of your xorg.conf:

    RgbPath "/usr/lib/X11/rgb"

    You will have to comment it out.

    NVIDIA should fix this soon.

    Jockey

    Jockey doesn’t support the new NVIDIA drivers yet, therefore you shouldn’t use it to install the NVIDIA driver (yet). I’ll work with Martin on this so that Jockey can keep rocking as usual.

Plans

    Dist-upgrades

    We will handle 2 cases: dist-upgrades done through Update Manager and the ones done from the command line.

      Update Manager

      If any version of the nvidia driver (with the old name schemes) is installed, basic hardware detection should be performed and the appropriate driver should be installed.

      Command line

      If the dist-upgrade is done from the command line we can’t install the appropriate driver automatically during the dist-upgrade (you can’t call apt while apt is in use). As Martin suggested, all we can do is warn our users through debconf so that they will know what to do. I have already implemented Martin’s idea by creating “nvidia-common”, which you can find in my PPA (NOTE: this is not the final release).

      How does nvidia-common work?
      nvidia-common depends on 4 new packages (nvidia-VERSION-modaliases) which contain the lists of the pci-ids of the NVIDIA cards supported by NVIDIA’s proprietary drivers. Such lists are generated automatically when the packages of the drivers are built therefore, when a driver is updated, its list of pci-ids will be updated too.

      My Python program will detect the pci-id of your card and find the newest driver which supports it. If you have more than 1 one card plugged in, then it will look for a driver which supports all your cards and install that if available, otherwise the newest driver will be chosen (since I guess that you would prefer using your GeForce 9xxx rather than your GeForce 2).

      This check is (currently) triggered in 3 cases:
      1) when nvidia-common is installed
      2) when the kernel image is installed/updated
      3) when the kernel headers are installed/updated

      If you haven’t a driver with the old name scheme installed or if your card is not supported you won’t see any debconf dialog, otherwise you should see something like this:

      How to test it on Hardy:
      add my PPA to your software sources:
      deb http://ppa.launchpad.net/lrm-intrepid/ubuntu intrepid main

      and install only nvidia-common (revision ubuntu12 or higher) and let it install its dependencies (i.e. the modalias packages). Then disable the PPA. Do NOT install any other package. You should see a debconf screen. The same will happen if you reinstall the kernel headers or image.

    Backports
    The drivers will be updated in the backports repositories as they will be actually backported from Intrepid+1 to Intrepid.

Credits

    Ben Collins:
    gave me some tips on TLS for the drivers.

    Bryce Harrington:
    has been very available and has followed all the steps of the migration to the new NVIDIA drivers.

    Mario Limonciello:
    tested the packages and gave me a few useful tips.

    Martin Pitt:
    guided me through the migration and has been very available. He gave me a lot of feedback on the packages, on the new name schemes and on how we should deal with dist-upgrades. His experience has been invaluable. Furthermore he is doing all the uploads for me.

    Timo Aaaltonen:
    did the merge of the Debian package with my initial package (hoping that the changes could be merged back into Debian) thus providing me with a new base to work on.
    Furthermore he suggested the use of a dynamic dependency on the server ABI (so that we don’t have to hardcode it in the source) like the Intel driver does.

Posted by admin | July 15, 2008 5:59 pm
Filed under: Planet,Ubuntu
Comments (14) |


It took me some time to update the FGLRX and the NVIDIA driver in Ubuntu since I’m working on the drivers for Intrepid and on my new projects for Ubuntu. Furthermore driver 173.14.09 breaks the compatibility with realtime kernels and I didn’t want to upload something which would cause problems to a lot of users. For this reason I have written a patch (thanks to mizvekov from the NvNews forums for the tips) which will fix this problem while keeping the compatibility with non-realtime kernels.

Both the NVIDIA and the FGLRX contain a lot of fixes and I need your help to test the packages so that we can get them into hardy-updates (i.e. the stable repositories) soon. Please report your experience with the driver in this bugreport.

NOTE: the instructions to enable and use -proposed are in the bugreport (see Martin’s link)

Posted by admin | July 8, 2008 8:52 am
Filed under: Envy,GNU/Linux,Planet,Ubuntu
Comments (14) |


Today, I’ve uploaded the latest release of the NVIDIA driver (173.14.05) to the the hardy-proposed repository (you should thank the Ubuntu-SRU and the MOTU-SRU teams for this). This is the bugreport containing the request for a SRU (Stable Release Update). Please test the new driver and post your comments there so that we know whether the driver works well for you too, and if it does, the update will be moved to the stable repository.

NOTE: this update won’t affect Ubuntu’s official linux-restricted-modules but only the linux-restricted-modules-envy so that nothing will break if you use the former.

Instructions:
All you have to do in order to test the new driver is enable the hardy-proposed repositories, refresh your list of packages and:
1) if you have already installed the driver through EnvyNG you should receive an update through Update manager
2) otherwise you will have to install and launch EnvyNG and select the “Manual selection of the driver” (since I haven’t had the time to update EnvyNG’s compatibility list for the automatic detection).

News:
I promised that I would blog about the projects I was assigned at the UDS and here’s the first news: I’ll maintain the NVIDIA driver for Ubuntu Intrepid together with Timo Aaltonen while Mario Limonciello will take care of the ATI (fglrx) driver. We’ll use DKMS for both drivers.

Stay tuned for more news and please help us testing the driver.

P.S. I’m working on the latest ATI driver too

Posted by admin | June 11, 2008 9:00 pm
Filed under: Envy,GNU/Linux,Planet,Ubuntu
Comments (45) |


I’ve been experiencing problems with people who said that they had sent me emails which I never received. I thought there were some temporary problems with my mailbox (with alice.it) since it’s not unusual to see the pop server complaining for nonsensical reasons.

This morning I noticed that I had no new messages in Evolution (my email client of choice) and this was a bit weird since I’m subscribed to a few mailing lists. I tried accessing my mailbox from alice’s web interface and, while it was true that there were no new emails, I noticed that there were about 860 emails in the junk folder, even though I had never set up a junk filter. A lot of emails were spam but a number of other messages were not. The website says that the emails in the junk folder are automatically deleted after 20 days. Now I’m wondering how many emails I lost all these years thanks to such a smart junk filter (which I hope I have disabled for good now).

If you sent me an email and didn’t receive a reply, it is very likely that alice’s spam filter is to blame.

P.S. If you sent me an email on adding the latest release of the graphics driver then I’ve definitely received a lot of them but I haven’t replied yet since I’ve been very busy with some new projects which I hope to be able to show soon. I will blog about the new drivers soon too since, in case you had doubts, I’m working on them.

Posted by admin | June 5, 2008 4:08 pm
Filed under: Daily routine,Planet,Ubuntu
Comments (3) |


I haven’t blogged for a while since I’ve been very busy and and I was too tired to blog or to do any actual work on my projects. This was my 1st time at the UDS and my 1st time abroad. It was a dream-like experience and went far beyond my expectations. I have met lots of interesting people ranging from developers to forum staff. We discussed about the new features in Ubuntu Intrepid 8.10 and, as a result, a few non-trivial tasks have been added to my todo list (I’ll blog about this later). The sessions were very well organised and the topics were extremely interesting but unfortunately I couldn’t attend them all at the same time.

We had a lot of fun and I would like to thank all the people who contributed to make this UDS rock.

In case you haven’t noticed, I appeared in some photos on flicker and in some blog posts:
A Kubuntu session

Here are a few photos taken with Emanuele Gentili’s camera with some very interesting people.

myself, Mark Shuttleworth and Emanuele Gentili

Martin Pitt and I

Emanuele Gentili, Timo Aaltonen and myself

Emanuele, Henrik Nilsen Omma and myself

Agostino Russo, me and Emanuele

myself and Emmet Hikory

me, Scott Kitterman and Emanuele

Emanuele, Rob Savoye (the GNASH guy) and myself (a special thanks to MaryBeth Panagos – the girl in the background – who provided the nice “Gnash Cygnal” logo).

WARNING: talking to Rob about programming will dramatically decrease your self-esteem. He’s a genius.

A creepy guy on the 3rd floor… :-P

Posted by admin | May 25, 2008 3:50 pm
Filed under: Planet,Ubuntu,UDS
Comments (3) |


It’s been a month since my last blog post. EnvyNG was included in Hardy but it had a few problems and I have worked to fix them. I can’t upload such fixes since Hardy is a stable release. This means that all the updates will have to be tested before they are moved to the stable repositories. This is why I need your help. The more users test the fixes the sooner we can get them into stable.

Special Thanks:
All this wouldn’t have been possible without the amazing support of Martin Pitt, who guided me and helped me with the SRU (Stable Release Update). He has spent a lot of time on EnvyNG, gave me a lot of extremely useful suggestions, therefore I can say that you should really thank Martin for this release.

Timo Aaltonen brought bugs #212648, #186382, #118605 to my attention and suggested the solution. In case you don’t know it already, he’s one of the guys who take care of Ubuntu’s restricted modules. Keep up the good work, Timo!
(more…)

Posted by admin | May 10, 2008 10:16 am
Filed under: Envy,GNU/Linux,Planet,Python,Ubuntu
Comments (65) |


I’m working on EnvyNG every day. I’m fixing as many bugs as possible. Here’s a list of what’s changed in EnvyNG and Envy Legacy:

Improvements in EnvyNG-core:
* New connection detection method (based on Network Manager)
* Update compatibility list
* Update translations
* Use unicode (utf-8) for the translators' names
* Use an additional xorg.conf parser in order to set the default colour depth

EnvyNG checks the availability of an Internet Connection either by asking Network Manager (through dbus) or (if you don’t use network manager) by using only Python’s “urllib2″. This solves Bug 211620.

The latest update of EnvyNG-core includes an additional xorg.conf parser which should finally solve the problem with ATI cards which don’t have a “defaultdepth” option set in xorg.conf. This made the Xserver crash (at times?) since the fglrx driver assumed that the default colour depth was 8bit.

Improvements in EnvyNG-qt:
* The links in the about dialog can be selected with the mouse cursor
* Fix complete dialog showed up when restart dialog should have
* About dialog can expand now
* Fix if both EnvyNG-qt and -gtk are installed, -qt should be the one which is launched on KDE

Improvements in EnvyNG-gtk:
* GTK filechooser points to /home by default

Bugfixes in Envy Legacy:
* Fix Bug #210392 in classes
* Catch exception in classes.restorenvfolder()
* Add "n/a" to dkms blacklist so the unofficially dkms is not installed
on Debian Lenny (Lenny is still unsupported)

Should you find other bugs, please report them to me.

Posted by admin | April 9, 2008 3:15 pm
Filed under: Envy,GNU/Linux,Planet,Python,QT,Ubuntu
Comments (73) |


I’ve set up a new PPA repository for Hardy containing EnvyNG 1.1.0. The repository includes a new version of the three packages with a few bugfixes.

Add this line to your /etc/apt/sources.list so as to be sure to get always the latest release of EnvyNG :
deb http://ppa.launchpad.net/envyng-hardy/ubuntu hardy main

Update your list of packages:
sudo apt-get update

and then, for the textual installer, type:
sudo apt-get install envyng-core

or for the GTK GUI:
sudo apt-get install envyng-gtk

or for the QT4 GUI::
sudo apt-get install envyng-qt

I have followed your suggestions and I’ve fixed a few inconsistencies in the QT4 interface, therefore I need you help again with the translations for just 1 word (“Cancel”). I’ve tried to use what Rosetta suggested as alternative translations from other packages (i.e. firefox 3) therefore some translations will look like they are complete but please check that everything’s ok even in such case.

Thanks again.

P.S. please keep reporting bugs so that I can fix them ASAP.

EDIT: I had posted the wrong repository. Sorry for the inconvenience.

Posted by admin | April 2, 2008 5:38 pm
Filed under: Envy,GNU/Linux,Planet,Python,QT,Ubuntu
Comments (35) |