Change enable and disable structure

[ArchangeGabriel]

I'm proposing to you a new structure for the enable and disable scripts. It's not really different, but solves a lot of things.

The example for my U43Jc are available here : http://pastebin.com/0V7tbWa9 http://pastebin.com/fkFdZcDM

If you agree with this new structure, we will juste have to remove the formerly work on watching if the card is on or not and also find a good way to change the scripts for users.

[Lekensteyn]

Those scripts should return a meaningful exitcode which may be used in bumblebee. Currently, if something fails, bumblebee continues without verifying. As with $result, it should be truncated to say, 50 characters. The kern.log (and dmesg) contain the full data anyway.

if [lspci -v -s $NVIDIABUSID |grep -c !-eq 1 ]; then can be replaced by:

if lspci -v -s $NVIDIABUSID | grep -q !; then

[ArchangeGabriel]

I think you mean if lspci -v -s $NVIDIABUSID | grep -q !; then.

[ArchangeGabriel]

Oh, bonus : we can use this scripts also for models without the good calls, as if we can't do anything to the card, it can't be off. Note : work only for the enable part.

I'm updating the scripts at pastebin to reflect changes. http://pastebin.com/Zk6nmBF8 http://pastebin.com/LUPpMvxR

[Lekensteyn]

This is great in a step to an unattended installation.

[ArchangeGabriel]

I have and idea, but I need to know what does that : `if ! lspci -v -s $NVIDIABUSID |grep -q !; then

INSERTPOWEROFF

fi`

If nothing, then we have our solution. The configuration scripts, which may be run after the installation, and only once for this part, may just grab the #INSERTPOWEROFF from the DB or even better from a sort of local DB.

[Lekensteyn]

if ! lspci -v -s $NVIDIABUSID | grep -q !; then
    # the card is OFF
fi

To allow for upgrades, we need either to overwrite that file with a template or have something that detects the inserted text. Alternatively, store the method in some file.

[ArchangeGabriel]

Store the method in some file, this is the good idea !

I will work on it tomorrow.

[Lekensteyn]

Use sensible places. Currently, martin thought it could be useful to store the version in /etc/bumblebee. Not a very good decision, but we have to live with it. Should we store it in /etc/bumblebee.d/methods and source it? Or use the whole file for storing the method, so we can immediately do: tee /proc/acpi/call < /etc/bumblebee.d/method-disable. Validation could be done before to ensure that the methods have the correct syntax.