0x7f9d0fc9e000 | Main                 | INFO  | 2026-09-19 12:38:47,112 | Show splash screen message: Checking Licenses
sh: line 1: python2: command not found
0x7f9a38dfd000 | Main                 | INFO  | 2026-09-19 12:38:47,742 | Started listener socket at port 15000
0x7f9a395fe000 | Main                 | ERROR | 2026-09-19 12:38:47,743 | Failed to read mac address from interface , using default value of '00:00:00:00:00:00'

Those lines are weird , how did you install DR ?

0x7f9d0fc9e000 | Main                 | INFO  | 2026-09-19 12:38:46,523 | Running DaVinci Resolve Studio v21.0.4.0005 (Linux/Clang x86_64)

Aur davinci-resolve & davinci-resolve-studio were updated to 21.1.1 just a few days ago, have you tried with that version ?

Please read the whole thread before responding.
I recommend you also read http://www.catb.org/~esr/faqs/smart-questions.html thoroughly .

TBH I feel like it's kinda systemd's fault for not providing visibility on what it's doing here. A feature request might be in order, but you might want to make sure there is really no way to make it more verbose. (e.g. Asking in systemd's IRC or Matrix chat)
I tried adding "LogLevelMax=debug" to systemd-tpm2-setup.service, but it's still nowhere near as verbose as some other units.

Are the fans controlled by firmware or OS?

they're controlled by firmware, but i've just remembered i have power profile daemon active that could have an impact on how the cpu behaves

nope, everything on that side remained like the day i bought it. as i said, i just have power profile daemon but it's usually in balanced mode

also, i just woke up the laptop since it was in sleep mode all night and the idle temperature is between 40 and 50 C. ill check for dust

I'm troubleshooting an intermittent SDDM/multi-monitor black-screen problem on Arch Linux with NVIDIA.

The problem started around Thursday. Before that, this multi-monitor setup had been operating normally.

Relevant setup:

- Arch Linux
- KDE Plasma
- Plasma session: Wayland
- SDDM: X11
- SDDM theme: Breeze
- NVIDIA open kernel modules
- nvidia-open 615.71.09-3
- nvidia-utils 615.71.09-1
- linux 7.2.6.arch2-1
- linux-lts 6.18.52-1
- Three-monitor setup
- One monitor is an ASUS XG27UCG with dual-mode functionality

Timeline:

On Thursday I performed a normal Arch system update. That update included a new NVIDIA driver.

Later that same day, after playing CS2, I switched the ASUS XG27UCG using its dual-mode function (4K <-> 1080p/high-refresh mode).

Immediately after changing the monitor mode, all three monitors went black.

The system subsequently reported NVIDIA DRM errors similar to:

[drm:nv_drm_atomic_commit [nvidia_drm]] *ERROR*
[nvidia-drm] [GPU ID ...] Flip event timeout on head 0

I initially treated this as a runtime display/mode-switching issue.

Since that day, however, I have also started seeing intermittent problems while the displays are being initialized during boot/SDDM.

The behavior is not consistent between boots.

On one boot, SDDM appeared but monitor detection seemed unusually slow.

On another boot, all monitors remained black when SDDM should have appeared. The computer itself had NOT frozen. Ctrl+Alt+F3 successfully switched to a TTY and I could log in and use the system normally from there.

On the next successful boot, SDDM appeared, but one monitor remained black at the login screen. As soon as I logged into the Plasma Wayland session, that monitor initialized and operated normally.

This made me investigate SDDM separately from Plasma.

During the boot where all monitors remained black, I captured the failure from the TTY.

sddm-greeter-qt6 had crashed:

PID: 1327 (sddm-greeter-qt)
TID: 1372 (QSGRenderThread)
UID: 963 (sddm)
Signal: 11 (SEGV) si_code: SEGV_MAPERR
Command Line: /usr/bin/sddm-greeter-qt6 [...] --theme /usr/share/sddm/themes/breeze
Executable: /usr/bin/sddm-greeter-qt6

The relevant part of the crashing QSGRenderThread stack is:

Stack trace of thread 1372:

