! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Cursor change to "cross" (window move) and no way to come back to normal work...


Description angelo70 2015-09-03 08:26:19 CEST
Created attachment 6442 
session log

Dear all,

still not found a way to reproduce exactly the issue, but since it happen at least now 2 times per day, i fill a bug about it, maybe you xfwm experts could have some idea about.

In a casual moment, but clicking with the mouse, the cursor change from arrow to cross (move). There is not way to come back to the normal cursor until i don't kill xfce4-session from a virtual console (ALT+F1).

In the cursor "cross" state, the windows manager seems working still, windows borders and everything looks the same, but i can't anymore focus to anything. Cursor moves, but clicking the mouse can't unlock in any the state of the cursor.

The keyboard also seems not able to unlock the state, only action possible from the keyboard seems ALT-TAB or in general ALT+X combinations. None of those actions can unlock the cursor state.

I attach an .xsession-errors that should contain details, at least it is on the same day where issue happen.

Important notes: i am currently using Logitech K520 wireless keyboard and mouse kit. System setting set as "Logitech Unifying device"

If possible, as a temporary solution, a workaround to unlock without killling the session would be great. Keyboard has been set to Logitech Cordless Desktop (Italiana).

Many thanks

Some system details:

|-- angelo@jerusalem:~ --|
$ cat /proc/version 
Linux version 3.18.3 (root@jerusalem) (gcc version 4.9.2 (Debian 4.9.2-22) ) #1 SMP Tue Aug 25 11:57:31 CEST 2015

|-- angelo@jerusalem:~ --|
$ X -version

X.Org X Server 1.17.2
Release Date: 2015-06-16
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.16.0-4-amd64 i686 Debian
Current Operating System: Linux jerusalem 3.18.3 #1 SMP Tue Aug 25 11:57:31 CEST 2015 i686
Kernel command line: BOOT_IMAGE=/vmlinuz-3.18.3 root=/dev/mapper/jerusalem--vg-root ro quiet
Build Date: 11 August 2015  10:03:42AM
xorg-server 2:1.17.2-1.1 (http://www.debian.org/support) 
Current version of pixman: 0.32.6
	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
Comment 1 angelo70 2015-09-03 14:50:55 CEST
As suggested in irc channel, tested xfwm 4.12.3.

Changed also mouse battery.

Issue happen in the same way.
Comment 2 Olivier Fourdan editbugs 2015-09-03 14:52:08 CEST
Please provide a way to reproduce.
Comment 3 Olivier Fourdan editbugs 2015-09-03 14:58:50 CEST
(In reply to Olivier Fourdan from comment #2)
> Please provide a way to reproduce.

Sorry my bad, xfwm4-4.12.3 does *not* contain the fix I was thinking about (that would explai nthe behavior you see).

Any chance that you try xfwm4 from git master, or alternatively add this patch to you 4.12.3 build:


And retry? I am pretty sure this is your problem.
Comment 4 angelo70 2015-09-05 21:00:25 CEST
As suggested on IRC, applied the suggested patch (should be as per last git code), built, and issues seems not happening anymore.
Comment 5 Git Bot editbugs 2020-05-29 12:08:16 CEST
-- GitLab Migration Automatic Message --

This bug has been migrated to xfce.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.xfce.org/xfce/xfwm4/-/issues/198.

Please create an account or use an existing account on one of our supported OAuth providers. 

If you want to fork to submit patches and merge requests please continue reading here: https://docs.xfce.org/contribute/dev/git/start#gitlab_forks_and_merge_requests

Also feel free to reach out to us on the mailing list https://mail.xfce.org/mailman/listinfo/xfce4-dev

Bug #12183

Reported by:
Reported on: 2015-09-03
Last modified on: 2020-05-29


Olivier Fourdan
CC List:
0 users




session log (11.58 KB, application/x-trash)
2015-09-03 08:26 CEST , angelo70
no flags

Additional information