Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Mattia Dongili]

On Fri, Jun 03, 2011 at 05:38:08PM +0200, Marco Chiappero wrote:
> sony_nc_notify rewritten (and placed near the other acpi callbacks),
> the hotkey decoding code move to a new function
> sony_nc_hotkeys_decode. Now generating acpi netlink events too.

one thing I'm wondering is if we shouldn't stop sending input
events also via the acpi bus rather than adding new notification
methods. The /proc/acpi/event notification will go away on its own one
day so maybe letting this habit die with it is a reasonable deprecation
plan for /proc/acpi/event users.

Dmitry, Matthew,
any thought about this?

> Signed-off-by: Marco Chiappero <marco@absence.it>
> ---
> 
> --- a/drivers/platform/x86/sony-laptop.c
> +++ b/drivers/platform/x86/sony-laptop.c
> @@ -1151,62 +1151,6 @@ static struct sony_nc_event sony_127_eve
>  /*
>   * ACPI callbacks
>   */
> -static void sony_nc_notify(struct acpi_device *device, u32 event)
> -{
> -	u32 ev = event;
> -
> -	if (ev >= 0x90) {
> -		/* New-style event */
> -		unsigned int result;
> -		int key_handle = 0;
> -		ev -= 0x90;
> -
> -		if (sony_find_snc_handle(0x100) == ev)
> -			key_handle = 0x100;
> -		if (sony_find_snc_handle(0x127) == ev)
> -			key_handle = 0x127;
> -
> -		if (key_handle) {
> -			struct sony_nc_event *key_event;
> -
> -			if (sony_call_snc_handle(key_handle, 0x200, &result)) {
> -				dprintk("sony_nc_notify, unable to decode"
> -					" event 0x%.2x 0x%.2x\n", key_handle,
> -					ev);
> -				/* restore the original event */
> -				ev = event;
> -			} else {
> -				ev = result & 0xFF;
> -
> -				if (key_handle == 0x100)
> -					key_event = sony_100_events;
> -				else
> -					key_event = sony_127_events;
> -
> -				for (; key_event->data; key_event++) {
> -					if (key_event->data == ev) {
> -						ev = key_event->event;
> -						break;
> -					}
> -				}
> -
> -				if (!key_event->data)
> -					pr_info("Unknown event: 0x%x 0x%x\n",
> -						key_handle, ev);
> -				else
> -					sony_laptop_report_input_event(ev);
> -			}
> -		} else if (sony_find_snc_handle(sony_rfkill_handle) == ev) {
> -			sony_nc_rfkill_update();
> -			return;
> -		}
> -	} else
> -		sony_laptop_report_input_event(ev);
> -
> -	dprintk("sony_nc_notify, event: 0x%.2x\n", ev);
> -	acpi_bus_generate_proc_event(sony_nc_acpi_device, 1, ev);
> -}
> -
>  static acpi_status sony_walk_callback(acpi_handle handle, u32 level,
>  				      void *context, void **return_value)
>  {
> @@ -1237,6 +1181,42 @@ static int sony_nc_function_setup(unsign
>  	return 0;
>  }
> 
> +static int sony_nc_hotkeys_decode(unsigned int handle)
> +{
> +	int ret = 0;
> +	unsigned int result = 0;
> +	struct sony_nc_event *key_event;
> +
> +	if (sony_call_snc_handle(handle, 0x200, &result)) {
> +		dprintk("sony_nc_hotkeys_decode,"
> +				" unable to retrieve the hotkey\n");
> +		ret = -1;

when sony_call_snc_handle(handle, 0x200, &result) fails above you will
be reporting -1 via the acpi bus. The old code restored the event and
reported the raw number instead.

> +	} else {
> +		result &= 0xff;
> +
> +		if (handle == 0x100)
> +			key_event = sony_100_events;
> +		else
> +			key_event = sony_127_events;
> +
> +		for (; key_event->data; key_event++) {
> +			if (key_event->data == result) {
> +				ret = key_event->event;
> +				break;
> +			}
> +		}
> +
> +		if (!key_event->data)
> +			pr_info("Unknown hotkey 0x%.2x (handle 0x%.2x)\n",
> +							result, handle);

For not yet mapped keys instead you'll always report 0;
The current behaviour is different, please don't change it without a
good reason.

> +		else
> +			dprintk("sony_nc_hotkeys_decode, hotkey 0x%.2x decoded "
> +					"to event 0x%.2x\n", result, ret);
> +	}
> +
> +	return ret;
> +}
> +
>  static void sony_nc_rfkill_cleanup(void)
>  {
>  	int i;
> @@ -1864,6 +1844,52 @@ static int sony_nc_snc_resume(void)
>  	return 0;
>  }
> 
> +static void sony_nc_notify(struct acpi_device *device, u32 event)
> +{
> +	u8 ev = 0;
> +	int value = 0;
> +
> +	dprintk("sony_nc_notify, event: 0x%.2x\n", event);
> +
> +	/* handles related events */
> +	if (event >= 0x90) {
> +		unsigned int result = 0, handle = 0;
> +
> +		/* the event should corrispond to the offset of the method */
> +		unsigned int offset = event - 0x90;
> +
> +		handle = handles->cap[offset];
> +		switch (handle) {
> +		/* list of handles known for generating events */
> +		case 0x0100:
> +		case 0x0127:
> +			/* hotkey event, a key has been pressed, retrieve it */
> +			value = sony_nc_hotkeys_decode(handle);
> +			if (value > 0) /* known event */
> +				sony_laptop_report_input_event(value);
> +			/* else unknown event or failure, do nothing */
> +			ev = 1;
> +			break;
> +
> +		default:
> +			value = event;
> +			dprintk("Unknowk event for handle: 0x%x\n", handle);
> +			break;
> +		}
> +
> +		/* clear the event (and the event reason when present) */
> +		acpi_callsetfunc(sony_nc_acpi_handle, "SN05", 1 << offset,
> +				&result);
> +	} else {
> +		ev = 1;
> +		sony_laptop_report_input_event(event);
> +	}
> +
> +	acpi_bus_generate_proc_event(device, ev, value);
> +	acpi_bus_generate_netlink_event(device->pnp.device_class,
> +					dev_name(&device->dev), ev, value);

see above about this.

> +}
> +
>  static int sony_nc_add(struct acpi_device *device)
>  {
>  	acpi_status status;
-- 
mattia
:wq!

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Marco Chiappero]

Il 04/06/2011 10:43, Mattia Dongili ha scritto:
> when sony_call_snc_handle(handle, 0x200,&result) fails above you will
> be reporting -1 via the acpi bus. The old code restored the event and
> reported the raw number instead.

You are right, does the following sony_nc_notify modification look fine 
to you?

/* hotkey event, a key has been pressed, retrieve it */
value = sony_nc_hotkeys_decode(handle);
if (value > 0) /* known event */
	sony_laptop_report_input_event(value);
else /* restore the original event */
	value = event;

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Mattia Dongili]

