Losing events from USB barcode reader

Hello,

I have a Qt-based application which reads events from a Linux input
device through /dev/input/eventX. The device I have is an USB barcode
scanner, which works just like a keyboard.

Unfortunately, I sometimes lose events coming from this USB barcode
scanner, and I'm worried about the size of the in-kernel buffer for
events. The USB barcode scanner acts like a keyboard, but sends events
much, much faster. For example, when it scans a barcode such as
"AZERTYUIOP1234", it generates the Shift press, key press, key release,
Shift release for every character, generating at least 56 events in a
row, very quickly (and the kernel only buffers 64 events if I'm
correct).

There are even worse cases: I have an USB barcode reader which is
connected by Bluetooth with the barcode reader itself. When the barcode
reader is far away from the base station, it just buffers the scanned
barcodes, and when the barcode reader is again within the Bluetooth
range from the base station, it sends all the buffered scanned barcode
in a row. Potentially hundreds and hundreds of Linux input events
coming in.

Shouldn't the in-kernel buffer be larger for such devices, in order to
leave more time for the applications to come and fetch the events ?

As far as I could see, it doesn't seem to be possible to adjust the
size of the in-kernel buffer from userspace (through some ioctl() call,
for example). Did I miss something ?

Thanks,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Hi Thomas,

I have a Qt-based application which reads events from a Linux input
device through /dev/input/eventX. The device I have is an USB barcode
scanner, which works just like a keyboard.

Unfortunately, I sometimes lose events coming from this USB barcode
scanner, and I'm worried about the size of the in-kernel buffer for
events. The USB barcode scanner acts like a keyboard, but sends events
much, much faster. For example, when it scans a barcode such as
"AZERTYUIOP1234", it generates the Shift press, key press, key release,
Shift release for every character, generating at least 56 events in a
row, very quickly (and the kernel only buffers 64 events if I'm
correct).

With 2.6.39, it is possible to tell if events are dropped by looking
for the (EV_SYN, SYN_DROPPED) event in the stream, for instance using
evtest.

The buffer size can be set by the driver in question, which may
utilize information about the device. Is your device exactly a
keyboard, except it has a higher event rate, or are there perhaps
other ques?

There are even worse cases: I have an USB barcode reader which is
connected by Bluetooth with the barcode reader itself. When the barcode
reader is far away from the base station, it just buffers the scanned
barcodes, and when the barcode reader is again within the Bluetooth
range from the base station, it sends all the buffered scanned barcode
in a row. Potentially hundreds and hundreds of Linux input events
coming in.

Assuming we talk about a hid device, knowing the specification would help.

Shouldn't the in-kernel buffer be larger for such devices, in order to
leave more time for the applications to come and fetch the events ?

That seems reasonable, yes.

As far as I could see, it doesn't seem to be possible to adjust the
size of the in-kernel buffer from userspace (through some ioctl() call,
for example). Did I miss something ?

Adjusting internal kernel buffers from userspace seems like the wrong
level of interaction. The kernel should be able to resolve this
internally, either dynamically or using information such as production
rate and consumption rate.

Thanks,
Henrik

Hello Henrik,

Thanks for your feedback.

On Tue, 24 May 2011 11:55:56 +0200
"Henrik Rydberg" [off-list ref] wrote:

With 2.6.39, it is possible to tell if events are dropped by looking
for the (EV_SYN, SYN_DROPPED) event in the stream, for instance using
evtest.

Yes, I've seen that. Unfortunately, I can hardly recover even if I'm
notified of lost events: a barcode is scanned as a series of
characters, which ends by a newline. If some are lost in the middle,
there's no way to detect them, so I'd prefer not to loose events.

However, I'll upgrade my kernel to 2.6.39 and use the new SYN_DROPPED
feature at least to be able to log the fact that events were lost.

The buffer size can be set by the driver in question, which may
utilize information about the device. Is your device exactly a
keyboard, except it has a higher event rate, or are there perhaps
other ques?

My device acts just like a keyboard, and appears to be recognized as
such (see logs below).

quoted

