D18486: [RFC] XWayland Multi DPI support

romangg added inline comments.

INLINE COMMENTS

> zzag wrote in abstract_output.cpp:98
> Could you please explain what it is doing?

If scale is 1.000000000000 I wanted to make sure it's not ceiled up to 2. But it's probably not necessary and unrelated to the main idea here. So I'll remove it.

> main_wayland.cpp:409
> +
> +    // TODO: Make this dependent on the release number. pkgconfig?
> +    arguments.append(QStringLiteral("-multidpi"));

Pkgconfig wouldn't work on user installs, since it's something installed with dev packages.

I'm thinking about adding a `-version` argument to XWayland, that just returns its version in the raw format the same way it is returned by `xcb_get_setup(c)->release_number` above (for example 12099000) and then quits.

Then before launching XWayland with all arguments compositors would need to launch `XWayland -version` first and see if an error is returned because the argument is not known or if not, what's the version number.

Of course one could also just directly try to launch XWayland with the option, but then one would need to redo all the process afterwards in case it fails.

> davidedmundson wrote in scene_opengl.cpp:1163
> This needs some work, but I understand what you're doing.
> 
> Logically we should have some sort of:
> 
> if (bufferSize  != windowLogicalSize * outputScale) {
> 
>   setFilter(Linear)
> 
> }
> 
> Though I remember trying it and couldn't see a difference.
> 
> We can split that out this patch and ship that.

Good that you mention it. I forgot to talk about it in the description.

Indeed this stuff was one of the worse problems and I don't yet fully understand it. Without these changes including the generateMipmaps call the XWayland texture of a HiDPI client looked blurry on the LoDPI display.

This makes in some way sense since mip-maps are used for down-scaling. But why do we not have the same problem with Wayland native buffers of larger scale factor and parts of them being shown on LoDPI screens? There everything looks crisp although it also needs to be downscaled.

Maybe does the glViewport call in our EGl GBM backend do this automatically? But if yes, why not for the XWayland buffers. They should behave in this aspect exactly the same.

> zzag wrote in scene_opengl.cpp:1486-1488
> I think GL_LINEAR shouldn't be used in this case. Why mipmaps anyway? I don't see where the number of levels is set.

From my research the number of levels is not something to be set, but it's determined by the size of the texture to be mip-mapped. A 2x2 texture has 2 mip-maps (2x2, 1x1), a 4x4 texture has 3 (4x4, 2x2, 1x1).

Don't know why our code tries to set levels.

> davidedmundson wrote in scene_qpainter.cpp:283
> I would expect one of the QPainter::setRenderHints will fix this.

You expected correctly. :)

The Antialising one didn't help, but SmoothPixmapTransform did.

REPOSITORY
  R108 KWin

REVISION DETAIL
  https://phabricator.kde.org/D18486

To: romangg, #kwin
Cc: leezu, zzag, davidedmundson, kwin, jraleigh, GB_2, mkulinski, ragreen, jackyalcine, Pitel, iodelay, bwowk, ZrenBot, ngraham, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas, apol, mart