OK, after an extremely long and painful debugging session, I finally worked out what was going on, which was a combination of non-deterministic and slightly broken behaviour of laptop-mode-tools and a bug in nvclock.
So, I was having laptop-mode-tools call nvclock to change the brightness settings when the laptop was plugged/unplugged. Capturing the output from the laptop-mode-tools script, I saw that nvclock was non-deterministically reporting the error: "Smartdimmer is only supported on certain (HP/Samsung/Sony/Zepto) laptops using a Geforce 6200/7x00Go/8x00Go. If you want support on your laptop contact the author." Weirdly, I could only trigger this from laptop-mode-tools, and not from the console, as root or otherwise. After some extremely slow tracing of how nvclock set its capability flags, I discovered that the issue was actually due to nvclock's configuration file code failing, but returning a success value, causing nvclock to fail much later as if the graphics card had reported that it didn't support screen dimming. The true error condition that nvclock had encountered was the the environment variable HOME had not been set. Strangely, when laptop-mode-tools invokes the screen brightness command, this variable is sometimes unset, and sometimes set to "/". The latter is pretty problematic too as it results in nvclock creating its configuration folder .nvclock in /. So, I guess bug in laptop-mode-tools is that it should try set up a minimal environment was for command its invokes, and should set HOME to something like "/root" and definitely not "/". I guess that for some reason, 1.55 always ended up setting it to "/". Francis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
