Window decorations (specifically the title bar) can be grabbed with a left mouse click, which will drag around the window on the 2D desktop - this is not what we want.
We also don't want to forbid all input on the decorations as for example the right click menu can be useful. Furthermore with CSD (client side decorations) there may be toolbars embedded in the decoration or we don't even know the area where a window can be grabbed to move it around. This is also the case for some Qt windows that are "grabbable" on empty surfaces.
- kwin: Mostly fixed by not executing mouse move events while a window is in "resize" or "move" mode.
- Issue: Right clicking title bar and choosing "move window" attaching window to cursor is problematic.
- Issue: Left clicking title bar while in hotspot zone may tile window without cursor movement.
- gnome-shell: TODO, "move" and "resize" mode recognition difficult, handled in mutter.
On X11 sending input directly to a window is very difficult to get right. In our first release we go through the standard X11 cursor and keyboard input, which means that input is only possible on areas of the 2D desktop, where the X11 cursor can move to.
Windows that are partially pushed outside of the desktop area will have a "dead area" where the X11 cursor can not go, but of which the user will be blissfully unaware in VR.
Another consequence is that windows need to be fully contained inside the desktop area, specifically they can not be bigger than the desktop resolution, if mouse movements and clicks should work on their entire area. Thus, a user with a 3840x2160 monitor will be able to use larger windows in VR than a user with a 1920x1080 monitor.
Possible improvements include moving the window around the X11 desktop as needed, or setting a larger virtual resolution with RandR and using RandR panning or scaling, or even creating a virtual invisible monitor with a large resolution.
Scrolling up/down on the controller touchpad may be accompanied by unwanted left/right scrolls. We need to assist the user in scrolling only in the intended direction, especially on touchpads that are narrower in one direction than the other, for example the Vive Index touchpad.
Specifically on gnome shell some textures come with a bad alpha channel, which makes some windows partially transparent. Affected examples are for example blender and the steam client. This will be fixed in upcoming updates.
Slow texture sharing
Specifically when using the proprietary nvidia driver on gnome shell, some issues with color formats required implementing a fall back to a slow texture sharing code path for this release. Affected windows are some applications with toolkits that are non native to gnome, for example firefox and Steamm.
We will work with gnome shell upstream and other developers to fix these issues and use a fast external memory based texture sharing code path everywhere.
VR input focus
While running a VR application with xrdesktop overlays, all input that goes to xrdesktop overlays, will also go the VR application. For example if you press
a to left click a link in a browser, the game also receives a press of the
Solving this issue may require changes in SteamVR.