<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - XWayland does not support scaling" href="https://bugs.freedesktop.org/show_bug.cgi?id=101193#c6">Comment # 6</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - XWayland does not support scaling" href="https://bugs.freedesktop.org/show_bug.cgi?id=101193">bug 101193</a> from <a class="email" href="mailto:jadahl@gmail.com" title="Jonas Ådahl <jadahl@gmail.com>"> Jonas Ådahl</a> <pre>(In reply to Pekka Paalanen from <a href="show_bug.cgi?id=101193#c5">comment #5</a>) > (In reply to Jonas Ådahl from <a href="show_bug.cgi?id=101193#c4">comment #4</a>) > > What about changing modes not only for the resolution, but for selecting a > > different framerate, or a mode with a different flag such as interlaced? > > Given that we don't even have a solution for Wayland native clients, it's a > bit hard to see how Xwayland should be mapped there. I think it'd make sense to come up with a native Wayland client solution can work with Xwayland too, just as with pointer locking vs pointer warping emulation. > > The first idea coming to mind would be to associate the RandR chosen mode > with *all* Xwayland windows, perhaps with some per-output heuristics, and > let the Wayland window manager do the same standard magic it would do with > native Wayland windows. > > That is purely because X11 has no per-window video mode thing, so Xwayland > cannot know which window a setting should apply to. Just as with pointer locking. We simply try to guess what window. I guess for a video mode changing client, we could figure out what window should trigger a fullscreen based temporary mode by matching the client setting the mode, with a window that has the same size and position covering the whole monitor.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>