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

[=JeffH]

Hi Rick, thx for your reply.

Rick related..
 >
 > Quoting =JeffH (Jeff.Hodges at KingsMountain.com):
 >
 >> Travis Hassloch suggested I ping Linux folk here locally (SFBay Area
 >> -- I'm in Redwood City) and so here I am, and here's the problem:
 >
 > Jeff, that's going to be a difficult one, and, I have to warn you, may
 > be essentially impossible.  (However, note disclaimer below that I've
 > only had time to barely glance at this.)
 >
 > When you talk about scancodes and keyboard maps, it's evident you think
 > this is basically a keyboard interaction problem, and that you just have
 > to make Fn F8 _really_ generate Fn F8.  However, I have a very, very
 > strong suspicion, based on earlier professional experience, that the
 > problem lies much lower, in the area of ACPI support for proprietary
 > firmware functions.

yeah, it (the problem) might lie in ACPI stuff, dunno -- I did some poking at 
that too and the output of said poking is ensconced in the posts I pointed to.

<innaresting & frustrating story elided />


 > If indeed the sole problem is that Dell changed hte scancodes,

I suspect so, in looking around at various posts on this issue, at least one 
person notes that Fn-F8 worked fine on E6x00 and related systems until that 
person went to Ubuntu 10.xx, for example.

so I have my fingers crossed.

 > you might
 > find it easiest just to compile a really recent upstream 3.x kernel,
 > under the plausible assumption that the issue has probably been resolved
 > in the kernel mainline but that the fix just hasn't yet trickled down to
 > distro precompiled kernels.
 >
 > In fact, I note that one of the Launchpad links you cite says
 > essentially that:
 >
 >   If you could also please test the latest upstream kernel available
 >   that would be great. It will allow additional upstream developers to
 >   examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds
 >
 > That's good advice.  You really shouldn't expect Ubuntu to do kernel
 > development and debugging -- nor should they.  That's what upstream is for.

yeah, i understand, I was hoping I/we can figure out a little xmodmap / keymap 
/ whatever hack and have it fixed (for me at least).

Before mucking about with compiling an upstream kernel, is there any way to 
figure out if the problem was recognized and fixed in said upstream?

What are the risks for breaking currently-working things by running a newer 
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?  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.

thanks for your thoughts,

=JeffH