Re: Lost events in older kernels

[Dmitry Torokhov <dmitry.torokhov@gmail.com>]

On Sat, May 22, 2010 at 10:57:42PM +0200, Henrik Rydberg wrote:
> Dmitry Torokhov wrote:
> > On Sat, May 22, 2010 at 12:27:15PM +0200, Henrik Rydberg wrote:
> >> Rafi Rubin wrote:
> >>> -----BEGIN PGP SIGNED MESSAGE-----
> >>> Hash: SHA1
> >>>
> >>> On 05/22/10 03:42, Dmitry Torokhov wrote:
> >>>> On Sat, May 22, 2010 at 03:06:07AM -0400, Rafi Rubin wrote:
> >>>>> I'm playing with a project with a 2.6.29 kernel, and the userspace application
> >>>>> seems to miss some events.  Is there a particular fix that improved the handling?
> >>>>>
> >>>>> Also tried catting the dev to a file while testing, and the dump also is missing
> >>>>> some events.
> >>>>>
> >>>> No "interesting" patches went into evdev for a few release now...
> >>>>
> >>>> Hm, could it be that event queue is overflowing before userspace gets a
> >>>> chance to empty it. What kind of event rate are we talking here?
> >>>>
> >>> Quite possibly.  It is a multitouch device and we know Henrik's been concerned
> >>> with the load for a while.
> >>>
> >>> So to put some numbers behind his fears:
> >>>
> >>> 146668 hid events processed
> >>> 24952 evdev events captured with a cat
> >>> 30 seconds (give or take).
> 
> Thanks for these numbers, Rafi.
> 
> >>> This is for a mix of different numbers of fingers, but continuous use for those
> >>> 30 seconds.  And X was running and reading the dev node too.
> >> Others have experienced this too. Mika has a patch for this, increasing the
> >> (kernel) evdev buffer quite a bit, from 64 to 256. I believe the reason it is
> >> not sent upstream is because it increases the footprint by 3 Kb. Perhaps a
> >> dynamic solution could work here.
> >>
> > 
> > Yes, if input devices could hint handlers about their "packet size"
> > then evdev could size it's event queue accordingly. I'd say we need to
> > keep about 8 packets worth of data (number is pulled right out of my
> > behind ;) )...
> > 
> 
> Yeah. The bcm5974 driver sends 8 events per finger, plus some ST stuff. With
> four fingers on the pad, that amounts to roughly 40 events per packet.
> 
> 146668 / 24952 = 5.9
> 40 * 8 / 64 = 5.0
> 
> Looks reasonable, doesn't it?
> 
> Regarding the packet size hinting, the handler already knows which events are
> potentially being sent, and could produce a reasonable buffer size from it. In
> particular if it knows which events are bypassing filtering. ;-)
> 

Yes, but the driver knows for sure. Why making one guess when another
can tell?

-- 
Dmitry