On Sat, Jun 04, 2011 at 01:26:28PM +0200, Marco Chiappero wrote:
> Il 04/06/2011 10:43, Mattia Dongili ha scritto:
> >when sony_call_snc_handle(handle, 0x200,&result) fails above you will
> >be reporting -1 via the acpi bus. The old code restored the event and
> >reported the raw number instead.
> 
> You are right, does the following sony_nc_notify modification look
> fine to you?
> 
> /* hotkey event, a key has been pressed, retrieve it */
> value = sony_nc_hotkeys_decode(handle);
> if (value > 0) /* known event */
> 	sony_laptop_report_input_event(value);
> else /* restore the original event */
> 	value = event;

it's a bit out of context but I guess it should work. It would be good
to have sony_nc_hotkeys_decode also report the "not decoded" case
consistently back to callers though.
-- 
mattia
:wq!

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Marco Chiappero]

Il 06/06/2011 00:38, Mattia Dongili ha scritto:
> it's a bit out of context but I guess it should work. It would be good
> to have sony_nc_hotkeys_decode also report the "not decoded" case
> consistently back to callers though.

Do you mean a negative value instead of 0? If so, let's return -EIO (or 
-2) on error and -1 for the unknown mapping case, else the translated 
key value (> 0).

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Mattia Dongili]