There are even worse cases: I have an USB barcode reader which is
connected by Bluetooth with the barcode reader itself. When the
barcode reader is far away from the base station, it just buffers
the scanned barcodes, and when the barcode reader is again within
the Bluetooth range from the base station, it sends all the
buffered scanned barcode in a row. Potentially hundreds and
hundreds of Linux input events coming in.

Assuming we talk about a hid device, knowing the specification would
help.

What kind of specification are you interested in ?

Here is what I have in dmesg when the device is plugged in:

[31786.703736] usb 2-1.4: new full speed USB device using ehci_hcd and address 13
[31786.804559] input: Symbol Technologies, Inc, 2002 Symbol Bar Code Scanner as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4:1.0/input/input19
[31786.804699] generic-usb 0003:05E0:1200.000B: input,hidraw2: USB HID v1.10 Keyboard [Symbol Technologies, Inc, 2002 Symbol Bar Code Scanner] on usb-0000:00:1d.0-1.4/input0

Here is what I have in sysfs :

thomas@surf:/sys/class/input/input19$ ls
capabilities  device  event13  id  modalias  name  phys  power  subsystem  uevent  uniq
thomas@surf:/sys/class/input/input19$ cat phys 
usb-0000:00:1d.0-1.4/input0
thomas@surf:/sys/class/input/input19$ cat name 
ﾩSymbol Technologies, Inc, 2002 Symbol Bar Code Scanner
thomas@surf:/sys/class/input/input19$ cat uniq 
S/N:A1B8593E4C748F4C8BD5052D9E29AE11 Rev:NBRMSAAEDM:12JAN113
thomas@surf:/sys/class/input/input19$ cat capabilities/
abs  ev   ff   key  led  msc  rel  snd  sw   
thomas@surf:/sys/class/input/input19$ cat capabilities/abs 
0
thomas@surf:/sys/class/input/input19$ cat capabilities/ev 
120013
thomas@surf:/sys/class/input/input19$ cat capabilities/ff 
0
thomas@surf:/sys/class/input/input19$ cat capabilities/key 
10000 7 ff9f207a c14057ff febeffdf ffefffff ffffffff fffffffe
thomas@surf:/sys/class/input/input19$ cat capabilities/led 
1f
thomas@surf:/sys/class/input/input19$ cat capabilities/msc 
10
thomas@surf:/sys/class/input/input19$ cat capabilities/rel 
0
thomas@surf:/sys/class/input/input19$ cat capabilities/snd 
0
thomas@surf:/sys/class/input/input19$ cat capabilities/sw 
0

What other informations would be needed to better understand what the
device is ?

quoted

As far as I could see, it doesn't seem to be possible to adjust the
size of the in-kernel buffer from userspace (through some ioctl()
call, for example). Did I miss something ?

Adjusting internal kernel buffers from userspace seems like the wrong
level of interaction. The kernel should be able to resolve this
internally, either dynamically or using information such as production
rate and consumption rate.

Agreed. However, I don't know on which criteria should the kernel
decide what the size of the internal buffer should be, in this
particular case.

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.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

Hello,

On Wed, 25 May 2011 17:38:32 +0200
Thomas Petazzoni [off-list ref] wrote:

Agreed. However, I don't know on which criteria should the kernel
decide what the size of the internal buffer should be, in this
particular case.

Any idea on how to adjust the kernel internal events buffer size for
this particular device ?

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

On Fri, Jun 03, 2011 at 10:15:11AM +0200, Thomas Petazzoni wrote:

Hello,

On Wed, 25 May 2011 17:38:32 +0200
Thomas Petazzoni [off-list ref] wrote:

quoted

Agreed. However, I don't know on which criteria should the kernel
decide what the size of the internal buffer should be, in this
particular case.

Any idea on how to adjust the kernel internal events buffer size for
this particular device ?

Since v2.6.36, the device may hint the size of the buffer through
input_set_events_per_packet. Perhaps, you could use a QUIRCK or
something like that to indicate that you need a larger buffer and then
use that to set the buffer to a size like 60, which is what is used by
most other uses of this indication. To compare to the minimum default
value, this is 8 input_event's in evdev per event. That is, a hint of 60
will allocate a buffer of 480 entries, instead of 64.

Regards,
Cascardo.

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com