Multiple clients reading from /dev/input/eventX

Multiple clients reading from /dev/input/eventX

[simon]

Hi all,
I'm trying to track down a problem with SDL missing events from a gaming
wheel. It looks like it's not seeing a 'section' of events and this
results in an axis from the wheel/joystick being stuck on.

If I simultaneously use evtest to monitor the same /dev/input/eventX I see
all the events in evtest, but not in SDL.

I suspect that some scheduling (or other business) is causing SDL not to
check the file handle, and as a result the input system is
dropping/resyncing the interface.

Can anyone here confirm the behaviour under the situation that one client
is busy? What is the maximum time it can be 'away' or what is the size of
the inline buffer?

Many thanks,
Simon.

Re: Multiple clients reading from /dev/input/eventX

[Dmitry Torokhov]

Hi SImon,

On Fri, Oct 19, 2012 at 11:49:29AM -0400, simon@mungewell.org wrote:
> Hi all,
> I'm trying to track down a problem with SDL missing events from a gaming
> wheel. It looks like it's not seeing a 'section' of events and this
> results in an axis from the wheel/joystick being stuck on.
> 
> If I simultaneously use evtest to monitor the same /dev/input/eventX I see
> all the events in evtest, but not in SDL.
> 
> I suspect that some scheduling (or other business) is causing SDL not to
> check the file handle, and as a result the input system is
> dropping/resyncing the interface.
> 
> Can anyone here confirm the behaviour under the situation that one client
> is busy? What is the maximum time it can be 'away' or what is the size of
> the inline buffer?

Every user of event device has a buffer that can hold up at least 64
input events and is completely independent from other users. Newer
kernels generate EV_SYN/SYN_DROPPED event to indicate that user was too
slow reading data and there was buffer overrun.

Hope this helps.

-- 
Dmitry

Re: Multiple clients reading from /dev/input/eventX

[simon]

[-- Attachment #1: Type: text/plain, Size: 1229 bytes --]

>> Can anyone here confirm the behaviour under the situation that one
>> client
>> is busy? What is the maximum time it can be 'away' or what is the size
>> of
>> the inline buffer?
>
> Every user of event device has a buffer that can hold up at least 64
> input events and is completely independent from other users. Newer
> kernels generate EV_SYN/SYN_DROPPED event to indicate that user was too
> slow reading data and there was buffer overrun.
>
> Hope this helps.

Yes, very helpful.... I am seeing 'SYN_DROPPED' on my system, so the next
question is how to work around this?

In the event of an overflow is there any method of reading/polling the
last (correct) event value for each of the axis?

In my case on the G27 wheel when your foot transitions from the brake to
accelerator, you get no more 'brake events' to 'refresh' the value.

I see that I could use QUIRK to enlarge the buffer for this device, would
that be an acceptable workaround?
http://www.spinics.net/lists/linux-input/msg15497.html

Attached is a little log showing SDL 'missing' 68 events, which are
correctly reported by 'evtest'. The time stamps in log will give you an
idea about how quickly the events are coming in from this wheel.

Thanks,
Simon.

[-- Attachment #2: SDL_missing_events2.txt.gz --]
[-- Type: application/x-gzip, Size: 1379 bytes --]

Re: Multiple clients reading from /dev/input/eventX

[Dmitry Torokhov]

On Wed, Oct 24, 2012 at 12:26:17AM -0400, simon@mungewell.org wrote:
> >> Can anyone here confirm the behaviour under the situation that one
> >> client
> >> is busy? What is the maximum time it can be 'away' or what is the size
> >> of
> >> the inline buffer?
> >
> > Every user of event device has a buffer that can hold up at least 64
> > input events and is completely independent from other users. Newer
> > kernels generate EV_SYN/SYN_DROPPED event to indicate that user was too
> > slow reading data and there was buffer overrun.
> >
> > Hope this helps.
> 
> Yes, very helpful.... I am seeing 'SYN_DROPPED' on my system, so the next
> question is how to work around this?
> 
> In the event of an overflow is there any method of reading/polling the
> last (correct) event value for each of the axis?

EVIOCGABS() and other ioctls allow to query state of the device.

> 
> In my case on the G27 wheel when your foot transitions from the brake to
> accelerator, you get no more 'brake events' to 'refresh' the value.
> 
> I see that I could use QUIRK to enlarge the buffer for this device, would
> that be an acceptable workaround?
> http://www.spinics.net/lists/linux-input/msg15497.html

With 3.7 Henrik just put in code that would better estimate number of
events in devices event packet, so hopefully quirk is not needed.

> 
> Attached is a little log showing SDL 'missing' 68 events, which are
> correctly reported by 'evtest'. The time stamps in log will give you an
> idea about how quickly the events are coming in from this wheel.

You need to figure out why SDL takes such a long time to get around
reading device data

Thanks.

-- 
Dmitry