On Mon, Jun 06, 2011 at 02:23:34PM +0200, Marco Chiappero wrote:
> Il 06/06/2011 00:38, Mattia Dongili ha scritto:
> >it's a bit out of context but I guess it should work. It would be good
> >to have sony_nc_hotkeys_decode also report the "not decoded" case
> >consistently back to callers though.
> 
> Do you mean a negative value instead of 0? If so, let's return -EIO
> (or -2) on error and -1 for the unknown mapping case, else the
> translated key value (> 0).

I was more thinking of -EINVAL for all cases.

-- 
mattia
:wq!

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Marco Chiappero]

Il 06/06/2011 14:42, Mattia Dongili ha scritto:
> On Mon, Jun 06, 2011 at 02:23:34PM +0200, Marco Chiappero wrote:
>> Il 06/06/2011 00:38, Mattia Dongili ha scritto:
>>> it's a bit out of context but I guess it should work. It would be good
>>> to have sony_nc_hotkeys_decode also report the "not decoded" case
>>> consistently back to callers though.
>>
>> Do you mean a negative value instead of 0? If so, let's return -EIO
>> (or -2) on error and -1 for the unknown mapping case, else the
>> translated key value (>  0).
>
> I was more thinking of -EINVAL for all cases.

Ok, added to my changelist. As soon as there are no more comments I'll 
repost the modified patches.

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Matthew Garrett]

On Sat, Jun 04, 2011 at 05:43:39PM +0900, Mattia Dongili wrote:
> On Fri, Jun 03, 2011 at 05:38:08PM +0200, Marco Chiappero wrote:
> > sony_nc_notify rewritten (and placed near the other acpi callbacks),
> > the hotkey decoding code move to a new function
> > sony_nc_hotkeys_decode. Now generating acpi netlink events too.
> 
> one thing I'm wondering is if we shouldn't stop sending input
> events also via the acpi bus rather than adding new notification
> methods. The /proc/acpi/event notification will go away on its own one
> day so maybe letting this habit die with it is a reasonable deprecation
> plan for /proc/acpi/event users.

Yeah, it's about time for this to die.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Marco Chiappero]

Il 04/06/2011 14:42, Matthew Garrett wrote:
>> one thing I'm wondering is if we shouldn't stop sending input
>> events also via the acpi bus rather than adding new notification
>> methods. The /proc/acpi/event notification will go away on its own one
>> day so maybe letting this habit die with it is a reasonable deprecation
>> plan for /proc/acpi/event users.
>
> Yeah, it's about time for this to die.

Sorry, I don't understand what should be changed and the desired behavior:
1) no acpi notification at all, neither proc nor netlink (but we need 
some new entries in input.h first).
2) no acpi notification for hotkeys events only.
3) no acpi notification to the deprecated /proc/acpi/event only

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Matthew Garrett]

On Sat, Jun 04, 2011 at 04:22:53PM +0200, Marco Chiappero wrote:
> Il 04/06/2011 14:42, Matthew Garrett wrote:
> >>one thing I'm wondering is if we shouldn't stop sending input
> >>events also via the acpi bus rather than adding new notification
> >>methods. The /proc/acpi/event notification will go away on its own one
> >>day so maybe letting this habit die with it is a reasonable deprecation
> >>plan for /proc/acpi/event users.
> >
> >Yeah, it's about time for this to die.
> 
> Sorry, I don't understand what should be changed and the desired behavior:
> 1) no acpi notification at all, neither proc nor netlink (but we
> need some new entries in input.h first).
> 2) no acpi notification for hotkeys events only.
> 3) no acpi notification to the deprecated /proc/acpi/event only

No acpi notification at all. There's no good way for userspace to make 
use of them without knowing the hardware they're running on, which is 
far from ideal.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Marco Chiappero]

