Clients with fullscreen hint does not open in fullscreen

[akinokonomi]

Output of awesome --version:

awesome v4.3-1606-g0e5fc4575-dirty (Too long)
 • Compiled against Lua 5.1.4 (running with LuaJIT 2.1.0-beta3)
 • API level: 4
 • D-Bus support: yes
 • xcb-errors support: yes
 • execinfo support: yes
 • xcb-randr version: 1.6
 • LGI version: 0.9.2
 • Transparency enabled: yes
 • Custom search paths: no

Also tested with Lua 5.4.6

Default config

How to reproduce the issue:

The following command starts client in floating mode, instead of fullscreen:
(I also experience this with some Wine applications)

> mpv --fullscreen --player-operation-mode=pseudo-gui --pause

Though xprop output shows fullscreen state:

> xprop _NET_WM_STATE
_NET_WM_STATE(ATOM) = _NET_WM_STATE_FULLSCREEN

Even with following awesome rule, mpv does not open in fullscreen as long as I start it with --fullscreen argument:

ruled.client.append_rule {
  id       = "mpv_fullscreen",
  rule_any = {
    class = { "mpv" },
  },
  properties = { fullscreen = true }
}

I found similar report #2173, but in my case application is not stuck anywhere, it also has proper borders, etc., it just starts floating.

I guess there are other, though. Sorry if it's a duplicate.

Actual result:

Client starts floating.

Expected result:

Client open in fullscreen.

---

As a workaround, following rule fixed the problem for me:

ruled.client.append_rule {
  id         = "ewmh_fix_fullscreen_state",
  rule       = { },
  callback   = function(c)
    if c.fullscreen then
      c.fullscreen = false
      c.fullscreen = true
    end
  end
}

[Aire-One]

Hello @akinokonomi,

Do you have some configurations/rules that could be interfering? Can you try again with the default awesomerc.lua?

I have just downloaded a random youtube video and tried your command mpv --fullscreen --player-operation-mode=pseudo-gui --pause Zig\ in\ 100\ Seconds\ \[kxT8-C1vmd4\].webm. It works as expected, the video opens in fullscreen mode.

[akinokonomi]

Hi!

Do you have some configurations/rules that could be interfering? Can you try again with the default awesomerc.lua?
Can you try again with the default awesomerc.lua?

Nope. I've mentioned it, but I've already tested it with the default config (default rules). It's still the same.

I've also tested it as cleanly as possible, with all env variables unset, etc.

It works as expected, the video opens in fullscreen mode.

Thank you very much for testing it yourself.

I see. Maybe it's due to changes in dependencies?

Here is part from the build log

log

CMake Deprecation Warning at CMakeLists.txt:1 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


-- The C compiler identification is GNU 13.2.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
CMake Deprecation Warning at CMakeLists.txt:21 (cmake_policy):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.


