[conspire] help: linux scancode/keycode problem on Dell E6500 ?

Rick Moen rick at linuxmafia.com
Thu Oct 6 16:22:54 PDT 2011


Quoting =JeffH (Jeff.Hodges at KingsMountain.com):

> Hi Rick, thx for your reply.

No problem.  Again, apologies for being rushed, but I'm stealing time to 
draft this really quick comment.

> What are the risks for breaking currently-working things by running
> a newer kernel?

None, really, because you carefully avoid _removing_ your installed 
distro kernel, but instead merely compile a new one separately and 
add an additional stanza to your bootloader configuration so that you
can boot the new kernel, without removing or messing with the
bootloader's reference to your distro kernel as the default boot
object.  Make sense?

In any event, this would be mainly for information-gathering.  If you
determine that the problem is fixed upstream, then you know what to 
watch out for in revisions to the distro kernel.

> From wiki.ubuntu.com/KernelMainlineBuilds it sounds
> like one would want to generally only run them for testing in that
> they lack "Ubuntu kernel patches". So if a newer "mainline kernel"
> aka "recent upstream 3.x kernel" /does/ have whatever it takes to
> resolve this issue, i may not wish to run it day-to-day, yes?

I'd be really surprised if Canonical Ltd. / Ubuntu Project did any
really significant amount of kernel work in-house, as they lack the
funding, staffing, and expertise.  I'm not trying to sound catty about
that or dump on Ubuntu; it's merely an observation.

> If so, then I wonder about how to discover the particular fix and
> backport it (if that's the correct term) -- but I can cross that
> bridge when I come to it I spose.

Well, personally, that'd be a bit too much real work for my taste, but
in that case I _might_ search for Ubuntu official or unofficial
precompiled kernels that included that hypothetical patch, _or_ 
just run a recent kernel.org kernel that I compiled myself.  





More information about the conspire mailing list