Closed lukasbash closed 5 years ago
How many screens do you have, can you give the relevant xrandr output? How were the screens configured?
@Elv13
I have just one screen (it is my notebook).
xrandr
outputs:
Screen 0: minimum 8 x 8, current 1920 x 1080, maximum 32767 x 32767
eDP1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 290mm x 170mm
1920x1080 60.00*+ 59.93 48.00
1680x1050 59.88
1400x1050 59.98
1600x900 60.00 59.95 59.82
1280x1024 60.02
1400x900 59.96 59.88
1280x960 60.00
1368x768 60.00 59.88 59.85
1280x800 59.81 59.91
1280x720 59.86 60.00 59.74
1024x768 60.00
1024x576 60.00 59.90 59.82
960x540 60.00 59.63 59.82
800x600 60.32 56.25
864x486 60.00 59.92 59.57
640x480 59.94
720x405 59.51 60.00 58.99
640x360 59.84 59.32 60.00
DP1 disconnected (normal left inverted right x axis y axis)
DP2 disconnected (normal left inverted right x axis y axis)
VIRTUAL1 disconnected (normal left inverted right x axis y axis)
What do you mean how the screens were configured? I did not start with plain xorg. As I still have gnome installed, they might be configured through the gnome shell. (I am also launching awesome through GDM). Or do you refer to any specific configuration?
Update: It seems that it is related to the layoutbox at the bottom bar. If I remove the layoutbox from the bar, there seems to be no issue.
How could it be?
-- Add widgets to the bottom wibox
s.mybottomwibox:setup {
layout = wibox.layout.align.horizontal,
{ -- Left widgets
layout = wibox.layout.fixed.horizontal,
},
s.mytasklist, -- Middle widget
{ -- Right widgets
layout = wibox.layout.fixed.horizontal,
-- If line below is commented, there seems to be no issue
-- s.mylayoutbox,
},
}
Similar symptom: #2470
Wow, it used to happen often back in Awesome 3.4 days (10 years ago) and it was a driver issue (and usually had some pink artifact for some reasons), but before #2470 and this I havn't heard of a corrupted surface bug in a long time.
When it happen, can you try to call awesome-client "mouse.screen.mybottomwibox.draw()"
(and/or awesome-client 'mouse.screen.mybottomwibox._drawable._do_complete_repaint()'
) and see what happen?
wasn't it id-related problem? (in related ticket, not in 3.4)
Thank you for all the responses so far!
@Elv13
I tried to execute the two lines you posted.
awesome-client "mouse.screen.mybottomwibox.draw()"
actually did nothing.
awesome-client 'mouse.screen.mybottomwibox._drawable._do_complete_repaint()'
fixed the bottom bar again.
What does this mean now?
That it's a duplicate of #2470. The surface gets corrupted with precisely the content of another surface with no artifacts, which is a red flag in itself. Can you try with git-master? It's weird because if it was really an awesome bug, why did it take more than a year to show up in a stable release... Also that code is like from 2011 so saying it has been battle tested would be an understatement.
May I ask for a "fun" experiment. Can you make one of the 2 bar taller than the other and reproduce the problem. If they both get rendered correctly (correct height) then it means Awesome paints the wrong layout on the surface. It would rule out driver issues.
@Elv13 Your "fun" experiment leads to the following result:
So the issue is only gone when I use double the size of the bottom bar. Increasing or decreasing with lower numbers does not do anything. Sounds very weird.
I will not try to install it from git master. Question to this: Is the package receipt still valid for arch linux? The package seems to be outdated. Should I checkout the repo or can I use the AUR?
Random data point: Both #2470 and this issue are with Lua 5.3 (but 5.3.4 vs 5.3.5).
The package seems to be outdated. Should I checkout the repo or can I use the AUR?
Why does it seem to be outdated? The AUR package looks fine to me.
Randomly switch between empty workspaces with keybindings.
Looking at the config: In the top wibar, this updates the taglist. This causes a relayout and also a redraw (at least two of the taglist widgets change their background). There are also lots of other widgets in there that I did not look at... The bottom wibar only has a tasklist and a layoutbox. The tasklist does a delayed update and the layoutbox does an immediate update. Thus, I guess there will actually be two redraws, one for the layoutbox and then later for the tasklist.
The "broken" screenshot shows that the layoutbox is drawn ontop of the contents of the upper wibar, so the "copying of contents" must happen before the layoutbox is drawn...
Apropos copying: I do not think that a tag change should cause a complete repaint; only the changed parts are redrawn. Thus, if this were just painting to the wrong surface, I'd only expect a partial copy of the top wibar.
It seems that it is related to the layoutbox at the bottom bar. If I remove the layoutbox from the bar, there seems to be no issue.
So... given that the layoutbox is ontop of the content of the top wibar.... I don't know. The layoutbox is also only shown in one of the wibars, so this cannot be something due to the widget appearing twice.
Setting the bottom bar to height 22 instead of 24 -> issue still persists Setting the bottom bar to height 26 instead of 24 -> issue still persists Setting the bottom bar to height 12 instead of 24 -> issue still persists
How does the result look like? E.g. if the bottom bar has height 26, is the copy of the top bar drawn with height 24 or 26? And with height 12, is it cut of or "scaled"?
@psychon
Why does it seem to be outdated? The AUR package looks fine to me.
I was just curious because the package has not been updated since more than a year. No dependency, nothing. That's why I was asking. Also the package details show a lower version than I have actually installed.
It shows awesome-git 4.0.225.gd6412b96-1
The result of the height changes looks like this: Height 26 (instead of 24):
Height 12 (instead of 24):
So it actually seems it is not "scaled" but drawn with its original height (top bar copy).
Can you try with https://aur.archlinux.org/packages/awesome-luajit-git/
Now we know much more.
The next test will use a different Lua version, so we will know if it is related to the Lua version or the LGI binding Lua version. That will narrow the possibilities.
Why does it seem to be outdated? The AUR package looks fine to me.
I was just curious because [...]
The PKGBUILD contains source=("$pkgname::git+https://github.com/awesomeWM/awesome.git")
, so it will build from git. I'm no expert, but I don't see anything in there forcing a specific git hash. I guess they just have to provide some pkgver
for AUR.
So it actually seems it is not "scaled" but drawn with its original height (top bar copy).
Wow. If this would persist, I had an idea on what kind of "memory corruption" could cause this. But for just a single draw... I'm confused.
Another random idea: Does running awesome with --no-argb
make the issue go away as well?
[If yes: This points fingers at the X11 server / video driver]
So I used https://aur.archlinux.org/packages/awesome-git to install it.
To be precise, here you have another version output:
awesome v4.2-598-g8fe06f95 (Human after all)
• Compiled against Lua 5.3.5 (running with Lua 5.3)
• D-Bus support: ✔
• execinfo support: ✔
• xcb-randr version: 1.6
• LGI version: 0.9.2
Unfortunately the issue still persists. See:
Should I still try to use https://aur.archlinux.org/packages/awesome-luajit-git/ ?
EDIT: Issue reproducible also with https://aur.archlinux.org/packages/awesome-luajit-git/
@Elv13 @psychon
LOL what a guess!!
Another random idea: Does running awesome with --no-argb make the issue go away as well?
Yes it indeed goes away. What the heck is happening here? XD
(But as I am launching awesome from GDM I would like to avoid passing this argument as I would have to login from another TTY.)
Is there a fix necessary in awesome itself? Or did I configure something wrong on X?
(But as I am launching awesome from GDM I would like to avoid passing this argument as I would have to login from another TTY.)
Personally, I have some hack in /usr/share/xsessions/own-awesome-session.desktop
:
[Desktop Entry]
Name=awesomeSession
Exec=/home/psychon/bin/awesome-session
Type=XSession
I use this to also start some other stuff (e.g. compton) when I log in. You could do something similar with a shell script that simply does exec awesome --no-argb
.
Is there a fix necessary in awesome itself? Or did I configure something wrong on X?
No and no.
Things are complicated. But --no-argb
does not really change anything in awesome. The only difference is that awesome now creates all its windows with 32 bits per pixel (alpha/red/green/blue) instead of 24 bits per pixel (red/green/blue). Also, awesome tells cairo about this difference and cairo handles all the actual differences in drawing things for us.
Without an (unused) alpha channel, true transparency does not work, but that requires running a compositing manager like compton anyway to work. The plus side of having this is that awesome "behaves more" like most other window managers in that it creates 24 bpp windows. Apparently, the 32bpp code in Xorg still has some problems and gets random things wrong (although I haven't heard about a problem like this before).
Does this clear things up for you or should I bore you with more technical details?
On what happens next: I don't know. I'm 99.8% sure that the issue is not in awesome itself. Also, I'm 99.5% sure that I won't be able to figure out a bug in Xorg that I cannot even reproduce, so I guess this bug will just linger around forever until the Xorg people accidentally fix this bug. I don't even think that this is worth reporting upstream, because instructions like "install this, put this file here, and then do these steps 10 times and hope that the issue shows up" are scary and already sound time-intensive. And even then one would need a good idea on how to debug this.
Sorry.
Personally, I have some hack [...]
I guess I have no other choice to also get this kind of workaround in place.
Apparently, the 32bpp code in Xorg still has some problems and gets random things wrong [...]
Can you control whether awesome creates windows/drawings in 32bpp or 24bpp? Wouldn't it make sense then to not use the alpha channel at all? Or is it automatic if the --no-argb
flag is/is not passed?
[...] so I guess this bug will just linger around forever until the Xorg people accidentally fix this [...]
That's so sad. But I absolutely understand you. Maybe at some point they fix it. Maybe at some point it turns out that the issue is actually caused by awesome. You never know.
Sorry.
Really thank you for the efforts to debug and trace this with me. No need to say sorry at all. If you need any more information, help or steps to reproduce and fix this issue, just ping me.
For now, to resolve this issue, I will either create my own session entry and pass the --no-argb
flag, or I will just remove the bottom bar.
Can you control whether awesome creates windows/drawings in 32bpp or 24bpp? Wouldn't it make sense then to not use the alpha channel at all? Or is it automatic if the --no-argb flag is/is not passed?
All Awesome API widgets (bars, titlebars, notification, etc) support transparency. There is no real way to detect if the user theme has transparency. Nor if it will have in the future. The only thing that could be done is using 24bpp when there is no compositing then reloading all surfaces with 32bpp, including reparenting all clients, when a compositor shows up. This would be more complex and probably would cause more bugs, not less. ARGB surfaces are officially supported by Xorg. If they don't work, then its the driver developer problem to fix it. Please note that some web browser have an explicit blacklist of open source drivers because of related issues. We wont start to keep that kind of version per version blacklist of all drivers. They release much more often than us anyway.
But that would mean, that if I actively use the alpha channel or transparency in my bars it could be that it suddenly works right? Maybe I should give it a try (also with a running composition manager maybe).
Still I am curious if this does not happen in other places as well (and other window managers or desktop environments)...
Hello again guys,
I told you that I will get back to you :laughing: I think we should close the issue. The issue was resolved for me by using a composition manager. Even without using the argb flag on session start.
Thank you guys for the help!
Output of
awesome --version
:awesome v4.2 (Human after all) • Compiled against Lua 5.3.5 (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:
Randomly switch between empty workspaces with keybindings. NOTE: There must be at least one non-empty tag!
Actual result:
At some point the top panel is duplicated to the bottom panel (even though no keys are working on the bottom panel then and on the top they are).
Expected result:
The bottom panel should not be inferred in any way by the top panel.
Notes: I used the
multiclor
theme from awesome-copycats. Here my rc.lua:And the theme file: