On Mon, May 09, 2011 at 08:59:01AM -0700, Andy Ross 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). It shouldn't even be a dbus send - something in userspace should just be listening for event notifications on the accelerometer. Use udev directly. > > 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? acpid is for dealing with cases where the kernel doesn't provide functionality that the kernel should provide. Arbitrary APCI events shouldn't be being delivered to userspace - they should be handled in-kernel and delivered through a meaningful mechanism in order to avoid cases where userspace needs to know about a platform implementation. In this case the right way for the event to hit userspace is as a generic message from the accelerometer, not as a device-specific ACPI event through a deprecated interface. -- Matthew Garrett | mjg59@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe platform-driver-x86" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
