Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Regression in dynamic buffer scale changes #1559

Closed
chrisduerr opened this issue Oct 7, 2024 · 4 comments · Fixed by #1565
Closed

Regression in dynamic buffer scale changes #1559

chrisduerr opened this issue Oct 7, 2024 · 4 comments · Fixed by #1565

Comments

@chrisduerr
Copy link
Contributor

Introduction of 9a7afcf has broken the ability to manually set the preferred buffer scale for my surfaces. If I change a surface from scale 2 to 1, then back to 2, it will stay at 1 forever.

chrisduerr added a commit to catacombing/catacomb that referenced this issue Oct 7, 2024
This fixes an issue where changing the buffer scale from 2 to 1, would
permanently lock the scale to 1 even after the buffer scale was changed
to 2 again.

See Smithay/smithay#1559.
@chrisduerr
Copy link
Contributor Author

@Drakulix I'd appreciate some feedback on whether this is intentional or if it's an unintended regression. No point looking into a fix if it doesn't want to be fixed.

@Drakulix
Copy link
Member

Drakulix commented Oct 8, 2024

Yes I do consider this a regression. Said commit introduces another layer of scaling, but doesn't replace what was already there. The preferred buffer scale should still work the same, I am personally a bit baffled how exactly this broke, just looking at the code.

@YaLTeR
Copy link
Contributor

YaLTeR commented Oct 20, 2024

9a7afcf also breaks wl_output scale updates to clients. You can test in anvil by running

env WAYLAND_DEBUG=1 gtk4-demo 2>| grep -E 'wl_output.*scale'

then pressing Super+Shift+P to "scale up". The window should get wl_output.scale(2) but starting from that commit it keeps getting wl_output.scale(1).

@chrisduerr
Copy link
Contributor Author

I've tested it just to confirm and #1565 definitely did fix this issue.

chrisduerr added a commit to catacombing/catacomb that referenced this issue Oct 22, 2024
This patch updates all dependencies, including a bump of Smithay back to
the upstream master now that Smithay/smithay#1559 is fixed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants