How to enable/disable Ctrl+Alt+Backspace in Kubuntu Jaunty

As you might have noticed already, X.org no longer ships with the DontZap option set to False by default i.e. pressing Ctrl+Alt+Backspace won’t restart the xserver any longer. At the UDS we discussed on how to deal with this change and we came to the conclusion that Ubuntu and Kubuntu would deal with this change in different ways. I worked on both the implementations.

This blog post is about the Kubuntu implementation. Click on the thumbnails to see the screenshots in their full size.

1) Install the “dontzap” package (hopefully this step can be skipped in the future):
sudo apt-get install dontzap

2) Launch “systemsettings”
Kde's menu

3) select the “Display” module
Settings panel

4) click on the checkbox which says “Ctrl+Alt+Backspace restarts the xserver” and press the apply button:
Display Module

5) insert your password
Password dialog

And that’s it.

I’ll blog more about the way you can do it in Ubuntu and from the command line.

Back from the UDS

After spending a week in Sunnyvale I’m back from the UDS. It was a long trip and I can definitely say out loud that it was a fantastic experience, very hard to put into words, part of which you’ll be able to see in the video-recorded sessions (available soon?).

I gave speeches on 3 projects of mine: Xorg Options Editor, Tablet configuration tool (the project doesn’t have a name yet), Display configuration tool (no name yet). I’ll blog about these projects as soon as I clean up the relevant specs and the wiki pages. It’s been an extremely productive UDS and (in addition to these 3 projects) I think I have already work for Jaunty+1 (and maybe Jaunty+2 too). The feedback I received was really great.

The Silicon Valley is exactly as I expected (if you played GTA San Andreas you know what I mean) and I really liked the place, which is very different from the European towns I visited.

The UDS is all about people (apart from serious development) and I met a lot Ubuntu enthusiasts. I met some old friends and made a lot of new acquaintances. Actually the term “acquaintances” doesn’t do justice to these extremely nice people which therefore I’ll promote to “friends”:

mv acquaintances friends ;)

Having studied Spanish (together with English) at the university, I had a great chance to practice my Spanish with Ara, María and Luis and I also bugged them with some notions of Spanish Linguistics that I learnt. Do you see the irony? An Italian guy who talks to native Spanish speakers about some peculiarities of their own language 😉

I also received a lot of hugs and ended up in the Ubuntu Hall of Fame. I really didn’t expect to see myself on that page, therefore I was very surprised when Bryce showed my picture and the article on his laptop. A lot of people congratulated me on this achievement but all I have to say is simply that it’s the Ubuntu Community that really rocks. I have yet to find another community which makes you feel not only at ease but perfectly integrated, as in a very big family. It’s definitely something you have to experience (at least) once in your life.

I won’t list the names of all the people I met since I really wouldn’t like to flood Ubuntu planet but I would really like to thank them all for being so nice to me and for making this UDS even better than the one in Prague (which I deemed impossible).

A special thanks to Google for hosting the event at the Googleplex (Mountain View). It’s a really cool place and I met Guido Van Rossum (yes, the creator of Python) there. I told him that I started learning programming thanks to Python and he joked about it by replying that he was sorry that his language made me enter the programming world. A very cool guy.

A big thanks to Canonical for sponsoring my travel and to all the people who made this possible.

Call for testing: NVIDIA drivers and nvidia-settings in Intrepid

As promised, NVIDIA drivers 71.86.07 and 96.43.09 are now available for testing in Intrepid’s proposed repositories. If you don’t know how to use these repositories you can read the instructions.

Please give feedback here (say something like “driver 96 works for me”, etc.).

There is also a small fix which will solve a problem with diversions for drivers 177 and 173.
Please give feedback here

I have also fixed a bug in nvidia-settings (i.e. NVIDIA’s control panel) which made it segfault when no ServerLayout section is available in the xorg.conf.

Please test the package and give feedback here.

The sooner you test these packages, the sooner they will enter Intrepid’s stable repositories.

Some updates on the NVIDIA driver in Intrepid and Hardy…

First of all, happy release to you all.

I have noticed that NVIDIA released two beta drivers which work with Intrepid’s X.org and I will make new packages available in the -proposed archives ASAP. In the meantime you might want to see why I recommend you to wait for these packages. Keep an eye this bug report so as to know when these packages are available for testing.

As regards Hardy, I need a plan to backport driver 177 from Intrepid without breaking dist-upgrades and/or the available drivers. I should also update the fglrx driver in my lrm-envy.

Stay tuned.

A few updates on EnvyNG, NVIDIA and URandR

EnvyNG:
I have updated envyng-core (2.0) and envyng-qt (2.0) in Intrepid. The GTK interface doesn’t work and even if I managed to solve the problems with GTK and threading I couldn’t upload it since we’re in feature freeze.

The new textual interface and the QT4 interface now rely on python-apt and python-xkit. Thanks to the work I did on the drivers I won’t have to keep the compatibility list updated since it will rely on the same system which we are using for Jockey.

By testing EnvyNG you will (indirectly) help Jockey too since you will test X-Kit and some other features I have worked on for Jockey.

NOTE: if you have this problem please have a look at the suggested solution in the same bug report.

NVIDIA and kernel 2.6.27:
Currently only driver 177.68 seems to work with 2.6.27. I have written a patch for driver 173 too, however I’m experiencing a rather nasty problem.
EDIT: the driver works well with a new patch now

URandR:
as you can see on Bryce’s blog I am now contributing to GNOME’s Monitor Resolution Settings panel. There is still some work to do (in C) and I’m having a lot of fun with it. I find it a great program and I’m focusing on it instead of completing the rewrite of URandR. I’m not saying that URandR is dead but it’s development has stalled.

Stay tuned

NVIDIA driver 173.14.12 in hardy-proposed and intrepid

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.

Blueprint – X-Kit and Xorg Options Editor

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.

Updates on the NVIDIA drivers in Intrepid

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.

NVIDIA 173.14.09 and FGLRX 8.6 in hardy-proposed

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)