-- lua -> /usr/bin/lua5.4
-- git -> /usr/bin/git
-- asciidoctor -> /usr/bin/asciidoctor
-- gzip -> /usr/bin/gzip
-- ldoc -> /usr/bin/ldoc
-- convert -> /usr/bin/convert
-- Found PkgConfig: /usr/bin/pkg-config (found version "1.8.1")
-- Found Lua: /usr/lib/liblua.so.5.4;/usr/lib/libm.so (found version "5.4.6")
-- Using version from git: v4.3-1606-g0e5fc4575
-- Checking for module 'xcb>=1.6'
--   Found xcb, version 1.15
-- Checking for modules 'glib-2.0;glib-2.0>=2.40;gdk-pixbuf-2.0;cairo;x11;xcb-cursor;xcb-randr;xcb-xtest;xcb-xinerama;xcb-shape;xcb-util;xcb-util>=0.3.8;xcb-keysyms;xcb-keysyms>=0.3.4;xcb-icccm;xcb-icccm>=0.3.8;xcb-xfixes;xcb-xkb;xkbcommon;xkbcommon-x11;cairo-xcb;libstartup-notification-1.0;libstartup-notification-1.0>=0.10;xproto;xproto>=7.0.15;libxdg-basedir;libxdg-basedir>=1.0.0;xcb-xrm'
--   Found glib-2.0, version 2.76.4
--   Found glib-2.0, version 2.76.4
--   Found gdk-pixbuf-2.0, version 2.42.10
--   Found cairo, version 1.17.8
--   Found x11, version 1.8.6
--   Found xcb-cursor, version 0.1.4
--   Found xcb-randr, version 1.15
--   Found xcb-xtest, version 1.15
--   Found xcb-xinerama, version 1.15
--   Found xcb-shape, version 1.15
--   Found xcb-util, version 0.4.1
--   Found xcb-util, version 0.4.1
--   Found xcb-keysyms, version 0.4.1
--   Found xcb-keysyms, version 0.4.1
--   Found xcb-icccm, version 0.4.2
--   Found xcb-icccm, version 0.4.2
--   Found xcb-xfixes, version 1.15
--   Found xcb-xkb, version 1.15
--   Found xkbcommon, version 1.5.0
--   Found xkbcommon-x11, version 1.5.0
--   Found cairo-xcb, version 1.17.8
--   Found libstartup-notification-1.0, version 0.12
--   Found libstartup-notification-1.0, version 0.12
--   Found xproto, version 7.0.33
--   Found xproto, version 7.0.33
--   Found libxdg-basedir, version 1.2.3
--   Found libxdg-basedir, version 1.2.3
--   Found xcb-xrm, version 1.3
-- Looking for backtrace_symbols
-- Looking for backtrace_symbols - found
-- checking for execinfo -- found
-- Looking for round
-- Looking for round - not found
-- Looking for round
-- Looking for round - found
-- checking for round -- in libm
-- Checking for module 'dbus-1'
--   Found dbus-1, version 1.14.8
-- Checking for module 'xcb-errors'
--   Found xcb-errors, version 1.0.1
CMake Deprecation Warning at tests/examples/CMakeLists.txt:17 (cmake_minimum_required):
  Compatibility with CMake < 3.5 will be removed from a future version of
  CMake.

  Update the VERSION argument <min> value or use a ...<max> suffix to tell
  CMake that the project does not need compatibility with older versions.
Call Stack (most recent call first):
  awesomeConfig.cmake:307 (include)
  CMakeLists.txt:33 (include)


-- busted not found.
-- luacheck not found.
-- Checking if 'package' target should be generated.
-- rpmbuild not found.
-- The 'package' target will not build a RPM.
-- dpkg not found.
-- The 'package' target will not build a DEB.
-- Skipping generation of 'package' target.
-- Configuring done (1.9s)
-- Generating done (0.4s)

Or perhaps it's something else entirely.

[actionless]

the build log a bit weird, but i don't think it's related. however more weird looks that you building awesome with lua 5.4 but running with luajit - but again it doesn't seems related to this particular issue. see here for tested example of working luajit build commands: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=awesome-luajit-git

so, aside from testing with default awesome config, please also try running mpv itself with default config and without any extra user-scripts

[akinokonomi]

however more weird looks that you building awesome with lua 5.4 but running with luajit

@actionless, Sorry for the confusion. It's because I specifically rebuilt it with lua 5.4.

I already mentioned, but though awesome --version is from luajit build, I also tested it with lua 5.4.6, to see if it's related to luajit.

please also try running mpv itself with default config and without any extra user-scripts

Yeah, I did that, nothing changed.

Again, mpv is just an example, it happens with some other applications too.
I've mostly seen it happen with wine applications, but it also happens with mcomix --fullscreen ...

Though there are also many applications where fullscreen works fine, like vlc --fullscreen ..., totem --fullscreen ..., smplayer -fullscreen ..., chromium --start-fullscreen.

