On 7/2/06, Jaya Kumar <jayakumar.acpi@xxxxxxxxx> wrote:
Hi Len,
On 7/1/06, Brown, Len <len.brown@xxxxxxxxx> wrote:
> > + if (function == ACPI_WRITE) {
> > + status = acpi_bus_generate_event(dev, 0x80, address);
> > + atlas_input_report((u8) address);
>
> What is the reasoning to simultaneously report the same event
> via both ACPI and input?
The event is reported to ACPI because there are legacy apps that read
/proc/acpi/event for this ASIM event. Newer apps can use the F1...
events that they can get via evdev. btw, if CONFIG_INPUT is disabled,
atlas_input_report gets dummied out and it's reported only to ACPI.
I can remove the acpi_bus_generate_event if that's the consensus.
I think because the driver would be new for the mainline we should
remove the old way of reporting events and rely on input layer (and
make the driver depend on CONFIG_INPUT).
Also, could you please change phys from "acpi/input0" to something
like "ASIM0000/atlas/input0" to make it more unique?
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
