A week ago I wrote about my mouse woes and how they were
by enabling the "Enable modesetting on intel by default" kernel option
But all was still not right with X. I could boot into a console,
start X, and everything was fine -- but once X was running, I
couldn't go back to console mode. Switching to a console, e.g.
Ctrl-Alt-F2, did nothing except make the mouse cursor disappear,
and any attempt to quit X to go back to my login shell put the
monitor in sleep mode permanently -- the machine was still up, and
I could ssh in or ctrl-alt-Delete to reboot, but nothing else I did
would bring my screen back.
It wasn't strictly an Ubuntu problem, though this showed up with
Karmic; I have a Gentoo install on another partition and it had the
same problem. And I knew it was a kernel problem, because the Ubuntu
kernel did let me quit X.
I sought in vain among the kernel's various Graphics settings.
You might think that "enable modesetting" would be related to,
you know, being unable to change video modes ... but it wasn't.
I tried different DRM options and switching framebuffer on and off.
Though, oddly, enabling framebuffer didn't actually seem to enable
Finally I stepped through the Graphics section of
menuconfig comparing my settings with a working kernel, and
saw a couple of differences that didn't look at all important:
"Select compiled-in fonts" and "VGA 8x16 font". Silly, but
what could they hurt? I switched them on and rebuilt.
And on the next boot, I had a framebuffer, and mode switching.
So be warned: those compiled-in fonts are not optional if you
want a framebuffer; and you'd better want a framebuffer, because that
isn't optional either if you want to be able to get out of X once
you start it.
[ 19:22 Nov 16, 2009
More linux/kernel |
permalink to this entry
I've been seeing intermittent mouse failures since upgrading to Ubuntu
At first, maybe one time out of five I would boot, start X, and find
that I couldn't move my mouse pointer. But after building a 184.108.40.206
kernel, things got worse and it happened nearly every time.
It wasn't purely an X problem; if I enabled gpm, the mouse failed in the
console as well as in X. And it wasn't hardware, because if I used
Ubuntu 9.10's standard kernel, my mouse worked every time.
After much poking around with kernel options, I discovered that if I
tunred off the Direct Rendering manager ("Intel 830M, 845G, 852GM, 855GM,
865G (i915 driver)"), my mouse would work. But that wasn't a
satisfactory solution; aside from not being able to run Google Earth,
it seems that Intel graphics needs DRM even to get reasonable
performance redrawing windows. Without it, every desktop switch means
watching windows slowly redraw over two or three seconds.
(Aside: why is it that Intel cards with shared CPU memory need DRM
to draw basic 2-D windows, when my ancient ATI Radeon cards without
shared memory had no such problems?)
But I think I finally have it nailed. In the kernel's Direct Rendering
Manager options (under Graphics), the "Intel 830M, 845G, 852GM, 855GM,
865G (i915 driver)" using its "i915 driver" option has a new sub-option:
"Enable modesetting on intel by default".
The help says:
Choose this option if you want kernel modesetting enabled by default,
and you have a new enough userspace to support this. Running old
userspaces with this enabled will cause pain. Note that this causes
the driver to bind to PCI devices, which precludes loading things
Sounds optional, right? Sounds like, if I want to build a kernel that
will work on both karmic and jaunty, I should leave that off
so as not to "cause pain".
But no. It turns out it's actually mandatory on karmic. Without it,
there's a race condition where about 80-90% of the time, hal won't
see a mouse device at all, so the mouse won't work either in X or
even on the console with gpm.
It's sort of the opposite of the
"Remove sysfs features which may confuse old userspace tools"
in General Setup, where the name implies that it's optional on
new distros like Karmic, but in fact, if you leave it on, the
kernel won't work reliably.
So be warned when configuring a kernel for brand-new distros.
There are some new pitfalls, and options that worked in the past
may not work any longer!
Update: see also the
post for two more non-optional options.
[ 22:34 Nov 10, 2009
More linux/kernel |
permalink to this entry