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

[Rick Moen]

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.

Some years back, I was in charge of all Unix (Linux, Solaris) hardware
certification for a very large EDA-industry firm, and we were major
purchasers from a leading laptop manufacturer, and in particular of a
really nice model with an ATI video chip.  Our engineers needed to
be able to switch between external and internal monitors for
demonstrations at meetings, and could do this with Fn F4 under
MS-Windows XP very reliably.   If using the open source video driver 
in RHEL, they were unable to make Fn F4 do anything at all.  If using
the proprietary ATI driver, Fn F4 still did nothing, but the proprietary
video driver was hardcoded to drive -both- the internal and external
video, without any option to disable either of them.

Our engineers didn't like that a bit, so they put pressure on my
department to engineer a fix.  We tried, it didn't seem to be working,
so we applied pressure up the management chain through the leading
laptop manufacturer.  Nothing happened.  Six months passed, and we kept
up the pressure.  Our high-level sales engineer seemed to be able to get
every problem but that one fixed for us.  We kept pestering him, telling
him that we'd determined through experimentation that enabling Fn F4
merely required adding support to the necessary ACPI call to the video
code on the kernel, and that we were willing to do the coding work but
needed access to the ACPI implementation specs.

Finally, he bent just a bit to tell us the reason for the lack of help.
Headquarters back in the Far East acknowledged that it was an ACPI call.  
However, they had an understanding with a large Pacific Northwest
operating system vendor that they would continue to hold that as
proprietary information.

And that was that.

However, I don't know that this is actually the explanation for your
problem.  In particular, I've barely examined your message and just
started looking at the links you provided.  

If indeed the sole problem is that Dell changed hte scancodes, 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.