Description of problem: Applications using VTE (e..g. Gnome-Terminal, GEdit) scramble input from the keyboard. Applications not using VTE (Chrome, Firefox, GVim), don't. Examples ... I have a barcode scanner that emulates a keyboard input. In GVim, when I scan a qrcode, it shows up as expected: https://prajna.io/9940a84a-1890-4711-8836-59d68f599f6d https://prajna.io/9940a84a-1890-4711-8836-59d68f599f6d https://prajna.io/9940a84a-1890-4711-8836-59d68f599f6d https://prajna.io/9940a84a-1890-4711-8836-59d68f599f6d https://prajna.io/9940a84a-1890-4711-8836-59d68f599f6d In vim in a Gnome Terminal, it shows up with replacement characters for several characters: https://prajna.io/9940a84a-1890-4711-8836-59d68f599f6d https;//prajna.io/9940a84a-1890-4711-8836-59d68f599f6d httpS://prajna.io/9940a84a-1890-4711-8836-59d68f599f6d httpS;//prajna.io/9940a84a-1890-4711-8836-59d68f599f6d https;//prajna.io/9940a84a-1890-4711-8836-59d68f599f6d httPS;//prajna.io/9940a84a-1890-4711-8836-59d68f599f6d Note the colon changing to semi-colon, and misplaced capitals. Other times, I've seen other characters randomly replaced. There doesn't seem to be any rule, but it appears to happen most often for the first few characters on any new line. Version-Release number of selected component (if applicable): vte291-0.60.2-1.fc32.x86_64 gnome-terminal-3.36.1.1-1.fc32.x86_64 How reproducible: 95% of the time Steps to Reproduce: 1. Scan in any code with the USB barcode reader Actual results: Example: "httPS;" Expected results: "https:" Additional info: Not sure how to debug this further.
Moving to correct component. :)
You could use the script(1) utility to record what input vte actually receives, and post the log file.
Created attachment 1687030 [details] Contents of Gnome Terminal (to compare a (against script-input.log)
Created attachment 1687031 [details] Script log
Thanks, I posted both a script log file and a copy/paste of what appeared in the Gnome Terminal for the same session. Will it help if I do the same in Eterm or some other unaffected component?
Thanks. The script log file shows that the raw input already contains the faulty data; so it's not a problem of vte's interpretation of the data. Given that the problem is uppercasing and replacement of ; with :, my guess would be that the Shift modifier is pressed when these characters are received. I also note that the first 4 bytes are always correct, and the fault always occurs on the 5th and 6th character. So probably this is a problem in the driver of the barcode reader, or the barcode reader itself is faulty.
Thanks. I think those are some reasonable possibilities, and I've tried to find ways to test them. Can you clarify ... if I am running script in a gnome-terminal window, doesn't that mean that the script recording is already passing through gnome-terminal's input, and therefore through vte? I've tested on Fedora 30 and Fedora 31, and I can not reproduce the problem. Nor can I reproduce anything similar in Mac or Windows. I also have a tried a large number of applications in Fedora 32, and it is only the applications using VTE that exhibit this behavior -- gnome-terminal, quake, text-edit, etc. It doesn't exhibit this behavior in Eterm, xterm, Chrome, Firefox, GVim, etc. All this considered, I already thought of and set aside the possibility of the barcode hardware, firmware or driver. It uses the same HID driver that my keyboard uses. If it is the shift modifier, why does it only happen in some applications and not others? Note, in the examples I've captured it has always been the 4th, 5th, or 6th character after the newline, and while that is the predominant case, I've had other cases where it was the first, 3rd, 7th, 8th, or 10th. I just don't have logs for those. Any theories on what else it might be if not VTE? Am I missing some other common denominator in the applications that could be causing this? I've been pulling me hair out trying to solve this and would welcome any help.
I've probed further ... this isn't VTE or my hardware/firmware/driver. It is somewhere in GNOME, but I am having trouble finding exactly where. No non-GNOME applications exhibit the behavior, and it only exhibits on the computers I've upgraded to Fedora 32 (or fresh install Fedora 32). I can demonstrate the problem doesn't exist in Fedora 31. I'm re-assigning to gnome-libs and will try to narrow down further.
Please find a different package to assign this to; gnome-libs is from the ancient Gnome 1 stack and was retired for Fedora 32. Perhaps gnome-terminal? At least that way you'd find an actual current Gnome maintainer that might have a clue as to the right component to assign it to.
Assigning to gnome-terminal per suggestion. Thanks.
> if I am running script in a gnome-terminal window, doesn't that mean that the script recording is already passing through gnome-terminal's input, and therefore through vte? Hmm right. I guess I had missed some parts of comment 0. > Applications using VTE (e..g. Gnome-Terminal, GEdit) gedit does not use vte. However, since it reproduces in gedit, this is likely a wayland related problem. g-t and gedit use wayland by default on F32, while I guess gvim is probably still using X.
Assigning now to Wayland. I tried with "GNOME on Xorg" and the problem disappears. Sorry for bouncing around a lot on this ... this bug was hard to find -- my library just started reporting scanners weren't working, and it took a while to narrow down, and I'm still finding it hard to get resources to debug this problem at this layer in the stack (and I welcome all pointers!). Now that I have seen this doesn't happen in Xorg, my urgency to fix this is diminished, but I'm still planning to debug -- but I am not quite sure how to proceed. I'm not a programmer (besides simple python scripts), so debugging Wayland seems a little daunting without a lot of background, but I'm willing to follow any tips people may offer. SUMMARY: A barcode/QR scanner that uses standard HID driver is getting incorrect input reflected in some applications. Right now the common denominator seems to be Wayland. Apps that show the wrong input are predominantly GNOME apps (haven't tried KDE) like gnome-terminal and gedit. Applications that DON'T show problem include Chrome, Firefox, ETerm, GVim. The result is that in these apps, using the scanner, some characters appear to be "shifted" ... that is that they are upper case when they should be lower, symbols instead of numbers, underlines instead of dashes, semi-colon instead of colon. Etc. Examples above. I can't duplicate this problem in the F31 version of Wayland, so it looks like it was introduced somewhere in the F32 ecosystem.
Sounds like a mutter input related issue to me.
Perhaps related to https://gitlab.gnome.org/GNOME/gtk/-/issues/2564
I'd be happy to test mutter. Any pointers on how to narrow it down to mutter or to verify that it's this known issue? I've tried to duplicating the problem in KDE Plasma and in Sway. I thought both used both Wayland and mutter, but both seem to be immune to the problem.
The links containing the supposed logs are dead, so can't see most of the relevant information. Always attach bug report information as attachments, as external links tend to go bad quickly. Anyhow, if the issue reproduces in e.g. weston-terminal or some other thing where one can type input, then run: WAYLAND_DEBUG=1 weston-terminal >& wayland-debug-log.txt and attach the resulting file here after having reproduced the issue in the opened window.
You can also use the vte test application, vte-2.91 to get a standalone terminal while still using gtk+ (in case the problem is in gtk+), just substitute vte-2.91 for weston-terminal above.
Created attachment 1688045 [details] Wayland Debug Log This doesn't seem to reproduce the problem, unfortunately.
Created attachment 1688046 [details] VTE Wayland Debug Log This does not duplicate the problem either, unfortunately.
Created attachment 1688047 [details] GEdit / Wayland Debug Log This DOES appear to duplicate the problem. Is there a way to simplify this by running WAYLAND_DEBUG with gnome-terminal? I've tried substituting in gnome-terminal and I don't get the wl_keyboard events in the resulting log output.
I ran a few attempts to duplicate with WAYLAND_DEBUG on both weston-terminal and on vte, and was not able to demonstrate the problem. Logs attached above. I was able to duplicate the problem with WAYLAND_DEBUG on in gedit on the very first session, so I've attached that also. This aberrant behavior is also apparent in gnome-terminal and other applications, but I wasn't getting the same sort of wl_keyboard events in the WAYLAND_DEBUG logs from gnome-terminal (with --wait and/or -p flags). I can post those logs too if they help, or if there are more useful flags I need to pass to gnome-terminal, I can do that also.
You need to run a separate gnome-terminal-server started with the extra env var for this to work, see https://wiki.gnome.org/Apps/Terminal/Debugging .
Created attachment 1688503 [details] Gnome-Terminal WAYLAND Debug Log Thanks! Attached is a gnome-terminal session log with WAYLAND VTE and GNOME_TERMINAL _DEBUG's on.
I'm not sure I'm reading this properly, but it looks like the modifiers events in the gnome-terminal session aren't coming in consistently ordered. It looks like it should be wl_keyboard(00, 11, 31, 0) wl_keyboard(00, 11, 42, 1) wl_keyboard(00, 1, 0, 0, 0) wl_keyboard(00, 11, 39, 1) wl_keyboard(00, 11, 42, 0) wl_keyboard(00, 0, 0, 0, 0) wl_keyboard(00, 11, 39, 0) wl_keyboard(00, 11, 53, 1) But I'm seeing all sorts of variations. E.g. wl_keyboard(00, 11, 31, 0) wl_keyboard(00, 1, 0, 16, 0) wl_keyboard(00, 11, 42, 1) wl_keyboard(00, 11, 39, 1) wl_keyboard(00, 0, 0, 16, 0) wl_keyboard(00, 11, 42, 0) wl_keyboard(00, 11, 39, 0) wl_keyboard(00, 11, 53, 1) ... and ... wl_keyboard(00, 11, 31, 0) wl_keyboard(00, 1, 0, 16, 0) wl_keyboard(00, 0, 0, 16, 0) wl_keyboard(00, 11, 42, 1) wl_keyboard(00, 11, 39, 1) wl_keyboard(00, 11, 42, 0) wl_keyboard(00, 11, 39, 0) wl_keyboard(00, 11, 53, 1) ... and ... wl_keyboard(00, 1, 0, 16, 0) wl_keyboard(00, 11, 31, 0) wl_keyboard(00, 11, 42, 1) wl_keyboard(00, 11, 39, 1) wl_keyboard(00, 0, 0, 16, 0) wl_keyboard(00, 11, 42, 0) wl_keyboard(00, 11, 39, 0) wl_keyboard(00, 11, 53, 1)
This message is a reminder that Fedora 32 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '32'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 32 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.