search

QubesOS / qubes-issues

The Qubes OS Project issue tracker
https://www.qubes-os.org/doc/issue-tracking/
543 stars 48 forks source link

Fullscreen apps with wine unusable #7307

Open iacore opened 2 years ago

iacore commented 2 years ago

Qubes OS release

r4.1

Brief summary

Full screen windows opened with Wine flicker white + show window decoration for an instance on every click, also dropping 1 out of 2 clicks. It makes full screen applications in Wine unusable.

Didn't seem like any existing wine issue on other distros like Ubuntu (no QubesOS).

Related to https://github.com/QubesOS/qubes-issues/issues/2391

Workaround

This is no issue using with Wine Virtual Desktop, where each applications don't get their own X11 window (every wine window is drawn in a "virtual desktop" window).

Steps to reproduce

With Lutris

With Steam

Expected behavior

Wine applications that use full screen windows should act the same as Linux applications.

Actual behavior

Window flicker white and show window title and border when clicked, also ignoring that click. Within one second the window will not flicker again.

The window don't receive mouse motion/move events.

iacore commented 2 years ago

The Wine implementation for full screen games is creating and destroying a X window on every frame. Qubes OS always focus on the new window, and the new window looks white.

This is probably some nuance of X Protocol that makes Wine work when they directly connect to X server. Normally the window created on every frame should be invisible.

I think I'll wait for Wayland.

DemiMarie commented 2 years ago

I think I'll wait for Wayland.

It will be a while before Wine has Wayland support, but the Wayland agent will support XWayland (it’s supposed to replace the X11 agent outright) and hopefully wlroots has a better X window manager implementation than the current GUI agent does.

marmarek commented 2 years ago

The Wine implementation for full screen games is creating and destroying a X window on every frame.

That sounds rather weird, I'd suspect it's some unexpected interaction with gui-agent. Does it do the same without qubes-gui-agent (for example when running some Live linux system in HVM, or even on bare metal)?

iacore commented 2 years ago

There is no visible window on bare metal. Do you know how to log every X window creation?

iacore commented 2 years ago

This is probably related to qubes-guid auto focus newly created window. Usually, which window to focus should be handled by the window manager, and I guess some X windows aren't focused by default.

Same cause as #7403 (VM X server do not have any control over window focus).

DemiMarie commented 2 years ago

@locriacyber That is interesting. I imagine it would be safe for a VM to say “do not focus this window”, provided that the window is also not visible. That said, if the window is not visible at all, should the daemon just ignore it, or always set the “do not focus” flag?

marmarek commented 2 years ago

That said, if the window is not visible at all,

If window is not mapped, it is not focused, by definition. It also isn't considered by the window manager.

marmarek commented 2 years ago

There is no visible window on bare metal. Do you know how to log every X window creation?

The simplest thing is to enable debug mode for the VM (in VM settings). You'll have then detailed logs in both /var/log/qubes/guid.*.log in dom0 (gui daemon) and journalctl in VM (gui agent).

On bare metal, you could try x11trace (the heavy way) or xev -root -event substructure (the light way).

DemiMarie commented 2 years ago

That said, if the window is not visible at all,

If window is not mapped, it is not focused, by definition. It also isn't considered by the window manager.

A window could be mapped but outside the frame.

iacore commented 2 years ago

Here's the log inside an VM: https://gist.github.com/locriacyber/dce9cf0e0cb5b9405c62d817e862b9ae

The application tested is a fullscreen game; it should only have one fullscreen window.

Interesting features in log from xev.

DemiMarie commented 2 years ago

I wonder if this is something that needs to be discussed on the Wine mailing list. The Wine developers might know something that could be of use here.

logoerthiner1 commented 2 years ago

(may be off the topic)

Many applications dislike Qubes OS GUI architecture including wine. Use Xephyr and/or docker to satisfy them.

One lesson about wine & Qubes OS I have learnt at least since 4 years ago is: wine dislikes Qubes OS GUI architecture. At that time I found that every time wine is creating a window or destroying a window, there would be a 1-second lag. When certain app creates such window in a chain rapidly, the program would be laggy. I believe that I had asked the Qubes OS community with no response.

Due to that reason I once thought that wine was not supported by Qubes OS, as both are uncommon way of abusing protocols (wine run windows binaries on linux, abusing win32 api; Qubes OS guid does not behave like a normal X server in other linux distributions, abusing X11 protocol). Actually quite a lot of programs dislike Qubes OS architecture. For example VSCode and Google Chrome disrespect dom0 minimization decision, see #7403 . Also one cannot use xdotools directly in default setup in appVM.

This is one of the reasons why I jail my wine docker and some other things inside a dedicated Xephyr - Xephyr seems more standard on X11 protocol and does not break things (the other being that Xephyr enables reasonable screen-shoting and screen recording).

For wine there are some differences as wine virtual desktops naturally is an alternative way of solving the problem, though. Not every application has this.

Isn't Xephyr good? I can open a Xephyr of size equal to my screen size, run a xfce4-session in it, full screen it, and pretend as if this xfce4-session is my host OS, for a little amount of time! Xephyr solves many of compatibility problems caused by Qubes OS being special in X server behavior. If a full screen win32 program runs in wine when X server is a Xephyr, I think there will be a large chance it will work.

Qubes OS makes seamless mode as common as air. However seamless is a feature rather than a curse, and you can get rid of it at anytime if this have annoyed you. When seamless mode breaks, you are not helpless - do not forget that you can always "partially disable seamless mode" with Xephyr.

Actually I believe that "partially disable seamless mode" using Xephyr should be discussed in Qubes OS documentation if possible, since something WILL break in Qubes OS (for example you are a user of a special software and their linux version only fits Ubuntu, and you can neither turn to the vendor of the software since Qubes OS is not a common operating system, nor turn to Qubes OS devs since the software is close source, not in English, and also not a common software; when this happens, you can install the app in ubuntu docker while run the app inside Xephyr).

Xephyr, as well as docker, are some of the tricks that makes Qubes OS less strange in environments, though Qubes OS is designed to be strange in some ways as security is a must (for example some missing features includes kvm, hibernation (as well as suspension in many machines), GPU acceleration in most apps, etc.)