Thank you for that, mlsmith. I tried it and closing/reopening the lid still triggers the bug.

I think my best chance is to disable the lid switch at the lowest possible level. dmesg shows this:

bruno@thinkpad:~$ dmesg | grep Lid
[    0.797043] input: Lid Switch as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:2a/PNP0C09:00/PNP0C0D:00/input/input1
[    0.797058] ACPI: Lid Switch [LID]

Is eudev related to the first line above?

I will try ralph.ronnquist's idea to explore eudev meanwhile.

ralph.ronnquist, I updated my post above with the subsequent lines from the log. It does seem that something else is presenting the lid switch to X.

I will do the experiment and will report back in a minute.

I guess the problem is that redshift requires an adjustable "gamma ramp" (per redshift's github page), but the VESA graphics driver does not offer a gamma ramp (see Richard's first post here).

What other graphics drivers are there for my machine? My searches so far have been futile. If i915 gives me artifacts and VESA breaks redshift, I'd like to find a third option. This is my hardware:

bruno@thinkpad:~$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)

EDIT: Since this question is a lot more broad and does not have to do with redshift specifically, I'll open a new thread for it.

I see. Sorry I missed the detail about the theme you are using. I don't currently have Clearlook-Phenix but used it in the past and remember that it is nice-looking and conservative. I'm not surprised that its gtk2 settings give you want you want out of the box.

It sounds like you are all set with icons, but check out the gnome-colors package. It provides nice, conservative (read: non-flat and actually informative) icon sets in virtually every color. I use the blue set ("Gnome-Brave") on my system, wife likes the pink set ("Gnome-Illustrious").

The main theme-related headache I had when I upgraded to Ascii is that its newer libgtk-3-0 (version 3.22) broke the gtk3 component of the themes I was using in Jessie. Therefore, I had to head over to gnome-look.org to look for themes that support gtk3 version 3.22. The problem with these newer themes is that almost all of them are flat and lack scrollbar buttons. So I settled on one of them (Arc-Darker) and "simply" put scrollbar buttons back in and took out the flat component that was bothering me the most (window titlebars that blend into other window titlebars). The resulting custom theme is here in case you are interested.

I realize that my hack only works for gtk3 applications. A lazy way to customize scrollbar for gtk2 applications is to just use all of a different theme's gtk2 settings (see post #10 here: https://dev1galaxy.org/viewtopic.php?pid=8432#p8432).

If anyone knows a more elegant solution, please share. Alas, after tinkering for several hours I can't seem to find a way to override just the scrollbar component of a theme's gtk2 settings.

Geoff42, I found an app in which my scrollbar hack isn't working: Filezilla.

Initial investigation results: My hack targets only gtk3, but some apps (such as Filezilla) rely on gtk2 settings. I will try to fix my hack so that a traditional scrollbar shows up in Filezilla.

Easiest way to see all contrib and non-free packages installed on your computer. In terminal:
First run: sudo apt-get install vrms (vrms stands for "virtual Richard M. Stallman" )
Then run: vrms

This is what you want to see:

bruno@thinkpad:~$ vrms

No non-free or contrib packages installed on thinkpad!  rms would be proud.

If not all packages on your system are free (and 100% free is what you want), just uninstall all the dirt that vrms digs up.

Thanks, ralph.ronnquist. That was key.

I logged both without nomodeset (suspend working consistently) and with nomodeset (suspend works once then fails to work subsequently).

Interestingly, the logs without nomodeset and the first log with nomodeset are identical. With nomodeset, second attempt to suspend onwards do nothing and the last few lines of the log are:

+ flock -x -n 3
+ return 1
+ exit 1

It seems that the problem is that when running on vesa graphics, the pm-suspend command gets stuck at some point (presumably during the resume phase) and never finishes executing, leaving behind some kind of lock that prevents further attempts to suspend.

For posterity's sake: While the 3.16.x kernel made my graphics issue go away, sometimes (~10% of the time) that kernel causes a grapics-related lock-up during boot (see https://dev1galaxy.org/viewtopic.php?id=1962).

I found that using the nomodeset kernel boot option disables i915 graphics driver, causing fallback to vesa graphics. This made all graphics artifacts go away for me on ascii, with all kernels I tested. The only two disadvantages I can think of with this approach is that it seems to break my computer's ability to suspend (see https://dev1galaxy.org/viewtopic.php?pid=8355#p8355). Also, some people report that with vesa graphics they cannot use multiple monitors at once (this doesn't affect me but I thought I'd mention it for completeness's sake).

I'm going with this for now: # chattr +i /etc/modprobe.d/blacklist.conf