desktop-packages team mailing list archive

[Nick Minkler <nick.minkler@xxxxxxxx>]

Here's what xterm is apparently seeing when I scan a barcode and use the
-l option to log the output.

^[]0;isisup@LUBE151: ~^Gisisup@LUBE151:~$ 1G

The 1G is the first 2 printed characters of the barcode in this case,
but there are 15 more it should have kept reading instead locking up.

Using another barcode I get this:
^[]0;isisup@LUBE151: ~^Gisisup@LUBE151:~$ 3B5

The 3B5 is actually incorrect in this case, the barcode I scanned is
should be showing 3B7 then another 14 characters.

Now I tried the same thing on the older version of xterm and it also has
the same control characters in the log to start with, but will finish
scanning the full barcode to the command line.  Any ideas on this?

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xterm in Ubuntu.
https://bugs.launchpad.net/bugs/1499416

Title:
  xterm freeze when accepting input from usb scanner

Status in xterm package in Ubuntu:
  New

Bug description:
  I have a symbol DS4208 Wired USB barcode scanner hooked up to a
  machine running Ubuntu 14.04 via a USB connector.  When using xterm
  and attempting to scan a 1D or 2D barcode the xterm window will accept
  in a couple characters from the USB scanner not in the correct order,
  and then lockup. The number of characters accepted varies, and is
  never in the correct order.

  This also happens from any child process launched from the xterm
  window.

  This issue is not present when I first sudo -s to obtain a root shell.
  Scans will be interpreted properly and characters are entered into
  child processes, or command line correctly depending on where the
  cursor is situated.

  This issue is not present in other terminal emulators such as
  lxterminal.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xterm/+bug/1499416/+subscriptions