#0  n/a (libnvidia-glcore.so.615.71.09 + 0xb2f1f5)
#1  n/a (libnvidia-glcore.so.615.71.09 + 0x7e73c0)
#2  n/a (libnvidia-glcore.so.615.71.09 + 0x7e8941)
#3  n/a (libnvidia-glcore.so.615.71.09 + 0x7e8b34)
#4  n/a (libQt6Gui.so.6 + 0x5e21c3)
#5  n/a (libQt6Gui.so.6 + 0x5e6f07)
#6  n/a (libQt6Gui.so.6 + 0x5dd3bf)
#7  QRhi::endFrame(...) (libQt6Gui.so.6 + 0x42d0a7)
#8  n/a (libQt6Quick.so.6 + 0x4c2eb8)

The SDDM greeter stack also contains the XCB/X11 Qt platform components:

libQt6XcbQpa.so.6
libxcb.so.1
xcb_wait_for_event

I then checked my SDDM configuration.

There is no custom DisplayServer override in /etc/sddm.conf or /etc/sddm.conf.d/.

The packaged SDDM configuration currently contains:

[General]
DisplayServer=x11

[Wayland]
CompositorCommand=weston --shell=kiosk
SessionCommand=/usr/share/sddm/scripts/wayland-session

[X11]
SessionCommand=/usr/share/sddm/scripts/Xsession

Therefore Plasma is running Wayland after login, while the SDDM greeter itself is running through X11/XCB.

I also found other Arch forum discussions suggesting early NVIDIA KMS as something to check for SDDM startup/display initialization problems.

However, my /etc/mkinitcpio.conf already contains:

MODULES=(nvidia nvidia_modeset nvidia_uvm nvidia_drm)

So the NVIDIA modules are already explicitly included in the initramfs.

I have not yet:

- switched SDDM from X11 to Wayland
- added an artificial delay before SDDM starts
- downgraded the NVIDIA driver
- changed the NVIDIA initramfs configuration

I wanted to collect evidence from an actual failed boot before changing the configuration.

The system is currently able to boot and run Plasma normally. On a successful boot I have no NVIDIA errors at journal priority 3, no priority 2 errors, and systemctl --failed reports zero failed units.

The timing is what makes me suspicious:

Thursday:
Arch update including new NVIDIA driver
    ->
CS2
    ->
ASUS dual-mode switch
    ->
all monitors black
    ->
NVIDIA DRM flip-event timeout

Following boots:
intermittent monitor initialization problems
    ->
one completely black SDDM boot
    ->
TTY still functional
    ->
sddm-greeter-qt6 QSGRenderThread SIGSEGV
    ->
stack trace enters libnvidia-glcore.so.615.71.09

I don't want to assume that the NVIDIA update, the dual-mode/flip-timeout incident, and the later SDDM crash necessarily have the same underlying cause, but the timing seemed relevant enough to include.

Does this look more like:

1. SDDM starting before the NVIDIA/multi-monitor stack is completely ready,
2. an NVIDIA/Qt6 rendering issue affecting the X11 SDDM greeter,
3. or a display initialization/race issue related to the current NVIDIA driver?

Since early NVIDIA KMS is already configured, would delaying SDDM be a reasonable diagnostic step?

Would testing SDDM under Wayland be useful, or would it be better to leave the current configuration unchanged until the cause is better established?

Also, could the earlier NVIDIA DRM flip-event timeout triggered by the monitor's dual-mode switch be relevant to the later SDDM failures?

I can provide additional journal output, package versions, SDDM logs, or boot timing information if needed.

Thanks.

Try using audacity to select the USB input source to check if the microphone is working. If it works fine, then you need to change the default input source for recording, using alsa tools or pavucontrol.

When enabling autostart inside of Discord settings it points to ~/.config/discord/app-*/Discord as-well.
Updating Discord doesn't update autostart, same with closing and re-opening discord after the update.

The only way I got discord to update autostart is to disable and re-enable it inside of Discord settings.

I had to do the same solution where I disabled autostart inside of Discord then re-add Discord to autostart through the KDE UI which points to /usr/bin/discord.