Creating a hack to override the gtk2 scrollbar settings seems to require more time and patience than I can spare. So a lazy solution is to open up Filezilla (or other gtk2 application of your choice) and keep changing the theme until finding one that makes Filezilla look nice (i.e., traditional scrollbar and reasonable color scheme). Then it's a simple matter of using those gtk2 settings instead of the gtk2 settings in your theme. For example:

I like the Arc-Darker theme the best overall, but prefer how Filezilla (and other gtk2 applications) looks with the TraditionalOk theme. Therefore:

# mv /usr/share/themes/Arc-Darker/gtk-2.0{,-bkup}
# cp -r /usr/share/themes/{TraditionalOk,Arc-Darker}/gtk-2.0

Then log out and log back in (or change theme from Arc-Darker to something else, then back to Arc-Darker) for the settings to take effect.

msi has a good point.

By the way, I experienced no buggy installer behavior when I installed Devuan Jessie last year or Devuan Ascii back in March. There were no contrib or non-free packages on my system after either installation.

Devuan is as committed to free software as Debian. Just remove contrib and non-free from your /etc/apt/sources.list and use vrms to find any packages you don't want. It really is as simple as that.

Since the only lines in the log having to do with graphics are these:

+ PM_QUIRKDB=/usr/lib/pm-utils/video-quirks
+ PM_LKW_QUIRKS=/var/cache/pm-utils/last_known_working.quirkdb

I tried different command line parameters having to do with quirks. This command causes suspend/resume to work as expected when running with nomodeset/vesa graphics: sudo pm-suspend --quirk-dpms-on

Wow, this was tough. I'll mark as solved.

I did one more experiment:
Deleted the nomodeset kernel boot option, blacklisted the i915 kernel module, rebooted.

Result:
All observations are the same as when using nomodeset.

I think this proves that using the vesa fallback instead of i915 is breaking computer's ability to suspend--it does not matter if i915 is disabled directly (by blacklisting it) or indirectly (by using nomodeset).

Since i915 seems to be responsible for all the graphics bugs I was experiencing, I'm happy with vesa. Nevertheless, if anyone knows a way to make suspend work while on vesa graphics, please do share.

I did a bit more research on this issue and discovered that the i915 kernel module, which is the default graphics driver on my T400 with integrated Intel graphics, requires kernel mode setting (see here). Therefore, using nomodeset kernel boot option on my machine causes it to fallback to the more barebones vesa graphics driver.

I can confirm that i915 is not the graphics driver when I use nomodeset kernel boot option.

Here is the output of  sudo lshw -c video without nomodeset (notice the "configuration:" line):

  *-display:0 UNCLAIMED     
       description: VGA compatible controller
       product: Mobile 4 Series Chipset Integrated Graphics Controller
       vendor: Intel Corporation
       physical id: 2
       bus info: pci@0000:00:02.0
       version: 07
       width: 64 bits
       clock: 33MHz
       capabilities: msi pm vga_controller bus_master cap_list
       configuration: driver=i915 latency=0
       resources: memory:e1400000-e17fffff memory:d0000000-dfffffff ioport:5400(size=8) memory:c0000-dffff

And here is the output of the same command with nomodeset:

  *-display:0 UNCLAIMED     
       description: VGA compatible controller
       product: Mobile 4 Series Chipset Integrated Graphics Controller
       vendor: Intel Corporation
       physical id: 2
       bus info: pci@0000:00:02.0
       version: 07
       width: 64 bits
       clock: 33MHz
       capabilities: msi pm vga_controller bus_master cap_list
       configuration: latency=0
       resources: memory:e1400000-e17fffff memory:d0000000-dfffffff ioport:5400(size=8) memory:c0000-dffff

LOL

Good one!

Here is an example of the problem, with kernel image 4.0.8-2 amd64 (from Debian snapshots). The relevant output from dmesg, from the time I give the "Safely Remove Drive" command is below. The output shows the device disconnecting then about 0.4 seconds later it is detected as a new device (see lines I marked with asterisks):

[   59.310643] sd 4:0:0:0: [sdb] Synchronizing SCSI cache
[   59.428081] sd 4:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
***** [   59.464441] usb 2-2: USB disconnect, device number 2
***** [   59.841273] usb 2-2: new SuperSpeed USB device number 3 using xhci_hcd
[   59.863925] usb 2-2: New USB device found, idVendor=0bc2, idProduct=2322
[   59.863937] usb 2-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[   59.863944] usb 2-2: Product: Expansion
[   59.863950] usb 2-2: Manufacturer: Seagate
[   59.863956] usb 2-2: SerialNumber: NA8DFHL6
[   59.871807] scsi host5: uas
[   59.874809] scsi 5:0:0:0: Direct-Access     Seagate  Expansion        9300 PQ: 0 ANSI: 6
[   59.876620] sd 5:0:0:0: Attached scsi generic sg2 type 0
[   59.876695] sd 5:0:0:0: [sdb] 1953525167 512-byte logical blocks: (1.00 TB/931 GiB)
[   59.876698] sd 5:0:0:0: [sdb] 4096-byte physical blocks
[   59.877103] sd 5:0:0:0: [sdb] Write Protect is off
[   59.877107] sd 5:0:0:0: [sdb] Mode Sense: 4f 00 00 00
[   59.877297] sd 5:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   59.877677] xhci_hcd 0000:04:00.0: ERROR Transfer event for disabled endpoint or incorrect stream ring
[   59.877681] xhci_hcd 0000:04:00.0: @000000026312df00 00000000 00000000 1b000000 01038000
[   60.646377]  sdb: sdb1
[   60.647569] sd 5:0:0:0: [sdb] Attached SCSI disk
[   61.378077] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)

Any idea why the disconnected device is then immediately being detected as a new device?

P.S. I have no idea what to do with this information, but I've noticed a pattern:
- In the old kernels that don't have this issue (e.g., 3.16.x), only xhci_hcd kernel module exists
- In the kernels that have the issue (3.18-4.3), which I would like to use once I can fix this, both xhci_hcd and xhci_pci kernel modules exist
- In newer kernels that don't have this issue (but give me graphics artifacts) (4.4+) neither kernel module exists

Hi, Geoff42. I'm using the Arc-Darker theme plus my scrollbar hack (plus a custom metacity-1 theme--see rant below). I don't use emacs (I'm a vim/geany person) so can't comment there, but my scrollbar hack works nicely in Synaptic.

I was hoping my scrollbar hack would work with any theme, but I guess I was just lucky with all the themes I tried.

Rant: Another annoying thing about the new themes are the "flat" window titlebars. When these titlebars overlap, it is impossible to know where one window's titlebar ends and another window's titlebar begins. I spent an unhealthy amount of time hacking a metacity-1 theme to a) have titlebar color gradient, b) use Arc-Darker's minimize/maximize/close buttons, and c) integrate well with the colors of the Arc-Darker theme. The metacity theme is here in case anyone is interested. I know the theme works if you are using metacity or marco as your WM, probably wouldn't work with other WMs but I'm not sure. To try it: Download the tarball, extract it, put the extracted folder in /usr/share/themes/, then customize your theme to use FineryDark-ArcButtons for "window borders".