Synchronizing evdev readers and drivers?

Synchronizing evdev readers and drivers?

[Bill Gatliff]

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?


Thanks!


b.g.
-- 
Bill Gatliff
bgat@billgatliff.com

Re: Synchronizing evdev readers and drivers?

[Dmitry Torokhov]

On Thu, Dec 02, 2010 at 11:26:53AM -0600, 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,

We do not have such fine granularity as per-read. Input drivers get
notified when first application opens one of the interfaces (by
implementing input->open()). We expect that applications that open
input interfaces will read the data from them.

-- 
Dmitry

Re: Synchronizing evdev readers and drivers?

[Bill Gatliff]

Guys:



On Thu, Dec 2, 2010 at 3:22 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> We do not have such fine granularity as per-read. Input drivers get
> notified when first application opens one of the interfaces (by
> implementing input->open()). We expect that applications that open
> input interfaces will read the data from them.

Right, I know that applications will ultimately read from the interface.  :)

I have noticed that several Android ports (among others) call read on
/dev/input/eventX inside of a delayed loop--- as if they want to pace
the rate of incoming events themselves.  In fact, in those ports the
length of each delay is controlled by how often Android applications
a.k.a. Activities want events streamed to them.

This is a great idea in theory, especially for things like
accelerometers which can go much, much faster than an activity might
need the data.  But I just haven't seen anywhere in those
aforementioned ports where the pacing information gets conveyed over
to the kernel-side driver.  You have answered my basic question,
however: if such information gets conveyed back to a driver, it
doesn't get there through the evdev interface!

Would a patch that adds a read callback, similar to how open works
now, be well-received?  I can see it being very useful for certain
situations...


b.g.
-- 
Bill Gatliff
bgat@billgatliff.com

Re: Synchronizing evdev readers and drivers?

[Mark Brown]

On Thu, Dec 02, 2010 at 03:34:20PM -0600, Bill Gatliff wrote:

> I have noticed that several Android ports (among others) call read on
> /dev/input/eventX inside of a delayed loop--- as if they want to pace
> the rate of incoming events themselves.  In fact, in those ports the
> length of each delay is controlled by how often Android applications
> a.k.a. Activities want events streamed to them.

The sysfs interface offered by polldev is *mostly* doing the same thing
(providing user space control of the sample rate) - see "Input:
input-polldev - add sysfs interface for controlling poll interval".
Implementing the same interface for other input devices seems like a
reasonable approach to the problem?  It would mean that if the hardware
is capable of autonomously controlling the rate at which it generates
samples the application would be able to take advantage of that.

A callback on read seems like it's a bit limited as it's more work for
the application (handling the latency introduced by waking up from your
delay and doing the read is faff) and requires polling in the hardware
too.

Re: Synchronizing evdev readers and drivers?

[Bill Gatliff]

On Fri, Dec 3, 2010 at 6:42 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
>
> The sysfs interface offered by polldev is *mostly* doing the same thing

True, except that there is still no synchronization of the polling
events between the driver and application.  For example, if the
polling interval is once per second then the sample ultimately
delivered to applications could be almost one second old--- even if
the application reads from the evdev interface once a second as well.

The callback can be used to reduce the delay between sample generation
and event delivery.  It can also increase system load, but reduces
phase error in situations where that is desirable.  I don't expect
that many drivers will use the callback, but for the ones that do it
will be very useful.

> A callback on read seems like it's a bit limited as it's more work for
> the application (handling the latency introduced by waking up from your
> delay and doing the read is faff) and requires polling in the hardware
> too.

Right.  But if the hardware works that way anyway, then the
alternatives seem to boil down to either unsynchronized polling, or
samples-on-demand.  Some applications e.g. mine, really want the
latter.


b.g.
-- 
Bill Gatliff
bgat@billgatliff.com

Re: Synchronizing evdev readers and drivers?

[Mark Brown]

On Fri, Dec 03, 2010 at 07:03:12AM -0600, Bill Gatliff wrote:
> On Fri, Dec 3, 2010 at 6:42 AM, Mark Brown

> > The sysfs interface offered by polldev is *mostly* doing the same thing

> True, except that there is still no synchronization of the polling
> events between the driver and application.  For example, if the
> polling interval is once per second then the sample ultimately
> delivered to applications could be almost one second old--- even if
> the application reads from the evdev interface once a second as well.

Surely that's what poll() and whatnot are for?  If userspace has to poll
at all that seems to be a failure in itself.

Re: Synchronizing evdev readers and drivers?

[Bill Gatliff]

Mark:


On Fri, Dec 3, 2010 at 7:53 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
>
> Surely that's what poll() and whatnot are for?  If userspace has to poll
> at all that seems to be a failure in itself.

The poll() and blocking read() system calls allow an application to
tell an input device that it is prepared to receive an event, and for
an input device driver to tell userspace when an event has occurred.
As implemented in evdev, however, neither system call provides a
natural, consistent way for userspace to tell an input device driver
how often it wants data--- or even if it wants any (at the moment) at
all.

