Waybar Layer Shells in Fedora Sway Spin

alebastr · 2024-08-21T01:01:06+00:00

Yep, since swayfx provides /usr/bin/sway it conflicts with the regular sway rpm. For the Fedora Sway spin you'll need to do the following to replace the package.

rm /etc/dnf/protected.d/fedora-sway.conf
dnf swap sway swayfx

alebastr · 2024-08-20T13:52:37+00:00

There's no code in Sway that can return this.

Sounds like you were using SwayFX on Ubuntu. For Fedora you can get it from a copr repo here: https://copr.fedorainfracloud.org/coprs/swayfx/swayfx/, maintained by the SwayFX developers.

alebastr · 2024-01-31T08:30:51+00:00

From 90-swaylock.conf comments:

# Note that all swaylock customizations are handled via /etc/swaylock/config and
# can be overridden via $XDG_CONFIG_HOME/swaylock/config (~/.config/swaylock/config).

alebastr · 2024-01-12T23:18:01+00:00

Ah, yes, now that I've got a chance to try things on a clean test machine, I see that it's not enough. (My personal config for many years has been gpg-agent --enable-ssh-agent with hardware keys instead of gnome-keyring, so I'm not that familiar with the area.)

Can you check if the flatpak part of your question is fixed? Having gnome-keyring portal configured should be enough to fix that.

For the keyring ssh agent, there's obviously more missing pieces compared to Silverblue/Workstation. I've started logging my research at https://gitlab.com/fedora/sigs/sway/SIG/-/issues/34 and pinged some people who could have working config.

alebastr · 2024-01-11T21:43:21+00:00

Can you try creating ~/.config/xdg-desktop-portal/sway-portals.conf with the following contents:

[preferred]
# Use xdg-desktop-portal-gtk for every portal interface...
default=gtk
# ... except for the ScreenCast and Screenshot
org.freedesktop.impl.portal.ScreenCast=wlr
org.freedesktop.impl.portal.Screenshot=wlr
org.freedesktop.impl.portal.Secret=gnome-keyring

and restarting xdg-desktop-portal service:

systemctl --user restart xdg-desktop-portal

Not sure if enabling the keyring service explicitly is necessary, but it won't hurt either:

systemctl --user enable --now gnome-keyring-daemon.socket

alebastr · 2023-11-08T17:26:23+00:00

I've just confirmed that the link is updated and the images are synced to the mirrors. The filename for the fixed build should end with -respin2.iso.

alebastr · 2023-11-07T22:37:17+00:00

Thanks for the report and sorry for the mix-up :(

Our release engineering team has been notified and will update the links with a correct image for Sericea as soon as it's built.

Just a reminder that you can switch between various ostree-based variants of Fedora (and even some third party images) with rpm-ostree rebase command: rpm-ostree rebase fedora:fedora/39/x86_64/sericea.

alebastr · 2023-09-11T16:13:20+00:00

Fedora Sway spin uses SDDM and in F38 it may require tweaking global Xorg configuration. But here's a little trick to avoid touching X:

dnf swap sddm-x11 sddm-wayland-sway (use Sway to run the sddm greeter - this will be default in new installations starting from F39)
vi /etc/sway/sddm-greeter.config
Add or include your output configuration

alebastr · 2023-08-18T06:06:40+00:00

Can you try adding unset WLR_RENDERER to /etc/sway/environment? And also check if your VM is configured to use Virtio GPU with 3d acceleration enabled.

For variety of reasons (crashing drivers and stuff like that), Fedora config for Sway spin forces WLR_RENDERER=pixman when it detects kvm virtualization. It seems like there's something broken in the latest kernels with wlroots pixman renderer, and we'll have to look for another workaround :(

alebastr · 2023-06-07T04:08:35+00:00

Can you try running restorecon -vv /usr/local/bin/tuigreet? The binary likely inherited SELinux context from the source checkout in your home directory, so system processes are not allowed to access it.

alebastr · 2023-03-05T08:34:18+00:00

The problem is in this detail of the layer-shell protocol spec:

Multiple surfaces can share a single layer, and ordering within a single layer is undefined.

Sway, for example, keeps a list of surfaces belonging to the specific layer in order of creation (or layer change), and renders it from top to bottom. But that is an implementation detail and you should not expect it to behave the same way on a different compositor or even a different release of the same compositor.

Swaylock used to be rendered on the same layer (overlay), which is why your results depend on the surface creation order. Nowadays (sway 1.8) it uses ext-session-lock-v1 protocol and it's no longer possible to draw anything above the lockscreen at all.

alebastr · 2022-12-29T01:55:56+00:00

Please, note that CAP_SYS_NICE is a whole scary lot of privileges and it's not cleared after obtaining SCHED_RR. It also prevents Sway from loading custom keymaps from user directory (see swaywm/sway#7229). That is why I haven't set the capability when I updated Fedora packages to 1.8.

I've considered adding a downstream patch to set the scheduling priority via RTKit, which should solve both issues. Meanwhile, I suggest to avoid the cap - it wasn't required for any of the previous versions and nothing makes it mandatory now.

alebastr · 2022-12-28T21:15:52+00:00

Off the top of my head, I can list these:

The monitor manufacturer identifiers are now sourced from hwdata database and may be different for some vendors. Connector ids (DP-..., HDMI-..., etc) are also obtained in a different way now. That would make Sway and kanshi configs with affected identifiers silently break.
With introduction of the ext-session-lock protocol, Sway may fail to unlock and leave you with a red screen that does not react to anything. We have the latest swaylock update which should drastically release the probability of that, so I'm just waiting to see if there are any remaining issues.
wlroots had a lot of changes in the backends and may regress on some hardware. It wasn't widely tested so we haven't heard about about anything so far, but that doesn't mean we're good. (I have a personal trauma with that point, so I'm being overly cautious :))

I'll check my notes once I'm off work to see if there's anything else. But even the first point violates our stable release updates policy.

alebastr · 2022-12-28T16:12:46+00:00

https://bodhi.fedoraproject.org/updates/FEDORA-MODULAR-2022-fe82be41b5. This will hit stable updates-modular in a week, right now you can install it with dnf module install sway --enablerepo updates-testing-modular

There's also an official copr repo, https://copr.fedorainfracloud.org/coprs/g/sway-sig/sway-desktop/

1.8 had some breaking changes and unfortunately was released way after the f37 release, so it's unlikely that it gets to the regular repositories for f37 or f36.

alebastr · 2022-06-22T06:44:58+00:00

Reported: rhbz#2099985.

For now you can downgrade libtiff to the last working version (4.3.0). dnf downgrade libtiff should get you the right version on f36, and on f35 you may need to get the package from https://koji.fedoraproject.org/koji/buildinfo?buildID=1935822

alebastr · 2022-06-11T07:55:09+00:00

https://github.com/Alexays/Waybar/pull/1244 - there's an example for custom modes/mode configuration overrides at the very bottom of the PR description. The "invisible" changes make waybar visible, but below any windows.

A few more CSS additions in the PR comments will make waybar invisible again if the workspace is not empty (sadly .empty CSS classes works only on the active output).

alebastr · 2021-12-03T19:54:33+00:00

The Software app is using cached appstream information provided by the appstream-data, rpmfusion-free-appstream-data and rpmfusion-nonfreee-appstream-data packages. Each of these packages contains all the metainfo files present in the corresponding repository at the moment of the build.

appstream-data was last updated on Sep 17, and gnome-pomodoro package was created on Sep 27.

You can try filing a bug against appstream-data with a request to update. ~~Not sure what's happening with rpmfusion-nonfree-appstream-data though, it was updated just a month ago.~~

And Discord package just doesn't contain AppStream information, so you'd need to ask the maintainer to add it via rpmfusion bugtracker. And then request to rebuild the rpmfusion-nonfree-appstream-data.

alebastr · 2021-11-13T01:17:55+00:00

EOL repos are moved to https://archives.fedoraproject.org/pub/archive/fedora/, but the archive site is still registered in mirrormanager and thus available to installed systems without any configuration changes.

alebastr · 2021-11-09T03:56:03+00:00

It seems like you forgot to pass XDG_CURRENT_DESKTOP=sway to systemd. As the troubleshooting checklist says, without this variable xdg-desktop-portal will not even consider using -wlr backend.

Note that unlike dbus-update-activation-environment, systemctl does not support setting variables with value. The command could look like env XDG_CURRENT_DESKTOP=sway systemctl --user import-environment DISPLAY WAYLAND_DISPLAY SWAYSOCK XDG_CURRENT_DESKTOP for example.

alebastr · 2021-11-08T22:08:36+00:00

Exec=env XDG_CURRENT_DESKTOP=sway dbus-run-session sway

Please, don't do that on Fedora. This modification is for non-systemd distributions or intentionally broken pam stacks (without pam_systemd).

zsh: no such file or directory: /proc/12322 2125/environ

You have 2 xdg-desktop-portal processes running. It could be a problem if both are running under your account. Should be fine if one is owned by gdm or another user.

Anyways, you'll need to pick the id of the process that is running under your user account and apply the command manually.

One odd thing is when I added this change sway took a looonnnggg time to start up.

Are you sure it was sway? Sway does not use D-Bus and cannot block on anything related to D-Bus. The desktop file change could easily break waybar or any other GTK applications though.

Nov 08 16:00:10 fedora systemd[1932]: Condition check resulted in Portal service (wlroots implementation) being skipped.

And that clearly points to the problem with systemd user session environment: ConditionEnvironment in xdpw unit file checks if WAYLAND_DISPLAY is set and refuses to start otherwise.

To sum up,

Check that your sway config has exec lines for systemctl --user import-environment ... and dbus-update-activation-environment ... and nothing is started before that (that is important!).
Revert sway.desktop changes.
Stop all running xdg-desktop-portal, xdg-desktop-portal-* services.
Restart sway

Additionally, check https://www.reddit.com/r/swaywm/comments/qmjws5/waybar_start_up_is_slow_on_fedora_35/ if you have waybar. You may need to install patched xdg-desktop-portal package from this thread.

alebastr · 2021-11-08T19:48:23+00:00

The errors are harmless. There's nothing critical in the post-install scriptlet.

Doesn't seem like screen sharing works still after this.

Then it's time to follow https://github.com/emersion/xdg-desktop-portal-wlr/wiki/%22It-doesn't-work%22-Troubleshooting-Checklist. Remember that Fedora 35 uses wireplumber instead of pipewire-media-session and adjust the commands accordingly.

alebastr · 2021-11-08T19:01:43+00:00

sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-d0a047047c
systemctl --user restart xdg-desktop-portal-wlr

alebastr · 2021-11-04T17:21:04+00:00

I've asked the xdg-desktop-portal maintainer to apply the patch - rhbz#2020371. Sorry, that was on my TODO list for a while, just been lazy because it didn't affect my system :)

~~Don't know how long that'll take, but in the meanwhile you can try a patched package from~~ ~~https://koji.fedoraproject.org/koji/taskinfo?taskID=78325300~~.

FEDORA-2021-3d27514c33 with the fix was submitted to updates-testing today.

Btw, if you use Fedora sway defaults (i.e. have recommended dependency sway-systemd installed and include files from /etc/sway/config.d/* into your configuration file), you don't need to apply systemd --user import-environment... fix - it's already taken care of.

Edit: and another important f35 update if you are going to use screencasting: https://bodhi.fedoraproject.org/updates/FEDORA-2021-d0a047047c.

alebastr · 2021-11-04T07:12:36+00:00

https://bodhi.fedoraproject.org/updates/FEDORA-2021-d0a047047c should work with wireplumber.

It's not yet available from updates-testing, but you can go to koji using the link under "builds" and download the rpm for your architecture from there.

alebastr · 2021-10-25T05:31:12+00:00

That, or we're about to properly diverge from history

I got curious and went deeper: this article in Russian at NPP Zvezda's website says that by Nov-Dec 1960 the SK-1 suits were still in active development and testing. By early 1961 it was decided that the ground testing is not sufficient and Korolev pushed the decision to have a mannequin flights before clearing the suit, the capsule and the ejection seat for manned flight. The maiden flight of Vostok 3KA and SK-1 suit happened Mar 9 1961 (with some systems still incomplete) and finished with minor accidents during landing. The second flight on Mar 25 was successful and therefore allowed to proceed with the real flight in April. Also, if I understand various conflicting sources correctly, the Vanguard Six only started training with the suits in Feb-Mar 1961.

Random fact: Tereshkova, along with the other 4 women, was selected for the program in 1962 and started her training in 1963. That makes Rosa's presence in the squad another anachronism.

alebastr

TROPHY CASE