On Wed, Oct 24, 2012 at 12:26:17AM -0400, simon@xxxxxxxxxxxxx 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 -- 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
