Bug 2170830

(In reply to Vikramsingh Patil from comment #0)
> 1. scan SN barcodes to gnome terminal.

Please describe this step more thoroughly. As I honestly don't understand what the step involves. Do we have hardware to reproduce locally? @tpelka do you know?

(In reply to Tomas Popela from comment #7)
> (In reply to Vikramsingh Patil from comment #0)
> > 1. scan SN barcodes to gnome terminal.
> 
> Please describe this step more thoroughly. As I honestly don't understand
> what the step involves. Do we have hardware to reproduce locally?
> @tpelka do you know?

If you mean a barcode scanner then no, but I believe a camera can be used too, no?

(In reply to Tomas Pelka from comment #8)
> (In reply to Tomas Popela from comment #7)
> > (In reply to Vikramsingh Patil from comment #0)
> > > 1. scan SN barcodes to gnome terminal.
> > 
> > Please describe this step more thoroughly. As I honestly don't understand
> > what the step involves. Do we have hardware to reproduce locally?
> > @tpelka do you know?
> 
> If you mean a barcode scanner then no, but I believe a camera can be used
> too, no?

Do you have a mode in your camera that puts the content of the barcode (the code itself) into stdout? I'm failing to understand how that would work.

I purchased this scanner and was able to reproduce the issue.  The customer provided a sample code which I will attach.  In testing this on rhel9.1 and rhel8.3 I was unable to reproduce the issue if I scanned into vim running inside gnome-terminal.  The provided code prints "205X8397780035".

When I scanned the code into just the bash shell, and hit space after each scan I would get an erroneous code about every 25-30 scans.  What is interesting is how the scan was modified:

  @)%X8397780035

  20%X8397780035

Are the two errors I was able to capture.  The characters that are incorrect are the same characters you would get after holding shift and hitting the correct character.  The customer reports that the issue does not appear in xterm.  He further reports that the issue does reproduce in 8.7.

I have asked the customer to confirm if his erroneous scans all correlate to "correct character" + shift.

Customer attempted additional test and the output does indeed match the same behavior that Steve noted. Erroneous shifts appear to be getting inserted, with numbers being replaced with symbols and letters capitalizing.

I was given https://wayland.freedesktop.org/libinput/doc/latest/tools.html which I used the following ways:

libinput debug_events  --verbose  (which does not look useful) 
libinput record /dev/input/event23 (which I do not understand)

I am attaching both outputs.  In the file libinput_record_dev_input_event23.out I scanned the customer's code ~80 times which consistently reads 205x8397780035 (note the lowercase x) and on the second to last scan it recorded @)%x8397780035.

- I tested this in tcsh within Gnome Terminal and could reproduce this.
- I tested in xterm and could not reproduce the issue.  Curiously, in xterm the code reads 205X8397780035 (note the capital X)

In learning about the scanner it looks like it might be programmed by scanning UPC codes.  The customer mentioned that his scanner inserts a carriage return that mine does not.  I stumbled across this https://poscatch.com/blog/how-to-activate-the-symbol-ls2208-carriage-return-enter-function/ but did not program the device.  Looking for similar issues I also stumbled across https://supportcommunity.zebra.com/s/article/000016982?language=en_US in which the manufacturer has a kbase that instructs you to program the device with an intercharacter delay.  I did not program my copy of the device in this way, since I was unsure how to reset it.

I have asked the customer about the impact they see when the intercharacter delay is added to the scanner.

I tested this build on my thinkpad and it seems that modifier keys are not working for me.  I installed the rpm and rebooted.  I wanted to ensure that I had the right package so I was attempting to type out "rpm -qa | grep mutter" and I can't type the | key.  I conduct the test and cannot reproduce the issue.  I try to hit control + c to get a prompt back from the terminal so I can clear it.  That does not work either.  I tested both key combinations in xterm and they work fine.

- I cannot reproduce the scanning failure with the test build.
- The test build seems to make my modifier keys not work correctly
- The test build still prints the code with lower case letters which xterm does not do.

Sorry, the backport to 3.32 was a bit more of a rewrite and I missed an important bit that went under the rader in my quick testing. https://brewweb.engineering.redhat.com/brew/taskinfo?taskID=53238434 should work better wrt modifiers in Wayland clients.

Ok, this version tests correctly.  

 - I cannot reproduce the scanner character issue
 - My modifiers work correctly
 - The letters are printed upper case.

I will provide the new build to the customer since they do a bit more than what I have been doing in my testing.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (mutter bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:6960