0

Barcode scanners behaves like a usb keyboard device and my case was no different at the beginning. I opened a nano screen, plugged the scanner through usb port, read a barcode and saw the string what is written right under the barcode.

I don't know how, but right now it doesn't work that way. The scanner (the keyboard-like device) sends some garbage to the system.

I wrote a simple NodeJS code that dumps what is captured:

data:  <Buffer 04 00 62 60 5b 00 00 00> string:  b`[
data:  <Buffer 00 00 00 00 00 00 00 00> string:  
data:  <Buffer 04 00 62 5f 5b 00 00 00> string:  b_[
data:  <Buffer 00 00 00 00 00 00 00 00> string:  
data:  <Buffer 04 00 62 60 62 00 00 00> string:  b`b
data:  <Buffer 00 00 00 00 00 00 00 00> string:  
data:  <Buffer 04 00 62 5c 5d 00 00 00> string:  b\]
data:  <Buffer 00 00 00 00 00 00 00 00> string:  
data:  <Buffer 04 00 62 5d 5a 00 00 00> string:  b]Z
data:  <Buffer 00 00 00 00 00 00 00 00> string:  
data:  <Buffer 04 00 62 5c 5d 00 00 00> string:  b\]
data:  <Buffer 00 00 00 00 00 00 00 00> string:  
data:  <Buffer 04 00 62 5c 61 00 00 00> string:  b\a
data:  <Buffer 00 00 00 00 00 00 00 00> string:  
data:  <Buffer 00 00 28 00 00 00 00 00> string:  (
data:  <Buffer 00 00 00 00 00 00 00 00> string:  

I was expecting a string, like SIP-4-1. (Here is the showkey output of the same barcode)

Same scanner works correctly on Windows. I guess it's related with a keyboard mode or something. How can I change the mode for a specific USB keyboard device?

5

Your scanner is not sending garbage. Those are perfectly conventional input reports for a conventional USB HID keyboard device with the conventional 8-byte "boot" report descriptor.

Decoding them, it can be seen that your scanner is not sending the keys for "S", "I", and so forth directly. Rather, it is simulating entering them with the ⎇ Alt key. It is making several rather poor assumptions about the operating system in doing so, any or all of which could easily be faulty.

For example:

  • The input report
    04 00 62 60 5b 00 00 00
    is the keys with the USB HID usage codes E2, 62, 60, and 5B all pressed simultaneously.
  • E2, 62, 60, and 5B are the USB HID usage codes for ⎇ Left Alt, Ins/0, ↑/8, and PgDn/3.
  • 08310 is the code for "S".
  • The input report
    00 00 00 00 00 00 00 00
    indicates that all of those keys have been released.

The rest does indeed decode to "I", "P", "-", "4", "-", and "1" all typed in this way as ⎇ Alt plus three decimal numbers. (The final two input reports are press and release of ⮠ Return.)

You can see the several broken assumptions here.

  • The scanner is assuming that the keyboard driver parses the input report in a particular direction. This is not guaranteed, and the scanner should properly be generating individual reports for Ins/0, ↑/8, and PgDn/3 being pressed and released in turn with the modifier key held down throughout. It is relying upon an accident of implementation, and what the scanner is actually sending is all four keys being pressed and released simultaneously.
  • The scanner is assuming that ⎇ Left Alt is the key to use for this. But in some operating systems and keyboard layouts it might be ⇮ Alt Gr/⎇ Right Alt instead, which is E6 (encoded as 40 in the first byte of the input report) not E2.

    Indeed, your current operating system, keyboard driver, and keyboard layout might not even support entering characters using codes like this at all. (FreeBSD's syscons kernel terminal emulator does, for example. So too does Microsoft Windows, of course. But the nosh toolkit's console-fb-realizer, GUIs like LXDE and XFCE4, and it seems all available GUIs on Ubuntu; do not.)

  • The scanner is assuming that NumLock is off. If NumLock is on, it should be faking one of the shift keys being pressed as well, in order to reverse the sense of the lock.

With some scanners, this stuff is modifiable by scanning special "control" barcodes. That is probably what happened here. You scanned a "control" barcode that switched the scanner into an operational mode that your operating system, keyboard driver, and keyboard layout cannot cope with. In which case, you need to consult your scanners' manual and find the control code that turns the behaviour back off.

For example: With an NLS-HR32 series scanner, this is the effect of putting the scanner into "ALT+Keypad mode 2" or "ALT+Keypad mode 3" and you would need to switch back to "disable ALT+Keypad" or "ALT+Keypad mode 1".

  • Your last guess was correct. I downloaded the manual, Reset it to its factory defaults and put to "USB Default Mode", and it just worked. I still don't know how come it stucked such a mode in Linux but worked correctly in Windows. Anyway, problem is gone, thank you. – ceremcem Sep 16 '17 at 21:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.