Re: [RFC] Reporting "orientation changed" event

[Anisse Astier <anisse@astier.eu>]

On Mon, 09 May 2011 08:59:01 -0700, Andy Ross <andy.ross@windriver.com> wrote :

> On 05/09/2011 08:47 AM, Matthew Garrett wrote:
> > Yes, so the accelerometer driver should (in-kernel) know that a coarse 
> > orientation event has occured and then send an appropriate uevent to 
> > userspace indiciating that it has new data.
> 
> OK, so substituting udev for acpid, but otherwise leaving the
> input-polldev device alone.  That certainly sounds nice to me, though
> I'm not sure where the "dreadful / don't do that" advice is directed
> as the handling in userspace will be virtual identical (moving the
> dbus-send from the acpid event file into a udev rule).
> 
> > I'm going to NAK anything that reports "Coarse orientation change"
> > to userspace without providing any context.
> 
> Just to be clear: there's no kernel code to NAK here.  The acpid hook
> is raw, and in userspace.  It's not clean, but it's also a single-device
> fixup: seems to me to be pretty much exactly what apcid is for, no?

I think this was aimed at my proposal to send an input event
KEY_DIRECTION from within asus_laptop driver, which wouldn't provide
context with regard to which accelerometer device triggered it (although
in our setup there's only one device, and the ACPI event doesn't provide
any context either, but at least we know it's an ACPI accelerometer).

An udev event(e.g "change") works for me, it would provide context, and
wouldn't disturb the handling of the polled-input device which we'd like
to open as little as possible.

Anyway, whatever solution we choose, the priority is to get this driver
included, even if we don't support the "Coarse Orientation Changed" event
in kernel yet.

Anisse