Il 04/06/2011 16:30, Matthew Garrett ha scritto:
> No acpi notification at all. There's no good way for userspace to make
> use of them without knowing the hardware they're running on, which is
> far from ideal.

Ok, fine. So, should we forward any event (als events, shock protection, 
hybrid GFX, etc.) to the input core then?

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Matthew Garrett]

On Sat, Jun 04, 2011 at 04:34:43PM +0200, Marco Chiappero wrote:

> Ok, fine. So, should we forward any event (als events, shock
> protection, hybrid GFX, etc.) to the input core then?

als events and shock protection probably ought to be uevents on the 
appropriate device. Hybrid graphics requests probably ought to be input 
events, but we'll probably want to talk to the graphics people about 
that.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Marco Chiappero]

Il 04/06/2011 16:36, Matthew Garrett ha scritto:
> On Sat, Jun 04, 2011 at 04:34:43PM +0200, Marco Chiappero wrote:
>
>> Ok, fine. So, should we forward any event (als events, shock
>> protection, hybrid GFX, etc.) to the input core then?
>
> als events and shock protection probably ought to be uevents on the
> appropriate device.

More precisely? As far as I know there is no ALS device class; and I 
know nothing about the other.

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Matthew Garrett]

On Sat, Jun 04, 2011 at 04:42:24PM +0200, Marco Chiappero wrote:

> More precisely? As far as I know there is no ALS device class; and I
> know nothing about the other.

Where there's no generic implementation of a hardware class that's 
present in multiple pieces of hardware, the first step is to define a 
generic implementation :)

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Corentin Chary]

On Sat, Jun 4, 2011 at 4:45 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Sat, Jun 04, 2011 at 04:42:24PM +0200, Marco Chiappero wrote:
>
>> More precisely? As far as I know there is no ALS device class; and I
>> know nothing about the other.
>
> Where there's no generic implementation of a hardware class that's
> present in multiple pieces of hardware, the first step is to define a
> generic implementation :)

The last ALS device class attempt didn't went so well, what's the
current status for this one ?



-- 
Corentin Chary
http://xf.iksaif.net

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Marco Chiappero]

Il 04/06/2011 17:04, Corentin Chary ha scritto:
> The last ALS device class attempt didn't went so well,

In fact I had to expose some sysfs nodes in sony-laptop. I don't know 
how other vendors implemented the ALS stuff (I suppose mostly with an hw 
solution), but the software based solution from Sony is quite complex 
and I don't know if it can fit in a generic interface, but we can try. 
However in the meantime I cloned the (nicely working) Windows software 
behavior, with the help of Javier Achirica: by means of the acpi bus and 
a Vaio specific daemon (using some model specific parameters provided by 
the DSDT code and the same lux-to-backlight formula used by the windows 
software from Sony) we managed to have everything working and every 
model supported. Ok, it not the best design (a better one may be 
introduced later), but it works great and now (please consider that 
older ALS equipped models are now 2 years old, so it would be good to 
support them as soon as possible); many people are already happily using 
this solution.
I think there will be a lot to discuss about patch #23.

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Alan Cox]

On Sat, 04 Jun 2011 16:42:24 +0200
Marco Chiappero <marco@absence.it> wrote:

> Il 04/06/2011 16:36, Matthew Garrett ha scritto:
> > On Sat, Jun 04, 2011 at 04:34:43PM +0200, Marco Chiappero wrote:
> >
> >> Ok, fine. So, should we forward any event (als events, shock
> >> protection, hybrid GFX, etc.) to the input core then?
> >
> > als events and shock protection probably ought to be uevents on the
> > appropriate device.
> 
> More precisely? As far as I know there is no ALS device class; and I 
> know nothing about the other.

Start reading around here

http://lkml.org/lkml/2010/3/3/334

(and the earlier threads on the ALS class which Linus rejected)

I'd like to see an ALS class but it seems the head penguin won't accept
one, so we now have a zillion incompatible light sensors mostly out of
tree because nobody can be bothered to have the argument again.

