A new Panasonic ACPI driver is required for kernel-2.6.15

The small patch:

--- pcc_acpi.c.orig 2006-02-24 21:23:08.000000000 +0900
+++ pcc_acpi.c 2006-02-24 21:23:42.000000000 +0900
@@ -149,9 +149,7 @@ MODULE_DEVICE_TABLE(pnp,acpi_pcc_pnp_tab

 #define BUS_PCC_HOTKEY BUS_I8042 /*0x1a*/ /* FIXME: BUS_I8042? */

-/* Fn+F4/F5 confricts with Shift+F1/F2 */
-/* This hack avoids key number confrict */
-#define PCC_KEYINPUT_MODE (0)
+#define PCC_KEYINPUT_MODE (1)

 /* LCD_TYPEs: 0 = Normal, 1 = Semi-transparent
    ENV_STATEs: Normal temp=0x01, High temp=0x81, N/A=0x00

I asked the driver author that the key events are really conflict with others. But I've never received any responce from him.

As far as I confimed, there is no conflict with any key events.
We need the patch to control sound volume by GNOME.

Thanks.

Confirmed that I am seeing this

https://wiki.ubuntu.com/LaptopTestingTeam/PanasonicCFR4

According to 'drivers/acpi/pcc_acpi.c', the driver hasn't been updated since 2004, unfortunately, the current 'linux-source' tarball also seems to have corrupted timestamps on the files so it's not possible to rely on those either.

The last entry is about "combing the patches from XXX", who is the author the other patch about.

The affects of the new-driver suggested above seem to be to change the driver from sending ACPI HKEY events to adding an input driver and sending them via that.

The original driver website is at http://www.da-cha.org/letsnote/index.html. This hasn't had any updates since 2004. As noted in the source the latest version was simply including modifications by Yokota Hiroshi.

Yokota Hiroshi has his own website where he continues to update the driver: http://www.netlab.cs.tsukuba.ac.jp/~yokota/izumi/panasonic_acpi/
This is where the new driver posted above can be found.

I'm now using Yokota's driver on my panasonic cf-t2 and it is working fine.

This is a regression from 5.10, dropping in the latest version of the driver is reported to fix the issues.

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

No, the acpi_fakekey behaviour is entirely correct. acpi_fakekey generates kernel keycodes. These are then heavily remapped by the kernel before they hit X, which then remaps them further.

yes, sorry- I didn't look at the acpi_fakekey source before posting, I see now that it just generates kernel input events. So the problem is with the kernel to X keymap conversion. Perhaps this is just a laptop-specific issue that we will have to deal with on the wiki page. Thanks for the feedback.

-Ted

No, there *is* *no* *problem*. Kernel keycode get remapped to X keycodes. The mapping is consistent. That's fine. The only issue is over having X tie those to appropriate keysyms.

OK, so users just need to use the appropriate Gnome/KDE/X tools to map these keys to their desired actions. Sorry that this thread has diverged from the original topic.

cheers,

-Ted

The updated pcc_acpi driver is now part of kernel 2.6.15-20, and is available in dapper. Hotkeys now work fine on a Panasonic R4 with this standard kernel. Can the original poster confirm that the new kernel package resolves this bug?

Sorry for the delay.
Kernel 2.6.15-20 works fine except volume-up/down and mute hot key.
And these keys works with Ted's modification for acpi-support in BUG#16424.