Wine Wayland Driver Lands Improved HiDPI Support

[phoronix]

Phoronix: Wine Wayland Driver Lands Improved HiDPI Support

The newest Wine Wayland driver code to be merged is improved HiDPI support...

https://www.phoronix.com/news/Wine-Wayland-HiDPI-Merged

[MorrisS.]

Also Wine is going to Wayland native support. Well.

[espi]

Nice, Wine is basically the only thing I run on XWayland nowadays. Really hyped to get decent scaling.

[bple2137]

This is perfectly fine if it will only go as the default driver on Wayland sessions in Wine 10 if it won’t make it in time for the next major release, which it probably won’t. It will have a full year to polish before the actual prime time.

It would be great if it was also adopted in Steam’s Proton, but then Valve needs to somehow figure out their overlay and Steam input to work natively on Wayland. Given the current state of Steam, I wouldn’t expect it to be very soon.

[GreenByte]

It would be great if it was also adopted in Steam’s Proton, but then Valve needs to somehow figure out their overlay and Steam input to work natively on Wayland. Given the current state of Steam, I wouldn’t expect it to be very soon.

Valve is already using native wayland on proton. How, you ask? There was an XDC talk by one of valve employees/contractors. Basically, when running under gamescope, some hooks get installed to the wine program that swap the primary window's X11 surface with a wayland-native one. That's how steam deck also gets HDR on proton games.

EDIT: I suppose input is still handled over X11, so that's still not sorted. But overlay should work under wayland, if I understand things correctly (it's literally hooking into GL/VK swapchain).

[Quackdoc]

I wonder how embedded windows are going to work, I assume it will wind up just falling back to xwayland or failing. I myself just target xwayland, realistically it works fine and on KDE (honestly the only DE i care about anymore) scaling doesnt bugger up xwayland windows either so it feels native and good enough.

[oiaohm]

I wonder how embedded windows are going to work, I assume it will wind up just falling back to xwayland or failing. I myself just target xwayland, realistically it works fine and on KDE (honestly the only DE i care about anymore) scaling doesnt bugger up xwayland windows either so it feels native and good enough.

Perfectly fine for applications inside wine because wine is basically it own compositor you can see this with the Wine virtual desktop under X11 by the way. Now to Xembed a wine window inside application you will end up doing as much code as doing a proxy wayland compositor if you want it to work. Why wine expects Xemded every specification listed Xembed notice include the optional ones. Common error people run into with Xembed and wine is failing to have all the notices for return from the application embedded what the current window position is and with this mistake wine goes and presumes that the wine has to be sitting at 0.0 and renders pop include menu even if the Xembedded window is sitting at like 100x100 so rendering all pop ups in completely the wrong place. Also you have move window application need to update where wine has been moved to(note application not X11 server) this leads to a nice stack of race condition issue.

Different parties who do VST wrappers using Wine are looking at wayland proxy not just for Wayland wine but for X11 wine as well to avoid the Xembed race conditions and errors.