If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite
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.
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).
Last edited by GreenByte; 15 November 2023, 11:06 AM.
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.
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.
Comment