There is something wrong with inputs

[Elv13]

Hello, I have something strange here.

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

With this and my real X server, then I click on the taglist of screen *, all inputs go to the other screen if it was selected first. So if I launch X and do ctrl+enter, it will launch the terminal on the other screen. My 3rd and 4th screens are unaffected. It happen with both the default config and mine. I use the latest gentoo packages for just about everything and never saw that before.

I also have strange errors with the default config (3.5.6 and master), but not always

W: awesome: luaA_dofunction:78: error while running function
stack traceback:
    [C]: in function 'ipairs'
    /usr/share/awesome/lib/awful/layout/init.lua:46: in function 'inc'
    /etc/xdg/awesome/rc.lua:171: in function 'press'
    /usr/share/awesome/lib/awful/button.lua:42: in function </usr/share/awesome/lib/awful/button.lua:42>
    [C]: in function 'emit_signal'
    /usr/share/awesome/lib/wibox/widget/base.lua:59: in function </usr/share/awesome/lib/wibox/widget/base.lua:27>
    (tail call): ?
    /usr/share/awesome/lib/gears/object.lua:68: in function 'emit_signal'
    /usr/share/awesome/lib/wibox/drawable.lua:279: in function </usr/share/awesome/lib/wibox/drawable.lua:273>
error: /usr/share/awesome/lib/awful/layout/init.lua:46: bad argument #1 to 'ipairs' (table expected, got number)

X -version
X.Org X Server 1.16.3
Release Date: 2014-12-20
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.18.3 x86_64 Gentoo
Current Operating System: Linux localhost 3.18.3 #5 SMP Tue Feb 10 12:18:31 2015 x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.18.3 root=/dev/sda2 rw
Build Date: 25 January 2015  06:48:17AM

Current version of pixman: 0.32.6
    Before reporting problems, check http://wiki.x.org
    to make sure that you have the latest version.

NVIDIA driver (but it happen on Xephyr too...)

I tried (and failed) to reproduce on other computers with other distros. I really have no idea (and did not look too deep beside a git bisect that show that all awesome 3.5+ versions are affected, I didn't tried older)

[Elv13]

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).

[psychon]

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.

[psychon]

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)

[psychon]

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.

[Elv13]

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

[Elv13]

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

[lrvick]

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

It makes me sad :(

[Elv13]

https://github.com/awesomeWM/awesome/pull/507 should at least improve some corner cases triggering this issue

[Elv13]

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)

[psychon]

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.

[Elv13]

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.

[psychon]

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.

[psychon]

@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.

[Elv13]

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).

[psychon]

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.