~ubuntu-branches/ubuntu/utopic/glx-alternatives/utopic

« back to all changes in this revision

Viewing changes to debian/glx-diversions.README.Debian

  • Committer: Bazaar Package Importer
  • Author(s): Andreas Beckmann
  • Date: 2011-06-24 02:44:16 UTC
  • Revision ID: james.westby@ubuntu.com-20110624024416-4qwm2oi7tfi5ach5
Tags: 0.1
* Upload to unstable.
* Put slave alternatives into a private namespace (prefix 'glx--').
* Document the alternatives/diversions in glx-diversions.

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
Short summary about selecting a glx implementation
 
2
==================================================
 
3
 
 
4
To switch between the GLX implementation from MESA, NVIDIA and AMD(fglrx),
 
5
use
 
6
 
 
7
    update-alternatives --config glx
 
8
 
 
9
 
 
10
 
 
11
Detailed description of the diversions/alternatives for libGL.so.1 etc.
 
12
=======================================================================
 
13
 
 
14
The GPU vendors NVIDIA and AMD provide proprietary drivers including GLX
 
15
acceleration for their hardware.  Therefore they need to replace the free
 
16
implementation of libGL.so.* (from MESA) and the X.Org module libglx.so with
 
17
a vendor implementation.  NVIDIA furthermore maintains several legacy driver
 
18
versions that support older hardware.
 
19
 
 
20
Simply packaging all of them and having each packaging divert the files that
 
21
are going to be replaced (as it was done in the past) causes several
 
22
problems:
 
23
  - All the packages conflict with each other, so only one driver can be
 
24
    installed at a time and it can only be disabled (i.e. switching back to
 
25
    MESA) by uninstalling the driver again.
 
26
  - While a single driver should be sufficient for e.g. a normal desktop
 
27
    system, it is insufficient for e.g. a live CD (which would have to
 
28
    detect the GPU, select the appropriate driver and libraries and
 
29
    configure X.Org accordingly at boot).
 
30
  - The rather complicated code maintaining the diversions is duplicated
 
31
    several times.
 
32
 
 
33
Therefore we changed this in the following way:
 
34
  - Only one package (glx-diversions) handles the diversions, any package
 
35
    requiring the diversions of libGL.so*, libglx.so needs to declare a
 
36
    dependency on this package.
 
37
  - Vendor implementations are installed into a private library directory
 
38
    instead of the locations of the diverted files.  This allows parallel
 
39
    installation of different drivers without becoming active immediately.
 
40
  - To activate an implementation (and to allow easy switching between them)
 
41
    an alternative "glx" is being registered with slave alternatives for all
 
42
    the libraries, modules and other files of that implementation.  This is
 
43
    handled by the glx-alternative-{mesa,nvidia,fglrx} packages.
 
44
  - As the implementations are split into several packages and optional
 
45
    packages may be installed/removed later on, triggers are being used to
 
46
    automatically update the alternatives whenever files of that vendor
 
47
    implementation are added or removed.
 
48
 
 
49
To switch between the GLX implementation from MESA, NVIDIA and AMD(fglrx),
 
50
use the command
 
51
 
 
52
    update-alternatives --config glx
 
53
 
 
54
For NVIDIA an additional alternative exists that allows one to switch
 
55
between the current driver and legacy versions.  For selection use the
 
56
command
 
57
 
 
58
    update-alternatives --config nvidia
 
59
 
 
60
The actual list of choices of course depends on the packages currently
 
61
installed on the system.
 
62
 
 
63
 
 
64
libGL.so
 
65
========
 
66
 
 
67
The libGL.so link is managed by a dpkg trigger as an alternative, too.
 
68
But there are no alternative solutions available besides the diverted link
 
69
from the libgl1-mesa-dev package (if this package is installed), so this
 
70
cannot be reconfigured.  The intention behind this is to always link an
 
71
application at compile time to the MESA implementation of libGL.so.1 in
 
72
order to produce portable binaries, but to use the accelerated libGL.so.1
 
73
when the application is being executed.
 
74
 
 
75
 
 
76
 -- Andreas Beckmann <debian@abeckmann.de>  Wed, 22 Jun 2011 12:44:11 +0200
 
77