driver list doesn't contain "via" driver

For mentoring:

Is there actually no "via" driver available in the drivers list that is provided by guidance or does it not get displayed?

Perhaps affected method:

displayconfiggtk.DisplayConfigGtk._populate_gfxcards

Furthermore it would be interesting to know which cards these exotic drivers like "ast" support? Only some rare framebuffer devices? Do we need all the drivers in our list?

It seems that Guidance doesn't list the via driver at all - the GfxCardModelDB object contains a hard-coded list of drivers, and the via driver (and several others) are not listed there. The displayconfig frontend has information about the via driver in its own information.py file, but it only uses that to improve the info provided by Guidance. And displayconfig really only displays the drivers listed by Guidance, even if information.py contains more drivers.

Thing is, displayconfig should in fact display the list of drivers that are actually installed on the system. An Xorg installation only supports a certain set of drivers (that is: you can only specify certain driver names in the xorg.conf - unknown driver names are rejected). So displayconfig should only list these drivers.
Per default, Ubuntu installs all xserver-xorg-video-* packages, so displayconfig would offer lots of drivers to choose from. But if we don't have a via driver installed (ie. package xserver-xorg-video-via is not installed), the via driver would indeed not be listed in displayconfig.
That would also shift the question of "should some obscure 'ast' driver be included?" to the packagers :-) because then if an Ubuntu release ships and installs the package for some obscure driver, displayconfig will duly offer it. Btw. I only mentioned the "ast" driver because it was the first in the information.py list that was not provided by Guidance :-) so nothing special about it.

The "only" difficult thing is to get the list of available drivers from xorg... /usr/lib/xorg/modules/drivers/ has the available modules, but I think the actual driver names are embedded in the .so files. Maybe there's an official way to ask xorg for that info?
Another way would be that the xserver-xorg-video-* packages install some metadata files that list the actual driver name(s) provided by the package. Maybe that would also make it possible to move the info from Guidance's Cards+ file into this metadata: every driver package could announce there what models it actually supports. Installing a new driver package would automatically extend the driver list and the vendor/model list in displayconfig.

If all that is too big, I think the Guidance driver list should be changed to match the list of default-installed drivers. That would at least hide the problem :-) in that displayconfig lists the "official" drivers, and if you manually install a xserver-xorg-video-* package it just doesn't show up in displayconfig.

Btw. getting the driver list from X seems to be easy. When running `X -configure`, it will print the list of available drivers; and this list is obtained basically by just looking at the names of all *_drv.so (and *_drv.o) files under /usr/lib/xorg/modules/drivers/ . So that might be a way to replace the hardcoded driver list in Guidance.

I have experimented with creating the driver list dynamically from the installed drivers, and it works so far. But I think this approach also has some problems:
- there are drivers that are not documented in the information.py (amd, atimisc, dummy, psb, v4l, and ztv). Of these, maybe the dummy driver shouldn't be listed here at all, and the others should probably be added to information.py. All in all this means that this external information file still has to be kept synced to the list of installable drivers.
- the vendor/model list still contains some "bugs" (independent of the driver list). For example, selecting "Other -> Openchrome" doesn't change the selected driver, probably because the associated driver name (openchrome?) is not contained in the list. It wasn't contained in Guidance's hardcoded list either. And to make it available I probably would have to install the xserver-xorg-video-openchrome package... So why list this card model if the driver is not installed anyway?

I start to like the approach of shipping information files with the xserver-xorg-video-* packages... That could solve at least the two problems I've listed above, and might also make some other features possible. For example, the -via and the -openchrome and the -unichrome packages all seem to support the same devices, so they could all announce that, and displayconfig could list the three drivers in the "Available drivers" list (where it currently only offers open and proprietary drivers).

Such a change would require some discussion with the Guidance devs, I guess.

Thinking about this, maybe it will be too difficult to maintain the Cards+ database if it is spread over the various xserver-xorg-video-* packages... So maybe it would be better to keep the single Cards+ file, but in displayconfig hide all drivers that are not actually installed. And then update information.py (add info for amd, atimisc, psb, v4l, and ztv, and mark the dummy driver as hidden).
That's not as elegant as installing the driver/vendor/model info files with the driver packages :-) but maintenance of the Cards+ file should be easier.

I also cannot see the "via" driver. Ask me about particular details if you need some info.

This is a patch for guidance-backends which will make guidance create the list of drivers on the fly based on the actually installed drivers files. With this, the via driver is automatically displayed in displayconfig-gtk if it is installed. Also, the new psb, sisusb and voodoo drivers will be displayed then, and the glide driver will no longer be displayed.

Based on the previous comment, here is a patch which will hide all graphics card models where the driver is not in the driver list (that is, the driver is not installed).
Currently, when selecting a graphics card where the driver is not in the driver list, the driver list will stay at the old entry, which can be confusing (see for example the Other/OpenChrome model). With this patch, the OpenChrome model will not be displayed, and same goes for some other models with drivers like nvxbox or "None" :-) and also most Sun models will be hidden as they seem to use Sparc-specific drivers.
Also, if a vendor section will be empty because it contains no models, it is hidden as well.

Why not switch it around so that if someone selects a driver that's not installed, give them a prompt with instructions on how to download it. Since we're trying to make things more user friendly to those who don't really know what's going on, I think it would be better to show them, and then just provide feedback, letting the user know they're not installed and how to install them. I'm really new to ubuntu but I am a developer so if someone would like to mentor me with this project i'd love to help with the code. Not exactly sure how the mentoring process works though...

-Kevin

This bug was fixed in the package kde-guidance - 0.8.0svn20080103-0ubuntu9

---------------
kde-guidance (0.8.0svn20080103-0ubuntu9) hardy; urgency=low

  [ Andreas Wenning ]
  * Added kubuntu_22_userconfig_utf8.patch which fixes unicode problems present
    under some locales. (LP: #205487)

  [ Scott Kitterman ]
  * Add kubuntu_20_displayconfig_dynamic_driver_list.patch to dynamically list
    all available driver vendors and not depend on a hard coded list
    (LP: #149793)

 -- Scott Kitterman <email address hidden> Sat, 29 Mar 2008 23:10:20 -0400

For Kubuntu, the front end already had the dynamic driver not installed functionality (that's where the patch for displayconfig-gtk came from), so Kubuntu is done as far as this bug goes.

Thank you for reporting this bug and for your efforts to make
Ubuntu better. As Xorg has improved this past year, an unfortunate side
effect of these improvements is that it has rendered several design
assumptions in displayconfig-gtk obsolete. So, starting with Hardy we
are no longer putting displayconfig-gtk forth as a primary configuration
tool, and are putting our development focus into the Screen Resolution
applet. As a result, we do not plan to fix this bug and thus are closing
it.

For more background on this change, please see this page:
https://wiki.ubuntu.com/X/DisplayConfigGtk