I think that you and I talking about two different scenarios.  You
seem to be focused on the one where userspace is informed when an
input event occurs, but has no ability to request or schedule those
events.  That model makes perfect sense for USB mice and keyboards
where the hardware itself is inherently event-driven.  For those kinds
of devices, users don't know or care when a key will be pressed---
they just need to respond when one is.  So they simply block in a
poll() or read() until a keypress shows up.  Problem solved.

I'm looking at input devices like accelerometers and compasses, which
must be explicitly sampled and can send events at upwards of 4K/sec if
you ask them to.  The vast majority of user applications don't need
data anywhere near that fast, but the range of desirable rates can't
be met by a simple "just sample it at 100 Hz" kernel thread because of
power consumption and phase error issues.  On a cell phone, for
example, some situations call for accelerometer data at 2 Hz while
other modes want the data at 200 Hz with minimal latency.  The current
architecture requires me to implement that range using a dedicated
kernel thread, plus a sysfs attribute/ioctl to dial the rate up or
down from userspace.

For something like a pushbutton, sometimes you simply don't care about
the state of the button except when you are asking for it--- and then
you don't want a sample that might be a few seconds old.  In other
situations, doing a poll() and getting blocked until the pushbutton
changes state works better.  Pushbuttons are therefore kind of a
corner case where the approach you choose depends more on what you
want the application to look like.  (Especially pushbuttons that
aren't connected to interrupt-capable inputs).

I don't want to do an ad-hoc method for communicating a polling rate
request to the hardware for each hardware driver that I have to deal
with.  One way to avoid this is to add a standard sysfs attribute or
ioctl for all input devices, which applications use to specify the
rate that they want the hardware to sample at--- if the hardware works
that way.  That's fine, except that it adds an extra step that
applications have to deal with.  It also forces you to pick an
arbitrary, default sampling rate if the application fails to specify
one.

The other option, which is the one I'm proposing and which seems more
natural for end users, is to add an optional read callback in the
input_dev structure that, if implemented by the driver, will call the
driver back whenever someone is asking for the state of the input
device.  Drivers can then choose to initiate a sampling operation only
when a user is asking for the data.  Users just call poll() or read()
at the rate they want the sampling to occur, and never get blocked for
longer than it takes to acquire a sample.

The advantage to the read callback approach is that users like Android
can completely eliminate all of the kernel threads, etc. that drivers
currently use to make high-rate hardware like accelerometers behave
more like keyboards and mice.  And this does more than simplify a
bunch of code: it also creates a natural place for powering up/down
the hardware between individual samples rather than just when the
interface is opened and closed.  It also automagically throttles up or
down the sampling request rate as necessary to precisely match the
user's demands.

Finally, with the read callback approach there isn't any behavioral
change in the evdev interface at all for existing drivers (and
existing drivers will continue to work as they do now).  When drivers
start implementing the read callback, users will just notice that
their drivers are simpler and their data is more recent--- if they
care to investigate either of those.

What I'm proposing is something that is very similar to input-polldev,
except that users don't even have to specify the polling rate: they
just call read() or poll() at the rate they want the input device
hardware to scan/sample itself.  Some current users of input-polldev
might be better served by a read callback, in fact.

The read callback approach is completely wrong for USB-ish keyboards
and mice, so those drivers won't implement a read callback.  But for
accelerometers, pushbuttons and such, a read callback seems like a
very useful tool.  I hope to have first-hand evidence of that later
today, preferably in a way that will be useful to the broader
community as well.  :)



b.g.
-- 
Bill Gatliff
bgat@billgatliff.com
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Synchronizing evdev readers and drivers?

[Mark Brown]

On Fri, Dec 03, 2010 at 11:36:50AM -0600, Bill Gatliff wrote:

I guess my main thing here is that I don't see why we'd want to present
applications with an interface which means we can't make use of hardware
scheduling facilities where they exist.  The other thing is that this
feels like a workaround for applications that are already doing
application layer scheduling rather than anything else and that feels
more like a workaround for a lack of control provided by the kernel than
anything else.

> The poll() and blocking read() system calls allow an application to
> tell an input device that it is prepared to receive an event, and for
> an input device driver to tell userspace when an event has occurred.
> As implemented in evdev, however, neither system call provides a
> natural, consistent way for userspace to tell an input device driver
> how often it wants data--- or even if it wants any (at the moment) at
> all.

This is what I'm saying the sysfs interface polldev provides (or a
similar interface done via ioctl() or whatever) should do.

> I think that you and I talking about two different scenarios.  You
> seem to be focused on the one where userspace is informed when an
> input event occurs, but has no ability to request or schedule those

No, not at all.  What I'm saying is that userspace should be able to
express to the kernel that it wants events delivering at a given rate
and the kernel should then attempt to deliver events at that rate.

