Sway December 2020

sway@lists.stg.fedoraproject.org

1 participants
2 discussions

redshift wayland support
by Dominique Martinet 15 Mar '21

15 Mar '21

Hi all. I've joined the list at Dan's suggestion, as I will be maintaining waypipe[1] now, and admittedly it could be useful for sway users, so why not. [1] https://gitlab.freedesktop.org/mstoeckl/waypipe Looking at the SIG page[2] there is a wishlist item for "redshift with wayland support", and as a big user myself I would be all for it. [2] https://fedoraproject.org/wiki/SIGs/Sway The problem is that upstream[3] has not been very active for a while - merged one PR in 2019, but that aside pretty much nothing since 2018. Frankly major DEs (gnome, KDE) incorporate the feature natively so users of redshift on wayland will basically only ever be wlroots-based compositors, so we shouldn't expect to get much help from anywhere on this... I imagine the dev uses gnome as he wrote the gnome-clock location helper redshift-gtk service files, so he's made the switch and hasn't looked back much. [3] https://github.com/jonls/redshift The wayland support issue[4] suggests arch uses minus7's wayland branch[5] but that would appear to still be AUR and they are in the same situation as us (some coprs have it alongside older versions of sway but nothing official). I would suggest the way forward would be to try to discuss with jonls and minus7 if an official fork could start somewhere; either minus7 tree if he is willing to do it or I suppose I could (I also have vested interest, I am also using the stdin remote control patches discussed on this issue[6], so "just" wayland wouldn't be enough for me, and whoever takes over would need to be willing to deal with at least accepting PRs :)) [4] https://github.com/jonls/redshift/issues/55 [5] https://github.com/minus7/redshift/tree/wayland [6] https://github.com/jonls/redshift/issues/690 So, what do you folks think? Worth a shot? Cheers, -- Dominique

2 1

[Michael Catanzaro] Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change)
by Dan Čermák 24 Dec '20

24 Dec '20

Hi folks (sway list CC'd as this also relevant for sway), in case you missed the thread on devel about systemd-oomd, the (imho) most important message for the i3 spin is below. If I understand this correctly, we'll have to ensure that systemd-oomd is disabled in the i3 spin, as it will simply kill the whole desktop if anything starts consuming too much memory. Unless anyone has an idea how to put every application that is launched from i3 into a cgroup in the same way that gnome shell already does that? The later would be of course preferable, as having apps in cgroups has a lot of advantages, but I don't know how feasible it is for us to achieve this. Cheers & happy holidays, Dan -------------------- Start of forwarded message -------------------- Date: Tue, 22 Dec 2020 13:03:14 -0600 From: Michael Catanzaro <mcatanzaro(a)gnome.org> Subject: Re: Fedora 34 Change: Enable systemd-oomd by default for all variants (System-Wide Change) To: Development discussions related to Fedora <devel(a)lists.fedoraproject.org> On Tue, Dec 22, 2020 at 6:55 pm, Tom Seewald <tseewald(a)gmail.com> wrote: > Overall I like the change for desktop use, but I'm not sure it > currently is a good fit for non-Workstation/KDE spins of Fedora. If your desktop doesn't segregate apps and services into cgroups, systemd-oomd will kill the entire desktop whenever anything uses too much memory, because the desktop is going to be running in the same cgroup as the apps that it launches. So I think desktop spins (other than KDE) ought to opt out of this. It should be good for all Fedora editions, though (including Workstation, Server, Atomic, CoreOS), and also for KDE spin. _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -------------------- End of forwarded message --------------------

1 0

2024

2023

2022

2021

2020

2019

Sway December 2020