<!DOCTYPE html><html data-lt-installed="true"><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body style="padding-bottom: 1px;">
    <p>> The SHM module was already using the viewporter in 3.0</p>
    <p>The SHM module should handle fractional scale if it is using
      viewporter. My understanding from the protocol and this crash is
      that whatever entity using viewporter needs to handle fractional
      scale as well. This probably means that it should be moved from
      the interface to the display module to prevent conflicts like
      this, and certainly the higher priority EGL module should support
      that as well (not only SHM).</p>
    <p>> A provider cannot use *any* rendering service on the surface
      unless it can't conflict with *any* potential use by *any*
      display.</p>
    <p>As I said, I'm willing to not use viewporter in the interface,
      but what is the alternative at the moment? I don't think not
      supporting fractional scale in 2025 is a good alternative. I used
      it in the interface because, 1) I'm more familiar with it than the
      display modules, and 2) the buffer scale was already set there
      (`wl_surface_set_buffer_scale()`), it only made sense to handle
      fractional scale there as well.</p>
    <p>> If triggering a crash in preexisting working merged code is
      not breaking it, then I don't know what is.</p>
    <p>We introduced a condition in Qt interface that we use viewporter,
      like the fractional protocol says, to support fractional scale in
      order to fit the video window properly. This did not require
      modifying the SHM module to cause crashes without the interface.
      This is problematic with the interface embedding in use, and it
      should be fixed if possible.</p>
    <p>> No, you just made that up. Can you even point to a precedent
      for that bold misleading claim?</p>
    <p>There is no guarantee that window embedding must be possible with
      all cases. I remember the `EGL_KHR_display_reference` case for
      example, which was a requirement for embedding.</p>
    <p>There can be a variety of configuration that can potentially make
      embedding impossible. This does not mean that these configuration
      should not exist, just to satisfy embedding in all cases. If in
      some situations video embedding is not possible, they should not
      be enabled or offered when the interface is used. I do not know if
      with the SHM module viewporter is the only issue, but as I said,
      we should try to support as many configurations as feasible in my
      opinion.</p>
  </body>
  <lt-container></lt-container>
</html>