Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1954884 - xscreensaver displays three dots for every char
Summary: xscreensaver displays three dots for every char
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: xscreensaver
Version: 34
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Mamoru TASAKA
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-04-29 02:02 UTC by Henrique Martins
Modified: 2021-05-17 11:10 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-05-17 11:10:26 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
xscreensaver -debug stdout stderrr (3.86 KB, text/plain)
2021-04-29 04:28 UTC, Henrique Martins
no flags Details
rpm -q -a (152.22 KB, text/plain)
2021-04-29 04:28 UTC, Henrique Martins
no flags Details
photo of lock screen with one char typed (195.04 KB, image/png)
2021-04-29 04:37 UTC, Henrique Martins
no flags Details
xscreensaver -debug -verbose with :0.0, :0.1 and :0.2 (6.89 KB, text/plain)
2021-04-29 16:14 UTC, Henrique Martins
no flags Details
JWZ patch for duplicate xinput events (1.27 KB, patch)
2021-05-03 14:37 UTC, Henrique Martins
no flags Details | Diff

Description Henrique Martins 2021-04-29 02:02:13 UTC
Description of problem:
Updated to f34.  When trying to unlock xscreensaver I get three dots for every character I type.  Can't unlock the screen.  Hopefully I can ssh in and kill xscreensaver.

Version-Release number of selected component (if applicable):
xscreensaver-6.00-1.fc34.x86_64

How reproducible:
Unfortunately always

Steps to Reproduce:
1. Lock screen
2. attempt to enter password to unlock

Actual results:
As in description.

Expected results:
Possible to unlock screen :-)

Additional info:
Downgraded to latest f33 available on bodhi, xscreensaver-5.45-1.fc33, and it works fine.

Comment 1 Mamoru TASAKA 2021-04-29 03:36:38 UTC
Unless I can reproduce your environment, I cannot debug this issue.

* Would you write the detailed procedure so that I can reproduce this issue?
  Especially

  - If you can reproduce this issue from clean install, the procedure from the first
  - What locale you are using ( e.g. $ locale )
  - What desktop environment you are using ( e.g. $ env )
  - If you can reproduce this issue from clean install, the procedure
  - your ~/.xscreensaver
  - If you can provide
    - Once kill xscreensaver by $ xscreensaver-command -exit
    - Launch xscreensaver with debug mode by $ xscreensaver -debug
    - Lock the screen and try to unlock
    The output on the terminal
  - Photo of lock screen

Comment 2 Mamoru TASAKA 2021-04-29 04:07:55 UTC
- Photo of lock screen
  This is : photo of lock screen when unlocking dialog appears and when you input one character
- Also: what rpms you've installed ( $ rpm -qa )

Comment 3 Henrique Martins 2021-04-29 04:26:31 UTC
- There's really no special procedure.  I upgraded this morning,
  logged in, checked a few things. rebooted the system a couple of
  times, and the first time xscreensaver kicked in it was like that.

- Not sure what you mean by clean install, this is a system that has
  been dnf upgraded from earlier versions.  The last fresh install was
  when I bought this box in Dec 2020, thus f31 probably.  I don't have
  hardware to do a clean install.

- LANG=en_Us.UTF-8

- No desktop environment, xdm + fvwm

- Not providing ~/.xscreensaver.  I renamed the file away and the
  problem persists

- I'll attach the result of xscreensaver -debug 1>log 2>&1.  In there
  it complains that xscreensaver-auth is not setuid root and thus
  xscreensaver can be killed by OOM.  I pressed a single asterisk,
  shift 8 on my keyboard, results in three Shift_L presses, three
  asterisk presses, then their releases in reverse order.

- I'll attach a photo of the screen, after I pressed asterisk once.

- I'll attach the list of installed RPMs, all 4383 of them.

And again, dld f33 xscreensaver works fine.

Comment 4 Henrique Martins 2021-04-29 04:28:17 UTC
Created attachment 1777001 [details]
xscreensaver -debug stdout stderrr

Comment 5 Henrique Martins 2021-04-29 04:28:42 UTC
Created attachment 1777002 [details]
rpm -q -a

Comment 6 Henrique Martins 2021-04-29 04:37:15 UTC
Created attachment 1777003 [details]
photo of lock screen with one char typed

Comment 7 Henrique Martins 2021-04-29 05:01:45 UTC
Works (almost) fine on a laptop that I also just upgraded. Same warning about xscreensaver-auth,
and instead of nice dots I have empty rectangles, like I' missing a font or something.

On the broken system I seem to have password authentication, on the laptop I have ssh_pam auth.
Broken system runs one X server, two independent screens, zaphod mode.
These probably don't make any difference.

Comment 8 Mamoru TASAKA 2021-04-29 05:37:57 UTC
> Broken system runs one X server, two independent screens, zaphod mode.

This can affect this issue, because log shows actually multiple input event is received,
and xscreensaver 6 uses xinput2. And so it seems I cannot reproduce your environment.