> events.  That model makes perfect sense for USB mice and keyboards
> where the hardware itself is inherently event-driven.  For those kinds
> of devices, users don't know or care when a key will be pressed---
> they just need to respond when one is.  So they simply block in a
> poll() or read() until a keypress shows up.  Problem solved.

This is also true for things like touchscreens which work by
continuously delivering samples (ideally only while there is a touch) at
intervals which currently can't be configured in the application layer -
they're also polling, and they may not even be doing so in hardware.

> I'm looking at input devices like accelerometers and compasses, which
> must be explicitly sampled and can send events at upwards of 4K/sec if
> you ask them to.  The vast majority of user applications don't need

Right, and what I'm saying is that userspace should just say what rate
it wants and then get that.

> data anywhere near that fast, but the range of desirable rates can't
> be met by a simple "just sample it at 100 Hz" kernel thread because of
> other modes want the data at 200 Hz with minimal latency.  The current

Resolving the rate needs of multiple simultaneous users sounds like a
tractable bit of programming which we'd only ever need to do once in the
input layer, surely?

> architecture requires me to implement that range using a dedicated
> kernel thread, plus a sysfs attribute/ioctl to dial the rate up or
> down from userspace.

No need for the kernel thread - timers should do the trick - but other
than that I see no problem with this at all, other than the fact that we
probably want to implement a standard API for setting the rate which can
be used across devices.  Worst case a fully software implementation is
pretty much equivalent to what you want to do but is very simple to use
in the application layer.  Best case the hardware is able to clock out
the samples by itself and we get to skip the bit where software
initiates the transfer which saves us work and is especially nice at
higher data rates.

For a devices like touchscreens driving the reads from the application
would typically be a 50-100% overhead on the I/O costs and involves
blocking the application while the conversion happens, neither of which
seems desirable.

> I don't want to do an ad-hoc method for communicating a polling rate
> request to the hardware for each hardware driver that I have to deal
> with.  One way to avoid this is to add a standard sysfs attribute or

I wasn't suggesting that at all.  Like you say, define a standard one
and/or use the interface we already have in polldev which looks general
enough for a lot of cases though it's pretty much root only.

> The other option, which is the one I'm proposing and which seems more
> natural for end users, is to add an optional read callback in the
> input_dev structure that, if implemented by the driver, will call the
> driver back whenever someone is asking for the state of the input
> device.  Drivers can then choose to initiate a sampling operation only
> when a user is asking for the data.  Users just call poll() or read()
> at the rate they want the sampling to occur, and never get blocked for
> longer than it takes to acquire a sample.

This seems painful for applications, it means they need to deal with
their own data scheduling and means we have to take the hit of
explicitly polling the device even when it is capable of pushing the
data at us.  If we triggered the callback on poll() they'd also have
issues blocking on other file descriptors simultaneously.

> Finally, with the read callback approach there isn't any behavioral
> change in the evdev interface at all for existing drivers (and
> existing drivers will continue to work as they do now).  When drivers
> start implementing the read callback, users will just notice that
> their drivers are simpler and their data is more recent--- if they
> care to investigate either of those.

Assuming the applications are behaving as you describe and not blocking
waiting for data - I'd expect that if they block waiting for data they'd
also end up seeing data delievered much faster.

I don't see any meaningful difference in the timeliness of data
delivery with the two approaches - no matter who's clocking the poll the
application will get the data at pretty much the same time after the
sample, the difference would be for applications that current schedule
their own reads.  For drivers that don't or can't have the hardware push
samples out I'd expect librification would mean that there'd be little
impact on driver code, obviously if the hardware was helping the
complexity would depend on how helpful the hardware is.

> What I'm proposing is something that is very similar to input-polldev,
> except that users don't even have to specify the polling rate: they
> just call read() or poll() at the rate they want the input device
> hardware to scan/sample itself.  Some current users of input-polldev
> might be better served by a read callback, in fact.

Perhaps I'm missing something here but my experience has always been
that having to worry about time periods adds rather than removes
complexity in applications; the raw POSIX APIs aren't especially
convenient here.  Obviously higher level libraries will often provide
timer facilities which make these useful (I've written such things
myself) but it's still going to be more work for the system than if the
hardware can push data out for us.

> The read callback approach is completely wrong for USB-ish keyboards
> and mice, so those drivers won't implement a read callback.  But for
> accelerometers, pushbuttons and such, a read callback seems like a
> very useful tool.  I hope to have first-hand evidence of that later
> today, preferably in a way that will be useful to the broader
> community as well.  :)

Pushbuttons seem like they'd want to be event driven, surely?

Re: Synchronizing evdev readers and drivers?

[Dmitry Torokhov]

