Module awful.rules (as well as ruled) seems to fail at positioning clients on the second screen.

[straightchlorine]

Output of awesome --version:

awesome v4.3 (Too long)
 • Compiled against Lua 5.3.6 (running with Lua 5.3)
 • D-Bus support: ✔
 • execinfo support: ✔
 • xcb-randr version: 1.6
 • LGI version: 0.9.2

How to reproduce the issue:

Honestly, I have no idea - the only thing that has changed was that I switched ports i.e. monitor that was plugged into the DP-2 is now plugged into DP-1 and vice versa. Along with that I have changed the config in xorg.conf.d specifying that the DP-2 monitor is on the right of the DP-1:

Option "RightOf" "DisplayPort-1" (before it was Option "LeftOf" "DisplayPort-1")

Actual result:

After that change my rule configuration stopped functioning how it's supposed to, for an instance:

 { rule = { class = "firefox" }, 
        properties = {  x = 18,  
                        y = 64,  
                        width = 1882,  
                        height = 996,  
                        screen = 2,  
                        tag = "3",  
                        floating = true } },  

Before, it would without any problems make firefox go to tag "3" on the second screen and create a floating client of a given size. Now it doesn't do anything, simply spawns on the first tag of the primary screen without any error message.

However, if I remove the screen = 2 line completely, like so:

{ rule = { class = "firefox" },
        properties = {  x = 18,
                        y = 64,
                        width = 1882,
                        height = 996,
                        tag = "3",
                        floating = true } },

All works good and spawns on the "3" tag of the primary screen. I have also tried with larger numbers, for example screen = 3 in such case i properly get an error that there is no such screen.

I have also experimented with regular bind, like this:

    awful.key({ mod, shift }, "f", function()
        awful.spawn(firefox, {
            screen = 2,
            tag = "3"
        })
    end,
    { description = "web browser", group = "applications"}),

Which, unexpectedly, works flawlessly. I also tried screen.count(), which also correctly returns number 2. In other words it seems like the screen is properly seen (i can use it after all), but for some reason awful.rules does not move clients there.

[Elv13]

For the awful.spawn part, see this. The problem is that firefox doesn't follow a protocol properly and Awesome cannot map the spawn to the window.

As for why you have issues, it might be that the rule works just fine, but Firefox moves itself milliseconds later. In AwesomeWM git-master, there is a permission you can deny to block this. In v4.3, you need to make some changes to awful.ewmh request::geometry handler. https://github.com/awesomeWM/awesome/issues/2752 https://github.com/awesomeWM/awesome/issues/2204#issuecomment-368977031

[straightchlorine]

Thank you for the help. Unfortunately nothing has changed.

I tested some solutions and decided to finally move to development version:

awesome v4.3-1533-gf8e0dfd48 (Too long)
 • Compiled against Lua 5.4.4 (running with 0.9.2)
 • API level: 4
 • D-Bus support: yes
 • xcb-errors support: yes
 • execinfo support: yes
 • xcb-randr version: 1.6
 • LGI version: /usr/share/lua/5.4/lgi/version.lua
 • Transparency enabled: yes
 • Custom search paths: no

I carefully rewrote the config and after that I have noticed that the bug persists. It is not exclusively firefox's problem, every single application that is specified by the ruled.client to run on the second screen does not work. It simply spawns on the first tag of the first screen.

I have also tested out the awful.permissions.client_geometry_requests like so:

-- Disconnect the original handler.
client.disconnect_signal('request::geometry', awful.permissions.client_geometry_requests)

It's basically copied from the documentation, for testing I put it in the callback of one of the rules.

I plan to look more into the ruled module, so I can understand why exactly does something like that happen, especially that I really haven't changed anything in the config.

[straightchlorine]

So, I've been poking around the issue and apparently it works now, honestly apart from updating some libraries nothing really changed, so I think that maybe it was because of changes in one of the libraries I have updated.

Still, I have no idea which one caused the behaviour.