Subject: FVWM: warping pointer w/ XFree86 4.0 + Xinerama

From: [email-masked] (Danny Dulai)
Date: 16 Mar 2000 05:55:00 -0000

I have the following keybinding that work with previous versions of
XFree86:

Key Left        A       C       CursorMove -1 +0
Key Right       A       C       CursorMove +1 +0
Key Up          A       C       CursorMove +0 -1
Key Down        A       C       CursorMove +0 +1
Key Left        A       SC      CursorMove -10 +00
Key Right       A       SC      CursorMove +10 +00
Key Up          A       SC      CursorMove +00 -10
Key Down        A       SC      CursorMove +00 +10

When i upgraded to XFree86 4.0, and enabled 2 heads, using Xinerama, I have
one giant resolution and nothing knows differently:

xdpyinfo results:

default screen number:    0
number of screens:    1

screen #0:
  dimensions:    3200x1200 pixels (1084x406 millimeters)
  ...

anyways, the problem is that if the cursor is on my primary monitor,
everything works fine, but if I'm on the secondary monitor, then the
control+arrows stop working. no response at all. All other fvwm keys seem
to work just fine, just control+arrows stop (or so I've noticed).

Now, its not that fvwm isnt getting the keys, since when i hit
control+arrows, my xterm temporarily looses focus, just like normal (the
cursor becomes hollow until i let go of the arrow key).

xev dumps of when I hit control+left arrow once and let go:

Primary montior:

KeyPress event, serial 25, synthetic NO, window 0x2a00001,
    root 0x2a, subw 0x0, time 3998046814, (94,181), root:(1391,739),
    state 0x0, keycode 66 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 characters:  ""

FocusOut event, serial 25, synthetic NO, window 0x2a00001,
    mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 25, synthetic NO, window 0x2a00001,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 25, synthetic NO, window 0x0,
    keys:  2   0   0   0   0   0   0   0   4   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

KeyRelease event, serial 25, synthetic NO, window 0x2a00001,
    root 0x2a, subw 0x0, time 3998051556, (126,181), root:(1423,739),
    state 0x4, keycode 66 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 characters:  ""

------------

Secondary montior:

KeyPress event, serial 25, synthetic NO, window 0x2a00001,
    root 0x2a, subw 0x0, time 3998110546, (363,129), root:(1660,687),
    state 0x0, keycode 66 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 characters:  ""

FocusOut event, serial 25, synthetic NO, window 0x2a00001,
    mode NotifyGrab, detail NotifyAncestor

FocusIn event, serial 25, synthetic NO, window 0x2a00001,
    mode NotifyUngrab, detail NotifyAncestor

KeymapNotify event, serial 25, synthetic NO, window 0x0,
    keys:  2   0   0   0   0   0   0   0   4   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

KeyRelease event, serial 25, synthetic NO, window 0x2a00001,
    root 0x2a, subw 0x0, time 3998114459, (363,129), root:(1660,687),
    state 0x4, keycode 66 (keysym 0xffe3, Control_L), same_screen YES,
    XLookupString gives 0 characters:  ""

Everything is the same, except timestamps and the coordinates that the
keypresses happened at. Each monitor is running 1600x1200, so if you notice the
X position of the secondary montior event is 1660.

Any ideas on getting this key to work?

-- 
___________________________________________________________________________
Danny Dulai                                           Feet. Pumice. Lotion.
http://www.ishiboo.com/~nirva/                            [email-masked]
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 16 Mar 2000 07:22:56 +0100

> cursor becomes hollow until i let go of the arrow key).

That doesn't mean that fvwm gets the events.  It only indicates
that the application noticed something.

If Xinerama is really what I think (a large root window;
applications are unable to tell the difference between
one big and many small monitors), this looks lika a bug
in the Xinerama code.

Bye

Dominik ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
The adjuration to be "normal" seems shockingly repellent to me; I see neither
hope nor comfort in sinking to that low level.  I think it is ignorance that
makes people think of abnormality only with horror and allows them to remain
undismayed at the proximity of "normal" to average and mediocre.  For surely
anyone who achieves anything is, essentially, abnormal.
                -- Dr. Karl Menninger, "The Human Mind", 1930

---

From: [email-masked] (Danny Dulai)
Date: 16 Mar 2000 07:37:52 -0000

>that the application noticed something.

how can i see if fvwm is getting the events?

>one big and many small monitors), this looks lika a bug

Yah, one large root window. so thats what I was thinking, but I can't
possibly see how Xinerama has anything to do with this.

xev is still getting the same events. I wrote a program to wrap the pointer
around and it works just fine on the second monitor. The control key works
in applications, the rest of the fvwm key bindings still function.

I'd like to pinpoint the problem here, and either get it fixed in FVWM or
Xinerama. You know fvwm code inside out, so I figured you would be able to
help me with ideas on making sure the bug is not in FVWM. Then I can go
talk to XFree people.

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 16 Mar 2000 18:14:08 +0100

> help me with ideas on making sure the bug is not in FVWM. Then I can go

The only thing I can think of is printing out all KeyPress
events in HandleKeyPress() (events.c) and see if fvwm gets
the cursor keys at all.  If not try printing out all keys
that are unbound in libs/Bindings.c in the GrabWindowKey()
function.  If they're not unbound there, then it must be
a XFree bug (?).

Bye

Dominik ^_^

---

From: [email-masked] (Danny Dulai)
Date: 21 Mar 2000 13:06:25 -0000

>function.  If they're not unbound there, then it must be

So I tracked it down to the XWarpPointer() call.. the actual numbers fvwm
was coming up with were correct, and it was passing them to XWarpPointer()
correctly too.

The only difference in my xwarppointer code and the fvwm code was that the
src window arg (2nd arg) is set to the root window in fvwm, and its set to
None in my code.

I replaced the 2nd arg with None in builtins.c on line 509 for fvwm-2.1.13
(the only call to XWarpPointer() in the file) and all works for me now with
XFree86 4.0.

Why was this set to the root window at all? From the manpage:

    However, if src_w is a window, the move only takes place if the window
    src_w contains the pointer and if the specified rectangle of src_w
    contains the pointer.

I have submitted a bug to XFree86, but if there is no real reason why the
src_w should be root, then can this change be made in the cvs repository so
future fvwms can work with XFree86 4.0?

Now it seems I have random RaiseLower issues.. I wonder if their window
stacking stuff is broken. This one is much harder to reproduce, so it might
take a while.