[Libreboot-dev] Issues with libreboot on T60

[Luke Shumaker]

I've commented on issues I've had with libreboot on my Gluglug T60 on
IRC, and fchmmr asked me to post info about them here.

The mouse

  This one occurred for the first time on Friday (April 3rd).  I'm
  running the latest libreboot; and the issue did not directly follow
  a change to libreboot, the kernel, or anything else that I know of.
  The issue is that the mouse stops working; both the touchpad and the
  trackpoint.  That both stop working rules out a loose connection or
  similar hardware failure, because the trackpoint is on the
  keyboard's cable, which otherwise works.  Normally /dev/input/mouse0
  is the touchpad, and /dev/input/mouse1 is the trackpoint.  When it
  happens, /dev/input/mouse1 no longer exists, and `sudo cat
  /dev/input/mouse0` gives no output when fiddling with either device.
  At a higher-level: the mouse neither works in X11 or GPM.

  I don't know what triggered it any of the times that it has happened
  (which makes doing something like a git bisect hard).  I mentioned
  on IRC the first time that I might have bumped some switch or key
  combo.  From the markings on the keys (US qwerty layout) it looks
  like Fn+F8 would toggle the mouse being enabled, but it appears to
  do nothing (well, in X11 it sends they keycode XF86TouchpadToggle,
  but I have nothing responding to that).

  The first time, I discovered that Fn+F7 (which the markings indicate
  would toggle an external screen) toggled the mouse working.  Note
  that this is below or in the kernel, as it affected /dev/input/.

  It happened again, briefly, but I don't remember what I was doing
  at the time.

  On Saturday, it happened a third time when I resumed from suspend,
  and plugged in (I'd closed the laptop, suspending it, to go look for
  an outlet, as the battery was low).  Unfortunately, these 2
  variables confound each-other; I don't know whether it was the
  addition of power, or suspend/wake, or both that caused it.  Anyway,
  this time, Fn+F7 did nothing.  The issue persisted across
  soft-reboots to the same kernel (3.14 (LTS) on Parabola), to
  different kernels (3.19.3 on Parabola), across distros (Trisquel
  with 3.13.0-48 (yes, it's been a while since I updated Trisquel)),
  and even across a hard power cycle (unplugging the power and
  battery).  It lasted for several hours, and seemingly spontaneously
  fixed itself while I was working.  I was on Parabola, but I don't
  remember if I was on 3.14 or 3.19 when it fixed itself; it was on
  3.14 when it triggered.

  This indicates to me a LibreBoot bug, as so many things are
  different between Parabola and Trisquel--the only thing they share
  that I could imagine is relevant is the swap partition.

The backlight

  When upgrading from the October release of libreboot to the current
  release, the backlight "broke".  The saved value that was restored
  by systemd-backlight at boot was so dim that I thought the screen
  wasn't working.  Prior to the update, /sys/class/backlight/ only had
  intel_backlight (max_brightness: 776).  After the update, it has
  intel_backlight (max_brightness: 2896545) and thinkpad_screen
  (max_brightness: 7), where intel_backlight actually changes the
  backlight, and thinkpad_screen does nothing that I can tell.  You
  can see why the restored value of 776 made the screen hard to see.
  xbacklight chooses thinkpad_screen, so xbacklight no longer works;
  though this is as much a configuration problem in xbacklight as it
  is an issue in libreboot, though thinkpad_screen should probably not
  show up if it is useless.  In the mean time, I'm writing to
  /sys/class/intel_backlight/brightness directly.

The fan

  I've had overheating issues (leading me to keep the CPU governor
  always in "powersave").  I've discovered that it's because the fan
  is spinning backward!  It's moving air, but not very effectively.
  This could be a hardware issue, I don't know.  Because it's a PWM
  fan, it could maybe be software?  I haven't looked into it much.

Suspend

  So, I'm like 90% sure that this is just a bug in systemd-logind (on
  Parabola), not libreboot.  But, sometimes when I close my laptop,
  one of several things happens:
   - Everything goes correctly
   - Laptop does not suspend, or seem to know that anything
     happened.  Though, the screen turns of while it is closed--I
     suspect this is a hardware switch.  Sometimes it works to switch
     from X11 to a TTY then close it.
   - It suspends, but the X11 server crashes immediately upon wake-up
     (flash of the previous screen, then the terminal from which I ran
     `xinit`).  If I look at the X.org logs, it complains about
     connection to logind.  If I look at the journal for logind, I see
     that it crashed, then auto-restarted.
   - It locks up; not suspending.  Usually requires me to hold the
     power button until it turns all the way off.  Sometimes tapping
     the power button or pressing Ctrl+Alt+F? to switch to a different
     terminal successfully un-locks it.  I don't really know; if I
     understood it, I'd be writing a patch, not an email.

  This happen{ed,s} with both the libreboot from October and the
  latest one.  Until recently noticing the logind messages, I always
  just assumed that it was a bug in X11.

  I've never had it misbehave when using `systemstl suspend` or
  pressing Fn+F4 (suspend).

LVM

  This isn't an issue, but a feature request: The "scan drive"
  functionality of the default GRUB config ignores LVM volumes; it
  would be nice if it did, as this means that the default
  configuration does not work for me.  I'm not sure how to do this, as
  I can't figure out how to do subshells or globbing in the GRUB2
  shell.  Also, GRUB's scanning for LVM volumes is *slow*.

--
Happy hacking,
~ Luke Shumaker