Option for setting the PM method about bumblebee

[starks]

On 12/30/2011 11:20 AM, Peter wrote:

The driver can be autodetected but can also be configured. Let's do it for PM as well which could have the next options:

• auto
• bbswitch
• switcheroo
• nono

---

Reply to this email directly or view it on GitHub:
https://github.com/Bumblebee-Project/bumblebeed/issues/14
Is the "switcheroo" option assuming a patched switcheroo?

What would the behavior be on an unpatched kernel?

[Samsagax]

I agree as long as the configuration file takes precedence in case something goes wrong, like in GH-8.

Not really sure about how the "auto" option should work (how it should detect the method). Here is my suggestion, once proposed by @Thulinma:

• look for bbswitch first, if present, set it as method.
• then look for vga-switcheroo if nouveau is present, set it as method
• none found, then go for the configured option

[Thulinma]

I totally agree with this stuff.
Configurable, and if not configured or manually set to "auto" follow what @Samsagax wrote above.

One thing though: I feel like the auto should re-detect available methods every time the card is (attempted to be) switched. This way it will work if somebody inserts or removes the bbswitch module after starting bumblebeed, for example, without crashing / failing. Perhaps display a debug message if the used method changes, something like that?

Of course, when set to anything else than auto, it should never switch to a different method at all :-)

[Lekensteyn]

@Thulinma If someone wants to use bbswitch, it should be configured. It's a bad idea to mix PM methods up as they're not compatible with each other. Especially vga_switcheroo will fail, it keeps the state in a variable where bbswitch looks up the state when called.

One possibility is using modinfo to check for the availability of bbswitch. The config_validate function contains such a call to check whether a driver is valid or not. One thing to keep in mind: sometimes drivers cannot be unloaded (marked as "permanent"). This occurs if the toolset used for compiling the kernel is different from the one used for compiling a kernel module.

A nice way for how auto works if by calling a (yet to be created) function in the struct which is called by swich_check(). For bbswitch, it could check whether the driver is loaded or not. In the case of vga_switcheroo, it can check whether the driver is nouveau or not. I haven't a solution for the vga_switcheroo incompatibilities yet.

[Samsagax]

Sounds like a failsafe approach to auto detection. Like that

[Lekensteyn]

@Samsagax The proposed values are options for the config file

@LLStarks The behavior on an unpatched kernel is just a lockup if the card is attempted to be used. The test for vga_switcheroo could be (switch = /sys/kernel/debug/vgaswitcheroo/switch):

• read the contents of $switch, if it's off then assume that it's available
• if it's on, try to turn it off, then check the pci config space at /proc/bus/pci/ID/HERE
• if all bits are 1 (FF FF ...), then vga_switcheroo is available. Write ON again and assume that it's available.
• If the bits are not all 1, vga_switcheroo did not work. Write ON again to avoid lockups.

For the above to work, nouveau needs to be loaded.

[Lekensteyn]

Proposal: drop the ENABLE_POWER_MANAGEMENT option and introduce PM_METHOD with the options mentioned in the first post:

• auto (default)
• bbswitch
• switcheroo (disable for auto-detection since it's still buggy, activate if it's explicitly requested in the config)
• none

If the configured method fails, it defaults to none. (unless someone has good arguments for why it should behave different, like exiting with an error)