| 27 Aug 2024 |
|  @aloisw:kde.org left the room. | 17:20:47 |
| 29 Aug 2024 |
|  (lambda (f l) (format nil "~a ~a")) "Artur" "Manuel" joined the room. | 05:48:08 |
|  Florens joined the room. | 12:24:47 |
 edgar.vincent | mica: Funny, I was just wondering about the exact same thing. Do keep us posted if you find the answer.
| 14:52:41 |
 mica | No answer so far... Don't think I'll get one. | 14:56:19 |
| 30 Aug 2024 |
| (lambda (f l) (format nil "~a ~a")) "Artur" "Manuel" changed their display name from Artur Manuel (old email was lost, migrating) to (lambda (u) (format nil "~A lost their email!" u)) "Artur Manuel". | 03:53:16 |
| 3 Sep 2024 |
 K900 | Question: what do y'all think about defaulting GNOME (and possibly the other GNOME-likes) to Pipewire for audio in 24.11? | 11:17:31 |
| K900 | I assumed GNOME didn't enable any sound server by default because that's what we do for Plasma | 11:19:29 |
| K900 | But turns out it enables Pulse by default | 11:19:37 |
| K900 | And we should probably figure out some way to be consistent on that | 11:19:53 |
 Honnip | it also enables Pipewire as gnome-remote-desktop requires it 😅 | 11:53:01 |
| K900 | Yes, but only for video | 12:01:35 |
 blitz | Are there still issues with pipewire? I'm using this for quite some time without issues | 14:18:28 |
| K900 | I haven't seen any particularly bad reports | 14:20:36 |
 Jan Tojnar | In reply to @k900:0upti.me
Question: what do y'all think about defaulting GNOME (and possibly the other GNOME-likes) to Pipewire for audio in 24.11? sounds good, I think we had plans for that as far back as when worldofpeace was still contributing but there were always other priorities | 15:40:20 |
 ElvishJerricco | In reply to @blitz:chat.x86.lol
Are there still issues with pipewire? I'm using this for quite some time without issues For some reason my microphone ends up sounding extremely bad if I enable pipewire. I have spent exactly zero time investigating this | 19:47:51 |
| blitz | In reply to @elvishjerricco:matrix.org
For some reason my microphone ends up sounding extremely bad if I enable pipewire. I have spent exactly zero time investigating this Bluetooth? | 20:06:33 |
| ElvishJerricco | blitz: I was not using bluetooth, no | 20:21:20 |
| ElvishJerricco | USB mic and motherboard analog audio out | 20:21:53 |
| blitz | Ah that sucks | 20:54:19 |
| 4 Sep 2024 |
|  Philip Taron (UTC-8) joined the room. | 21:38:14 |
|  emily joined the room. | 21:41:50 |
| ElvishJerricco | Jan Tojnar: Ok, we've made a lot of progress understanding this bug. Here's the short version. It's not specific to systemd-initrd, and it's not specific to plymouth. Those things just seem to make a race condition more likely to trigger the problem.
The problem is simply that there is no reason that GDM wouldn't put GNOME on tty1. The only thing that would prevent it would be getty@tty1.service starting earlier than GNOME, but in the auto-login case that's a race condition. So the result is that when getty@tty1.service does start, GNOME crashes. And it gets worse. Because we still have multi-user.target: Wants=network-online.target, and because getty@.service has Type=idle, that means that you get this issue, where logging in within 5 seconds while networking is still connecting results in the same crash.
| 21:43:00 |
| ElvishJerricco | So, I think the solution is to build GDM with -Dinitial-vt=1. We don't do this now because switch-to-configuration is rather clumsy in how it starts new units. So it sees that getty@tty1.service isn't started and includes it in the list of things to start. Then GDM's display-manger.service: Conflicts=getty@tty${initialVT}.service results in display-manager.service getting killed.
But we think we can fix this by being smarter about starting new units. If switch-to-configuration's start logic is changed to simply doing systemctl start default.target, it will correctly consider the Conflicts= directive, and the unit with the directive will win, meaning getty@tty1.service won't be started and display-manager.service won't be stopped.
| 21:45:24 |
| ElvishJerricco | My only remaining question is why doesn't plymouth count as having tty1 open when GNOME starts? It is indeed still running at that time, at least in the autologin case. Plymouth must be opening tty1 in such a way that it doesn't count for VT_OPENQRY. And I did check; plymouthd did have tty1 open according to lsof. | 22:00:45 |
| ElvishJerricco | hm actually plymouth may have only had tty1 open because of plymouth:debug. I'm not actually sure. It should be using DRM for the actual display | 22:13:00 |
| ElvishJerricco | would have to check | 22:13:19 |
| 5 Sep 2024 |
| ElvishJerricco | agh, no I still don't fully understand. It's only a race condition in the autologin case if plymouth is not enabled. When plymouth is enabled, it results in getty@tty1.service being delayed until 20 seconds after GDM starts, as described in the issue. Which means I still have no idea what causes GNOME to randomly start on tty1 or tty2 in that case. | 00:59:44 |
| ElvishJerricco | Regardless, putting GDM on tty1 will solve it | 00:59:58 |
| K900 | @Jan Tojnar can I get a final OK on the Orca thing | 09:07:40 |
