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