[actionless]

I found similar report #2173, but in my case application is not stuck anywhere, it also has proper borders, etc., it just starts floating.

it starts floating even if you're on tiling layout?

do you have 1 or more displays?

[actionless]

there is some weird bug sometimes similar to your problem - when starting an app for the first time - sometimes it have such behavior and hitting mod+m twice usually fixing it once for ever - i dunno about the details since it happens very ocasionally and hard to reproduce, but mb it's your case actually

[akinokonomi]

it starts floating even if you're on tiling layout?

Yeah, that's right.
In tasklist, it displays value from var theme.tasklist_floating = "value", but I can't actually move it like other floating clients.
It behaves more or less like maximized client.

(Sorry, I forgot to explain that.)

do you have 1 or more displays?

One.

there is some weird bug sometimes similar to your problem - when starting an app for the first time - sometimes it have such behavior and hitting mod+m twice usually fixing it once for ever

Sounds very similar, but hitting mod+f twice fixes it until I start it again.

since it happens very ocasionally and hard to reproduce

In my case, it happens every single time I start the application.

[Aire-One]

I wrote this first study case:

diff --git a/tests/_client.lua b/tests/_client.lua
index 3eb015f31..d29bfc8ff 100644
--- a/tests/_client.lua
+++ b/tests/_client.lua
@@ -13,7 +13,7 @@ local test_client_source = [[
pcall(require, 'luarocks.loader')
local lgi  = require 'lgi'
local GLib = lgi.require('GLib')
-local Gdk  = lgi.require('Gdk')
+local Gdk  = lgi.require('Gdk', '3.0')
local Gtk  = lgi.require('Gtk', '3.0')
local Gio  = lgi.require('Gio')
Gtk.init()
@@ -65,6 +65,9 @@ local function open_window(class, title, options)
           tonumber(options.resize_after_width), tonumber(options.resize_after_height)
       )
    end
+    if options.fullscreen then
+        window:fullscreen()
+    end
end

local function parse_options(options)
@@ -218,6 +221,10 @@ local function new(_, class, title, sn_rules, callback, resize_increment, args)
        options = options .. "gravity=" .. args.gravity .. ","
    end

+    if args.fullscreen then
+        options = options .. "fullscreen,"
+    end
+
    local data = class .. "\n" .. title .. "\n" .. options .. "\n"
    local success, msg = pipe:write_all(data)
    assert(success, tostring(msg))
diff --git a/tests/test-mpv-fullscreen.lua b/tests/test-mpv-fullscreen.lua
new file mode 100644
index 000000000..7366566fe
--- /dev/null
+++ b/tests/test-mpv-fullscreen.lua
@@ -0,0 +1,40 @@
+local runner = require "_runner"
+-- local test_client = require "_client"
+local spawn = require "awful.spawn"
+
+local c = nil
+
+runner.run_steps {
+    -- Spawns the a client
+    function(count)
+        if count == 1 then
+            -- test_client(nil, nil, nil, nil, nil, {
+            --     fullscreen = true,
+            -- })
+            spawn("mpv --fullscreen --player-operation-mode=pseudo-gui --pause '/home/aireone/downloads/Zig in 100 Seconds [kxT8-C1vmd4].webm'")
+        end
+        c = client.get()[1]
+        return c
+    end,
+    -- Test the client is fullscreen
+    function()
+        print(c.x, c.y, c.width, c.height, c.fullscreen, c.floating, c.maximized, c.maximized_horizontal, c.maximized_vertical)
+        assert(c.fullscreen)
+        local s = screen.primary.geometry
+        print(s.x, s.y, s.width, s.height)
+        assert(
+            c.x == s.x
+                and c.y == s.y
+                and c.width == s.width
+                and c.height == s.height
+        )
+        return true
+    end,
+    -- Clean up
+    function()
+        c:kill()
+        return true
+    end,
+}
+
+-- vim: filetype=lua:expandtab:shiftwidth=4:tabstop=8:softtabstop=4:textwidth=80

Working with a GTK window was actually a solid success. So I tried my luck by invoking mpv and got the following fail:

$ ~/documents/prog/awesome/tests > ./run.sh test-mpv-fullscreen.lua 
awesome v4.3-1606-g0e5fc4575-dirty (Too long)
 • Compiled against Lua 5.4.6 (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
awesome_log: /tmp/tmp.cR7ad3ktUU/_awesome_test.log
== Running test-mpv-fullscreen.lua ==

Fontconfig error: No writable cache directories
Fontconfig error: No writable cache directories
vulkan: No DRI3 support detected - required for presentation
Note: you can probably enable DRI3 in your Xorg config
vulkan: No DRI3 support detected - required for presentation
Note: you can probably enable DRI3 in your Xorg config
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory
Fontconfig error: No writable cache directories
0       18      1024    786     true   true    false   false   false
0       0       1024    768
Error: running function for step 2/4 (@1): ...one/documents/prog/awesome/tests/test-mpv-fullscreen.lua:25: assertion failed!
stack traceback:
        [C]: in function 'assert'
        ...one/documents/prog/awesome/tests/test-mpv-fullscreen.lua:25: in function <...one/documents/prog/awesome/tests/test-mpv-fullscreen.lua:20>
        (...tail calls...)
        [C]: in function 'xpcall'
        /home/aireone/documents/prog/awesome/tests/_runner.lua:110: in function </home/aireone/documents/prog/awesome/tests/_runner.lua:101>
        [C]: in function 'xpcall'
        lib/gears/protected_call.lua:41: in function <lib/gears/protected_call.lua:40>
        (...tail calls...)
        lib/gears/timer.lua:280: in function 'gears.timer.run_delayed_calls_now'!
NOTE: there were 1 clients left after the test.

===> ERROR running /home/aireone/documents/prog/awesome/tests/test-mpv-fullscreen.lua <===
Fontconfig error: No writable cache directories
Fontconfig error: No writable cache directories
Fontconfig error: No writable cache directories
Error: running function for step 2/4 (@1): ...one/documents/prog/awesome/tests/test-mpv-fullscreen.lua:25: assertion failed!

1 tests finished.

There were 1 errors:
 - /home/aireone/documents/prog/awesome/tests/test-mpv-fullscreen.lua: Fontconfig error: No writable cache directories
Fontconfig error: No writable cache directories
Fontconfig error: No writable cache directories
Error: running function for step 2/4 (@1): ...one/documents/prog/awesome/tests/test-mpv-fullscreen.lua:25: assertion failed!

MPV starts as both fullscreen and floating. It is placed with a Y margin of 18, probably to be after the wibar. Which is not normal for a fullscreen client. (Strangely, this behavior doesn't happen when I start a session from the default awesomerc.lua and launch mpv from a terminal [1])

The next step for me will be to find out what MPV does to fullscreen the client. And why Awesome seems to not pick it up correctly.

[1] : Just before sending the message, I altered the test a bit to spawn a client first, then the MPV --fullscreen. The MPV client always have the correct place/sizes/blabla. So it seems the fullscreen behavior depends on whether there is already a client or not.

[actionless]

it seems this issue reproduces only on certain hardware - i have 2 systems with intel+nvidia where i can't reproduce it, and can reproduce it on pure amd setup - or the difference might be even in cpu speed or certain optimizations

@akinokonomi which cpu, gpu and gpu driver do you have?

[akinokonomi]

I have intel and nvidia.

As for software, I've been having this issue for some time, so it can't be a problem with this specific version, but it's latest nvidia 535.98.

Just in case, I tried starting awesome with and without --no-argb, and it does seem to be relevant.

FWIW there is no such problem with openbox + lxpanel.

[actionless]

and it does seem to be relevant.

what do you mean by that, it works alright with --no-argb?

[akinokonomi]

and it does seem to be relevant.

what do you mean by that, it works alright with --no-argb?

No, I mean it does not change anything.

---

I've just rebuilt on latest commit 28381d2 (and luajit 2.1.1692616192) vs 0e5fc45, and for some reason it behaves differently now.

TLDR It's still broken, but even more than before.

When opening mpv --fullscreen, on tiling layout, client opens marked as floating, looks like maximized, I still can't move it like a normal floating client, and it still has no borders and titlebar--this, same as before.

Now, there are few things that are a bit different:

When starting mpv --fullscreen --autofit-larger=50%x50% on tiling layout, it starts way smaller, in the middle of the screen, and does not like maximized anymore, but still marked as "floating", and still can't be moved.
Starting it the same way but on floating layout, opens it like it used to on 0e5fc45.

Before, on 0e5fc45, with that option, it opened stretched on whole screen, except for panel, looking like "maximized" on tiling and floating layouts alike.

Now mcomix --fullscreen.
On tiling layout, client spawns in a position where next tiling client should (not in the middle screen like mpv), and the size of the next floating client too (not stretched on whole screen, except for panel).
It's marked as floating, and still cannot be moved as normal floating client.

Starting it on floating layout, I did not notice any difference from before, it starts marked as floating, looking like maximized (not covering the panel).

On 0e5fc45, it'd start looking like maximized on tiling layout too.

Hope I explained it well.

I did not test it with the default awesome config, though.

EDIT: but mpv tested with the default config.

[actionless]

what exact cpu do you have? i have a theory that if it's too fast, some certain code in ewmh/client state handling getting a race condition

[actionless]

also, getting back to the topic of unexpected optimizations - have you tried with lua instead of luajit?

[akinokonomi]

and it does seem to be relevant.

what do you mean by that, it works alright with --no-argb?

@actionless Ohhh, I'm very sorry, it was a typo, I meant it does not seem to be relevant.

[akinokonomi]

what exact cpu do you have? i have a theory that if it's too fast, some certain code in ewmh/client state handling getting a race condition

Just checked, it's Intel Core i3-6100 min/max: 800/3700 MHz

also, getting back to the topic of unexpected optimizations - have you tried with lua instead of luajit?

I tried with Lua before, but not with latest awesome commit.

[actionless]

i've already checked earlier today - luajit or lua doesn't make a difference

3700 MHz

probably cpu clock speed is not the case neither (i can't reproduce the problem on machine with 3500mhz speed, but can on machine with 4600, still could be marginal enough for some particular race to happen, but let's skip this possibility for now)

and which driver do you use, nvidia or nouveau?

[akinokonomi]

and which driver do you use, nvidia or nouveau?

It's proprietary nvidia 535.98

[actionless]

It's proprietary nvidia 535.98

apparently that's not the case neither - on machines on which i can't reproduce the problem - i also have proprietary nvidia, and on machine on which it happens for me - i have opensource radeon driver

[akinokonomi]

73fad77

It does not fix the initial issue for me, but it does revert new problems with tiled layout I had on 28381d2.
Now it's like it used to be before, on 0e5fc45

[actionless]

I've also tested it as cleanly as possible, with all env variables unset, etc.

and could you reproduce the problem inside a VM?

i thought before your problem related to that aforementioned fullscreen issue, but since not - it must be smth really corner case related to your specific configuration, and test on VM would be a good way to investigate what makes your setup special

the fastest way to get inside vm would be to get live-cd with majaro and install awesome-git from aur

[akinokonomi]

and could you reproduce the problem inside a VM?

I thought about doing that from the beginning, yeah, but it's just too bothersome.

I'm sorry. Maybe at some later point.

The workaround I mentioned #3834 (comment) is more than enough for me.

But thank you for spending so much time trying to figure it out. I appreciate your help!