smxi
Add compositor/window manager -G Graphics feature
In order to add a compositor, we need the following information. Adding each one is a pain and very boring, since it has to be done empirically, one by one.
See issue #140 for window manager/desktop specific System: items.
-
update list of compositors. Note that also we need to know if the compositor is also a window manager, so it can be added to the window manager logic blocks as well. Internally, this means adding a program_values item for that new compositor/wm, adding to the ps_gui generator for wm or compositor, then adding to the relevant compositor/window manager detections.
-
In order to add support, the following is required: A: does compositor program name support --version. If not, does it use an alternate version option, if so, what, like: -v -V -version. B: If it supports --version, does it output to stdout or stderr when in the running environment? Use
program --version 2>/dev/nullto confirm that it goes to stdout, if the result is empty, it is going to stderr ifprogram --versionshowed output. C: what is the actual program name when it is running D: can it be detected in xprop -root? I assume not since most compositors are wayland E: is the program name different from the actual application name (yes, this happens, sadly). F: if --version exists, what is the complete output of that command, so that the patterns for detection can be added G: does the compositor also act as a window manager? if so, it must then be added to the various window manager detection blocks as well.
These are 100% empirical tests, each has to be run on each compositor/window manager added, it's very boring. Note that I do not use compositors so the only way I can get that data is manually installing them in a vm set to use compositing video graphics mode, I think that may work, or it may not, I do not know if the guest can have compositing if the host doesn't.
Here is my working current list of compositors. Note that 'unknown' means it has not been tested or verified. 'supported' means it has been, at some point in the past. 'unsupported' means it has no --version type flag, that is, it is known that it does not support version string generation. Obviously the latter can change, but it's very risky getting wm/compositor command execution wrong, because sometimes it restarts or makes the compositor fail because you are giving it a command it does not understand. In other words, I won't test this on my desktops, only in vms.
- wm indicates it is known to be a window manager as well as a compositor.
## these are either wayland or x11/wayland wm/compositors
## budgie-wm, gnome-shell, kwin_x11, marco, muffin, mutter
## can be compositing/non compositing wm
3dwm - unknown - wm
asc - unknown
budgie-wm - unknown - wm
# owned by: compiz-core in debian
compiz - supported - wm
compton - supported
dwc - unknown
# as of version 20 is wayland compositor
enlightenment - wm - note, uses a different method for version, from xprop, so can't be used
fireplace - unknown - wm
gnome-shell - supported - wm - very slow --version execution, only show if not in System:
grefson - unknown
kmscon - unknown
kwin_wayland - unknown - wm
kwin_x11 - version not used - wm
liri - unknown # Uncertain if this is the name of the liri projectc compositor now
marco - supported - wm
metisse - unknown - wm
mir - unknown - wm
moblin - unknown
motorcar - unknown
muffin - supported - wm
mutter - supports --version, but no example seen - wm
orbital - unknown
papyros - unknown # merged into liri, along with hawaii
perceptia - unknown - wm
rustland - unknown
sway - unknown
swc - unknown
unagi - unknown
wavy - unknown
way-cooler - unknown
wayhouse - unknown
westford - unknown
weston - supports --version, but no example seen
xcompmgr - unknown
## x11 common wm/compositors that have optional compositing and are not
## shown in Compositor: item.
gala - unsupported - wm (deepin, --version works but not used, very slow)
kwin - ambuity, not in compositor: version not used - wm
metacity - ambuity, not in compositor: version not used - wm
xfwm4 - ambuity, not in compositor: version not used - wm
xfwm5 - ambuity, not in compositor: version not used - wm
compton - unsupported
Not sure if it was ever true but at least it's not for my version. So:
- A: yes, --version
- B: stdout
- C:
compton - D: no
- E: no
- F:
0.1~beta2+20150922 - G: no
Is the F: value the full version output? If that is the full version, pinxi 3.0.21-7 should show compton v:, but show: pinxi -SGxxx just to be sure.
I forgot one, heh: is it --version or -v or -V, I'll update. I was hoping we could get compton since it's the most commonly used one at the moment outside of the main ones.
Note that I also added in all the display managers to the program_values so now their print values will reflect what they are supposed to be, which is a nice enhancement as well.
Also, thanks for providing a perfect example for others to follow re adding in another compositor, or updating an existing one that is unknown or incorrectly marked unsupported.
$ compton --version
0.1~beta2+20150922
$ pinxi --version | head -n1
pinxi 3.0.21-07 (2018-08-25)
$ pinxi -SGxxx -y80
System:
Host: X541NA Kernel: 4.18.4-041804-generic x86_64 bits: 64 compiler: gcc
v: 8.2.0 Desktop: MATE 1.20.1 info: mate-panel wm: marco 1.20.1
dm: LightDM 1.26.0 Distro: Linux Mint 19 Tara base: Ubuntu 18.04 bionic
Graphics:
Device-1: Intel vendor: ASUSTeK driver: i915 v: kernel bus ID: 00:02.0
chip ID: 8086:5a85
Display: x11 server: X.Org 1.19.6 driver: modesetting unloaded: fbdev,vesa
compositor: compton resolution: 1920x1080~60Hz
OpenGL: renderer: Mesa DRI Intel HD Graphics 500 (Broxton 2x6)
I forgot about gala, I have a deepin wm so I can test that one. Oh, no, wait, I see why gala isn't in there, comment says, super slow result for version.
the problem with many compositors is that they can run as compositors or not. For example, metacity can be or not be a compositor.
I found a compton vm, so I can debug that one.
xfwm4 is another one that can enable compositing, needs to be on the list
the problem with many compositors is that they can run as compositors or not. For example, metacity can be or not be a compositor.
Yep. You are not detecting the metacity compositor at all though, another one that needs to go on the list, hadn't even noticed it was missing.
On the other hand, pinxi is listing the marco compositor even when it's not active. You could detect it via the command line (marco --composite but that's not reliable since you can also use a config file) but Mint's wm-detect script has a simple solution, up to you to see if you can replicate that in perl:
#!/usr/bin/env python3
import gi
gi.require_version('Gdk', '3.0')
from gi.repository import Gdk
display = Gdk.Display.get_default()
screen = display.get_default_screen()
if (screen.is_composited()):
print ("Compositing: enabled")
else:
print ("Compositing: disabled")
The original idea for compositor detection was something along those lines, but I don't know anything like that in Perl I can use. this is a library, I checked for example compton's tests in the C and it is I think using an external X library to do the detections, which is obviously a non starter for inxi/pinxi.
That logic is basically just a wrapper around whatever it is including there. all those imports are importing something in some language, which is probably not available to pinxi/inxi.
where is the code for that? note that this is not simple per se, it's just that the wrapper for the actual programming is simple.
Note that I left out, deliberately, things that can be a compositor or not a compositor, like metacity and xfwm4. I may have missed this in a few cases, or opted to show it anyway since it would or might usually be a compositor. Compositor is actually an alpha feature, that's why it is an -xx option by the way, and exactly for the reason you noted, there is no actual detection of if compositors are running or not, just a crude ps aux search hack. this hack works fine for window managers, I've tested it fairly heavily, in most cases, but does not work nearly as well for something that can be engaged in that functionality or not engaged.
Note that nothing Python will ever be included in inxi again, due to the total and utter, and never ending, inability of the python project to maintain stable language features, even within major versions (3.7, for example, just broke a bunch of programs, lol). So python is in the never ever to be used again category in inxi-land.
I should technically split the list into wayland and non wayland, since wayland are always compositors, but x11 are not necessarily compositors. Then of course, there are ones that will support wayland or x11, I think anyway. The process of collecting methods and data is a big part of a new feature, not to be underestimated.
I've updated the master list to reflect on why some are shown and others not. Showing the ones that will often not be compositors, like kwin, xfwm4, to me is confusing, and the other ambiguous ones like budgie-wm and gnome-session are left in because I don't really care enough to be too granular but want to show them since they often might be compositors.
That logic is basically just a wrapper around whatever it is including there. all those imports are importing something in some language, which is probably not available to pinxi/inxi.
where is the code for that? note that this is not simple per se, it's just that the wrapper for the actual programming is simple.
Obviously, the actual code is in Gdk3, but GNOME provides an API: https://developer.gnome.org/gi/stable/ You can use that API with perl as well. However, the last time I wrote code in perl was probably 20 years ago so all I can do is google for you. This is the first result that came up, I won't guarantee it's the best: https://metacpan.org/pod/Gtk3
You could cherry-pick just the code required for what you need and add it to your project.
The compton v: glitch is fixed now in pinxi 3.0.21-10
confirmed. Also works for marco now.
I've updated the master list to reflect on why some are shown and others not. Showing the ones that will often not be compositors, like kwin, xfwm4, to me is confusing, and the other ambiguous ones like budgie-wm and gnome-session are left in because I don't really care enough to be too granular but want to show them since they often might be compositors.
I have to admit I don't understand your logic here. For example, metacity and marco are basically the same thing, marco is a fork of metacity, yet you show them in different categories. You can enable xfwm4 compositing through a checkbox in every Xfce desktop. Etc.
metacity is older, and less likely to be a compositor, and wont' support wayland. xfwm4 --version offers no meaningfully different data than xfce version already shows, and isn't a wayland compositor. gnome-shell is included because it can be a wayland compositor. Same with enlightenment, though that has no version method. xfwm4 cannot be a wayland compositor. marco can also be a wayland compositor, I believe. The basic rule is: if the program can be both a wayland and an xorg compositor, it's generally included, if it's xorg only, and isn't certainly a compositor, then it's not included. That's why compiz and compton are included, for example, they are compositors only, and wont' be running without compositing.
As I indicated, despite the fact that compositor is present, it's actually an alpha feature, that has been alpha for a long time, primarily because I have currently no real way to know if an x11 desktop is compositing or not, so my initial preference was to show only known compositors, and a handful of others, like marco or gnome-shell that I knew had wayland support possibly in them. kwin_wayland for example is there too, because it's certainly a compositor. The reason I added compositor is not for x11 desktops, it's for wayland, because real waylands, if they ever actually appear, will have no x server data, only compositor data. The focus for me is filling out the missing wayland compositor queries, to determine if they are supported or not, from unknown.
I can poke around the perl gtk 3 thing, but honestly, I'm not going to add any gtk specific code because gtk's api constantly changes (and I'm never adding in a gtk 3 only test anyway), and I don't feel like being the person who has to then run to keep up after gtk api breaks for the rest of my life. I actually have dumped the last vestiges of anything related to gtk queries, they were all horribly slow, inaccurate, and basically worthless. And the gtk perl library is almost certainly not in core modules, so it's not an option, and I bet it's as slow as any other gtk queries, or gnome queries. I don't believe you can snip out little pieces of this type of code, since you have to create all the links to gtk3, which probably means this is a Perl C module, which would not run as Perl, it has to be a module compiled like an C thing. I've dabbled with C perl modules, and in fact, the correct solution would be to query using the xorg api, not the gtk one, since there is a trivial C test for compositor on/off, but it requires making a perl c module, which is unlikely to happen.
And besides, that's way too much code to just get a single bit of data. Note that I already know that if it's wayland, it's a compositor, so really the rest is just fine tunings, and probably isn't worth spending much more time on, though I had hoped that a simple x test would show if something was compositing or not, there is one, but in C, via the xorg api. I still have hopes that a simple clean test can be found, something maybe thinking outside the box, like, if x happens, then it must be a compositor. But I'm not in a huge hurry because this stuff takes too long to actually develop and research, all software based stuff mushrooms into harder and harder problems, with less and less actual data results relative to the time spent.
marco and metacity both show I think as window managers, but only marco shows as compositor option. The logic is not really important, as I've indicated on the revised list above, the decision on which compositors to include was pretty loose, and based I think more on the likelihood of it actually being a compositor in the first place. Since all my desktops run xfce mostly, and I never use compositing, it leans towards my bias of what I run, but there's really no good formula, it's just going to be wrong at times, in the case of xfwm4, I decided against showing it simply because I don't use it, and never will. Keep in mind, alpha state features don't have to be perfect, or logically consistent, they just need to basically sort of work, well enough to send data through, and to be reasonably reliable for the actual use case, which was wayland compositing. The x11 compositing needs a real test to activate it if it were to be 'perfect', and that switch is lacking, so it won't be perfect.
These software things take a lot of time to do, they are very boring, and in terms of compositing, since I don't use it, have almost no interest in it, beyond needing to show a server type data for Graphics if it's wayland, I'm unlikely to spend a huge amount of time on that particular problem, since I believe all the wayland compositors will work as intended, a few of the x11 won't, that's about it.
The reason I added compositor is not for x11 desktops, it's for wayland, because real waylands, if they ever actually appear, will have no x server data, only compositor data. The focus for me is filling out the missing wayland compositor queries, to determine if they are supported or not, from unknown.
Fair enough, that wasn't clear to me from your request for help in the OP. I'm not using any wayland desktop/compositor at this time so I got nothing more to contribute.
Keep in mind, alpha state features don't have to be [...] logically consistent
:rofl:
The alpha part is in x11 compositors, to be more accurate. Basically if a wayland compositor is running, it's a compositor, and is correct for this test.
I would change it to:
- all compositors that are wayland, like weston or kwin_wayland, or which are x11 and only serve as a compositor, like compiz or compton.
- A sub group is window managers that can be x11 or wayland compositors, like gnome-shell. Those are the ones I think that threw you off.
- An unhandled group, which I'm leaving out, which can be or not be an x11 compositor, like xfwm4, metacity.
- x11 compositors / window managers like kwin_x11, which I included in compositors for now simply because I believe many kde users like eye candy and are more likely to be using compositing for effects.
The things that are needed at this point are:
- a surefire way to detect if x11 compositing is active. One that does not involve building c libraries etc.
- once this way is found, using a boolean switch, x11 compositor/or window manager list will be added if compositing is active. In other words, if x11, and compositing active, add xfwm4, metacity, etc.
- completing the list above, to determine which are also window managers, which have version output, following the guidelines.
This is roughly how to be most helpful on this, I also don't use wayland, and am actually astounded by how long it's taken to get it working (still unusable I'm told by someone who tests on the cutting edge stuff and who runs a distro) without xwayland. I put in the compositor feature just to be ahead for when wayland started being normal and stock, and that still is not happening. Could it be that having no single compositor, like X has xorg, that handles most user desktops, and no real debugger that is wayland core tools item, and no tools like glxinfo, etc, for users to supply bug reports, that basically wayland can never be made stable except for specific compositors on specific distros? Or for very simple use cases. So far that's my guess re seeing where wayland actually is.
a surefire way to detect if x11 compositing is active. One that does not involve building c libraries etc.
Well, I don't know that X11 itself knows anything about compositing. But with the examples I gave you even I as a non-perl programmer can whip up a simple Gtk-based compositor detector:
#!/usr/bin/perl -w
use Gtk2;
Gtk2->init;
print "Compositing ".(Gtk2::Gdk::Screen->get_default()->is_composited ? "enabled":"disabled")."\n";
Are there any systems that don't have Gtk installed but use compositing? Probably not. Problem solved, don't think so complicated. ;)
No non core modules are used in standard inxi operation. The only non core modules are for json/xml export, those vary distro to distro if they are in core or not. gtk2 or gtk3 are not core modules, so they are excluded a priori. Here's what happens in the normal user world with that:
perl -MGtk2 -wse 'Gtk2->init;print "Compositing ".(Gtk2::Gdk::Screen->get_default()->is_composited ? "enabled":"disabled")."\n"'
Can't locate Gtk2.pm in @INC (you may need to install the Gtk2 module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base).
BEGIN failed--compilation aborted.
Note that I have a lot of Perl modules installed, far more than normal.This is why non core Perl modules were banned from all standard inxi features by design, from the very beginning, and actually, I've found, in most cases, writing the Perl myself results in faster execution than pulling in a big module to deliver what is in this case a single use case: determine the boolean value in x11 for $b_compositing.
By simple I mean, easy, fast, lightweight. There is an X api that delivers this, in C, it's 2 lines of code, plus of course you have to import the relevant X c libraries, which means, suddenly inxi goes from being very clean and simple relative to dependencies and installing, to very complicated and convoluted, relative to modules etc.
The kind of test I'm looking for is something that is true when compositing is running, and that can be determined in shell Perl execution, some value in glxinfo, xprop, something. Those tools are also not always installed, but given they already run, that is an available resource. An x11 compositor running check should involve no more than a few lines of code, and no extra dependencies, or it fails the fast, easy and simple test.
Well, the above works on all flavours of Ubuntu, Mint, LMDE, MX, and deepin that I have at hand, i.e. all Debian distros. The only one that doesn't seem to have it is manjaro, but I'm sure you can find an equivalent library on arch distros or whatever you are running.
glxinfo is much less likely to be present than Gtk2.
Don't get me wrong, at the end of the day I don't mind what you do, I just find it curious that you're rejecting this like that while you've got no alternative lined up. And by all means, do write your own rather than import the whole library, after all I did initially say that you should cherry pick just what you need.
My systems don't have gtk2 perl, and it's real debian. And it's not in core modules, so it's irrelevant, as I've already explained. I have doc files that list all core modules from all perl versions from 5.08 to roughly latest perl, though it doesn't change much. It has to be in Perl 5.008 to be considered at all, but I don't like using Perl modules, they are slow. Even if it were in core modules, first, at some point I'd have to test for gtk3, when gtk2 went away, then I'd be stuck in that gtk rat race, which you literally would have to pay me my full professional rates to enter, since there's no way I'm touching that game unless I get paid a lot to do it, over time. So that's in the 'never going to happen' category. Plus, I'm not going to pull in entire module just to get a simple boolean result, again, that's not going to happen, if I fell for that type of thing, inxi would rapidly grow totally out of control, and would slow to a crawl.
Your assumption that glxinfo is less common than a non core perl module is not correct, unless a distro explicitly added gtk2 or gtk3 perl module, it won't be present, and I don't know why distros would do that unless it was a dependency for some tool they used on their installer or system updater or whatever. I use standard Debian, so I don't know offhand what is or is not available, but again, you're not going to have any luck here, inxi features MUST fulfill all these requirements: always work, all distros, back to perl version 5.08, which is around 2008 or so, give or take a year or two. Must never require non core modules for standard features. Must not use modules that are slower to load and execute than writing the logic myself would be.
Again, you're barking up the wrong tree here, the rule is absolute, no non standard core modules are to be used in inxi unless there is a very, very good reason for it, like json export, which is an optional thing for users who want inxi output in json, or the xml export module, for xml. But that's all. I'm not clear on what is hard to understand about that, this is a dead tree you're barking up, it's excluded a priori by all the core inxi requirements, to be fast, always work on everything, etc, and you'll never get any different answer from me. I just showed you in real debian that this does not work, is not a standard core module, and thus is not going to be used. Plus it's probably horriblly slow in execution, but I'm not going to install that and test it just to find out that it's horribly slow.
It's from libgtk2-perl but all the ones I listed come with that pre-installed (and so does https://cdimage.debian.org/debian-cd/current/amd64/list-dvd/). Quite of few of them don't have glxinfo (mesa-utils) pre-installed though. Anyway, I said my thing, I heard your response, nothing more to add.
good, now let's focus on more constructive stuff, like if you are interested, testing, checking for version, etc, the above compositors.
Note that in roughly the same time I spent on this, I've added basic support for PPC architecture, fine tuned MIPS architecture, and will soon do SPARC. This is a FAR better use of my finite time as far as I'm concerned than trying to nail down an x11 only corner case on a handful of compositors, we're literally here talking about I think 3 maybe 4 wm / compositor tools here for x11. out of about 40 total.
There's now 4 basic items that need ongoing help, window managers, finding new ones, version info on them, desktops, though I think, finally, I have them all now, compositor version (and a real test that can be run cleanly to determine if shell can get compositing info in X), and distro id and system base id.
Each of these requires installing, testing, and then debugging, the ID / version methods. I do them now and again, when I get bored, or find some new data source, new lists of wm/dm/compositors, or hitherto unknown by me desktops, or display managers, etc, but my intention was not to do them all myself by installing them all in a vm, one by painful one.
Picom has been added to inxi-perl (pinxi) branch, will be in next inxi. Thanks