Fullscreen applications doesn't work

[musjj]

Output of `awesome --version`:

awesome 4.3 (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: no
 • execinfo support: yes
 • xcb-randr version: 1.6
 • LGI version: module 'lgi.version' not found:
	no field package.preload['lgi.version']
	no file './share/lua/5.1/lgi/version.lua'
	no file './lgi/version.lua'
	no file './lgi/version/init.lua'
	no file './lib/lua/5.1/lgi/version.so'
	no file './lgi/version.so'
	no file './lib/lua/5.1/loadall.so'
	no file './lib/lua/5.1/lgi.so'
	no file './lgi.so'
	no file './lib/lua/5.1/loadall.so'
 • Transparency enabled: yes
 • Custom search paths: yes

How to reproduce the issue:

1. Set your layout mode to tile
2. Open a new terminal window, make sure that it's tiled
3. Run awesome-client <<<"client.focus.fullscreen = true"

Actual result:

Fullscreen doesn't work. If you set the window to floating mode before fullscreening, it will work just fine:

awesome-client <<<"client.focus.floating = true; client.focus.fullscreen = true"

Expected result:

Fullscreen should just work.

[maverick1872]

I'm also experiencing the same issue with the latest update. In addition to the fullscreen issue @musjj reported I'm seeing this issue with maximizing vertically & horizontally as well.

Awesome version info albeit not sure what the -dirty is about.

awesome v4.3-1609-g28381d279-dirty (Too long)
 • Compiled against Lua 5.4.6 (running with 0.9.2)
 • API level: 4
 • D-Bus support: yes
 • xcb-errors support: no
 • 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

[Aire-One]

Hello,

Can you confirm this issue also happens with the default awesomerc.lua and the Super+f keybinding.

Also, can you try

awesome-client 'client.focus and client.focus.fullscreen = true or require("naughty"). notification { text = "no focused client" }'

[musjj]

Interesting, when the user config (~/.config/awesome) doesn't exist, fullscreen works just fine. I'm not sure what could possible be the cause, since my config is still relatively small. Gonna dig through it a bit.

[musjj]

Okay, I think my mistake was that I used the wrong default config (copy-pasted from the stable documentation) as my base config. I rebuilt my config based off the awesomerc.lua from the latest commit and I no longer have this problem. Not sure what was the exact cause though.

[musjj]

Okay, I narrowed down the cause. I had this in my config:

client.connect_signal("property::floating", function(c)
  if c.floating then
    c.ontop = true
  else
    c.ontop = false
  end
end)

For some reason this caused fullscreen to not work. Am I doing something wrong here or is this a bug?

[actionless]

@musjj i having a similar problem on (only) one of my machines, the fastest one. i suspect there is some race condition in handling of client signals or states

[actionless]

btw does it happen for you only with luajit?

[maverick1872]

@actionless will test for myself later today/tomorrow. Out of curiosity I started looking at the possibility for adding a keybind that would restart awesome with the fallback config explicitly.

Are you aware if this is achievable via a keybind or not?

Edit:
Based on the current fn definition for restart I presume there is no currently exposed ability for this. Would there be interest in this?

[actionless]

i think it's not possible

i usually just renaming rc.lua in such case

you also could use awesome --replace --config flags, but that wouldn't work in my case because i'm using custom startup wrapper for WMs: https://github.com/actionless/awesome_config/blob/master/packaging/awesome_no_argb

btw i checked regarding luajit - it seems to be not the case

so, let me know regarding your cpu model, to get potentially more info

[Pikabyte]

Hey, I just started having this problem as well, but only after recently updating. Like the original issue, Fullscreen only works in floating mode. The only thing I think that changed since last time I updated that could cause the issue is this commit: 28381d2

I will build it myself before this commit and see if it works again.

[actionless]

oh, that's quite interesting - i double-checked the patch - and the fix is indeed correct, just the initial code was broken initially - it was trying to check if client is floating - and if it's not floating - block geometry request

however that check was always broken (and always passing because check (not Object1) == Object2 was never happening) - so geometry change was working

so i think the right thing would be to remove that check for floating at all, or modify maximize and fullscreen handlers to not use geometry permission

[actionless]

thanks for helping to debug @Pikabyte i found the correct fix

[Pikabyte]

oh, that's quite interesting - i double-checked the patch - and the fix is indeed correct, just the initial code was broken initially - it was trying to check if client is floating - and if it's not floating - block geometry request

however that check was always broken (and always passing because check (not Object1) == Object2 was never happening) - so geometry change was working

so i think the right thing would be to remove that check for floating at all, or modify maximize and fullscreen handlers to not use geometry permission

Yep, just tested the commit before that patch. It works fine there.

[actionless]

@Pikabyte you can also test the final code in the PR above ⬆️

[Pikabyte]

@Pikabyte you can also test the final code in the PR above ⬆️

It does seem to work!

[musjj]

I tried the patch, unfortunately it didn't work. I used the default /etc/xdg/awesome/rc.lua with this snippet embedded to the end:

client.connect_signal("property::floating", function(c)
  if c.floating then
    c.ontop = true
  else
    c.ontop = false
  end
end)

But it still didn't work. Removing the snippet made it work.

This is my hardware, if it helps:

OS: NixOS 23.11.20230812.31a86dc (Tapir) x86_64 
Host: LENOVO SHARKBAY 
Kernel: 6.1.45 
WM: awesome 
CPU: Intel i5-4430 (4) @ 3.200GHz 
GPU: NVIDIA GeForce GT 635 
Memory: 3917MiB / 15957MiB 

[actionless]

@musjj try adding print()-s to that function to debug which code branches are getting executed and which aren't to understand why it's not happening - at this point i can't reproduce it anymore, so it's all on you

[musjj]

It looks like that both branches gets executed, when you activate fullscreen. I'm not really sure why it happens though. I tried adding a guard like this:

if c.maximized then
  return
end

But both branches still gets executed.

at this point i can't reproduce it anymore

Did you try my snippet?

Looks like that this might be relavant: #2698

[musjj]

Solved it, the correct guard is:

if c.fullscreen == true then
  return
end

[actionless]

oh, apparently that's this - #2698 (comment)

you could also check c.floating itself to be either false or nil

[actionless]

Did you try my snippet?

i thought i had the same in my config, but it was slightly different when i looked for it:

https://github.com/actionless/awesome_config/blob/5c2acc231681caac4d9508fc242019683045cbc2/config/rules.lua#L92-L97

[musjj]

Right, I tried to check the values for floating more explicitly, but it didn't work out, one of the branches still gets triggered.

It looks like that messing with the client options during fullscreen can really mess things up, including freezing the WM. I had another arrange signal that changes the window border width, and I also had to add a c.fullscreen == true guard there too to avoid a freeze.

it was slightly different

Yeah, a rule won't work for my case, because I want it to apply dynamically. I think rules only apply when the window first spawned.

[actionless]

what about checking _implicitly_floating property then?

[Aire-One]

@actionless will test for myself later today/tomorrow. Out of curiosity I started looking at the possibility for adding a keybind that would restart awesome with the fallback config explicitly.

Are you aware if this is achievable via a keybind or not?

Edit: Based on the current fn definition for restart I presume there is no currently exposed ability for this. Would there be interest in this?

I use LightDM, and have multiple session to start Awesome with different parameters/config/versions.

For example, I have this config to start Awesome from my local git clone

cat /usr/share/xsessions/awesome-git.desktop
[Desktop Entry]
Name=awesome-git
Comment=Highly configurable framework window manager
TryExec=awesome
Exec=/home/aireone/documents/prog/awesome/build/awesome --search /home/aireone/documents/prog/awesome/build/lib --config /home/aireone/documents/prog/awesome/awesomerc.lua
Type=Application

[maverick1872]

@actionless will test for myself later today/tomorrow. Out of curiosity I started looking at the possibility for adding a keybind that would restart awesome with the fallback config explicitly.
Are you aware if this is achievable via a keybind or not?
Edit: Based on the current fn definition for restart I presume there is no currently exposed ability for this. Would there be interest in this?

I use LightDM, and have multiple session to start Awesome with different parameters/config/versions.

For example, I have this config to start Awesome from my local git clone

cat /usr/share/xsessions/awesome-git.desktop
[Desktop Entry]
Name=awesome-git
Comment=Highly configurable framework window manager
TryExec=awesome
Exec=/home/aireone/documents/prog/awesome/build/awesome --search /home/aireone/documents/prog/awesome/build/lib --config /home/aireone/documents/prog/awesome/awesomerc.lua
Type=Application

Yea that's one manner of doing it but requires a logout/login. Which is what I was trying to avoid. Ended up just defining a pretty simple shell alias to ease the process without relogging myself.

swap-awesome-config() {
  swap ~/.config/awesome/rc.lua ~/.config/awesome/rc.lua.inactive
  echo 'awesome.restart()' | awesome-client
}

[actionless]

damn it, stop mentioning me when quoting