<html>
    <head>
      <base href="https://bugs.freedesktop.org/">
    </head>
    <body><span class="vcard"><a class="email" href="mailto:ppaalanen@gmail.com" title="Pekka Paalanen <ppaalanen@gmail.com>"> <span class="fn">Pekka Paalanen</span></a>
</span> changed
          <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>
          <br>
             <table border="1" cellspacing="0" cellpadding="8">
          <tr>
            <th>What</th>
            <th>Removed</th>
            <th>Added</th>
          </tr>

         <tr>
           <td style="text-align:right;">CC</td>
           <td>
                
           </td>
           <td>fourdan@xfce.org
           </td>
         </tr></table>
      <p>
        <div>
            <b><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#c3">Comment # 3</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 <span class="vcard"><a class="email" href="mailto:ppaalanen@gmail.com" title="Pekka Paalanen <ppaalanen@gmail.com>"> <span class="fn">Pekka Paalanen</span></a>
</span></b>
        <pre>(In reply to Maciej Piechotka from <a href="show_bug.cgi?id=101193#c2">comment #2</a>)
<span class="quote">> Personally I would like the RandR working on XWayland. I have HiDPI display
> and the non-HiDPI programs are suboptimal. I'd like to just set 1920x1080
> instead of 4K for them and be done with them. I don't know XWayland that
> well but I assume it renders to texture at some point to pass to compositor
> - I imagine it could render lower-res texture onto highier-res so to present
> highier-res image to compozitor.</span >

Yet another orthogonal approach coming to mind is having Xwayland use the
output scale to divide the resolution it exposes to X11 clients. There is no
way to detect which "buffer scale" X11 clients use for drawing, which means we
pretty much have to just assume something, and scale=1 is the default. If the
output scale was 2, the Wayland compositor would automatically scale up to 2x.
This could work in the cases where the output is configured as HiDPI. I just
wonder if it would break something.

<span class="quote">> Agree, at least partially. The most annoying thing is when game changes the
> resolution on exit of whole desktop. That said it might be needed for
> performance to use native resolution in full screen (this would be perf hack
> though, not configuration as it). That said I don't know (and most avenues I
> have would go under NDA) if this is the case and rendering texture might be
> fast enough.</span >

It should not be needed, not for fullscreen apps at least. The trick is to get
the display device (CRTC) do the scaling on the fly, not changing the video
mode (monitor scaling) and not using the GPU (rendering pass for scaling).

There are essentially two ways to tell the Wayland compositor to scale things:
wl_viewport and output/buffer scales. Optimally the Wayland compositor will
defer the scaling to the display device.

Achieving monitor scaling, i.e. temporarily changing the video mode, would need
a Wayland protocol extension (which might be eventually developed anyway) and
it might be a bit hard in the Xwayland case as it would then apply to all X11
apps, not just the one that used RandR. That might be awkward to use in
practice.</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>