Re: [PATCH] toshiba_acpi: Add full hotkey support

From: Andrey Borzenkov
Date: Sat Mar 07 2009 - 10:39:38 EST


On 7 ÐÐÑÑÐ 2009 18:06:40 Matthew Garrett wrote:
> On Sat, Mar 07, 2009 at 10:27:09AM +0300, Andrey Borzenkov wrote:
> > Matthew Garrett wrote:
> > > + {KE_KEY, 0x13d, KEY_SLEEP},
> > > + {KE_KEY, 0x13e, KEY_SUSPEND},
> >
> > I have two buttons marked with memory and disk pictures. When I
> > press the first one HAL emits "sleep" button event, for the the
> > second one HAL emits "hibernate" event. I am using KDE4 and neither
> > works :) According to KDE4 developer, they implement "suspend"
> > button as suspend to RAM. Just trying to clarify which key this
> > should be and whether HAL should be fixed. (I opened bug report
> > for KDE4)
>
> Yeah, I'm not really a KDE guy, so I'm not sure what's happening
> there.
>

Please see reply to another thread titled "Re: suspend / hibernate
nomenclature". What happens here is

- addon-acpi-buttons-toshiba emitted "suspend" for Fn-F3 and "hibernate"
for Fn-F4

- your patch makes HAL emit "sleep" for Fn-F3 and "hibernate" for Fn-F4

So the patch is incompatible change w.r.t. user space. To restore
previous behaviour we need

- patch toshiba_acpi to return KEY_SUSPEND/KEY_HIBERNATE instead of
KEY_SLEEP/KEY_SUSPEND. This depends on commit
6932b918e05b06165ed3457a9f3aa279099a7cbd in linux-next.

- patch HAL to recognize KEY_HIBERNATE and return "suspend" for
KEY_SUSPEND; right now it is:

[KEY_SLEEP] = "sleep",
[KEY_SUSPEND] = "hibernate",

In any case this means that combination of old HAL and new kernel (or
vice versa) becomes broken. Not sure how to handle it.

Attachment: signature.asc
Description: This is a digitally signed message part.