The longer term plan is to stick all kinds of device sensors (as distinct
from input devices) into the IIO layer but that is still in staging and
seems to have no clear plan of date for migration yet. However Jonathan
(the maintainer) also doesn't seem too keen on owning them either

http://lkml.org/lkml/2010/3/3/378

All in all ALS is a bit of a disaster area.

Alan

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Marco Chiappero]

Il 04/06/2011 22:22, Alan Cox ha scritto:

> The longer term plan is to stick all kinds of device sensors (as distinct
> from input devices) into the IIO layer but that is still in staging and
> seems to have no clear plan of date for migration yet. However Jonathan
> (the maintainer) also doesn't seem too keen on owning them either
>
> http://lkml.org/lkml/2010/3/3/378
>
> All in all ALS is a bit of a disaster area.

So, what to do now? I'm not sure that the IIO layer is always fine when 
dealing with notbooks. For example, on every ALS equipped Vaio notebook, 
setting the notebook to generate ALS events will also result in _BCM no 
longer applying any further backlight change, it will instead generate 
another ACPI event when calling (this allows to have, in userspace, a 
single piece of software mixing and applying coherently both ALS driven 
and user driven backlight corrections).
On newer Vaios, the ALS sensor is totally controlled by the EC, so we 
just have the illuminance reading and talking about "device driver" 
don't make much sense (we'd better have an ALS device class). I don't 
know how other vendors introduced this functionality, but I can imagine 
that many different implementation are present across different models 
or brands. We need a solution, now, because there are lots of notebooks 
with these tiny but useful sensors, and people do want to use them.

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Alan Cox]

> that many different implementation are present across different models 
> or brands. We need a solution, now,

We needed a solution last year nothing has changed there other than there
are now a bazillion more out of tree drivers.

I don't have a solution I just wanted to make sure you understood the
problem space. Personally I think the right solution is for someone who
has infinite time to point out the mess and cluebat Linus, I don't have
time for that.

Alan

Re: [PATCH 8/25] sony-laptop: sony_nc_notify rewritten and improved

[Marco Chiappero]

Il 05/06/2011 21:14, Alan Cox ha scritto:
>> that many different implementation are present across different models
>> or brands. We need a solution, now,
>
> We needed a solution last year nothing has changed there other than there
> are now a bazillion more out of tree drivers.
>
> I don't have a solution I just wanted to make sure you understood the
> problem space.

Sure, I was rather expecting a reply from Matthew about what to do now, 
since there is no "rule" to follow regarding the ALS support and it's a 
pity not to support hardware we can make 100% working. But at this point 
perhaps we'd better discuss only on the platform driver mailing list.

Marco

Re: [PATCH 22/25] sony-laptop: forward Hybrid GFX notifications to userspace

[Mattia Dongili]

