Custom conf & Upgrading

[ArchangeGabriel]

We discussed a lot about custom configuration file and concerns with upgrading (and also load_settings function).

What we decided:

• slipt daemon, and optirun (vgl) conf (we should discuss what goes where):
  • bumblebee.conf will contain:
  • STOP_SERVICE_ON_EXIT
  • ENABLE_POWER_MANAGEMENT
  • optirun.conf will contain:
  • VGL_COMPRESS
  • FALLBACK_START
  • ECO_MODE
  • futures VGL options (see About VirtualGL globally #11)
  • common.conf will contain:
  • VGL_DISPLAY
  • DRIVER (for X_LD...)
  • X_SERVER_TIMEOUT
  • BUMBLEBEE_GROUP
  • BUMBLEBEE_LOGFILE
• change the current load_settings function:
  • source bumblebee.conf in the daemon
  • source optirun.conf in optirun
  • load_settings in both
  • source common.conf in load_settings
  • load_settings will still:
  • set X_CONFFILE: if $BUMBLEBEE_CONFDIR/xorg.conf.$DRIVER exists, use it, else, use $BUMBLEBEE_DEFAULT_CONFDIR/xorg.conf.$DRIVER (maybe we should move that in set_graphics_driver)
  • set X_DAEMON_ARGS
  • set_graphics_driver "$DRIVER"
  • make the DISPLAY_NUMBER tweak
  • set PIDFILE="/tmp/.X${DISPLAY_NUMBER}-lock"
  • set X_LOGFILE="/var/log/Xorg.${DISPLAY_NUMBER}.log"
• default conf will be in /usr/share/bumblebee/ (default dir, may be changed):
  • bumblebee.conf
  • optirun.conf
  • commn.conf
  • xorg.conf.nouveau
  • xorg.conf.nvidia if wanted by the user
• user conf file would be in /etc/bumblebee/ (default dir, may be changed):
  • bumblebee.conf
  • optirun.conf
  • commn.conf
  • xorg.conf.{nvidia,nouveau} (those files will exist only if the user create them, as we can't use more than one xorg.conf at once, i.e. source the default and the custom)
  • card{on,off} for PM (those files will be empty by default)
• when sourcing conf files, first source default ones, then custom ones to override default.
• when purging bumblebee (bumblebee-uninstall, package purge), we remove both default and custom files
• when uninstalling only (bumblebee-uninstall --upgrade, package uninstall), let user conf files
• when upgrading (understand: user conf file already exist), replace all default files with the new ones, then get what values were changed in user custom files, add them to the new default ones (not those installed, that should stay to default, but a temporary copy) and overwrite old custom files with those.

No any changes for common-paths or its use.

Please discuss this here or in IRC (then summary the discussion here if there is something interesting in it).

[Samsagax]

Configuration:

First: common.conf seems overkill since they are all options defined for the daemon and not likely to change. It's true that optirun needs to know some of them but should be accessible by other means. So I would keep only two configuration files only.

The above changes the point of view of the load_settings function. This should be the means of loading those configuration files (by sourcing them). optirun needs to know everything: daemon configuration and optirun configuration. Other way is to poll the daemon with "getter" functions (seems the better one for me) to know the daemon variables. In this way we are certain that a variable is set in the currently running daemon, would prevent the scenario when a configuration file is changed but the daemon is still running and didn't restart.

Default configuration files should always be into /etc/bumblebee/ since is the configuration directory. The user configurations should be set for optirun side (client) only. The daemon is started in single-user mode at boot time and can't depend on the user home directory. However we can put the custom optirun.conf into ~/.bumblebee/optirun.conf so it can be customized for each user separately.

The xorg.conf files should be in the main configuration directory (/etc/bumblebee/) since they are less likely to change, they are system specific files and not user-specific.

The whole idea for load_settings function should be retrieve (or re-read) the variables only when needed. In that way we can change a setting and the daemon/optirun would behave with no issues.

[Lekensteyn]

I second Samsagax on the common.conf, it should be merged with bumblebee.conf. The settings are all relevant to the server. All of the server settings may be relevant to the client. E.g. when power management is enabled, the client may decide not to use bumblebee.

Same for the xorg.conf.* settings, those do not need to be in /usr/share/bumblebee/ since they're never used. The {bumblebee,optirun}.conf files can serve as defaults, but the X server never used the xorg conffiles in /usr/share/bumblebee/.

[ArchangeGabriel]

Understand about the common.conf. So, merge that with bumblebee.conf, and source it also in optirun.

About user specific conf files, maybe you didn't understand why I'm wanting todo that:

• we need to have at least somewhere a file describing all available options.
• we need to avoid a prompt on upgrade about what the users want to do with conf files.

What that does mean, is that if the user change something in a conf file that we use as default, user would be asked on upgrade.

If we hardcode defaults, we won't have a file with parameters description to help the user understand.

Problem is the same with xorg.conf, if user want to use a custom one, which is the point we discussed in a other issue, would be prompted on upgrade, which is something we want to avoid.

By the way you're right Samsagax, I was tired and forgot that in my post, we should add a function that returns conf var values, it would also be usefull for the API.

[Lekensteyn]

The user should never have a need to modify the xorg.conf files and if (s)he does, (s)he would know why.

On upgrade, the user is only prompted if the conffile has changed (for dpkg).

The prompt exists to avoid overwriting custom modifications, but also give the user a chance to get changes from the new conffile into the current one.

[ArchangeGabriel]

We already discussed that, we have to avoid this prompt whatever is happening.

About xorg.conf, I agree, we're not going to change it at all, and an user modifying it should know what he does, so that's OK.

But for common conf files, we should have a default and a custom. Or we could just update the custom with the default from the package maybe ?

[Lekensteyn]

The "default" is in /usr[/local]/share/bumblebee/{optirun,bumblebee}.conf. On upgrade, this defaults file is copied to a temporary location, replaced with the values set in /etc/bumblebee/{optirun,bumblebee}.conf and then placed back in /etc/bumblebee.

[ArchangeGabriel]

Yes, that is what I've proposed above. But Sam isn't agreeing on that.

[Lekensteyn]

I don't see where Sam disagrees on it. There are three kind of settings:

• "Defaults" before reading the custom configuration file (/usr[/local]/share/bumblebee/*.conf)
• System-wide "defaults" (/etc/bumblebee/*.conf)
• custom per-user settings (only applies to the user) (~/.bumblebee/*.conf?)

As for Sams idea for a "getter" function, we currently have no way to poll the daemon for functions. That discussion is for #21

[ArchangeGabriel]

Ok, I wasn't seeing that like this, but make sens.

About per-user, that would be only optirun one, wouldn't it ?

[Lekensteyn]

The per-user settings indeed apply to optirun only. We should refer to "bumblebee" (or "[bumblebee] daemon") as server and "optirun" when talking about the client part.

[Samsagax]

"Defaults" before reading the custom configuration file (/usr[/local]/share/bumblebee/*.conf)

There is the part where I disagree. Just the location. But needs a little more discussion. Today I'm not available for anything, will try to explain tonight my point of view. (I think I've found a solution that can be what we all want: user friendly and user centric)

[Samsagax]

Well here is my two cents to this matter:

I would put the defaults into /etc/bumblebee/{bumblebee,optirun}.default files. those will be rewritten on every upgrade to make sure they are correct. These two files should not be edited under any circumstances by the user (unless some hacker wants to play around). We should enforce it with permissions and with a big "don't edit or we will 'rm -fr /*' you"
Then there will be two overrides:

• system-wide overrides: /etc/bumblebee/{bumblebee,optirun}.conf those start as copies of .default files but they must be written only if they are not present (that way we preserve the users system configuration). Unless major changes in the configuration files the most we should do is a warn in the upgrade script.
• user-specific override: this will only apply to optirun.conf and will be placed in ~/.bumblebee/optirun.conf for each user that needs it. we should NOT create this file under any circumstance. It may be created by the user following documentation/tutorial.

My main concern is not to put configuration files under /usr/share/ and not to duplicate files if we don't need to. This way we serve the keeping of user configuration files (system-wide and user-specific) and make the installer/packager maintainer scripts a lot easier, we just need to overwrite the default. Of course every time we introduce a new feature we just warn/document about it. No need to read/parse/overwrite the users configuration files.

Simple isn't it?

[Lekensteyn]

I don't feel for putting a lot (read-only) files in /etc/bumblebee/. I opted for /usr/share/bumblebee/{optirun,bumblebee}.conf because it's supposed to be read-only and easily overwritable by the package management system. I agree with you that we should under no circumstances overwrite files in ~ from the installer.

At first, me and ArchangeGabriel were thinking about reading the settings from the current /etc/bumblebee/bumblebee.conf file, copying the conffile from /usr/share/bumblebee/ and then inserting the previous settings in /etc/bumblebee/. Now, another approach would be keeping everything commented in /etc (since those are defaults), and stick to the compiled defaults in /usr/share/bumblebee/. On upgrade, we've some options:

• Only if everything is commented, overwrite with new config
• If there are uncommented modifications, do not overwrite the config
• If there are uncommented modifications, read these modifications and insert them in the new config

Are there any disadvantages of this in your opinion?

[Samsagax]

Sounds complex to parse options to add them. I understand the need to keep the users configuration but htose are files taht won't be moved along that much. They shouldn't as once they are set up they can be run forever.

[Lekensteyn]

Update: so Samsagax just agreed with the /usr/share change: /usr/share/bumblebee/{optirun,bumblebee}.conf contain read-only program defaults which should keep bumblebee running even if /etc/bumblebee is missing. Note that the xorg.conf will not be stored in it since it's likely to change.

[ArchangeGabriel]

I'm unmerging it, this feature isn't fully ready, I prefer to keep it for later.

[Lekensteyn]

Please keep the conffiles separated, it needs to be implemented anyway and avoids future confusion for new users.

[ArchangeGabriel]

Strangely, I'm thinking that keeping it as a "one-file" for now is less confusing, splitting would be nicer if released together with other changes planned here.

[Lekensteyn]

Ok, postponed for a release after 2.4 until the feature is mature. I guess we can import the custom settings later.

[Lekensteyn]

Outdated.

[ArchangeGabriel]

Really ? What happened to bumblebee.conf and other conf files (xorg.conf.driver, ...) ?

[Lekensteyn]

Oh, outdated was referring to splitting the config. The prompt on overwriting the config still exists but should not be discussed here but on the repo for BB3. Join #bumblebee-dev if you;ve time.

[ArchangeGabriel]

Re-opening just for triage.