Re: acpi button event to input layer (was [RFC] [PATCH] Make ACPI button driver an input device)

[Dmitry Torokhov <dtor@insightbb.com>]

On Wednesday 06 September 2006 05:33, Yu Luming wrote:
> >
> >  Here they are, with 2 changes:
> >
> >   - button module now depends on CONFIG_INPUT (per discussion with Len)
> >   - if "_LID" evaluation fails SW__LID event is not delivered to userspace
> >
> >  acpi-button-as-input is on top of acpi-button-cleanup...
> >
> 
> Thanks for the patch. The attached one is the update patch against  2.6.18-rc6 git tree, including the 2 patches. 
> 
> >+                       if (!ACPI_FAILURE(acpi_evaluate_integer(handle, "_LID",
> >+                                                               NULL, &state)))
> >+                               input_report_switch(input, SW_LID, !state);
> 
> why it needs to report !state , NOT just state?
> Ps. ACPI defines 0 as closed,  non-0 as open.
> 

Arbitrary decision on my part. I consider switch be active when lid is
closed; when lid is open it is "normal" state.

> >@@ -304,6 +365,12 @@ static int acpi_button_add(struct acpi_d
> >        button->device = device;
> >        acpi_driver_data(device) = button;
> >
> >+       button->input = input = input_allocate_device();
> 
> On my test box, I got 
> drwxr-xr-x 5 root root 0 2006-09-19 18:04 input3
> drwxr-xr-x 5 root root 0 2006-09-19 18:04 input4
> drwxr-xr-x 5 root root 0 2006-09-19 18:04 input5
> 
> input 3 is power button, input4 is lid switch, 
> input 5  is CM power button.
> 
> why these buttons/switch need to have their own input device and event interface?
> Can one input device for all acpi button/lid work?

Right now it naturally ties up in the way corresponding acpi
devices get registered and bound with button driver. It also
better represents real picture, isn't it? After all they are
separate devices as presented by ACPI.

> 
> >+       input->name = acpi_device_name(device);
> Can I get more useful name under  /sys/class/input, rather than input3,4,5...

Not in sysfs. All core input devices in sysfs registered as inputX.
Handlers add their own names (mouseX, eventX). Having uniform name
allows to avoid clashes (if you add a custom name for a power button
what happen when you have 2 of these?). Cusom names belong to /dev
(either statically created or via udev rules). You can see what each
inputX is by looking at "name" sttribute in sysfs.

> >+       error = input_register_device(input);
> Shouldn't input_register_device be called before acpi_button_install_notify_handlers?
> Probably, we need to make sure input_report_switch/key can be invoked only after
> input _register_device has been invoked and succeeded.

It does not really matter. As long as input device was allocated with
input_allocate_device it can withstand input_event calls even if it
is not finished registration with the input core. The events will
be simply dropped (since there are no handles attached to the device
yet).


-- 
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html