need Panasonic notebook support in acpi-support

[Hiroyuki Ikezoe]

acpi-support-0.21 does not support brightness tuning of Panasonic notebook.

I created a patch to support it.

[Hiroyuki Ikezoe (ikezoe)]

Created an attachment (id=2166)
brightness of panasonic notebook

[Hiroyuki Ikezoe (ikezoe)]

This patch also makes changing brightness when AC adapter is connected or not,
but it is very slow because of "sleep 5" in /etc/acpi/power.sh.

I have no idea to solve it.

Do you have any ideas?

[Matthew Garrett (mjg59)]

Thanks - I'll try to integrate this into the next version of acpi-support

[Matthew Garrett (mjg59)]

Ok, I've added this except for the changing brightness on power events code.
I'll look into that.

[Hiroyuki Ikezoe (ikezoe)]

Thanks.

I found a bit better way.
The way is to receive the key press event instead of the key release event. In
this way, I could get more quick response.

Panasonic acpi driver sends 0000008x (00000081 or 00000082) event for key
presses and 0000000x (00000001 or 00000002) event for key releases, so I changed
the events file like the following:

Index: panasonic-brightness-down
===================================================================
--- panasonic-brightness-down (revision 440)
+++ panasonic-brightness-down (working copy)
@@ -1,3 +1,3 @@
 # /etc/acpi/events/panasonic-brightness-down
-event=pcc HKEY 00000080 00000001
+event=pcc HKEY 00000080 00000081
 action=/etc/acpi/panabright.sh down
Index: panasonic-brightness-up
===================================================================
--- panasonic-brightness-up (revision 440)
+++ panasonic-brightness-up (working copy)
@@ -1,3 +1,3 @@
 # /etc/acpi/events/panasonic-brightness-up
-event=pcc HKEY 00000080 00000002
+event=pcc HKEY 00000080 00000082
 action=/etc/acpi/panabright.sh up

[Matthew Garrett (mjg59)]

Now included.

[Jun Kobayashi (jkbys)]

Created an attachment (id=4377)
new brightness control script supports new Panasonic notebook

With acpi-support 0.45, the brightness control doesn't work well with my
Panasonic W4. This panabright.sh fixes this problem.

[Jun Kobayashi (jkbys)]

Created an attachment (id=4379)
diff file

This patch is a diff file of panabright.sh.

The new Panasonic notebook W4 has different max value of brightness(
/proc/acpi/pcc/"$INTERFACE"_max), so the span value should be calculated.

[Hiroyuki Ikezoe (ikezoe)]

I confirmed that this change works fine on my machine and new machine.
My machine's max value is 255 and the new one is 20.

I think this change is reasonable.
Please commit it.

Thanks.

[Hiroyuki Ikezoe (ikezoe)]

As far as I confirmed, on Panasonic Let'snote W2, Y2, W4 and Y4, resume works
fine if the modification in BUG #24610 is applied.

I will attach the file for these laptops should be in /usr/share/acpi-support/.

[Hiroyuki Ikezoe (ikezoe)]

Created an attachment (id=4782)
Matsushita Electric Industrial Co.,Ltd..config in /usr/share/acpi-support/

[tnoo (answer)]

Is this already activated in Dapper?
I upgraded from Breezy, no new installation. Anyway, calling panabright.sh from the command line works.

Thanks, Martin

[TedKisner (tskisner-public)]

I just installed flight 5 on a panasonic R4. After installing a new pcc_acpi driver to go with kernel 2.6.15 (see bug #33855), the hotkeys are now reported correctly to acpid (rather than just causing a kernel oops with the old driver). The mute/volume keys however are currently not handled in /etc/acpi/events/.

Also, the panabright.sh script does not allow small changes in brightness. Is there a reason that SPAN is not set to one?

The patch below changes panabright.sh to use a span of 1, and adds scripts for handling the volume up/down and mute buttons.

Let me know if this is the correct way to go about things...

-Ted

[TedKisner (tskisner-public)]

This works on a panasonic R4- it calls acpi_fakekey. HOWEVER, there may still be issues with the mapping of the number called by acpi_fakekey to the key number detected by showkey.

[TedKisner (tskisner-public)]

Just wanted to add that with the above patch, the mute, volume down, and volume up keys show up as X11 keycodes 160, 174, and 176. I have successfully used xmodmap to map them to some virtual function keys (F21, F22, and F23) and then configure kmix to use these to adjust the main volume.

Still not sure why acpi_fakekey 113 generates an X keypress of 160, but it doesn't really matter since we can remap it ;-)

-Ted

[Matthew Garrett (mjg59)]

113, 114 and 115 are the correct values (see /usr/include/linux/input.h) - these are then remapped in the kernel to correspond to legacy AT keyboards, which is the form that X gets them in. 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.

[TedKisner (tskisner-public)]

Just wanted to add that with the above patch, the mute, volume down, and volume up keys show up as X11 keycodes 160, 174, and 176. I have successfully used xmodmap to map them to some virtual function keys (F21, F22, and F23) and then configure kmix to use these to adjust the main volume.

Still not sure why acpi_fakekey 113 generates an X keypress of 160, but it doesn't really matter since we can remap it ;-)

-Ted

[TedKisner (tskisner-public)]

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

[TedKisner (tskisner-public)]

Just wanted to add that with the above patch, the mute, volume down, and volume up keys show up as X11 keycodes 160, 174, and 176. I have successfully used xmodmap to map them to some virtual function keys (F21, F22, and F23) and then configure kmix to use these to adjust the main volume.

Still not sure why acpi_fakekey 113 generates an X keypress of 160, but it doesn't really matter since we can remap it ;-)

-Ted

[TedKisner (tskisner-public)]

Yikes! I guess the email interface to the bug tracking system likes to spew tons of repeated messages- sorry.

Here is a tarball of the new panabright.sh that sets the SPAN so that there are 10 brightness increments. Also included are volume handlers that call /etc/acpi/volupbtn.sh, etc.

[TedKisner (tskisner-public)]

This version of panabright.sh has 10 brightness increments. Also included mute/volume events that call the existing mutebtn.sh and volume scripts.

[Hiroyuki Ikezoe (ikezoe)]

Matthew, please apply Ted's modification. I think it is reasonable for me.

[Matthew Lange (matthewlange)]

Bug is targetted for fix in acpi-support instead of Ubuntu general.

[Matthew Lange (matthewlange)]

Set to In-Progress for the folks working on it

[John Stowers (nzjrs)]

This is broken again in edgy beta

How can I help?

[John Stowers (nzjrs)]

Setting to Confimred because this bug appears in edgy beta 1 again...

[agostinomaurotto (agostino-maurotto)]

confirm again
in edgy RC the problem is still there.

[Wouter Stomp (wouterstomp-deactivatedaccount)]

0.97 brought improved panasonic support. Does this problem still occur?

[agostinomaurotto (agostino-maurotto)]

Wouter Stomp ha scritto:
> 0.97 brought improved panasonic support. Does this problem still occur?
>
>
no everything works fine by now

[Daniel Hahler (blueyed)]

Closing as "Fix released", as per comment.
If you encounter any other problems related to this, please create a new bug report.
Thank you.