Hello Henrik, Thanks for your feedback. On Tue, 24 May 2011 11:55:56 +0200 "Henrik Rydberg" <rydberg@xxxxxxxxxxx> 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). > > 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 ? > > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
