| 2 Mar 2025 |
 Fernando | so I've been playing with the KCL, and I do get a flicker-free boot from cold start into plymouth, but I'm missing the fade from plymouth into gnome-shell with autologin | 16:34:33 |
| Fernando | I can try without autologin though | 16:34:40 |
 emily | FWIW, I believe Intel drivers are the furthest ahead for this, but K900 will know more up-to-date info than me. | 16:34:44 |
| emily | my guess is that the flicker is when it switches from the EFI FB driver to amdgpu, but I could be totally off here | 16:35:33 |
| Fernando | without autologin (no gdm skip) seems to do the same: plymouth -> spinner stops -> black screen -> gdm | 16:37:25 |
 K900 | ^ | 16:37:37 |
| Fernando | How many displays: 1, which exact AMD: ryzen 7 7840U, which kernel version?: 6.13.4
| 16:39:20 |
| K900 | Try boot.initrd.kernelModules = [ "amdgpu" ] | 16:39:53 |
| Fernando | now I get no spinner and a black screen into GDM, lol | 16:42:53 |
| K900 | Then it's very likely your firmware is not setting the display to the correct mode | 16:43:57 |
| Fernando | no idea then | 16:54:07 |
| K900 | In general any sort of flicker free anything requires the early boot firmware to cooperate | 16:54:31 |
| K900 | And in general not all firmware actually does | 16:54:37 |
| K900 | This is especially often the case with high refresh rate displays | 16:55:04 |
| K900 | Because it's common for the firmware to drive them at 60Hz anyway | 16:55:14 |
| emily | it could also be that Linux isn't choosing the right mode to use, right? | 16:57:28 |
| emily | IIRC you can end up with "modes" that are basically the same but with some silly difference that means a modeset happens anyway | 16:57:47 |
| emily | I may not be helping here though. the last time I seriously tried to get a flicker-free Linux boot was in 2014 | 16:57:58 |
| emily | but I recall there were things you could do to override what Linux would try to switch to to prevent this | 16:58:09 |
 Jan Tojnar | I finally got around to implementing toposort in update.nix. Hopefully, this will make this GNOME bump less painful. | 22:22:52 |
| 3 Mar 2025 |
| Jan Tojnar | I have started the GNOME 48 PR, feel free to push fixup commits there https://github.com/NixOS/nixpkgs/pull/386514 | 02:28:31 |
|  bendanm joined the room. | 04:43:51 |
| 6 Mar 2025 |
|  Grimmauld (moving to @grimmauld:grapevine.grimmauld.de) changed their display name from Grimmauld to Grimmauld (any/all). | 15:53:02 |
| 7 Mar 2025 |
 Andrew | Nothing feels better than 31 GiB of fully filled RAM and swap on GNOME NixOS, after which earlyoom starts killing stuff. | 07:20:41 |
| Andrew | * Nothing feels better than 31 GiB of fully filled RAM and swap on an idle GNOME NixOS, after which earlyoom starts killing stuff. | 07:20:57 |
| Andrew | * Nothing feels better than 31 GiB of fully filled RAM and swap on an idle Wayland GNOME NixOS, after which earlyoom starts killing stuff. | 07:23:37 |
| K900 | You definitely have a memory leak somewhere and you should really figure out where tbh | 07:28:49 |
| Andrew | tbh, I already asked about this and nothing came out of it, and figuring out by myself isn't easy. I have too little time to conduct research on who's the impostor. | 08:22:54 |
| Andrew | If I will have time for this, might as well switch to Hyprland and hope the problem will go away. | 08:23:20 |
| Andrew | I know that on X11 GNOME Pop!_OS there was a tiny memory leak and normally with time the gnome-shell process will eat more and more, but I think at worse it was about 600 MiB or something. But by far the worst issue was that the system start to have frequent and long freezes. So watching any video is pure pain. | 08:25:57 |