On Thu, Dec 02, 2010 at 03:34:20PM -0600, Bill Gatliff wrote:
> Guys:
> 
> 
> 
> On Thu, Dec 2, 2010 at 3:22 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > We do not have such fine granularity as per-read. Input drivers get
> > notified when first application opens one of the interfaces (by
> > implementing input->open()). We expect that applications that open
> > input interfaces will read the data from them.
> 
> Right, I know that applications will ultimately read from the interface.  :)
> 
> I have noticed that several Android ports (among others) call read on
> /dev/input/eventX inside of a delayed loop--- as if they want to pace
> the rate of incoming events themselves.  In fact, in those ports the
> length of each delay is controlled by how often Android applications
> a.k.a. Activities want events streamed to them.
> 
> This is a great idea in theory, especially for things like
> accelerometers which can go much, much faster than an activity might
> need the data.  But I just haven't seen anywhere in those
> aforementioned ports where the pacing information gets conveyed over
> to the kernel-side driver.  You have answered my basic question,
> however: if such information gets conveyed back to a driver, it
> doesn't get there through the evdev interface!
> 
> Would a patch that adds a read callback, similar to how open works
> now, be well-received?  I can see it being very useful for certain
> situations...
> 

How would the driver know if application that is opened the device
does not want to be aware of the events that happened before read as
opposed to the application that simply choses to "batch" events and
process them at once? The driver might not be able to retrieve the "old"
state of the hardware. Lets say toggle WIFI button was pressed and
released while application wasn't reading. Normally kernel would queue
the events and when userspace read the FD they'd see events, whereas in
your case events would be lost.

I'd say applications that really want this behavior simply need to
go through open/read/close cycles.

-- 
Dmitry

Re: Synchronizing evdev readers and drivers?

[Bill Gatliff]

Mark:

On Fri, Dec 3, 2010 at 12:52 PM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> On Fri, Dec 03, 2010 at 11:36:50AM -0600, Bill Gatliff wrote:
>
> I guess my main thing here is that I don't see why we'd want to present
> applications with an interface which means we can't make use of hardware
> scheduling facilities where they exist.

We'll still have the option to use those facilities, by merely not
using the read() callback.  The callback option just provides a much
cleaner way to move the problem out to userspace for situations where
that makes more sense.

It isn't a hypothetical situation: as far as I can tell right now,
most Android ports are already pacing their input device sampling in
userspace already.  That in itself doesn't justify implementing the
read callback, but it does suggest that there are situations (ok, at
least one) where users can truly benefit from that control.

I'll also note that even though Android *thinks* it is pacing the
reads, in many of the ports I have looked at it actually isn't--- or
it isn't pacing them strictly by pacing its own read() calls.

>  The other thing is that this
> feels like a workaround for applications that are already doing
> application layer scheduling rather than anything else and that feels
> more like a workaround for a lack of control provided by the kernel than
> anything else.

Yes.  And the read callback seems a very clean way to implement that control.

> This is what I'm saying the sysfs interface polldev provides (or a
> similar interface done via ioctl() or whatever) should do.

True, except in this specific situation we can get the behavior we
want without adding interfaces.  (It probably still makes sense to
standardize a sysfs/ioctl API anyway, for situations where
applications don't want to do the pacing themselves).

> No, not at all.  What I'm saying is that userspace should be able to
> express to the kernel that it wants events delivering at a given rate
> and the kernel should then attempt to deliver events at that rate.

Right.  And I'm saying that the other way to do that is for
applications to just ask for the data at whatever rate they want, and
we give the data to them at that rate.

> This is also true for things like touchscreens which work by
> continuously delivering samples (ideally only while there is a touch) at
> intervals which currently can't be configured in the application layer -
> they're also polling, and they may not even be doing so in hardware.

True.  The tsc2003 and similar resistive touch "controllers" come to
mind.  They are really just two ADCs that you can read as fast--- or
as slow--- as you want.

> Right, and what I'm saying is that userspace should just say what rate
> it wants and then get that.

We're mostly in violent agreement here.  :)  We just differ in how the
application communicates the desired rate to the interface.  I'm not
sure that the two approaches are mutually-exclusive.

> Resolving the rate needs of multiple simultaneous users sounds like a
> tractable bit of programming which we'd only ever need to do once in the
> input layer, surely?

Heck if I know.  :)  I hadn't though much about this problem until a
few days ago.  I certainly can't claim to understand the entire scope
of it just yet...

> For a devices like touchscreens driving the reads from the application
> would typically be a 50-100% overhead on the I/O costs and involves
> blocking the application while the conversion happens, neither of which
> seems desirable.

So a touch controller driver probably isn't going to bother with the
read callback.

> This seems painful for applications, it means they need to deal with
> their own data scheduling and means we have to take the hit of
> explicitly polling the device even when it is capable of pushing the
> data at us.  If we triggered the callback on poll() they'd also have
> issues blocking on other file descriptors simultaneously.

Yea, I'm not sure that hitting the callback in poll() is appropriate.
Still noodling on that one.

