EnvyNG
Current situation
Envy has demonstrated that there is a strong use case and need from users wishing to get newer versions of nvidia and ati drivers than is officially available in Ubuntu. Unfortunately, currently it can cause conflicts and inconsistencies with linux-restricted-modules ("l-r-m") esp. during upgrades.
Currently, envy gets the installer from either ATI or nVidia's website and packages it by using a customized version of Ubuntu's packaging scripts. It uses the same package names, but epoch'd versions so as not to get overwritten by Ubuntu's updates. Then Envy sets up the environment by installing dependencies, building the kernel module (via module-assistant), installs the packages, sets up the xorg.conf, and blacklists Ubuntu's restricted drivers. To blacklist the ubuntu drivers and stop the install override for modprobe.d, Envy adds the driver to /etc/default/linux-restricted-modules-common, comments out the content of /etc/modprobe.d/lrm-video, and removes any /lib/linux-restricted-modules/.nvidia*. To undo things, the user can run 'sudo envy --uninstall-all', and the user is expected to do this prior to doing a dist-upgrade, else they'll run into conf file mismatches and other issues.
Envy does not automatically update itself when new upstream drivers are released; but all that's required is to update the version of the driver in envy and set the new md5 of the installer.
Since Envy uses epoch'd versions, l-r-m is never able to update the drivers, even if it has ones that are newer than what Envy supplied. This can particularly be an issue if the user does a dist-upgrade and forgets to remove Envy.
Objective
Envy is a mechanism well appreciated by the user base. We want to make it play better with linux-restricted-modules by eliminating the version conflicts and making both packages more aware of the others' changes and status. We want to make l-r-m able to upgrade over Envy when appropriate. We want to make Envy more policy compliant and tie in with existing updating tools as much as feasible.
Ultimately, in doing all of this our hope is to gain the user-friendliness of Envy for users to easily upgrade to the newest drivers, while still retaining the solid policy compliance achieved when using l-r-m and eliminating problems when upgrading back and forth between the two.
When drivers become available via Envy, they should probably also be provided via ubuntu-backports, so that users following along there can benefit from gaining them automatically when they update.
Design Notes
In order to avoid kernel inconsistencies with l-r-m, Envy should be modified to use dkms for building the kernel module. Module components should be kept in a directory under /var/cache.
In order to enable seamless updates, envy needs modified to not place an epoch version, and to instead use natural versioning. l-r-m in turn needs modified to have some internal checks to detect if envy-provided modules have been installed, in which case it should ascertain the envy module versions and only upgrade if it has a newer version.
For a given driver, sometimes we wish to carry one or more legacy versions due to dropped hardware support or other issues. Currently we carry 3 different nvidia modules; it's conceivable we could end up with 4, or perhaps have a second fglrx module. Both l-r-m and envy need to be aware and in sync regarding which variant the user wishes to use, so that they don't accidentally upgrade to a different variant. This could be done via a special file that is installed by either package, containing an indicator of which .ko module to load.
l-r-m scripts like lrm-video will need modified to compare its version against the envy version, and load the latter instead of its own when it detects that glx is from envy and newer than what it has. This way, Envy can continue to generate the nvidia and fglrx glx packages for xorg driver and the GL libraries, and l-r-m can more properly take care of the kernel module side of things. In the case where l-r-m has newer versions of glx, it will then automatically upgrade to the l-r-m packages [does this imply running 'sudo envy --uninstall-all', or would l-r-m be able to replacing all needed files independently?]
Restricted Manager needs updated to give the user a choice between using the official Ubuntu (l-r-m) package, or the latest from nvidia or ati (envy). The former should be the preferred default, but perhaps this can be communicated via proper verbage ("stable" vs. "unstable"?)
Envy will change to use guidance-backends for updating the xorg.conf, so we have the same parser/updater as we're using with displayconfig-gtk, restricted-manager, etc. Reducing the number of different codes fiddling xorg.conf will simplify future maintenance and diagnosis of xorg.conf issues. We'll need to ensure guidance-backends allows updating driver options, which envy needs to do.
Direct action items
(DONE) tseliot will set up bzr branch for envy
- (DONE) tseliot will review l-r-m packaging scripts for nvidia and fglrx
- (DONE) Add DKMS support to the NVIDIA packages (instead of relying upon module-assistant)
- (DONE) Make sure that any version of the ATI driver supports DKMS
- (DONE)(CODE AVAILABLE) tseliot will investigate switching to use of guidance-backends/displayconfig/xorgconf.py
- benc will review envy code
- (DONE) dholbach will start a wiki page
- (DONE) dholbach will start the next "meeting" via email next week, with the goal of reviewing/finalizing this page
- Consider cc'ing kernel team and/or ubuntu-x@ mailing lists
- (DONE) bryce will flesh out EnvyNG with decisions from meeting
- (DONE) bryce will post irc log
- (DONE) bryce will check that guidance-backends permits driver option updating - nope
- (DONE) bryce will investigate into if l-r-m could be updated to use guidance-backends for xorg.conf updating
- Longer term we should probably come up with some simpler, more universal xorg.conf editing tool
- (DONE) bryce will evaluate doing automatic driver builds
- mvo will investigate what needs done to update restricted-manager to interface with envy as well as l-r-m
- mvo will review envy user interface for ways of integrating it more officially into Ubuntu
Future plans
- Make the new drivers be available through ubuntu-backports.
- It's not clear if/where this ties in with envy/l-r-m, but it seems that there should be synergy here.
- Auto-updating would minimize the work, but incurs risk of buggy drivers turning ubuntu-backports too dangerous
- Doing testing of updates before putting into ubuntu-backports minimizes danger, but adds extra month-to-month work
- Maybe if we had something like ubuntu-backports-proposed that gets auto-updated, with user-driven testing to filter out bad drivers, and permit drivers with sufficient testing to be automatically promoted to ubuntu-backports (and maybe also into envy?)
- (DONE byt tseliot using PPA)Use the buildd's instead of building packages on user's machine
- The current and proposed models above include a "download and build packages locally" mechanism
- Building them centrally may be more reliable
- Building them centrally would leave users of custom kernels without an easy way to install the driver
- Downloading pre-built packages may give faster result than waiting for a build to complete
- When building locally, if there are variations in dependencies the resulting package will have unknowns
- Could result in issues we couldn't test for ahead of time
- Will make reproducing issues more challenging
- But if we're making Envy more official, we'll be expected to address such issues!
- Building them locally will fail with Ubuntu's real-time kernels (actually only the kernel module wouldn't build)
- OTOH, buildd-built packages may not be a perfect match for user's system
- They could have made other modifications (custom kernel, custom X, ...) where building locally would work better
- Requires we provide builds for a wide variety of distro versions, etc.
Possible Solutions to the problems between Envy and the LRM
Problem N.1
Ubuntu and Envy's packages should not try to overwrite each other when it's not required.
Aim:
Only when either Ubuntu or Envy have a more recent driver then one of them should overwrite the other (if the user decides so). When the kernel's ABI changes nothing changes in nvidia-glx. The kernel modules still remain in the linux-restricted-modules.
DKMS is unaffected by Kernel's ABI changes therefore Envy's packages should not be overwritten by Ubuntu's (even in case of ABI change) unless a new version of the driver is available.
Solution:
Envy will adopt the same version schemes as the lrm but use an ABI such as 500 and append a ".envy"
500.16.envy
Results:
“nvidia-glx-new_169.09+2.6.22-14-14.10_i386.deb” becomes "nvidia-glx-new_169.09+2.6.22.4-500.10.envy_i386.deb" "xorg-driver-fglrx_7.1.0-8.37.6+2.6.22.4-14.10_i386.deb" becomes "xorg-driver-fglrx_7.1.0-8.37.6+2.6.22.4-500.10.envy_i386.deb"
Ubuntu or Envy will overwrite such driver if they can provide a package with a higher version.
Problem N.2:
Envy and other's driver packages need Ubuntu's restricted modules to be blacklisted in the /etc/default/linux-restricted-modules-common. If Ubuntu overwrites Envy's package (thanks to the solution to problem 1), the kernel module won't be loaded because such module would still be blacklisted /etc/default/linux-restricted-modules-common. Aim: the switch from Ubuntu's to Envy's packages (and vice versa) should be as smooth as possible, with no driver API mismatch, etc.
Solution:
in Envy: the packages built by Envy will contain an empty file (e.g. “envy-dkms”) which they will put in a directory (e.g. /etc, /var/log). Envy will use DKMS.
in /sbin/lrm-manager: KMACH="$(uname -m)"
This part should be at line 28, after sourcing the lrm-common (i.e. . /etc/default/linux-restricted-modules-common)
# check if a driver was installed by Envy
if [ -f /etc/default/envy-dkms ]; then
if [ -f /var/lib/dkms/nvidia/kernel-"$KVER"-"$KMACH"/module/nvidia.ko ]; then
DISABLED_MODULES="$DISABLED_MODULES nvidia nvidia_legacy nvidia_new"
insmod /var/lib/dkms/nvidia/kernel-"$KVER"-"$KMACH"/module/nvidia.ko
elif [ -f /var/lib/dkms/fglrx/kernel-"$KVER"-"$KMACH"/module/fglrx.ko ]; then
DISABLED_MODULES="$DISABLED_MODULES fglrx"
insmod /var/lib/dkms/fglrx/kernel-"$KVER"-"$KMACH"/module/fglrx.ko
fi
fiIf envy-dkms is found and either the ati or the nvidia kernel module is found, lrm-manager appends one of these modules to the $DISABLED_MODULES variable. This is the same as blacklisting a module in /etc/default/linux-restricted-modules-common.
in /sbin/lrm-video:
grep -q -w $XORG; then
if [ -e /etc/default/envy-dkms ]; then
insmod /var/lib/dkms/"$XORG"/kernel-$(uname -r)-$(uname -m)/module/"$XORG".ko
else
modprobe --ignore-install -Qb $@ $MODULE
fiIf envy-dkms is found, then the module ($XORG i.e. either “fglrx” or “nvidia”) from DKMS is loaded instead of the one in the linux-restricted-modules. This is very important in order to make sure that the DKMS is loaded at boot.
Misc
Links
IRC Logs
--> You are now talking on #envy
mvo (n=egon@p54A67D0E.dip.t-dialin.net) has joined #envy
<dholbach> let's hope Alberto turns up... he said the time would be good for him
<mvo> yeah
noone from the kernel guys here?
<dholbach> mvo: BenC said he'll turn up
<mvo> ok
--> tseliot (n=tseliot@87.18.249.120) has joined #envy
<tseliot> hi all
<dholbach> hey tseliot
how are you doing?
<tseliot> fine thanks ;)
<dholbach> great... I know you talked to mvo before - did you talk to bryce too?
<tseliot> yes, a few times
<dholbach> nice
--> BenC (n=bcollins@debian/developer/bcollins) has joined #envy
<dholbach> we're still waiting for BenC to turn up
ahh there he is
<BenC> sorry
is there a phone line too?
<dholbach> tseliot, BenC: did you talk to each other before today?
oh... no - just an IRC meeting
<mvo> hello tseliot!
<BenC> ok, good :)
dholbach: no, haven't talked to him before today
<tseliot> dholbach: yes, about the problem with NVidia and wfb
mvo: hi
<dholbach> great
<BenC> ah, right, there was that :)
but not about envy
<dholbach> tseliot: so can you tell us what envy does right now and how it works, so we are all on the same page?
<tseliot> dholbach:ok
it gets the installer from either ATI or Nvidia's website
and packages it by using a customised version
of Ubuntu's packaging scripts
<BenC> does it use the same package names as we do?
<tseliot> BenC: yes, but the version is different
so as not to get overwritten
by Ubuntu's updates
then Envy sets up the environment i.e. it installs
all the dependencies required by such packaging scripts (only for the Nvidia driver)
and builds the kernel module with module-assistant
and then installs all the packages
finally it blacklists Ubuntu's restricted drivers and sets up the xorg.conf
questions?
<BenC> how does it blacklist just the ubuntu drivers, and stop the install override for modprobe.d (lrm-video call)?
basically, I'm wondering how policy compliant all this voodoo is :)
<tseliot> BenC: Envy adds the driver to /etc/default/linux-restricted-modules-common and comments out the content of /etc/modprobe.d/lrm-video
<BenC> also, does the versioning allow for the ubuntu packages to regain preference if we end up providing a newer nvidia/ati driver than what they have via envy
<tseliot> it also removes any /lib/linux-restricted-modules/.nvidia*
I guess not. Here is an example of the version of a package generated by Envy:
Package: nvidia-glx-new
State: installed
Automatically installed: yes
Version: 1:100.14.23+2.6.22-14
<BenC> ah, so it epochs
<tseliot> all can be undone by typing: sudo envy --uninstall-all
<BenC> what happens when a user upgrades lrm-common, and it asks them about replacing conffiles that you've modified, and they say "yes, use newer conffile"?
<bryce> when new drivers are released upstream, do you manually update the envy package, or do you have scripts to do this automatically?
<tseliot> BenC: a mismatch? This is why I recommend to uninstall the driver from Envy before a dist-upgrade
<tseliot> bryce: I only have to change the version of the driver in my script and to set the new md5 of the installer(s)
<tseliot> no, autoupdate is not implemented
--> seb128 (n=seb128@ubuntu/member/seb128) has joined #envy
<dholbach> first of all: thanks tseliot for your work, I think you've shown that there's a big demand for getting more recent versions of nvidia/ati drivers into Ubuntu :-)
<mvo> I wonder if we couldn't use this cool auto-update feature to get regular updates (e..g via -backports) of the nvidia packages
<tseliot> dholbach: thanks
<mvo> it seems like there is a real demand for this feature and it would be cool to move it close to ubuntu (if tseliot is happy with that of course). what do you think ?
(you == kernel and X.org :)
<BenC> tseliot: yes, and thanks for taking my questions...not trying to poke holes in your work, just making sure I understand how things work :)
<dholbach> it'd be great, if we could share resources on that and make it happen across the board inside of Ubuntu
<tseliot> mvo: it's very interesting
BenC: no problem ;)
<bryce> tseliot: same here; I've read through the scripts, you're meeting an important need from the community
<BenC> sounds like the best place for this is right inside lrm, but the mechanism has to be more policy compliant, and the possibilities for "oh shit, I broken things" need to be lessened
<tseliot> mvo: how would the kernel module be built? With dkms?
<mvo> my vision is that we get regular updates (based on the envy script) into -backports, but closer to our policy. then envy (the brand is good and strong) could become the downloader for those packages
<bryce> one thing I notice though is that there's a quite large difference between how envy handles drivers, and how lrm's approach. I think this gap could be closed, but currently the two approaches are likely going to conflict often
<mvo> tseliot: BenC knows better how the modules would have to be build, I'm not really familiar with l-r-m
<tseliot> bryce: I can adapt Envy
<bryce> cool
<BenC> well, something like dkms would be good, we already have the hooks in place for it
<bryce> the thing that looks best with envy is its user interface
<tseliot> bryce: I might rework the logo :-P
<BenC> we could store downloaded module components in /var/cache/ I guess
<bryce> it seems like if envy could be adapted to use l-r-m on the backend, but still provide users with the friendly frontend for finding and downloading the updates, it would meet the needs and avoid the conflicts
<tseliot> BenC: the next release of the fglrx driver will use dkms by default
<BenC> kernel modules are the easy part...the hard part is the nvidia-glx* conflicts
same for fglrx
<bryce> mvo, mentioned that there isn't an autoupdate function, however I've been working on such a feature the last few weeks, which could be plugged into this as well
<tseliot> another thing: Envy uses the packages generated by the fglrx installer instead of making its own
<bryce> tseliot, how familiar are you with lrm's internal packaging scripts?
<BenC> just a quick note, I have a conf call in 38 minutes (18:00 UTC)
* mvo is happy to help with the frontend code that deals with download/installing/enabling repositories via python-apt
<tseliot> bryce: I studied them a bit, stripped them down, etc. I can work with them
<bryce> cool
<BenC> tseliot: one thing I'd like to see is lrm+envy ensure that if we provide an nvidia/fglrx driver that is newer than what they have installed, then it will use ours (or atleast allow the user to configure that preference)
<tseliot> mvo: I can switch to python-apt
<dholbach> do you all think we can tackle the problem spec-style? or at least start off with a wiki page that lists all the different ideas or packages that needed to be modified?
<BenC> tseliot: and I'm more than happy to work with you on lrm internals, and setting up dkms hooks, etc
<tseliot> BenC: this would mean changing the version of the packages and other things
<dholbach> tseliot: is your code available in a bzr branch? you seem to be using LP for envy generally already: https://launchpad.net/envy
<tseliot> dholbach: no, I'm only using it for bug reports
<dholbach> ah ok
<tseliot> but I can start a new bzr branch, as I did with URandR
<dholbach> nice
<tseliot> BenC: thanks
<bryce> that'd be a good idea
<BenC> tseliot: well, if the epoch was removed, then natural versioning would allow our nvidia-glx-new package to update, and then we would just need internal checks to match provided modules or generated modules, with this installed package
<tseliot> dholbach: making a new spec would be a good idea
<dholbach> shall we use https://wiki.ubuntu.com/EnvyNG for collecting ideas?
<BenC> dholbach: sounds good
* mvo nods
<bryce> works for me too
<tseliot> ok
BenC: ok, we should work on those checks then
<dholbach> I just did the initial page
<BenC> tseliot: could be as simple as the envy created nvidia-new-glx containing a special file to test on
<bryce> probably just one of us should work on it presently, else we'll get wiki conflicts ;-)
<dholbach> maybe we should just add the wiki log into it later on and subscribe to the page and go from there
sorry, I didn't want to interrupt the discussion
<bryce> dholbach: that's a good idea
dholbach: I can take care of doing that
<dholbach> nice
<bryce> (I assume by wiki log you mean irc log)
<dholbach> bryce: yeah, sorry - that's what I meant
<tseliot> BenC: a special file... something we should check before installing, right?
<dholbach> I'm really excited about this - this looks like a very good start off
<tseliot> dholbach: I hope so ;)
<bryce> yes now just the hard work ;-)
<dholbach> hehe
<BenC> tseliot: no, something that gets checked before setting up which nvidia.ko module to load
tseliot: either the one from lrm or the one that envy generated
<tseliot> BenC: ahhh, ok. It makes sense now.
<bryce> BenC, tseliot, so am I understanding correctly that the idea is that envy would contain an "override" copy of fglrx or nvidia that it would insert into the system in a way that l-r-m can detect and update appropriately?
or, would envy be using a modified copy of l-r-m with the new driver inserted into it, and versioned correctly so new l-r-m's can install over it?
<BenC> bryce: my hope is that the current lrm scripts (e.g. lrm-video) would work with envy in such a way that it knows to load the envy generated module instead of it's own version, when it detects that glx is from envy
bryce: the nvidia and fglrx glx packages (for xorg driver and GL libs) will have to be generated from envy and installed, like it is now, but the kernel module stuff would be handled a little better
<BenC> and yes, upgrades where the lrm glx packages are newer than the envy generated ones would occur, and work
that's my hope :)
<tseliot> Question: would Envy coexist with Restricted Drivers Manager?
<BenC> that would avoid all the conffile twiddling that occurs now
tseliot: that would be nice...I'd like to see the case where restricted-manager can say "Ubuntu provides driver X for nvidia, but a newer version exists from nvidia's website...pick one..."
<tseliot> and should I use "debconf" python bindings instead of my own xorg parser?
BenC: that would be great
<BenC> tseliot: I would suspect that using the same mechanism as lrm for xorg.conf would be best
<bryce> tseliot, I've got some thoughts there
<tseliot> the only problem I have with debconf is the fact that if the xorg is modified by hand, debconf might not work
<bryce> tseliot: do you need more than just setting the driver - e.g., options, etc.?
<tseliot> bryce: yes, I do. This is why I made my own parser
<bryce> tseliot: we've been moving towards using displayconfig-gtk/guidance-backends for manipulating xorg.conf rather than relying on debconf
however at UDS we discussed about how many different xorg.conf parsers/generators/updaters there are, and considered moving to all use a consistent one (probably something in xorg itself)
<tseliot> bryce: I haven't studied guidance code yet but I will if there is a default parser
<bryce> however, for now if it is at all possible to have envy use guidance-backends and its parser, that'd at least move us in the correct direction
<tseliot> ok
<bryce> lemme dig up the specific file to look at ...
<dholbach> mvo: is glatzor or you move involed in the guidance-backends thing right now?
<bryce> in the guidance-backends package, it's displayconfig/xorgconfig.py
<mvo> dholbach: glatzor more than I am
<BenC> bryce: hmm, some updates to lrm to use that would be nice
<mvo> dholbach: but I know a bit about it too
<tseliot> bryce: thanks, I'll have a look at it
<dholbach> mvo: because of the discussion above
<mvo> yeah, I think restricted-manager uses it too with some success
<dholbach> nice
<mvo> its standard in kdes guidance and displayconfig-gtk, we consider it quite good
what do you think about the idea to get updates of l-r-m and nvidia-glx into ubuntu-backports? is that something we should aim for?
<bryce> mvo, in general, yes, but there's one issue
mvo, first, often the new binary drivers are extremely buggy, so I'd be concerned it would incur risk for people
er, two issues
<tseliot> mvo, BenC: by the way, we would (currently) need to support 2 versions of the fglrx driver. And what happens when a 3rd flavour of the same driver is added?
<BenC> tseliot: am I going to have to create a fglrx-new?
<tseliot> bryce: users should be able to get back to the driver in the restricted repo
* BenC remembers something about hw support being dropped in the latest ati driver
<bryce> mvo, second, I've found the drivers often have slight changes that cause conflicts getting them to build with lrm, so there's some manual work involved each time.
<tseliot> BenC: yes, the new fglrx driver
<BenC> ok, I need to cut out in order to prep for the next call
<tseliot> which supports AIGLX
<dholbach> ok... we have 10 minutes left until BenC will have to leave us
<mvo> bryce: hm, I see.
<dholbach> where do we go from here? will we meet again?
<-- seb128 has quit ("Ex-Chat")
<bryce> mvo, the good news is I *think* that this envy/lrm approach may make -backports less necessary
mvo, since it will be a user-controlled opt-in thing
<BenC> I can hang on for anything important, but I wont be putting in my 2 cents as much :)
<dholbach> I think it'D make sense to list all ideas, problems and probable solution on the wiki page
and then see what we can do in the hardy time frame
<bryce> dholbach: is there a mailing list or irc channel where we can continue discussions?
<dholbach> and meet again in a week or talk about it on a mailing list?
<BenC> sounds good to me
<dholbach> shall we aim for a review of https://wiki.ubuntu.com/EnvyNG in a week on the kernel mailing list?
does that make sense?
or in the kernel channel?
<mvo> bryce: right. I kind of hoped that we could make it more packaged based, my understanding is that the discussed approach is still download+build packages on the users machine. I like the idea of using buildds etc better, but then I'm happy with whatever you guys are happy with
<tseliot> dholbach: do I have access to the kernel mailing list (even though I'm only an Ubuntu user)?EnvyNG (last edited 2008-08-06 16:33:52 by localhost)