Comment 6 for bug 33855

I just wanted to confirm that the new driver in the original report works correctly on a Panasonic R4. I don't think the rejected patch (changing PCC_KEYINPUT to 1) is necessary. With the unmodified new driver, the panasonic brightness events are handled correctly (after fixing the panabright.sh script- see tarball in #16424).

The audio events simply need some handler scripts for the events. See the scripts I proposed to the acpi-support bug #16424.

The final "strangeness" that occurs is that acpi_fakekey {113, 114, or 115} produces X keycodes of 160, 174, and 176. I have successfully got the keys working under KDE by using xmodmap to map the keycodes to fake function keys, and then using these function keys to adjust the mixer.

This acpi_fakekey problem is not related to the pcc_acpi driver, and I'm guessing indicates that something is wrong with the X keymap or keyboard layout. The kernel key layout (from getkeycodes) has the correct scancode --> keycode mapping...

So to recap, the 3 separate problems are

1. need new pcc_acpi driver - already committed according this report. this fixes the kernel oops.

2. (unrelated to this bug) need new panabright.sh that computes brightness increments dynamically plus audio handling scripts. Found in tarball in bug #16242.

3. (unrelated to this bug) need to have acpi_fakekey 113, 114, and 115 actually generate the same keycodes under X. (or work around by using xmodmap).

If anyone has clues about how to fix number 3 above, let me know and we can file a bug against acpi-support so that these laptops work "out of the box".

-Ted