What if you don't use zaphod mode, especially? Are you using custom xorg.conf?

Comment 9 Mamoru TASAKA 2021-04-29 07:41:54 UTC
And 
- Would you show the log with $ xscreensaver -debug -verbose
  when trying to lock and typing a character?

Comment 10 Henrique Martins 2021-04-29 16:13:20 UTC
I run xdm + fvwm. I configure my initial windows via a session script.
In it my DISPLAY is :0 and I start xscreensaver with no arguments
(redirecting stdout and stderr to /dev/null), which is equivalent of
running with -display :0.

If I move my xorg.conf away, I get one "screen" for all my windows
:0.0, and if I run like that, i.e. without a xorg.conf file,
xscreensaver reads one character for each character I type and I can
unlock the screen.

If I switch systemd to not run the graphical interface (old init 3),
login at the console tty, run X -configure, I get a xorg.conf.new
file.  If I run with this file in place, I get the same behavior as
with no xorg.conf file.

If I change that xorg.conf to make it have dual independent screens
via the ZaphodHeads Option, i.e. :0.0 and :0.1, then for each
character I type to the xscreensaver unlock dialog, I get ... two
characters. 

What hapens is that I actually have three independent screens, via
ZaphodHeads.  Third screen is on the second input of the second
monitor, and I need to toggle the input switch on that monitor to be
able to see it.  With this configuration, for each character I type to
the xscreensaver unlock dialog, I get three characters. 

Thus if one has N independent screens, :0.0, :0.1, ..., :0.N-1, I would
get N characters for each one I typed :-). This happens whether
xscreensaver is running with a DISPLAY if :0  or any :0.x.

I'll attach the log of xscreensaver -debug -verbose for the three
screens case.

Comment 11 Henrique Martins 2021-04-29 16:14:41 UTC
Created attachment 1777226 [details]
xscreensaver -debug -verbose with :0.0, :0.1 and :0.2

Comment 12 Mamoru TASAKA 2021-05-01 14:33:44 UTC
Would you kindly provide *very detailed, step by step procedure* to reproduce this issue?
Especially, would you provide how you set up your environment?

You seem to be using some customized X settings, and unless I (and the upstream) can understand exactly the way 
how you set up your environment, it seems very hard to reproduce this issue.
Usually I just install some Fedora live spin (usually just install LXDE live spin) and test xscreensaver 
and so on, and I don't do such customized X settings.
I don't use xdm or fvwm, and I don't know how you are using them.

Comment 13 Henrique Martins 2021-05-01 15:43:28 UTC
I don't think you need xdm/fvwm, but simple enable ZaphodHeads.

It is hard to give detailed instructions without knowing your hardware, but 
if you get a system with two monitors ro
- switch away from graphical level (init 3 still works even with systemd)
- login at the tty/console and run "X -configure"
- move xorg.conf.new in the home directory to xorg.conf in /etc/X11
- edit that file and add
   Option "ZaphodHeads" "Output"
  where Output depends on your system, but will be one of the xrandr available outputs
- init 5, login to X and try it.

I filed a bug report with JWZ.  This seems to be a problem with his use of XInput2 in version 6.x

Comment 14 Mamoru TASAKA 2021-05-03 13:11:40 UTC
I think fixing this needs not a few time. Thank you for reporting th jwz anyway.

Comment 15 Henrique Martins 2021-05-03 14:35:34 UTC
Both myself and Jamie came up with patches that fixes the problem by eliminating duplicated/triplicated XI events.
With no surprise his is better than mine and more in line with the code structure.
I'll attach here, but you may want to wait for his.
I've only built from source, not RPMs.

Comment 16 Henrique Martins 2021-05-03 14:37:06 UTC
Created attachment 1779022 [details]
JWZ patch for duplicate xinput events

Comment 17 Mamoru TASAKA 2021-05-03 15:27:49 UTC
Okay, thank you. I was about trying to remove events which came within very short time,
but jwz patch is much cleaner.
I will apply this patch tomorrow. For now I am going to bed.

Comment 18 Fedora Update System 2021-05-04 12:55:39 UTC
FEDORA-2021-7140ac3ac5 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-7140ac3ac5

Comment 19 Henrique Martins 2021-05-04 14:46:53 UTC
Thanks Mamoru, seems to fix my problem. (Didn't check the other 3 bugs it solves, i.e. from the -2 version)

Comment 20 Fedora Update System 2021-05-05 01:51:05 UTC
FEDORA-2021-7140ac3ac5 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-7140ac3ac5`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-7140ac3ac5

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 21 Fedora Update System 2021-05-06 01:58:19 UTC
FEDORA-2021-c2e2cc1e9a has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-c2e2cc1e9a`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-c2e2cc1e9a

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 22 Fedora Update System 2021-05-14 17:49:14 UTC
FEDORA-2021-c2e2cc1e9a has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.