> Assuming the applications are behaving as you describe and not blocking
> waiting for data - I'd expect that if they block waiting for data they'd
> also end up seeing data delievered much faster.

Even in my read callback implementation, the application still always
gets blocked until a sample shows up in the event FIFO.  The read
callback just gives a driver a chance to know when the application is
desiring another sample.

> I don't see any meaningful difference in the timeliness of data
> delivery with the two approaches - no matter who's clocking the poll the
> application will get the data at pretty much the same time after the
> sample, the difference would be for applications that current schedule
> their own reads.

If the driver is doing periodic sampling, without consideration for
whether an application is actually reading the interface, it will fill
the event FIFO with data that the application doesn't pick up until
later.  Depending on the sampling rate, that can amount to a very
large delay (relatively speaking) between when the sample is taken by
the hardware and when it's delivered to applications.

> Perhaps I'm missing something here but my experience has always been
> that having to worry about time periods adds rather than removes
> complexity in applications

True.  But in this case, the code on the application side is already
there: a pthread running a while(1) loop with an msleep.  Ugly to
some, but it works.

> Pushbuttons seem like they'd want to be event driven, surely?

In many cases, yes.  I mentioned them mostly because they are easier
to discuss/type than accelerometers and such.  :)


b.g.
-- 
Bill Gatliff
bgat@billgatliff.com
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Synchronizing evdev readers and drivers?

[Bill Gatliff]

Dmitry:

On Fri, Dec 3, 2010 at 1:32 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> How would the driver know if application that is opened the device
> does not want to be aware of the events that happened before read as
> opposed to the application that simply choses to "batch" events and
> process them at once? The driver might not be able to retrieve the "old"
> state of the hardware. Lets say toggle WIFI button was pressed and
> released while application wasn't reading. Normally kernel would queue
> the events and when userspace read the FD they'd see events, whereas in
> your case events would be lost.

Good question.

What I'm proposing is really useful only for embedded work, where you
have absolute control (or at least understanding) over what the
hardware and driver stack looks like.  If one wanted to see all the
transitions of the WiFi button (to use your example), they'd bind the
hardware to a driver that worked that way.  The system integrator
would make the choice, not the application.

In situations where an application wanted the accumulating behavior
sometimes, and the stateless behavior at other times, then the system
integrator could provide for that by using two different event
interfaces, one for each personality.  I think...

> I'd say applications that really want this behavior simply need to
> go through open/read/close cycles.

Wow, that seems really, really expensive at a sampling rate of 100+Hz.


b.g.
-- 
Bill Gatliff
bgat@billgatliff.com

Re: Synchronizing evdev readers and drivers?

[Dmitry Torokhov]

On Fri, Dec 03, 2010 at 11:36:50AM -0600, Bill Gatliff wrote:
> Mark:
> 
> 
> On Fri, Dec 3, 2010 at 7:53 AM, Mark Brown
> <broonie@opensource.wolfsonmicro.com> wrote:
> >
> > Surely that's what poll() and whatnot are for?  If userspace has to poll
> > at all that seems to be a failure in itself.
> 
> The poll() and blocking read() system calls allow an application to
> tell an input device that it is prepared to receive an event, and for
> an input device driver to tell userspace when an event has occurred.
> As implemented in evdev, however, neither system call provides a
> natural, consistent way for userspace to tell an input device driver
> how often it wants data--- or even if it wants any (at the moment) at
> all.

Right. The indication that application wants the data is open() call. If
userspace does not want data, it should close() the interface.

Drivers have no idea what users want to do with the data so they can't
decide whether to ignore the hardware or query it and queue events up.
Some applications might be interested in "sample on demand", while
others would prefer events to be queued and consumed at once.

[... cut long argument for an inconsistent and incompatible change to
the interface ...]

BTW, if application reads (supplies space for) just one event should we
disacard the rest of hardware state that we read from the device? You
know, just asking...

-- 
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Synchronizing evdev readers and drivers?

[Bill Gatliff]

Dmitry:


On Fri, Dec 3, 2010 at 1:50 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> Right. The indication that application wants the data is open() call. If
> userspace does not want data, it should close() the interface.

It *does* want the data, just at a specified rate.  And right now, we
have no consistent way of having applications express that rate to the
input device.  A read callback is one, very flexible way of correcting
that.

> Drivers have no idea what users want to do with the data so they can't
> decide whether to ignore the hardware or query it and queue events up.
> Some applications might be interested in "sample on demand", while
> others would prefer events to be queued and consumed at once.

Yep.  We've already covered that.

> [... cut long argument for an inconsistent and incompatible change to
> the interface ...]

I object.

My proposed change is carefully considered to be neither inconsistent
nor incompatible with the current interface.  Existing drivers will
continue to work exactly as they do now.  Future drivers that don't
utilize the read callback will work exactly as conventional drivers do
now.

