There is something wrong with inputs about awesome HOT 15 OPEN

Here is the x11trace
https://gist.github.com/Elv13/bc6a6c441180b6dfeee8

So, in this, I open awesome on 6 screen, (1920x1080+0+600, 1920x1080+1920+600, 1680x1050+3840+0, 1680x1050+5540+0), move the mouse to the second screen and press mod4+enter, then quit. The terminal open on screen 1.

There is also the issue where pressing the taglist change the tag on the wrong screen, but this is not in this trace (for simplicity).

from awesome.

Ok, so what am I seeing: (The first four digits are sequence numbers, "f" and "ff" mean "and following")

Your root window (id 0x98b) has size 5939x1680 (and your X11 server claims it has a size of 1620mm times 454mm.
0001 - 0006: Awesome initializes extension, RANDR extension is not available
0007 - 000a: cairo initializes, you have quite a recent cairo version (git master?), no X11 resource property set on the root window
000b: Cursor font is opened
Then another X11 client connects (xtrace assings id 001)... urgh... looks like dbus
And yet another client, 002. No idea what this is, but Xlib is initializing
000c - 0050: Awesome grabs the server, declares itself the window manager, lots of initialization
0051 - 0052: screen information is queried through xinerama, screens={x=0 y=600 width=1920 height=1080},{x=1920 y=600 width=1920 height=1080},{x=4889 y=0 width=1050 height=1680},{x=3839 y=0 width=1050 height=1680};
0053 - 0058: Various EWMH properties are set up, window=0x00400002 is the _NET_SUPPORTING_WM_CHECK window
0059: window=0x00400003 is created, dunno why
005a - 0060: systray and startup-notification related atoms are interned
0061 - 0064: window=0x00400004 is created and destroyed, just to set up GC cid=0x00400005
0064 - 0066: We are not the WM, ungrabbing the server
0067f: Root window cursor is set
0069ff: Wallpaper is set up
Another, new X11 client, 003. This could be a new connection that awesome uses for setting up the wallpaper... it creates pixmap pid=0x00a00000
006aff: Looks like more cairo initializations
0071ff: Cairo is drawing to the pixmap created by client 003 (yup, this is awesome setting the wallpaper)
0074: Sadly, shared memory isn't used for uploading the wallpaper :-(
0079: Back to client 003 which finishes setting up the wallpaper
007cff: Meh. The whole wallpaper-related show begins again, client 004 connects
...and 005... and 006... looks inefficient to set the wallpaper so often (and slow)
009dff: tags are created (and whenever a is created or renamed, lots of X11 requests announce this)
010dff: A drawin is created(?), window=0x00400011, border color is black, final size is 100x30
0119ff: Drawin window=0x00400014 is created, 1920x19 (???)
0127ff: Drawin window=0x00400017, 1920x19
0145ff: Drawin window=0x0040001a, 1050x19
0148ff: window=0x0040001d, 1050x19
0154ff: Keys are grabbed
0252ff: The windows that already existed when awesome started are being managed (there are three, one is InputOnly, all are unmapped)
0258ff: Systray is set up
025aff: First redraw
0281ff: Second redraw (why???; this time there is text involved)
02a1ff: Border color of window=0x00400003 is changed to something grayish (#222222) and that window is unmapped (hidden), This might be the systray window (but why would we set its border color?), it is reparented into parent=0x00400014
02a5ff: More text is drawn
02b6ff: Another redraw is started (btw I see the beginning of redraws by seeing the requests that check if a composite manager is running)
02c9ff: Another redraw (did I mention the weirdness and ineffeciency?)
02ddff: Another redraw (Hm, I didn't check which window is being redrawn, this could be one of the many other drawins)
02deff: Another redraw
02f0ff: Seems like the main loop is starting, we are restacking the drawins into the order we want them to be and handle all the Expose events that have piled up; input focus is set to 0x98b (the root window)
0314ff: Another redraw
0314ff: Another redraw
0329ff: Another redraw
033cff: Another redraw
034bff: Border color is again set to #22222 and the window is unmapped again (I guess it was never mapped?)
0352ff: More redraws
0365ff: redraw
0370ff: Keyboard state is updated (Dunno why, I didn't check the various events that were received), keys are grabbed again
0470ff: Let's do the same again!
056f: A key is pressed, keycode=0x24 state=Mod4
0470ff: A new window is created, window=0x00400026, we generate some startup-notification stuff (So I guess this started a terminal?)
0578ff: Mouse cursor is changed
Client 007 connects, looks like it is using Xlib, I'll just skip whatever it is doing
0579: Awesome receives a map request, some window wants to be shown, window=0x00a00009
0579: Startup-notification is being noisy
057aff: Awesome starts managing the window (at the same time that the window redraws itself, grrrrr)
0580: window=0x00400028 will be the frame window for this
058e: Ahh, WM_NAME = urxvt, so 007 must be urxvt
05a6f: New geometry for window=0x00400028 is 1920x0, size 576x340
05b0ff: Keys and buttons are being grabbed on this new window
05e8f: New geometry for window=0x00400028 is 0x619, size 576x340
05eeff: We haven't had a redraw in a long time, let's do that
0603ff: Systray(?) again
060eff: Another redraw
0634ff: Redraw
064aff: We are restacking windows, so another main loop iteration must be done, input focus is set to focus=0x00a00009
(Lots of events follow from the stuff we did above)
064eff: Expose events, copy from our offscreen pixmap to the screen
065e: PropertyNotify for an unknown atom (xtrace doesn't know which atom this is)
065e: More Expose-related events follow
065f: We give up the systray ownership? Did you send a SIGINT to awesome or something like that?
0660ff: Lots of cleanup

I can't really see what should be useful in there, except that urxvt was shortly shown at 1920x0 and then moved to 0x619.

When using xtrace, I would suggest using the --relative-timestamps options. That prepends "time since first client" to every line and makes it easier to figure out where awesome was idle and e.g. some input event woke it up.

from awesome.

Oh and since this is apparently lua moving the client around:

client.connect_signal("manage", function(c) print(c.name, c:geometry(), debug.traceback()) end)

from awesome.

One more thing: Since this might be about mouse.screen, here are the QueryPointer requests (which is how mouse.screen is implemented):

05a3: pointer is at 2185x1142 (and mod4 is pressed)
05e5: pointer is at 2185x1142 (and mod4 is pressed)

So mouse.screen is accessed only twice.

from awesome.

Umm, that would make sense. My screen layout doesn't have a 1920x0, as I have 2 vertical screen, it should be 1920x600 (there is nothing at "0"). Then, as the client is outside of the visible area, the "manage" signal catch it and move it back to 0x600+wibox.height(19px). So the question is: why does it try to go to 1920x0

from awesome.

Here is some more debug info, a print in move_to_screen and a print in screen_getbycoord

at the end of the gists there is the backtraces of what call move_to_screen
https://gist.github.com/Elv13/4242a807f6d75852cae3

from awesome.

This issue impacts me as well with the following screen layout: https://i.imgur.com/diuI9AV.png

It makes me sad :(

from awesome.

#507 should at least improve some corner cases triggering this issue

from awesome.

Still true as of today

Xephyr :1 +xinerama -screen 1280x800+0+600 -screen 1280x800+1280+600

or

Xephyr :2 +xinerama -screen 1280x800 -screen 800x600+1280

Cause weirdness such as selecting the tag on the wrong screen when using a screen taglist widget (default config)

from awesome.

Oh, someone I missed that Xephyr supports Xinerama and that the original post in the issue mentions that it can be reproduced that way. I will try this out on the weekend.

So... I have to click around in the taglist, open a terminal via mod+Enter and the terminal will appear on the wrong screen? I'll check that.

from awesome.

If you play with strange geometry, everything will just brake down and act strangely. It happen in both "real" setup and Xephyr. The symptoms vary depending on the screen layout. Having a non y=0 first screen was making Awesome totally unusable, but any setup with different screen height/y seem to cause at least some issues.

from awesome.

First observation: Running Xephyr :1 +xinerama -screen 1280x800+0+600 -screen 1280x800+1280+600 starts an X server in which RandR sees only a single screen of size 1280x800 (so only one is visible?) while xdpyinfo shows that the root window has the expected size.
Xinerama sees {x=0 y=0 width=1280 height=800},{x=1280 y=0 width=1280 height=800};. Awesome sees the same:

return require("gears.debug").dump_return(screen[1].geometry)
   string "table: 0x1c78350
  y : 0 (number)
  x : 0 (number)
  height : 800 (number)
  width : 1280 (number)"
return require("gears.debug").dump_return(screen[2].geometry)
   string "table: 0x1bc6b10
  y : 0 (number)
  x : 1280 (number)
  height : 800 (number)
  width : 1280 (number)"

So, the y-offset doesn't seem to have any effect.

from awesome.

@Elv13 Sorry, but I don't have anything helpful to report. The bug with mouse clicks is in Xephyr.
These are the events that awesome gets when you click on the tag 1 on the taglist of the first screen:

Got button event at root 24x10, window relative 24x10 to root 0x4b7 window 0x200012 child (nil) of type 4
Got button event at root 24x10, window relative 24x10 to root 0x4b7 window 0x200012 child (nil) of type 5

And this is the mouse click for the second screen (Type 4 is mouse press, type 5 is mouse release):

Got button event at root 29x10, window relative 29x10 to root 0x4b7 window 0x200012 child (nil) of type 4
Got button event at root 29x10, window relative 29x10 to root 0x4b7 window 0x200012 child (nil) of type 5

As you see, Xephyr reports the event relative to the top-left corner of the screen that the mouse pointer is in both cases. So awesome just behaves the way it is told to. The event is even reported to the wrong window! Even though I click on different windows, the event is reported to the same window in both cases (the wibox of the first screen).

In the original post you write

With this and my real X server, then I click on the taglist of screen *, all inputs go to the other screen

Does your real server behave the same? You can try this out by running xwininfo, click on your wibox and then run xev -id THE_WINDOW_ID_THAT_XWININFO_PRINTED. That way you can test if the X server reports the events wrongly.

Edit: Just for completeness, here is the patch that I used for printing the events:

diff --git a/event.c b/event.c
index f650d52..c1f27a4 100644
--- a/event.c
+++ b/event.c
@@ -173,6 +173,11 @@ event_handle_button(xcb_button_press_event_t *ev)

     globalconf.timestamp = ev->time;

+    printf("Got button event at root %dx%d, window relative %dx%d to root %p window %p child %p of type %d\n",
+            ev->root_x, ev->root_y, ev->event_x, ev->event_y,
+            (void *) ev->root, (void *) ev->event,
+            (void *) ev->child, ev->response_type);
+
     {
         /* ev->state contains the state before the event. Compute the state
          * after the event for the mousegrabber.

from awesome.

Yes, the problem was on a real Xserver with a configuration similar to @lrvick one. But I use a laptop now, I can't test.

So, you managed to get Xephyr to work in Xinerama mode? One common mistake is to use -xinerama instead of +xinerama. The commands are tricky to get right, but Awesome should show up on both screens and clients can be drag and dropped between them.Avoid -resizeable, Awesome go boom (100% cpu usage, but who care, I blame Xephyr).

from awesome.

I copy&paste'd the command from your command. And yes, I was able to drag urxvt between screens. The above still holds: I think the bug is in the X server and not in awesome. Please test when you have the time.

from awesome.