[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Libreboot-dev] Issues with libreboot on T60
From: |
Luke Shumaker |
Subject: |
[Libreboot-dev] Issues with libreboot on T60 |
Date: |
Mon, 06 Apr 2015 19:07:32 -0400 |
User-agent: |
Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (Gojō) APEL/10.8 EasyPG/1.0.0 Emacs/24.4 (x86_64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) |
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
- [Libreboot-dev] Issues with libreboot on T60,
Luke Shumaker <=