On Mon, 09 May 2011 08:59:01 -0700, Andy Ross <andy.ross@xxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
