showing mouse pointer position when pressing Ctrl interferes with Fcitx

[lhmouse]

Distribution

Linux Mint 21.2

Package version

5.8.4

Graphics hardware in use

Intel TigerLake-LP GT2

Frequency

Always

Bug description

Conventionally, Ctrl-Shift is used to scroll between input methods in Fcitx. With the 'Show position of pointer when the Control key is pressed', left Ctrl-Shift no longer works.

Steps to reproduce

1. Go to Mouse and Touchpad -> Mouse.
2. Turn on Show position of pointer when the Control key is pressed.
3. Press the left Ctrl and release it. A ripple effect beneath the mouse pointer is activated.
4. Install Fcitx with at least two IMEs. (I have Wubi, Pinyin and Mozc.)
5. Press the left Ctrl-Shift and release them. This should have changed the active IME, but it doesn't.
6. Press the right Ctrl-Shift and release them. This changes the active IME, as expeted.
7. Disable the option in 2.
8. Left Ctrl-Shift works again.

Expected behavior

1. Either Ctrl with the left Shift key should scroll IMEs from top to bottom, in installation order.
2. Either Ctrl with the right Shift key should scroll IMEs from bottom to top.

Additional information

No response

[rcalixte]

@lhmouse This is not an issue with Cinnamon but a limitation with X11. You can verify by using the other Ctrl key if you have one but also using and releasing another key modifier before Ctrl (i.e. pressing Alt, then Ctrl, then releasing Alt while still holding down Ctrl) will also free the Ctrl key combo for your regular modifiers.

To workaround this (other than with the key modifiers trick), you can map the "Show position of pointer when..." option to another key that does not interfere with your regular operations, such as the right Ctrl key. This option is only available via dconf (/org/cinnamon/muffin/locate-pointer-key) or gsettings (org.cinnamon.muffin locate-pointer-key) though.

[lhmouse]

@lhmouse This is not an issue with Cinnamon but a limitation with X11. You can verify by using the other Ctrl key if you have one but also using and releasing another key modifier before Ctrl (i.e. pressing Alt, then Ctrl, then releasing Alt while still holding down Ctrl) will also free the Ctrl key combo for your regular modifiers.

Yes looks like so.

I just switched from MATE to Cinnamon yesterday. On MATE, pressing left Ctrl with that option turned on could cause textboxes to lose focus (reported here) but certainly it did not prevent me from switching IMEs.

[rcalixte]

So possibly something in the key down sequence that changed? Hmm, if this is an issue, it would most likely be in muffin I think but I'm not sure if anything can be done in the short-term.

[rcalixte]

I wonder if changing the locate pointer action to occur on the key up is possible? I'm not sure but it might be worth a look.

[lhmouse]

That is already what it behaves; the ripple effect is played when the left Ctrl key is released. However, some inputboxes lose focus as soon as the Ctrl key is pressed.

Known to work (inputbox does not lose focus)

1. Opera
2. HexChat
3. Thunderbird
4. Menu

Known to fail (inputbox loses focus, which makes copying with Ctrl-C impossible)

1. Fcitx (pressing left Ctrl deactivates the IME)
2. Nemo (only when renaming a file)
3. gufw (when adding rules)

[rcalixte]

A few notes here:

1. I've worked around this by pre-pending the Ctrl key press with an Alt key press but any other key would work (i.e. pressing Alt, then pressing Ctrl, then releasing Alt while still holding down Ctrl). This combination prevents the location trigger from activating.

2. This issue is actually resolved in Wayland. While it's still fairly far away, this issue will go away some day (for what that's worth 😅). Link to the blog post with the Wayland update.

[lhmouse]

To be honest 'it doesn't work in X' sounds unsatisfactory. There are applications where it works perfectly (web browsers for example) and I suspect it should work everywhere.

[rcalixte]

To be honest 'it doesn't work in X' sounds unsatisfactory. There are applications where it works perfectly (web browsers for example) and I suspect it should work everywhere.

I can verifiably say it does not work in my browsers in X11:

• If you type in the address bar and it opens a dialog with history or bookmarks and hit the Ctrl key to trigger the location, it cancels out the address bar entirely.
• I often even have issues with Ctrl+Enter with addresses in the address bar unless I use the first item in my note above.

Please double check which input fields are and are not having issues because it is absolutely a limitation of X11.

[lhmouse]

That doesn't happen on my browser, Opera 104.0.4944.36. Does it happen on Chromium or Firefox? Or I suspect Opera has customized their address bar somehow?

[rcalixte]

That doesn't happen on my browser, Opera 104.0.4944.36. Does it happen on Chromium or Firefox? Or I suspect Opera has customized their address bar somehow?

