Open kode54 opened 1 month ago
kode54
commented
1 month ago I added more. It depends on the display that's 2.0 scale being turned off and disconnecting momentarily. It also depends on Kanshi being set to scale the output to 2.0 when it reconnects.
johanmalm
commented
1 month ago Oh dear. Looks bad. It'd be useful to know:
labwc -C /dev/null)labwc -d?kode54
commented
1 month ago Cannot reproduce on sway-git and wlroots-git. Not even if I manually set sway's output to 3840x2160 scale 1.0 and load kanshi to override it like I do with labwc. On to step 2.
kode54
commented
1 month ago Step 2. I cannot reproduce it on an empty config, until I use wlr-randr to change DP-1's scale to 2.0. The default desktop layout has DP-1 to the right of DP-2, even though they are physically the opposite positions. Adjusting the scale causes Firefox to jump to DP-2 and stay there. Moving it back to the "right" side of DP-2, it goes haywire as long as most of it is on DP-1 and the top left corner of the window is off the edge of the screen, or overlapped by another window.
Edit: My bad, it defaults to DP-1 on the left, DP-2 on the right. Adjusting DP-1's scale dumps DP-2 on the left, presumably because its position was staying at 1920,0.
On to step 3.
kode54
commented
1 month ago Okay, wlr-randr setting DP-1 to scale 2.0, DP-2 ends up at 3840,0 and DP-1 ends up at 5760,0.
Here's the log:
As the subject says, Firefox Wayland mode does bad things, at least on AMDGPU, in the following scenario:
1) Start labwc 2) kanshi configures primary output to scale 2.0 3) Firefox is started on display 4) kanshi reconfigures display scale, or Firefox is moved to a different 1.0 display and back again 5) kanshi reconfigures display scale back to 2.0 6) An overlapping Wayland window is placed over the top left rounded corner of the title bar 7) Firefox starts going crazy and flashing at 1.0/2.0 scale rapidly, sometimes losing window elements in the SSD