On 2015-10-19 00:24, Luca Boccassi wrote: >> always run >> dpkg-reconfigure glx-alternative-nvidia >> after >> update-alternatives --config glx
>> to activate and run the triggers >> >> (THIS NEEDS TO BE DOCUMENTED) Maybe we should write script (update-glx) that is a wrapper around update-alternatives nvidia/glx and triggers+runs the neccessary followup actions. ENOTIME - suggestions + patches welcome. > This works with 340.93-5. Also tested on the desktop for collateral > and it seems fine. Thanks. Does CUDA/OpenCL work with Bumblebee at all? Does it work with this configuration? > Would this mean that a bumblebee user has to run this manually when > the package is installed? Is there a way we can automate this and make > the bumblebee package trigger it? Right now, yes. Should I upload this now? How can I detect that a system is to be run under bumblebee? I could skip creation of the "regular" /usr/lib/nvidia alternative there. Or lower its priority. >From a live-system point of view having stuff installed does not mean that it is being used (thats why we aim for co-installability of nvidia, nvidia-legacy-*, fglrx, using the nvidia and glx alternatives for switching). If the bumblebee packages can provide some kind of switch, all that would be needed after toggling it is to run dpkg-trigger register-glx-alternative-nvidia from their maintainer scripts. >> since that will 'modprobe -r nvidia'/'modprobe nvidia' you may end up >> with the wrong^Wproblematic permissions - are you in the video group? > > The devices are created with 666: I won't trust the output from ls since you recently reported that the device node switched from root:root 0666 to root:video 0660 after gdm3 crashed (so probably the device node in the /dev tmpfs got updated after being accessed). :-) Andreas