On Fri, Jun 03, 2011 at 09:27:00PM +0200, Marco Chiappero wrote:
> Some Vaios come with both integrated and discrete graphics, plus a
> switch for choosing one of the two. When the switch position is
> changed, a notification is generated, now forwarded to userspace for
> example for visual notifications, user scripts, and so on.
> 
> Signed-off-by: Marco Chiappero <marco@absence.it>
> ---
> 
> --- a/drivers/platform/x86/sony-laptop.c
> +++ b/drivers/platform/x86/sony-laptop.c
> @@ -3118,6 +3118,14 @@ static void sony_nc_notify(struct acpi_d
> 
>  	dprintk("sony_nc_notify, event: 0x%.2x\n", event);
> 
> +	/* events codes list
> +	 * 1    Hotkeys
> +	 * 2    RFKILL
> +	 * 3    ALS
> +	 * 4    HDD protection
> +	 * 5	Hybrid GFX
> +	 */

how about some #defines instead of a comment?

>  	/* handles related events */
>  	if (event >= 0x90) {
>  		unsigned int result = 0, handle = 0;
> @@ -3169,6 +3177,23 @@ static void sony_nc_notify(struct acpi_d
>  			/* hdd protection event, notify userspace */
>  			break;
> 
> +		case 0x0128:
> +		case 0x0146:
> +			/* Hybrid GFX switching, 1 */
> +			sony_call_snc_handle(handle, 0x0000, &result);
> +			dprintk("sony_nc_notify, Hybrid GFX event received "
> +					"(reason: %s)\n", (result & 0x01) ?
> +					"switch position change" : "unknown");
> +
> +			/* verify the switch state
> +			   (1: discrete GFX, 0: integrated GFX)*/
> +			result = 0;
> +			sony_call_snc_handle(handle, 0x0100, &result);
> +
> +			ev = 5;
> +			value = result & 0xff;
> +			break;

shouldn't this be reported as an input event rather than just an acpi
one?
also, I am trying to recall how the speed/stamina switch was handled in
older SZ and other models. I think we are already notifying the
switching event as an input key (PROG4? PROG5?)
I didn't see a better option in input.h, maybe time to add one?

>  		default:
>  			value = event;
>  			dprintk("Unknowk event for handle: 0x%x\n", handle);
-- 
mattia
:wq!

Re: [PATCH 22/25] sony-laptop: forward Hybrid GFX notifications to userspace

[Marco Chiappero]

Il 04/06/2011 10:48, Mattia Dongili ha scritto:
> On Fri, Jun 03, 2011 at 09:27:00PM +0200, Marco Chiappero wrote:
>> Some Vaios come with both integrated and discrete graphics, plus a
>> switch for choosing one of the two. When the switch position is
>> changed, a notification is generated, now forwarded to userspace for
>> example for visual notifications, user scripts, and so on.

[...]

>> +		case 0x0128:
>> +		case 0x0146:
>> +			/* Hybrid GFX switching, 1 */
>> +			sony_call_snc_handle(handle, 0x0000,&result);
>> +			dprintk("sony_nc_notify, Hybrid GFX event received "
>> +					"(reason: %s)\n", (result&  0x01) ?
>> +					"switch position change" : "unknown");
>> +
>> +			/* verify the switch state
>> +			   (1: discrete GFX, 0: integrated GFX)*/
>> +			result = 0;
>> +			sony_call_snc_handle(handle, 0x0100,&result);
>> +
>> +			ev = 5;
>> +			value = result&  0xff;
>> +			break;
>
> shouldn't this be reported as an input event rather than just an acpi
> one?

If so, please someone let me know which keys to use.

Re: [PATCH 22/25] sony-laptop: forward Hybrid GFX notifications to userspace

[Mattia Dongili]

On Mon, Jun 20, 2011 at 11:12:50PM +0200, Marco Chiappero wrote:
> Il 04/06/2011 10:48, Mattia Dongili ha scritto:
> >On Fri, Jun 03, 2011 at 09:27:00PM +0200, Marco Chiappero wrote:
> >>Some Vaios come with both integrated and discrete graphics, plus a
> >>switch for choosing one of the two. When the switch position is
> >>changed, a notification is generated, now forwarded to userspace for
> >>example for visual notifications, user scripts, and so on.
> 
> [...]
> 
> >>+		case 0x0128:
> >>+		case 0x0146:
> >>+			/* Hybrid GFX switching, 1 */
> >>+			sony_call_snc_handle(handle, 0x0000,&result);
> >>+			dprintk("sony_nc_notify, Hybrid GFX event received "
> >>+					"(reason: %s)\n", (result&  0x01) ?
> >>+					"switch position change" : "unknown");
> >>+
> >>+			/* verify the switch state
> >>+			   (1: discrete GFX, 0: integrated GFX)*/
> >>+			result = 0;
> >>+			sony_call_snc_handle(handle, 0x0100,&result);
> >>+
> >>+			ev = 5;
> >>+			value = result&  0xff;
> >>+			break;
> >
> >shouldn't this be reported as an input event rather than just an acpi
> >one?
> 
> If so, please someone let me know which keys to use.

the speed/stamina switch is not very useful at the moment as we can't do
anything with it anyway. There is probably no need to send the event to
userspace at all for now. Else a new switch event should be defined for
this.

-- 
mattia
:wq!