On 12/02/10 17:26, Bill Gatliff wrote: > Guys: > > > Is there any way for an input device driver (e.g. something that > calls input_report_abs() and input_sync()) to know when there is a > reader of its associated /dev/input/eventX? > > I would love to know when something calls evdev_read() and/or > evdev_poll(), so that I could then initiate a sampling operation on > the hardware itself. Otherwise, I'm forced to periodically poll the > hardware and that means I'm either gathering data that no application > wants, or I'm gathering it before (or faster than) an application is > actually asking for it. > > I have stared at a lot of the evdev and related code, and can't find > anything that looks like what I want. Am I just not seeing it, or am > I looking in the wrong place? Hi Bill, It's not entirely relevant, but I thought I'd take this opportunity to say how we would do the same in IIO. In our case we have explicit triggers that cause data to be captured. At the moment they are things like dataready signals and periodic timers, but they are intended to be more general. The big requirement we have is that more than one device can be sampled from based on a single hardware or software event. This is crucial for some inertial algorithms where we have to get readings from a number of sensors as close as possible in time. On the todo list that exists in my head is a userspace trigger. That would allow us to set up as many devices as we want to capture on a poke from userspace (sysfs file write or something else if lower overheads are needed). In our case this fine control of phase of capture is a key requirement and one that we don't have completely covered as yet. Right now there is no consideration of how long a given device takes to get a sample and they are merely triggered in series. Obviously that time delay is dependant on hardware state (particularly if low power modes exist on the device). Of course this is not all that relevant to input, just thought I'd mention similar work elsewhere. Jonathan -- 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
