Bug 1297349 - devilspie2 appears not to work on Xwayland
devilspie2 appears not to work on Xwayland
Status: NEW
Product: Fedora
Classification: Fedora
Component: devilspie2 (Show other bugs)
27
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Michal Minar
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-11 05:08 EST by Russel Winder
Modified: 2017-09-24 15:45 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Russel Winder 2016-01-11 05:08:36 EST
Description of problem:

I have set my environment up to run devilspie2 as a daemon on login with a configuration lua script in ~/.config/devilspie2

Login with Xorg and everything works as expected with devilspie2 (and devilspie, but that is no longer maintained).

Login with Xwayland and devilspie2 fails to set the opacity of windows. Currently I only set opacity so this is the only data point I have.

Version-Release number of selected component (if applicable):

devilspie2 0.39-1.fc23

(which implies it hasn't been rebuilt recently: should be a .fc24 package by now.)

How reproducible:

Always.
Comment 1 Olivier Fourdan 2016-02-10 09:28:41 EST
Devilspie uses EWMH properties to control appearance of windows on X11, like  _NET_WM_WINDOW_OPACITY for opacity, but that requires a compatible X11 window manager such as gnome-shell/mutter and that would obviously only work for X11/Xwayland applications and not Wayland native ones.

I tried with gnome-shell in a Wayland session and opacity as set with EMWH's _NET_WM_WINDOW_OPACITY works on an X11 application so that's either that you're trying this on a Wayland native application or your Wayland compositor manager/window manager does not support X11 properties on X11 apps.

Can you give a bit more info on your setup?
Comment 2 Olivier Fourdan 2016-02-10 09:39:38 EST
Test:

1. Select "GNOME on Wayland" session in GDM
2. Log-in "GNOME on Wayland"
3. Run xterm
4. from xterm, type:
   $ xprop -format _NET_WM_WINDOW_OPACITY 32c -set  _NET_WM_WINDOW_OPACITY 0x7FFFFFFF
5. Click within the xterm window with the pointer (cross shaped cursor)

=> in gnome-shell running as a Wayland compositor and X11 window manager with xterm running in Xwayland, the xterm becomes half-transparent as expected.
Comment 3 Russel Winder 2016-02-11 04:50:34 EST
The context is Fedora Rawhide fully up to date. There are two or three login options "GNOME", ["GNOME Classic"], "GNOME on Xorg". Some of my machines have the GNOME Classic option some do not, I have no idea what the algorithm is for this. However it doesn't matter as "GNOME" and "GNOME on Xorg" are the options that matter here.

I have an ancient Dell Precision T5400 workstation, Lenovo T500, Lenovo X201, and Lenovo X1. Currently there is a mouse settings problem all T5400, T500, X201, (reported but no activity as yet) but the X1 is working fine.

Experimenting on the X1, login to "GNOME" which is XWayland and XWayland from what I can tell. Run a GNOME terminal. Type in the xprop line above, click on terminal no response. Start an xterm, it comes up solid then when clicked on goes transparent and the xprop command terminates. I think this is the behaviour you were expecting?

So it seems that devilspie2 will need to do something very different for GNOME terminal (and I suspect many other things) and will have to allow itself to start when XWayland rather than XOrg is running so it can deal with XOrg applications as it has in the past.

Hopefully this is some of the "needinfo" needed?
Comment 4 Olivier Fourdan 2016-02-11 09:20:34 EST
Nope, that's not Xwayland but Wayland (GNOME on Rawhide uses Wayland indeed).

Xwayland is the rootless X server launched automatically by Wayland compositor to keep X11 compatibility with older X11 applications which have not been ported (yet) to Wayland.

But GNOME Terminal is Wayland native, so it's not running in Xwayland (like an older X11 application would).

Devilspie is for X11, it cannot work on Wayland native applications for several reasons:

 - Devilspie uses X11 properties defined in EWMH to control the appearance of applications in X11, that cannot work on Wayland as there is no X11 properties on Wayland native.

 - Wayland is a lot more secure than X11, an application (devilspie) cannot change the appearance or interfere with another Wayland application.

So devilspie cannot work in Wayland on Wayland native applications ,that's not a bug in Xwayland not devilspie.
Comment 5 Russel Winder 2016-02-11 10:09:59 EST
If, with Wayland, all applications are their own masters (which clearly has some benefits) and applications do not provide an opacity capability (as the GNOME terminal people removed), then there is no way with Wayland to have all windows except some a given level of opacity – which is what I like and want. I really do not want all my windows to be fully opaque. 

If there is no way of getting opacity changes globally, I am going to have to find a new platform :-(

It sounds though as though this not a bug, but a feature request – one that can possibly never happen.
Comment 6 Olivier Fourdan 2016-02-11 10:49:26 EST
I guess this would a be a feature request for the wayland compositor to implement then, ie mutter or gnome-shell maybe (for GNOME).
Comment 7 Jan Kurik 2016-02-24 09:15:30 EST
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
Comment 8 Fedora End Of Life 2017-07-25 15:45:14 EDT
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Comment 9 Jan Kurik 2017-08-15 02:55:32 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.
Comment 10 kxra 2017-09-24 15:45:23 EDT
Has this been reported upstream?

Note You need to log in before you can comment on or make changes to this bug.