Comment 18 for bug 16424

On Sunday 02 April 2006 04:48, Matthew Garrett wrote:
| 113, 114 and 115 are the correct values (see /usr/include/linux/input.h) -

yes, the kernel keymap is correct. If I run getkeycodes from a real console,
I get the values that I expect.

| these are then remapped in the kernel to correspond to legacy AT keyboards,
| which is the form that X gets them in.

well, the pcc_acpi driver captures these keypresses. In the case of the
brightness keys, the acpid event calls a script (panabright.sh) which
directly manipulates the hardware. In the case of the volume keys, I had
configured the event to call /etc/acpi/mutebtn.sh and the volume scripts.
These scripts call acpi_fakekey with "fake key values" of 113, 114, and 115.

However, the result of the acpi_fakekey commands produce X events with
keycodes of 160, 174, and 176 (according to xev).

So the problem is that acpi_fakekey does not generate the desired X key
numbers. The scancode --> keycode is correct in the linux keymap, it's only
the X keymap that has a problem. Note that I'm using the "Japanese 106 key"
keyboard layout in X. Perhaps I need a custom keyboard layout?

| I believe that span is set to 8
| because older machines don't allow as many brightness values, and so the
| brightness key would otherwise have to be hit several times before anything
| happened.

ah, ok, that explains it. In that case I think span should be calculated
dynamically rather than set to "32". I think this was mentioned previously
in this bug. I'll submit a new patch for this.

-Ted