I worked with Zebra on this and was able to get the scanner working by
reducing the USB polling interval on the scanner to 8msec, the default
is to poll every 3msec. I still believe this is a bug in how xterm
accepts input because of the following:
A) This issue does not occur when accepting
Thanks for the response Thomas. The DS4208 has multiple cables that it
can be plugged in with, the xterm issues are when it is plugged in over
USB. RS232 is not used for doing direct-text input.
--
You received this bug notification because you are a member of Desktop
Packages, which is
Reading the manual, I see that the DS4208 is talking via RS-232, which would
make xterm's
role in this mostly as a bystander, since (unless you've made your keyboard the
serial device,
it would only be echoing something).
The -l option doesn't show me much either, except for your shell prompt
Thomas,
The characters being sent/received are normal ASCII characters, we're doing
Vin code scanning so it's even in the domain A-Z 0-9 like I said, it was
working fine on an older version of xterm.
--
You received this bug notification because you are a member of Desktop
Packages, which is
Thanks, I'll try running with -k8 and other settings to see if I can't
get it to respond differently!
--
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
Thomas: This issue is reproducible simply by attempting to scan a
barcode into the xterm window NOT a child process, I was simply
indicating that it happened in both places. The USB scanner is acting
as a basic character-input device when used like this. There's no
special application running
Without knowing what characters are sent/received, I cannot offer advice other
than
to point to known problems with applications in this area.
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xterm in Ubuntu.
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
This sounds like a problem with the application rather than xterm.
For instance, there are a few applications which have hardcoded
escape sequences for Linux console's nonstandard color palettes.
XTerm has a workaround for that (the brokenLinuxOSC resource setting).
Some other applications do...
If that were so, then there would be a lot of bug reports
(control-characters would be something to check, but plain ASCII does not sound
plausible).
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to xterm in Ubuntu.
10 matches
Mail list logo