Opera is the only browser I haven't used in the past decade so I'm not sure what they're doing. 😅
They must be somehow drawing the address bar differently. Test with a different Chromium-based or Firefox-based browser and you'll see the issue clearly. Definitely test with the next version of Mint in a Wayland session and you'll see the difference as well. (It's one of the first things I tested myself.)

[lhmouse]

Opera is the only browser I haven't used in the past decade so I'm not sure what they're doing. 😅 They must be somehow drawing the address bar differently. Test with a different Chromium-based or Firefox-based browser and you'll see the issue clearly. Definitely test with the next version of Mint in a Wayland session and you'll see the difference as well. (It's one of the first things I tested myself.)

Thanks. I shall note this.

When will the next version of Mint be available, within this year? I don't mind whether it's beta whatsoever. We don't have Mint in production environments.

[rcalixte]

When will the next version of Mint be available, within this year?

Per this blog post, December 2023 is the current target.

[lhmouse]

I am now upgrading to 21.3 Beta to give it a try.

[lhmouse]

The upgrade completed. There was a third option in the login screen for Cinnamon on Wayland. I selected it, typed my password, then pressed Enter; but the inputbox vanished and I was not logged in. Strange.

So I logged into another console, restarted the graphical system (sudo systemctl isolate multi-user.target && sudo systemctl isolate graphical.target) but the same issue persisted; got stuck at the login screen.

So I'm back here to ask for some suggestions.

[lhmouse]

Dec 13 13:02:17 lhmouse-xps lightdm[4851]: gkr-pam: unable to locate daemon control file
Dec 13 13:02:17 lhmouse-xps lightdm[4851]: gkr-pam: stashed password to try later in open session
Dec 13 13:02:17 lhmouse-xps lightdm[4892]: Can't open display

[rcalixte]

Make sure you're fully up to date. It's a beta so you might have also encountered an unknown bug too. Whenever I have my system hang on the Wayland session, I run pkill -u ${my_user} as root in another virtual terminal and that takes me back to the login. If it's still not working, it might be worth waiting for the final release. Are you able to at least log into your regular session?

[rcalixte]

Dec 13 13:02:17 lhmouse-xps lightdm[4851]: gkr-pam: unable to locate daemon control file
Dec 13 13:02:17 lhmouse-xps lightdm[4851]: gkr-pam: stashed password to try later in open session
Dec 13 13:02:17 lhmouse-xps lightdm[4892]: Can't open display

Have you modified any of the .conf files in your LightDM configuration?

[lhmouse]

Dec 13 13:02:17 lhmouse-xps lightdm[4851]: gkr-pam: unable to locate daemon control file
Dec 13 13:02:17 lhmouse-xps lightdm[4851]: gkr-pam: stashed password to try later in open session
Dec 13 13:02:17 lhmouse-xps lightdm[4892]: Can't open display

Have you modified any of the .conf files in your LightDM configuration?

Yes, just noticed this from '/var/log/lightdm/lightdm.log':

[+15.60s] DEBUG: Authenticate result for user lh_mouse: Success
[+15.60s] DEBUG: User lh_mouse authorized
[+15.60s] DEBUG: Greeter requests session cinnamon-wayland
[+15.60s] DEBUG: Writing /home/lh_mouse/.dmrc
[+15.61s] DEBUG: Seat seat0: Creating display server of type wayland
[+15.61s] DEBUG: Using VT 8
[+15.61s] DEBUG: Launching process 4425: /etc/lightdm/xrandr.sh
[+15.61s] DEBUG: Process 4425 exited with return value 1

The login screen runs on VT 7 and I have '/etc/lightdm/xrandr.sh' which sets up mirrored display there:

#!/bin/sh
xrandr --auto --output eDP-1 --output DP-1 --same-as eDP-1

Apparently Wayland attempted to run on VT 8 which causes xrandr to fail. I appended true to that script and logged on successfully.

---

The Ctrl key no longer causes inputboxes to lose focus. However there are more serious issues: Fcitx is broken completely. I can no longer switch to the other IMEs. In addition, HexChat can no longer be minimized to tray.

[rcalixte]

The Ctrl key no longer causes inputboxes to lose focus. However there are more serious issues: Fcitx is broken completely. I can no longer switch to the other IMEs. In addition, HexChat can no longer be minimized to tray.

The Wayland session is still considered very Alpha.

There is linuxmint/wayland#14 and a few others for the input issues but I don't believe there is an open issue for HexChat. Can you create that in that project?

[lhmouse]

Done: linuxmint/wayland#23

BTW if Fcitx is unusable, then wayland is largely not an option for me, and I have to put up with this bug.

[rcalixte]

BTW if Fcitx is unusable, then wayland is largely not an option for me, and I have to put up with this bug.

Apologies for the confusion. I had only meant to highlight that this specific issue is resolved in Wayland sessions and to highlight the challenges that X poses in this regard. By no means would I suggest that the Wayland session is in a state of anything beyond testing and curiosity at this point for most people. The missing layout impacts a majority of international users which is unfortunate but this is part of why the session was labeled Experimental and Alpha. It is very early. It's good you were at least able to see the differences for yourself and thanks for opening the issue!

[lhmouse]

Thanks.

Would you please consider working on this issue? If it's unfixable I think this can be closed for now.