awesome

Welcome to awesome bug tracking system.
Tasklist

FS#953 - mouse.screen assignment fails to wrap pointer to second screen after randr mode switch

Attached to Project: awesome
Opened by Jonas (coroa) - Wednesday, 21 December 2011, 18:31 GMT
Last edited by Uli Schlachter (psychon) - Sunday, 06 October 2013, 09:25 GMT
Task Type Bug Report
Category Core
Status Closed
Assigned To No-one
Operating System All
Severity High
Priority Normal
Reported Version git/master
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Hej,

starting X afresh and leaving the default two-screen configuration alone. i can wrap the pointer in awesome to the top-left edge of the second screen by issueing

echo mouse.screen=2 | awesome-client

BUT after changing the mode of the second screen f.ex. by
xrandr --output VGA1 --mode 1024x768 ,

the same command
echo mouse.screen=2 | awesome-client
wraps the mouse pointer to the FIRST screen (as does mouse.screen=1).

a restart of awesome doesn't fix the problem. only after restarting X it works correctly again.

furthermore
screen[2].workarea.{x,y,w,h}
still show the correct values.

i'm running awesome from the current git-master (v3.4-599-ge38c523), but i'm seeing the same problem also with current stable.

unfortunately this short-coming has grave implications as screen.focus_relative doesn't work as expected i can't switch screen's via keyboard, which is rather bothersome.

i will gladly try any suggestion and do my best to provide additional information or help debugging if necessary.

thanks for your efforts,

coroa
This task depends upon

Closed by  Uli Schlachter (psychon)
Sunday, 06 October 2013, 09:25 GMT
Reason for closing:  Not a bug
Additional comments about closing:  We concluded that the bug must be elsewhere
Comment by Uli Schlachter (psychon) - Wednesday, 21 December 2011, 18:51 GMT
What does "screen[2].geometry.x" (and .y, .width, .height) print? What does "xrandr" print? (so that I know you screen configuration) What does "mouse.coords(screen[2].geometry)" do? What does "mouse.coords({ x = 10, y = 20 })" do?

(Trying to figure out if a) awesome detected the screen's correctly and if b) warping the mouse pointer fails)
Comment by Jonas (coroa) - Thursday, 22 December 2011, 14:48 GMT
screen[2].geometry.
x = 1400
y = 0
width = 1920
height = 1200

$ xrandr
LVDS1 connected 1400x1050+0+0 (normal left inverted right x axis y axis) 245mm x 184mm
1400x1050 50.0*+
...
VGA1 connected 1920x1200+1400+0 (normal left inverted right x axis y axis) 518mm x 324mm
1920x1200 60.0*+
...

upon mouse.coords(screen[2].geometry) mouse pointer warps to top-left corner of FIRST screen

mouse.coords({ x = 100, y = 20 }) also warps the mouse pointer to the same top-left corner of FIRST screen (independent of choice of x, y)

(thanks for the fast answer)
Comment by Jonas (coroa) - Thursday, 22 December 2011, 15:15 GMT
inserting
fprintf(stderr, "xcb_warp_pointer(.., %d, %d)\n", x, y);
into the function mouse_warp_pointer in mouse.c and calling
mouse.coords({ x = 100, y = 20 })

i get the expected output
xcb_warp_pointer(.., 100, 20)

and the mouse pointer warps to the top-left corner.

i'm on archlinux with libxcb 1.7-2.
Comment by Uli Schlachter (psychon) - Thursday, 22 December 2011, 17:16 GMT
Can you compile the attached file with 'gcc $(pkg-config --cflags --libs xcb) t.c' and tell us if it has the same, weird behavior?
This is getting weird, the X server doesn't seem to be doing what the X11 protocol expects it to do.
   t.c (0.3 KiB)
Comment by Jonas (coroa) - Thursday, 22 December 2011, 17:54 GMT
same weird behaviour.
ok, so it's definitely NOT an awesome bug.

where do i go from here?
Comment by Uli Schlachter (psychon) - Thursday, 22 December 2011, 18:39 GMT
That doesn't really mean that this has to be an awesome bug, it might just be me misunderstanding the X11 protocol. However, I don't really have any further ideas.
Comment by Jonas (coroa) - Tuesday, 10 January 2012, 13:57 GMT
hmm ... just to help people who experience the same problems:

for me it seems to work to force a reinitialisation of all my mice (replugging usb-ones) and issuing a

echo serio1 > /sys/devices/platform/i8042/serio1/driver/unbind
(where /sys/devices/platform/i8042/serio1/driver/description is PS/2 mouse driver)

to do the same for the internal PS/2 port of my laptop.

after automating this after resume from suspend. i'm not experiencing this weird behaviour anymore.

does this tell anything about the nature of the bug?
Comment by hemmo (hemmo) - Monday, 15 October 2012, 15:10 GMT
I have a similar problem. I have:

|Screen 3 (TV)|Screen 4|Screen 1|Screen 2|

When I focus to a specific screen, the cursor lags one screen behind.

I.e., I focus to Screen 1 and if I have a window on the screen, it gets the focus, but the cursor will appear in the left upper corner of Screen 4. Any new windows will also annoingly appear on the "incorrect" screen where the cursor is.


Similar behaviour can be seen with the above t.c program (edited it to take X and Y as arguments):

fcku ~ $ ./a.out $((1920+1920+1920+10)) 400

will make the cursor to appear on the left side of the Screen 1.

Using NVidia binary drivers (no XRandR), in case it might have something to do with this. This problem appeared a few days ago. Using Arch Linux and awesome v3.4.13 (Octopus).

Haven so far found a way to fix this even temporarily.
Comment by hemmo (hemmo) - Sunday, 21 October 2012, 07:19 GMT
Just booted up my machine and the problem seems to be gone. I updated some packages yesterday and out of those, I thought that these might be related:

[2012-10-20 23:56] upgraded xorg-server-common (1.13.0-2 -> 1.13.0-3)
[2012-10-20 23:56] upgraded xorg-server (1.13.0-2 -> 1.13.0-3)
[2012-10-20 23:56] upgraded nvidia-utils (304.51-1 -> 304.60-1)
[2012-10-20 23:56] upgraded nvidia (304.51-4 -> 304.60-1)
[2012-10-20 23:56] upgraded opencl-nvidia (304.51-1 -> 304.60-1)

Loading...