Certain hardware drivers will want to take advantage of the read
callback, and those drivers will perform differently in ways that some
applications won't care about, and others won't even notice.  And
those drivers will perform usefully for applications that *do* care
about the differences.

I predicted (and welcomed) a lot of constructive challenges to making
a change to such a widely used API.  But your outright hostility isn't
a productive use of anyone's time.

> BTW, if application reads (supplies space for) just one event should we
> disacard the rest of hardware state that we read from the device? You
> know, just asking...

Ridiculously hypothetical, distracting and unrelated question, but
I'll answer it anyway.  If the application wants more than one event,
it had better make room for them.  As for the events that remain in
the queue, if any: that depends on how the driver works.  Just like it
does today.


b.g.
-- 
Bill Gatliff
bgat@billgatliff.com

Re: Synchronizing evdev readers and drivers?

[Dmitry Torokhov]

On Fri, Dec 03, 2010 at 01:50:08PM -0600, Bill Gatliff wrote:
> Dmitry:
> 
> On Fri, Dec 3, 2010 at 1:32 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > How would the driver know if application that is opened the device
> > does not want to be aware of the events that happened before read as
> > opposed to the application that simply choses to "batch" events and
> > process them at once? The driver might not be able to retrieve the "old"
> > state of the hardware. Lets say toggle WIFI button was pressed and
> > released while application wasn't reading. Normally kernel would queue
> > the events and when userspace read the FD they'd see events, whereas in
> > your case events would be lost.
> 
> Good question.
> 
> What I'm proposing is really useful only for embedded work, where you
> have absolute control (or at least understanding) over what the
> hardware and driver stack looks like.  If one wanted to see all the
> transitions of the WiFi button (to use your example), they'd bind the
> hardware to a driver that worked that way.  The system integrator
> would make the choice, not the application.

Signficant number of drivers work in different environments as do
the applications. System integrator can not make this choice since _his_
choice might be different from another system integrator's choice.

> 
> In situations where an application wanted the accumulating behavior
> sometimes, and the stateless behavior at other times, then the system
> integrator could provide for that by using two different event
> interfaces, one for each personality.  I think...

Having a diffrent interface for certain class of devices is an option.
Accelerometers, magnetometers and other not pure HID devices might make
use of IIO and/or sysfs. In fact, most of accelerometer drivers attempt
to provide their own sysfs interfaces and among them ways to fetch
current device state. This kind of interface seems to suit your needs
best.

Note that standardizing sysfs accelerometer inteface is under
discussion and if you are interested you shoudl join it.

> 
> > I'd say applications that really want this behavior simply need to
> > go through open/read/close cycles.
> 
> Wow, that seems really, really expensive at a sampling rate of 100+Hz.

First of all - not really (this how much open is similar to your
callback anyway) and second - if it gets expensive you stop doing this.

-- 
Dmitry

Re: Synchronizing evdev readers and drivers?

[Dmitry Torokhov]

On Fri, Dec 03, 2010 at 02:17:36PM -0600, Bill Gatliff wrote:
> Dmitry:
> 
> 
> On Fri, Dec 3, 2010 at 1:50 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > Right. The indication that application wants the data is open() call. If
> > userspace does not want data, it should close() the interface.
> 
> It *does* want the data, just at a specified rate.  And right now, we
> have no consistent way of having applications express that rate to the
> input device.  A read callback is one, very flexible way of correcting
> that.

No it is not. Please re-read the paragraph below for the reasons why
read, as it was proposed, does not correct this.

> 
> > Drivers have no idea what users want to do with the data so they can't
> > decide whether to ignore the hardware or query it and queue events up.
> > Some applications might be interested in "sample on demand", while
> > others would prefer events to be queued and consumed at once.
> 
> Yep.  We've already covered that.
> 
> > [... cut long argument for an inconsistent and incompatible change to
> > the interface ...]
> 
> I object.
> 
> My proposed change is carefully considered to be neither inconsistent
> nor incompatible with the current interface.  Existing drivers will
> continue to work exactly as they do now.  Future drivers that don't
> utilize the read callback will work exactly as conventional drivers do
> now.
> 
> Certain hardware drivers will want to take advantage of the read
> callback, and those drivers will perform differently in ways that some
> applications won't care about, and others won't even notice.  And
> those drivers will perform usefully for applications that *do* care
> about the differences.

What about applications which will observe the change in behavior and it
will stop them from working?

You are arguing for interface which behavior changes from driver to
driver, from one version of driver to another. I do not believe you will
find many supporters for it.

> 
> I predicted (and welcomed) a lot of constructive challenges to making
> a change to such a widely used API.  But your outright hostility isn't
> a productive use of anyone's time.

It is not hostility. I simply state the fact - the proposed interface
change is inconsistent (behavior varies from driver to driver) and
incompatible (the same application get different behavior from drivers
which utilize the callback in the way you suggest).

