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.