Cosmic Desktop Alpha Release

[Grogan]

I added some information about how the Dock finds icons when you add something to it, at the bottom of the post about adding things to the panel

How to Add Things to the Dock (#p1749)

[Grogan]

I think I might try Wine in this Desktop. I noticed on Phoronix that Wine 9.16 was released with some more Wayland bits

https://www.phoronix.com/news/Wine-9.16-Released

The (pre-prepared TKG, with fsync etc.) sources I use have been updated to 9.16, so there's no excuse not to try it

These: https://github.com/Kron4ek/wine-tkg are what I use to build my system wine packages.

[Grogan]

Well... I just tested something very finicky, the EA App and I played Mass Effect Andromeda, that is also sensitive to DRM (activation) issues, rendering issues and input. It's only been since Wine 9.14 that I've been able to upgrade again because of EA games. (EA's ActivationUI.exe broken with Wine 9.6)

Lutris works fine (and that wasn't a given to me, because I have programs that don't work correctly under xwayland... but Lutris is a python-GTK3 application and GTK has Wayland support)

The EA App is mostly fine, though it opens a bogus little window and the main window can't be moved. I can get at the handles to drag it smaller or larger, but can't move it to fix its position. This does not affect me using it though.

Mass Effect Andromeda is the only game I've tested so far, but it worked perfectly well and did not exhibit a mouse pointer grab issue I've been having with that game. I'll have to test it under normal X11 conditions (IceWM) to see if it was Wine 9.16 that fixed the issue or simply because input devices are handled differently in this Wayland environment.

This is a good sign though, and that's a pretty good test of a DirectX 11 game, I'd say that game is working 100%. I'm not going to try Steam/Proton at this time in this environment though. That Wine won't have the Wayland work that upstream has at this time.

P.S. No, the mouse cursor issue is not fixed for me with the Wine 9.16 TKG build in X11, it just doesn't happen under Wayland (I presume... all I can really say is under Cosmic, but I doubt they invented their own input handling etc.)

What's happening under Wine 9.14+ (TKG), the first since Wine 9.5 that I can use, is that in Mass Effect Andromeda, I have a defunct mouse cursor on my screen most of the time. I can briefly get rid of it sometimes but it comes back on the next interaction where it grabs a cursor. Only that game... it's specific to the way it grabs and releases a mouse cursor. None of the other Mass Effect games, nor any other game I play in Lutris with that Wine.

I think it's actually something in Valve's patchsets that changed the behaviour. It first happened to my nephew in Steam (that's where he has Andromeda), with the Proton I built for him. We tried Valve's Proton Experimental, then Valve's 9.0 and it was the same thing. What made the cursor behaviour work correctly again for him was Valve's Proton 8.0. So for next week I built him a Proton 8.0 using the TKG/Frogging build system, and that broke the cursor behaviour again. That build was based on Proton 8.0, but it would have some of the updated patchsets. Then the same thing happened to me with an updated Wine TKG build with its patchsets...

That's just my rationale for my conclusion. My point is that I actually have a game that works better (correctly) under Wayland than X11. In one small way, but I must concede

[Grogan]

One thing I am afraid to try in this desktop environment is power management. I have absolutely none, of any kind, because I don't have upowerd installed. I refuse! (fortunately it's not a dependency, just a missing back end that prevents cosmic from loading its power management interface).

There's no way systemfuckingnomed is going to be managing my power. I also don't have xfce4-power-manager installed (I didn't even compile it) because it also uses upower (and I hate it). There at least I have X11's DPMS facility, but in Wayland I don't.

P.S. They say screensavers (like Xscreensaver) don't work in Wayland... but I'll bet the one thing I could get them to do is show a black screen!

(joking... I wouldn't be running that sort of poo unless it's to play with and not at all if it isn't going to work correctly. I LOVE the Xscreensaver collection, though, don't get me wrong. You just can't have stuff that can fuck up your session, when you've got work going on and step away for a smoko. Most screensavers are awful things to be running simply because no input devices have been moved, idle or otherwise)

[Zema Bus]

So no active power management in the alpha? I was wondering about that since the back end isn't there yet for configuring it in the settings GUI.

I may have missed it in the thread, but did you come across the color settings in the Cosmic Settings?

screenshot-2024-08-25-06-51-33.png (178.52 KiB) Viewed 45611 times

[Grogan]

Yes, but the Accent colour didn't change it. I clicked + to add one and it just reverted back to the blue. So I forced my colour in the config files.

The power management is a front end to upower (as is XFCE's), you should have the settings if you have upower installed.

[Zema Bus]

I installed upower but it still says backend not found after restarting my session.

My color settings have stuck after logging out and signing back in. The Cosmic Settings is very buggy though, I had trouble getting the screen settings to work for dual screens until I signed out and back, after which it worked just fine.

[Grogan]

Code: Select all

[nicetry ~]# pacman -Ss power-profiles-daemon
extra/power-profiles-daemon 0.21-1
    Makes power profiles handling available over D-Bus

Duh, it says right on the dialog. I thought that was upowerd, but it's a fork of it that this thing wants.

It actually says "Backend not found. Install system76-power or power-profiles-daemon" (obviously you don't want system76-power, that'd be for pop)

Uninstall upower if nothing else is using it (kind of surprised your system didn't have it. I have to intervene to keep it off. Ahh because you use KDE... it has its own shit)

[Zema Bus]

I think I did already have it, and just didn't notice it was actually just reinstalling it. I have Mate installed alongside Plasma, and it's a dependency for Mate. I should have checked with -Q first:

Code: Select all

[root@Raza zema]# pacman -R upower
checking dependencies...
error: failed to prepare transaction (could not satisfy dependencies)
:: removing upower breaks dependency 'upower' required by mate-applets
:: removing upower breaks dependency 'upower' required by mate-power-manager
:: removing upower breaks dependency 'upower' required by solid
:: removing upower breaks dependency 'upower' required by solid5

[Grogan]

So you already DID have upower because of mate (It does tell you "warning up to date - reinstalling" but if not paying attention when installing something it's easy to miss that... Arch just dutifully reinstalls and overwrites. I like that)

That's ok though, power-profiles-daemon doesn't conflict with anything. These are things loaded by dbus on call sort of thing, not daemons that start with systemd etc.

There is one reverse conflict though, on tlp which you won't likely have. (It's an alternate command line utility typically used for preserving laptop battery life etc. as far as I know, so it's that tlp won't work correctly if power-profiles-daemon is being used)

[Zema Bus]

Thought I tried it, maybe I misspelled the package name. But that did the trick, I now have power profiles available!

xyxthumbs.gif (139 Bytes) Viewed 45593 times

[Grogan]

Jeeze... I get the hint. I need to add some smileys (ours mostly suck)

P.S. A big reason they suck is they don't have clean edges, and the garbage shows up on dark backgrounds

[Grogan]

You'll now find that smiley as

Code: Select all

:thumbsup:

I made it first in the list on the "posting page" where smileys are displayed

[Zema Bus]

I wondered if you'd notice lol! Thanks Grogan!

[Grogan]

I meant to get back to this thought. I tried several games in Cosmic last night with that Wine 9.16 TKG build. Mass Effect Andromeda, Mass Effect Legendary Edition (I tried ME3 within that), Bioshock Remastered (finicky fuss ass with Wine breakage), Control (A DX12 game that makes heavy use of ray tracing if it can be enabled), Far Cry 2 Fortunes Edition (64 bit rebuild with a bit of extra stuff... not really a remaster), Witcher 3 (original DX11 "classic" edition from GoG, which I prefer) and I even screwed around in Just Cause 2 for an hour or so. All were good.

I still haven't gotten up the stomach to try Steam and Proton in that Wayland environment. It's probably OK in some capacity, I'd just rather not

P.S. I should not say that the EA App works perfectly correctly. After you launch the game and the EA client goes in the background, it doesn't come back again. The window is simply gone. That's fine, I simply kill it with the Stop button on Lutris.

HOWEVER, Mass Effect Legendary Edition doesn't actually work. I swear I tested that yesterday and it worked once, but that may not actually be so either, as I think it was in X11 where I launched it. By accident, by clicking the wrong tile in the EA app and clicking Play and then I thought I might as well test it and launch into the game. (why... duh). Anyway, the problem with that game in Cosmic/Wayland is that it doesn't draw a window. The game runs, I can hear the sounds of the menu screens but there's no display interface.

All those other games work. I tested Andromeda again after to be sure (and then tested Legendary Edition in IceWM to make sure it wasn't actually itself broken)

[Zema Bus]

Still that's pretty good. The last time I tried gaming under Wayland it wasn't a good experience, but that was a year ago.

[Grogan]

Indeed, it far exceeded my expectations. It seems to be a window handling method that doesn't work or something for ME Legendary. It's similar to what happens with the EA App window itself after a game is launched, its got no window to bring back in the foreground.

I quite enjoy using this desktop, though I don't really trust it to be reliable. So far its been only an occasional inconvenience if something malfunctions (Dock, copy/paste, screenshotter etc.), and I have to restart the DE, but I don't do anything I wouldn't want to lose. I wouldn't want my terminal window disappearing on me or worse, inputting commands etc. if anywhere serious.

One thing I don't see mentioned much is that this uses what they call "Dynamic Rendering" where it can choose the correct rendering method for your system. Vulkan, OpenGL, or... software rendering ( )

It will use Vulkan on our systems. I can confirm that it is on mine (I can use lsof to see things like that, e.g. "lsof | grep -i something"). The cosmic processes are hooking libvulkan_radeon.so through the vulkan loader (libvulkan.so.x and the icd.d)

By the way, the reason I thought that upower is what this was looking for is because of the warning messages I get on the root console. cosmic-greeter fails to load the unwanted things I don't have or have left deliberately dangling (like actually starting the systemd services). However it's a fork of it that it was looking for that likely uses the same org.freedesktop.dbus.whateverthefuckIdon'twantonmysystem back end. Output like this:

Code: Select all

WARN cosmic-osd: cosmic_session: [2024-08-26T20:20:00Z ERROR cosmic_settings_subscriptions::airplane_mode] Failed to monitor rfkill: No such file or directory (os error 2)
WARN cosmic-osd: cosmic_session: [2024-08-26T20:20:00Z ERROR cosmic_settings_subscriptions::upower::kbdbacklight] Error listening to KbdBacklight: org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable
WARN cosmic-greeter: cosmic_session: [2024-08-26T20:20:00Z WARN  cosmic_greeter::upower] upower error: org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable

It's not that noisy though, there's maybe a few dozen lines of noise if I've been using the session for a while. Often cosmic-greeter tries to do something, can't, and aborts that instance of itself. I might see that 3 times or so after a session.

[Grogan]

The GoG installer (Windows one) doesn't work on Wayland either, it pops up its first initial dialog for you to click OK (e.g. "This will install blahblah) but after that it doesn't draw a program window. That seems to be the problem I'm seeing with some applications under Wine. So I had to get out of Cosmic to install my game. After that the installed game worked perfectly in Cosmic though, No Man's Sky.

I just re-bought No Man's Sky on GoG, since some new work was done on the planets. My gripe with that game is that every time I install it again, soon it'll be big updates and game changing behaviour, then again etc. and I always get pissed off and remove it. Well, the answer is to have it on GoG, then there will be no updates or game changes until I say so.

[Grogan]

Oh ho ho... I just noticed that my video player (smplayer, but it's the mpv back end) doesn't work in Cosmic. I just didn't happen to watch anything in this DE yet (just youtube so far). Bad Window, invalid window parameter etc.

THAT will not do. Hopefully I can solve that with mpv (going to get git code and see if I need to enable something for Wayland etc.) That's actually a distro package I have installed. I shouldn't be using dogfood for that anyway. ( )

[Grogan]

Nope... latest mpv from git, latest smplayer from git (that's more because arch has mpv as a package dependency and I needed to remove the mpv package) and mpv still can't create a window.

So that tells me it's not just Wayland but Cosmic-comp window manager itself causing these problems. It is likely the case with the game window and child window problems in Wine too.

Wayland is definitely supported in my mpv build.

Code: Select all

meson setup build -Dprefix=/usr/local -Dlibmpv=true -Dgl-x11=enabled -Ddvdnav=enabled -Dlibarchive=enabled

output:
------------------------------------------------

Build targets in project: 49

mpv 0.38.0-UNKNOWN

    d3d11     : NO
    javascript: YES
    libmpv    : YES
    lua       : YES
    opengl    : YES
    vulkan    : YES
    wayland   : YES
    x11       : YES

  User defined options
    prefix    : /usr/local
    dvdnav    : enabled
    gl-x11    : enabled
    libarchive: enabled
    libmpv    : true

Found ninja-1.12.1 at /usr/bin/ninja

I probably don't need that old GLX back end (disabled by default), but Arch enables it and I like backwards compatibility. We're using EGL now for desktop opengl stuff like that.

[Grogan]

Actually shit... the problem here is actually smplayer, using X11 not MPV. The Cosmic-comp window manager doesn't get the blame here at all either. I can launch mpv itself with a video on the command line, without smplayer trying to use "gpu-next/X11"

I think it's because smplayer is passing this, for some reason even though I have hwdec=vulkan. It isn't about that, I guess.

--gpu-context=x11egl

I actually didn't realize this had such a nice GUI window itself, mpv.

mpv-itself.jpg (87 KiB) Viewed 45225 times

Also, it seems there is no more gpu-next, it's only gpu now. (vo=gpu)

P.S. Got to love Brad Dourif, the actor. He always plays a nut

Mr Suter on Star Trek Voyager (he was a serial killer that later redeemed himself)
Grima Wormtongue in Lord of the Rings (wonderful simpering, seething, manipulative toadie)
He's even been in some video games, Myst III Exile is one I enjoyed him in immensely.

[Grogan]

Line 1765 in smplayer/src/core.cpp

Code: Select all

if (proc->isMPV()) {
			if (pref->vo.startsWith("gpu")) {
				proc->setOption("gpu-context", "x11egl");
			}
		}
	}

What possesses people to do things like this. No wonder smplayer is trying to use X11. It's hard coded to default to that, yet they give you no setting for gpu-context... I'd have to add it to command line arguments in Advanced which will hopefully override theirs if passed twice, but a consequence of using that field is that it will launch mpv in a separate window if you add arguments (with no controls on it, controlled by the SMplayer stop buttons and shit). As far as I know that's deliberate behaviour as that's how it was before.

Not "gpu" but "starts with gpu", so that means, vo=gpu, gpu-next, gpu-foo, gpu-kissmyass... anything. That's why this is happening to me. Oh well, I certainly can fix that, somehow. I can't just change it there though because if I change that context for vo=gpu* to something for wayland then it won't work for me under X11 lol

I think my solution may be to simply change that code to use "auto" for gpu-context. Since that works in the Advanced field (but pops up a separate window) it should work within the smplayer window unless that's tied to X11. (But then why would they have a "wayland support" checkbox in smplayer for MPV)

P.S. Unfortunately, the gpu-context has to be for X11 for SMplayer to use it within its window. It's simply a qt-X11 application. I patched it to use gpu-context=auto for mpv on linux ("unix not mac" actually lol), but it will open mpv in a separate window under Wayland. At least I geddit now.

Code: Select all

--- a/src/core.cpp	2024-08-28 18:57:26.000000000 -0400
+++ b/src/core.cpp	2024-08-28 21:35:52.444200387 -0400
@@ -1764,7 +1764,7 @@
 		}
 		if (proc->isMPV()) {
 			if (pref->vo.startsWith("gpu")) {
-				proc->setOption("gpu-context", "x11egl");
+				proc->setOption("gpu-context", "auto");
 			}
 		}
 	}

That's fine, because it doesn't pop open a separate window when used in X11. The auto detected GPU context will be X11. But my smplayer with mpv at least works out of the box in a wayland session, though the video output is in a separate window. That's OK though, I have all the controls I had before, the video is just detached from the program.

Until I figure out something else anyway. I've been using smplayer for eons, and I like the mpv backend. Maybe by the time I'm using Cosmic (or something like it) for everything, smplayer will handle this better. In the mean time that's a good compromise for when I'm using this DE.

At least, having the source code for what you use, allows you to get to the bottom of things quickly.

[Grogan]

Seeing as mpv has such a nice GUI now (has mouse wheel controls for volume and position, full screen with a panel that comes up if you move the mouse... and looks good doing it, too), that's another method of opening videos. I don't really need smplayer, I can use it explicitly if i want to, or just open things in my XFE file manager. In those "Program" fields it will launch the file with whatever you put in there, correctly with the arguments you supply.

Of course, unless it's a special function like "Edit" or "View" a file association you add (e.g. through Open With, you can optionally check a box) is going to override that. So I removed the associations for video file types. Good old school software, it simply stores its entire configuration, including file type settings, in a flat INI type file with sections (xferc). So I did that first, and now when I double click a video in my XFE file manager it opens with that mpv command.

This has been a very handy file manager, for decades (formerly XWincommander, I think I found that for the first time in the assloads of programs that Mandrake 7.0 installed)

xfeprogramsettings.jpg (88.16 KiB) Viewed 44850 times

P.S. Actually, there's a --gpu-api=vulkan switch that I needed too. That was the missing piece of the puzzle to actually force vulkan video (has no choice now, it would fail if no vulkan with spirv compiler). This will work for both X11 and Wayland with the auto gpu-context setting. With the gpu-api and hwdec settings, that auto setting will now only be able to use x11vk or waylandvk for gpu-context.

Code: Select all

mpv --vo=gpu --gpu-context=auto --gpu-api=vulkan --hwdec=vulkan

If that was on the command line, it would be followed by filename. (my file manager supplies that). I found out that hwdec isn't enabled by default, so it does need that. However, it depends on the file format as to whether or not it can be used. That setting will fall back to software decoding in that case. (This is not the same thing as rendering). With h264 it can use it:

Code: Select all

[grogan@nicetry ~]$ mpv --vo=gpu --gpu-context=auto --gpu-api=vulkan --hwdec=vulkan filename.mp4
● Video  --vid=1               (h264 1920x1080 23.976 fps) [default]
● Audio  --aid=1  --alang=eng  (aac 2ch 48000 Hz 94 kbps) [default]
Using hardware decoding (vulkan).
AO: [pulse] 48000Hz stereo 2ch float
VO: [gpu] 1920x1080 vulkan[nv12]

Also, --vo=gpu-next DOES work in that context. Now though, vo=gpu works with vulkan output (man page still says you need gpu-next but this is latest git) so I can't decide which to use. Apparently gpu-next is faster, but it has some limitations and bugs. I guess I'll use gpu-next.

I got out the man page and actually waded through all the prose to understand those settings. It tells you vo= and gpu-context= but doesn't tell you the values, you have to go and read sections.

mpv doesn't have a full GUI, but it's got a nice enough player window when driven by command line that I don't think I'll miss smplayer. I'll bet that now I just won't use it anymore.

[Grogan]

The problem with a Wayland compositor is, when something goes really wrong, you're not going to just lose your X session, it's going to hard lock the system.

I was working on GTK+ stuff so I thought it would be more convenient to work outside of XFCE, so I chose Cosmic. Editing files, getting sources... went to maximize my urxvt terminal and... hard lockup. Filesystems all needed fscking including DOS... boot sector, free space count etc. Fuck I hate having a FAT32 filesystem that's so mission critical. That's got to be the dumbest thing Linux has to do yet... because of asshole Microsoft.

[Grogan]

All of this shit again in Arch, alpha.2 now... I'm going to try building the packages, but if it breaks my config I'm just going to ditch the whole kit and kaboodle including unwanted dependencies installed for this. I have ZERO patience for things like this right now.

Code: Select all

[nicetry ~]# pacman -Syu
:: Synchronizing package databases...
 core is up to date
 extra
 multilib is up to date
:: Starting full system upgrade...
warning: cosmic-app-library: ignoring package upgrade (1.0.0.alpha.1-1 => 1.0.0.alpha.2-1)
warning: cosmic-applets: ignoring package upgrade (1.0.0.alpha.1-1 => 1.0.0.alpha.2-1)
warning: cosmic-bg: ignoring package upgrade (1.0.0.alpha.1-1 => 1.0.0.alpha.2-1)
warning: cosmic-comp: ignoring package upgrade (1.0.0.alpha.1-1 => 1.0.0.alpha.2-1)
warning: cosmic-files: ignoring package upgrade (1.0.0.alpha.1-1 => 1.0.0.alpha.2-1)
warning: cosmic-greeter: ignoring package upgrade (1.0.0.alpha.1-2 => 1.0.0.alpha.2-1)
warning: cosmic-launcher: ignoring package upgrade (1.0.0.alpha.1-1 => 1.0.0.alpha.2-1)
warning: cosmic-notifications: ignoring package upgrade (1.0.0.alpha.1-1 => 1.0.0.alpha.2-1)
warning: cosmic-osd: ignoring package upgrade (1.0.0.alpha.1-1 => 1.0.0.alpha.2-1)
warning: cosmic-panel: ignoring package upgrade (1.0.0.alpha.1-1 => 1.0.0.alpha.2-1)
warning: cosmic-randr: ignoring package upgrade (1.0.0.alpha.1-1 => 1.0.0.alpha.2-1)
warning: cosmic-screenshot: ignoring package upgrade (1.0.0.alpha.1-1 => 1.0.0.alpha.2-1)
warning: cosmic-session: ignoring package upgrade (1.0.0.alpha.1-1 => 1.0.0.alpha.2-1)
warning: cosmic-settings: ignoring package upgrade (1.0.0.alpha.1-1 => 1.0.0.alpha.2-1)
warning: cosmic-settings-daemon: ignoring package upgrade (1.0.0.alpha.1-1 => 1.0.0.alpha.2-1)
warning: cosmic-terminal: ignoring package upgrade (1.0.0.alpha.1-2 => 1.0.0.alpha.2-1)
warning: cosmic-text-editor: ignoring package upgrade (1.0.0.alpha.1-1 => 1.0.0.alpha.2-1)
warning: xdg-desktop-portal-cosmic: ignoring package upgrade (1.0.0.alpha.1-1 => 1.0.0.alpha.2-1)
resolving dependencies...
looking for conflicting packages...

Packages (2) cosmic-icon-theme-1.0.0.alpha.2-1  pop-launcher-1.2.1.r66.6a1b8b9-1

No more cosmic-icon-theme or pop-launcher? Or have the packages just been renamed to something else (I only know about the packages I have from the above)

Nope, they seem to be gone:

https://archlinux.org/groups/x86_64/cosmic/

P.S. For fuck's sake, they are stilll packages, they are still package dependencies... it's because they have been moved out of the "cosmic" group. They are not in any package group. So because of that, they are package conflicts. Fucking silly Arch packagers.

cosmic-icon-theme-1.0.0.alpha.2-1

[Grogan]

Got it all built and so far, so good. Nothing seems broken or amiss.

The only thing was it stopped recognizing my "myfirefox.desktop" shortcut in ~/.local/share/applications on the panel. I don't know why it ever recognized that in the first place (it added that there, not me), but I had to rename it to firefox.desktop lol

[Grogan]

Well, one good thing... the EA App works completely correctly now in this environment. It can redraw its window etc. after a game closes. Also, it actually works to update and restart itself (it did before in this environment... it doesn't work anywhere else, it exits and can't execute itself again after staging)

[Zema Bus]

I heard about it being out, guess I'll update it and have a look.

[Zema Bus]

Alpha 3 is out now, though Arch still has it in testing.

[Grogan]

I was wondering when updates to that were coming. I'll wait until I get pacman ignore list warnings, so I don't have to build it multiple times.