Skip to content

Conversation

guidocella
Copy link
Contributor

With 90° or 270° output rotations, make width and height in --geometry and --autofit* options refer to the dimensions after the rotation.

e.g. --geometry=100%x100% will fill the screen instead of going beyond it.

Not tested on multiple monitors.
Docs say to use wl_surface.preferred_buffer_transform, but that is received after the window is already created.

With 90° or 270° output rotations, make width and height in --geometry
and --autofit* options refer to the dimensions after the rotation.

e.g. --geometry=100%x100% will fill the screen instead of going beyond
it.
Copy link

@mahkoh
Copy link
Contributor

mahkoh commented Oct 10, 2025

The order of events is unspecified.

However, mpv should in any case not use the mode since applications might not actually be able to expand to the entire mode when fractional scaling is used. If necessary, it should use the xdg_output dimensions (which already account for the output transform) and the fractional scale to calculate the maximum size in physical pixels.

@guidocella
Copy link
Contributor Author

I don't understand how the maximum size lets us know if the output is rotated? --geometry=100%x100% is just an example, you can have e.g. --geometry=50%x100% and currently 50% is applied to the wrong dimension when the output is rotated.

@mahkoh
Copy link
Contributor

mahkoh commented Oct 10, 2025

There is no need to know if the output is rotated if you don't use the mode.

@guidocella
Copy link
Contributor Author

Ok, so you mean to also replace the existing code getting the position and dimensions from the mode. However https://wayland.app/protocols/xdg-output-unstable-v1 is still unstable so I don't know if we should support both ways or wait for it to become stable.

@mahkoh
Copy link
Contributor

mahkoh commented Oct 10, 2025

All wayland protocols are stable. As far as xdg_output is concerned, applications should not use it and neither should they use wl_output. But xdg_output is slightly less bad for this usecase.

@kasper93 kasper93 added this to the Release v0.41.0 milestone Oct 10, 2025
@guidocella
Copy link
Contributor Author

Well at least gamescope doesn't support xdg_output according to that page and it can be used for HDR passthrough with mpv.

@llyyr
Copy link
Contributor

llyyr commented Oct 11, 2025

Well at least gamescope doesn't support xdg_output according to that page and it can be used for HDR passthrough with mpv.

gamescope already can't because wp_viewporter is required for mpv but gamescope doesn't support it

Though I think the x11vk context in mpv should work for it too, it implements its own WSI layer to get HDR metadata out somehow. So gamescope should not factor in here

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 this pull request may close these issues.

4 participants