> 
> > BTW, if application reads (supplies space for) just one event should we
> > disacard the rest of hardware state that we read from the device? You
> > know, just asking...
> 
> Ridiculously hypothetical, distracting and unrelated question, but
> I'll answer it anyway.  If the application wants more than one event,
> it had better make room for them.

For how many? Lets say we have ABS_X, ABS_Y, ABS_Z. We post a read for 4
events (including EV_SYN), driver starts poll as you want it to and
userspace gets all 3. Then we post another read for 4, driver reads HW
state and this time Y stays the same so only 3 events (ABS_X, ABS_Z and
EV_SYN). So what to do with the 4th slot? Should it start another poll
so we could deliver another ABS_X and then what to do with the rest of
the state. Or maybe you say that we need to reset the whole internal
device state on every "read"? But what about other users reading from
the same device? And it gets close and closer to already existing
solution - open/close - anyway.

>  As for the events that remain in
> the queue, if any: that depends on how the driver works.  Just like it
> does today.

Today it does not depend on how the driver works. All events generated
stay in the client queue unless it is so slow that it overfills.

-- 
Dmitry

Re: Synchronizing evdev readers and drivers?

[Mark Brown]

On Fri, Dec 03, 2010 at 01:41:37PM -0600, Bill Gatliff wrote:
> On Fri, Dec 3, 2010 at 12:52 PM, Mark Brown

I'm only going to reply to a couple of specific things that weren't
covered in what Dimitry said here:

> It isn't a hypothetical situation: as far as I can tell right now,
> most Android ports are already pacing their input device sampling in
> userspace already.  That in itself doesn't justify implementing the
> read callback, but it does suggest that there are situations (ok, at
> least one) where users can truly benefit from that control.

When looking at Android phones it's important to remember how these
things are typically made: Android devices are put together by teams
that frequently have little prior Linux experience, and are often
produced under great time pressure.  They're a great source of data
about problems people are experiencing but you do have to really look
to make sure you're addressing the root problem.

For example, in this case I would imagine that the thought process of
people implementing the code you're looking at is something like "The
data is coming in too quickly.  How can I slow it down?  Oh, I can't.
Well, I'll just slow down my reading and worry about it later if that
turns out to be a problem.".  It's most likely to be the lack of any
current way to manage the data flow that is the underlying problem here,
the implementations are just a convenient way for applications to bodge
around the problem with the limited tools available to them.

> > Right, and what I'm saying is that userspace should just say what rate
> > it wants and then get that.

> We're mostly in violent agreement here.  :)  We just differ in how the
> application communicates the desired rate to the interface.  I'm not
> sure that the two approaches are mutually-exclusive.

I think they are; as Dimitry said in much more detail than me your
approach alters the blocking behaviour of the API for drivers using it
in a way that breaks expected behviour.

> > For a devices like touchscreens driving the reads from the application
> > would typically be a 50-100% overhead on the I/O costs and involves
> > blocking the application while the conversion happens, neither of which
> > seems desirable.

> So a touch controller driver probably isn't going to bother with the
> read callback.

On the other hand a touch controller really can use rate control - the
data rate required for handwriting recognition of Asian languages is
much greater than that required for pushing buttons.

> > Assuming the applications are behaving as you describe and not blocking
> > waiting for data - I'd expect that if they block waiting for data they'd
> > also end up seeing data delievered much faster.

> Even in my read callback implementation, the application still always
> gets blocked until a sample shows up in the event FIFO.  The read
> callback just gives a driver a chance to know when the application is
> desiring another sample.

Consider an application written like evtest: it sits and blocks waiting
for data by calling read() (realistically in a thread).  With the
current model drivers that can generate a continuous data stream will
rate limit it to something tasteful.  If read() is a trigger for
generating a new sample then the application will instead cause data to
be generated as fast as the hardware is capable of doing so.  This is
before you get to the issues with buffer sizes that Dimitry mentioned.

Consider also what happens when an application that blocks waiting for
data gets woken up and does a read().

> > Perhaps I'm missing something here but my experience has always been
> > that having to worry about time periods adds rather than removes
> > complexity in applications

> True.  But in this case, the code on the application side is already
> there: a pthread running a while(1) loop with an msleep.  Ugly to
> some, but it works.

As someone working in embedded systems I'm sure you're aware of the
unfortunate space between "makes the system behave" and "good design
idea" - the ugly to some bit's a really issue here.

Re: Synchronizing evdev readers and drivers?

[Dmitry Torokhov]

On Fri, Dec 03, 2010 at 10:27:45PM +0000, Mark Brown wrote:
> On Fri, Dec 03, 2010 at 01:41:37PM -0600, Bill Gatliff wrote:
> > On Fri, Dec 3, 2010 at 12:52 PM, Mark Brown
> 
> I'm only going to reply to a couple of specific things that weren't
> covered in what Dimitry said here:
> 
> > It isn't a hypothetical situation: as far as I can tell right now,
> > most Android ports are already pacing their input device sampling in
> > userspace already.  That in itself doesn't justify implementing the
> > read callback, but it does suggest that there are situations (ok, at
> > least one) where users can truly benefit from that control.
> 
> When looking at Android phones it's important to remember how these
> things are typically made: Android devices are put together by teams
> that frequently have little prior Linux experience, and are often
> produced under great time pressure.  They're a great source of data
> about problems people are experiencing but you do have to really look
> to make sure you're addressing the root problem.
> 
> For example, in this case I would imagine that the thought process of
> people implementing the code you're looking at is something like "The
> data is coming in too quickly.  How can I slow it down?  Oh, I can't.
> Well, I'll just slow down my reading and worry about it later if that
> turns out to be a problem.".  It's most likely to be the lack of any
> current way to manage the data flow that is the underlying problem here,
> the implementations are just a convenient way for applications to bodge
> around the problem with the limited tools available to them.

Another possibility for an app design like this could have nothing to do
with hardware rate limiting:

We have N inputs that we want to get events from but the latency is not
that important. We do not want to lose events but we can afford to
postpone their processing. We know that on average, we are getting data
from input every X. Therefore, instead of being woken up as soon as we
get an event on any of the inputs, potentially several times per X
interval, schedule nonblocking reads every X and process all accumulated
events from all inputs at once.

-- 
Dmitry

Re: Synchronizing evdev readers and drivers?

[Jonathan Cameron]

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

Re: Synchronizing evdev readers and drivers?

[Jonathan Cameron]

On 12/03/10 20:56, Dmitry Torokhov wrote:
> On Fri, Dec 03, 2010 at 01:50:08PM -0600, Bill Gatliff wrote:
>> Dmitry:
>>
>> On Fri, Dec 3, 2010 at 1:32 PM, Dmitry Torokhov
>> <dmitry.torokhov@gmail.com> wrote:
>>> How would the driver know if application that is opened the device
>>> does not want to be aware of the events that happened before read as
>>> opposed to the application that simply choses to "batch" events and
>>> process them at once? The driver might not be able to retrieve the "old"
>>> state of the hardware. Lets say toggle WIFI button was pressed and
>>> released while application wasn't reading. Normally kernel would queue
>>> the events and when userspace read the FD they'd see events, whereas in
>>> your case events would be lost.
>>
>> Good question.
>>
>> What I'm proposing is really useful only for embedded work, where you
>> have absolute control (or at least understanding) over what the
>> hardware and driver stack looks like.  If one wanted to see all the
>> transitions of the WiFi button (to use your example), they'd bind the
>> hardware to a driver that worked that way.  The system integrator
>> would make the choice, not the application.
> 
> Signficant number of drivers work in different environments as do
> the applications. System integrator can not make this choice since _his_
> choice might be different from another system integrator's choice.
> 
>>
>> In situations where an application wanted the accumulating behavior
>> sometimes, and the stateless behavior at other times, then the system
>> integrator could provide for that by using two different event
>> interfaces, one for each personality.  I think...
> 
> Having a diffrent interface for certain class of devices is an option.
> Accelerometers, magnetometers and other not pure HID devices might make
> use of IIO and/or sysfs. In fact, most of accelerometer drivers attempt
> to provide their own sysfs interfaces and among them ways to fetch
> current device state. This kind of interface seems to suit your needs
> best.
> 
> Note that standardizing sysfs accelerometer inteface is under
> discussion and if you are interested you shoudl join it.
hmm. that discussion kind of died out as it got down to just Hemanth and I.
Guess we might want to restart it, particularly with new drivers from ST
etc having been posted...

I'm going to get increasingly fussy about changing the interfaces in IIO
as we are gaining at lot of drivers conforming to pretty much my last proposal.
For a little while I'll still be open to changes though so better now than
later.  Take into account that our requirements cover a much larger set of
devices than typically turn up in the discussions.  If you want to know
where we currently are, it's reasonably documented in drivers/staging/iio/Documentation
in linux-next or:

http://git.kernel.org/?p=linux/kernel/git/gregkh/staging-2.6.git;a=shortlog;h=refs/heads/staging-next

> 
>>
>>> I'd say applications that really want this behavior simply need to
>>> go through open/read/close cycles.
>>
>> Wow, that seems really, really expensive at a sampling rate of 100+Hz.
> 
> First of all - not really (this how much open is similar to your
> callback anyway) and second - if it gets expensive you stop doing this.
> 

Re: Synchronizing evdev readers and drivers?

[Bill Gatliff]

Guys:


I really think you are blowing the significance of my as-yet-unwritten
patch totally out of proportion.

I didn't get to it yesterday due to schedule conflicts.  I expect to
have it done sometime next week.  Then I'll just post the thing, and
we can stir these coals up again--- but with something more tangible
to discuss.


b.g.
-- 
Bill Gatliff
bgat@billgatliff.com