Prompt on wrong monitor

LucenLuc · 28 September 2024 11:21

Hi, It’s my first topic.

My garuda-inxi:

System:
  Kernel: 6.10.10-zen1-1-zen arch: x86_64 bits: 64 compiler: gcc v: 14.2.1
    clocksource: tsc avail: hpet,acpi_pm
    parameters: BOOT_IMAGE=/@/boot/vmlinuz-linux-zen
    root=UUID=1b079d8b-58a3-4533-8245-22b97207f1e1 rw rootflags=subvol=@
    quiet loglevel=3 ibt=off
  Desktop: KDE Plasma v: 6.1.5 tk: Qt v: N/A info: frameworks v: 6.6.0
    wm: kwin_x11 vt: 2 dm: SDDM Distro: Garuda base: Arch Linux
Machine:
  Type: Desktop System: Gigabyte product: Z390 AORUS PRO v: N/A
    serial: <superuser required>
  Mobo: Gigabyte model: Z390 AORUS PRO-CF serial: <superuser required>
    uuid: <superuser required> UEFI: American Megatrends v: F13 date: 12/21/2023
CPU:
  Info: model: Intel Core i9-9900K bits: 64 type: MT MCP arch: Coffee Lake
    gen: core 9 level: v3 note: check built: 2018 process: Intel 14nm family: 6
    model-id: 0x9E (158) stepping: 0xD (13) microcode: 0x100
  Topology: cpus: 1x dies: 1 clusters: 8 cores: 8 threads: 16 tpc: 2
    smt: enabled cache: L1: 512 KiB desc: d-8x32 KiB; i-8x32 KiB L2: 2 MiB
    desc: 8x256 KiB L3: 16 MiB desc: 1x16 MiB
  Speed (MHz): avg: 800 min/max: 800/5000 scaling: driver: intel_pstate
    governor: powersave cores: 1: 800 2: 800 3: 800 4: 800 5: 800 6: 800 7: 800
    8: 800 9: 800 10: 800 11: 800 12: 800 13: 800 14: 800 15: 800 16: 800
    bogomips: 115200
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
  Vulnerabilities: <filter>
Graphics:
  Device-1: NVIDIA TU104 [GeForce RTX 2080 SUPER] vendor: Gigabyte
    driver: nvidia v: 560.35.03 alternate: nouveau,nvidia_drm non-free: 550.xx+
    status: current (as of 2024-09; EOL~2026-12-xx) arch: Turing code: TUxxx
    process: TSMC 12nm FF built: 2018-2022 pcie: gen: 3 speed: 8 GT/s
    lanes: 16 ports: active: none off: DP-2,DP-3
    empty: DP-1,HDMI-A-1,Unknown-2 bus-ID: 01:00.0 chip-ID: 10de:1e81
    class-ID: 0300
  Display: x11 server: X.Org v: 21.1.13 with: Xwayland v: 24.1.2
    compositor: kwin_x11 driver: X: loaded: nvidia unloaded: modesetting
    alternate: fbdev,nouveau,nv,vesa gpu: nvidia,nvidia-nvswitch
    display-ID: :0 screens: 1
  Screen-1: 0 s-res: 3926x1440 s-dpi: 108 s-size: 923x342mm (36.34x13.46")
    s-diag: 984mm (38.75")
  Monitor-1: DP-2 note: disabled pos: primary,top-right
    model: Asus ROG PG279Q serial: <filter> built: 2017 res: 2560x1440 hz: 60
    dpi: 109 gamma: 1.2 size: 598x336mm (23.54x13.23") diag: 686mm (27")
    ratio: 16:9 modes: max: 2560x1440 min: 640x480
  Monitor-2: DP-3 mapped: DP-5 note: disabled pos: bottom-l
    model: Philips 191EL serial: <filter> built: 2010 res: 1366x768 hz: 60
    dpi: 85 gamma: 1.2 size: 410x230mm (16.14x9.06") diag: 470mm (18.5")
    ratio: 16:9 modes: max: 1366x768 min: 640x480
  API: EGL v: 1.5 hw: drv: nvidia platforms: device: 0 drv: nvidia device: 2
    drv: swrast gbm: drv: nvidia surfaceless: drv: nvidia x11: drv: nvidia
    inactive: wayland,device-1
  API: OpenGL v: 4.6.0 compat-v: 4.5 vendor: nvidia mesa v: 560.35.03
    glx-v: 1.4 direct-render: yes renderer: NVIDIA GeForce RTX 2080
    SUPER/PCIe/SSE2 memory: 7.81 GiB
  API: Vulkan v: 1.3.295 layers: 11 device: 0 type: discrete-gpu name: NVIDIA
    GeForce RTX 2080 SUPER driver: nvidia v: 560.35.03 device-ID: 10de:1e81
    surfaces: xcb,xlib
Audio:
  Device-1: NVIDIA TU104 HD Audio vendor: Gigabyte driver: snd_hda_intel
    v: kernel pcie: gen: 3 speed: 8 GT/s lanes: 16 bus-ID: 01:00.1
    chip-ID: 10de:10f8 class-ID: 0403
  Device-2: Creative Labs CA0132 Sound Core3D [Sound Blaster Recon3D /
    Z-Series BlasterX AE-5 Plus] driver: snd_hda_intel v: kernel pcie: gen: 1
    speed: 2.5 GT/s lanes: 1 bus-ID: 04:00.0 chip-ID: 1102:0012 class-ID: 0403
  API: ALSA v: k6.10.10-zen1-1-zen status: kernel-api with: aoss
    type: oss-emulator tools: N/A
  Server-1: PipeWire v: 1.2.4 status: active with: 1: pipewire-pulse
    status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
    4: pw-jack type: plugin tools: pactl,pw-cat,pw-cli,wpctl
Network:
  Device-1: Intel Ethernet I219-V vendor: Gigabyte driver: e1000e v: kernel
    port: N/A bus-ID: 00:1f.6 chip-ID: 8086:15bc class-ID: 0200
  IF: eno1 state: up speed: 1000 Mbps duplex: full mac: <filter>
  Info: services: NetworkManager, smbd, systemd-timesyncd
Drives:
  Local Storage: total: 3.18 TiB used: 1.23 TiB (38.7%)
  SMART Message: Unable to run smartctl. Root privileges required.
  ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Crucial model: CT1000P5SSD8
    size: 931.51 GiB block-size: physical: 512 B logical: 512 B speed: 31.6 Gb/s
    lanes: 4 tech: SSD serial: <filter> fw-rev: P4CR313 temp: 31.9 C
    scheme: GPT
  ID-2: /dev/sda maj-min: 8:0 vendor: Crucial model: CT500MX500SSD1
    size: 465.76 GiB block-size: physical: 512 B logical: 512 B speed: 6.0 Gb/s
    tech: SSD serial: <filter> fw-rev: 023 scheme: GPT
  ID-3: /dev/sdb maj-min: 8:16 vendor: Seagate model: ST2000DM001-1CH164
    size: 1.82 TiB block-size: physical: 4096 B logical: 512 B speed: 6.0 Gb/s
    tech: HDD rpm: 7200 serial: <filter> fw-rev: CC27 scheme: MBR
Partition:
  ID-1: / raw-size: 465.46 GiB size: 465.46 GiB (100.00%)
    used: 157.43 GiB (33.8%) fs: btrfs dev: /dev/sda2 maj-min: 8:2
  ID-2: /boot/efi raw-size: 300 MiB size: 299.4 MiB (99.80%)
    used: 596 KiB (0.2%) fs: vfat dev: /dev/sda1 maj-min: 8:1
  ID-3: /home raw-size: 465.46 GiB size: 465.46 GiB (100.00%)
    used: 157.43 GiB (33.8%) fs: btrfs dev: /dev/sda2 maj-min: 8:2
  ID-4: /var/log raw-size: 465.46 GiB size: 465.46 GiB (100.00%)
    used: 157.43 GiB (33.8%) fs: btrfs dev: /dev/sda2 maj-min: 8:2
  ID-5: /var/tmp raw-size: 465.46 GiB size: 465.46 GiB (100.00%)
    used: 157.43 GiB (33.8%) fs: btrfs dev: /dev/sda2 maj-min: 8:2
Swap:
  Kernel: swappiness: 133 (default 60) cache-pressure: 100 (default) zswap: no
  ID-1: swap-1 type: zram size: 31.27 GiB used: 0 KiB (0.0%) priority: 100
    comp: zstd avail: lzo,lzo-rle,lz4,lz4hc,842 max-streams: 16 dev: /dev/zram0
Sensors:
  System Temperatures: cpu: 36.0 C pch: 37.0 C mobo: N/A gpu: nvidia
    temp: 42 C
  Fan Speeds (rpm): N/A gpu: nvidia fan: 0%
Info:
  Memory: total: 32 GiB available: 31.27 GiB used: 2.84 GiB (9.1%)
  Processes: 388 Power: uptime: 4m states: freeze,mem,disk suspend: deep
    avail: s2idle wakeups: 0 hibernate: platform avail: shutdown, reboot,
    suspend, test_resume image: 12.46 GiB services: org_kde_powerdevil,
    power-profiles-daemon, upowerd Init: systemd v: 256 default: graphical
    tool: systemctl
  Packages: pm: pacman pkgs: 1974 libs: 574 tools: octopi,pamac,paru
    Compilers: clang: 18.1.8 gcc: 14.2.1 Shell: garuda-inxi default: fish
    v: 3.7.1 running-in: konsole inxi: 3.3.36
Garuda (2.6.26-1):
  System install date:     2024-08-17
  Last full system update: 2024-09-26
  Is partially upgraded:   No
  Relevant software:       snapper NetworkManager dracut nvidia-dkms
  Windows dual boot:       Probably (Run as root to verify)
  Failed units:

It is not really a problem, but rather a nuisance, a degradation of the quality of life? I don’t know. That’s why I post it here.
Every time I start, my login screen, it pops up with the pormpt to type my password on the wrong screen, the one on the left, when my main screen is the one right in front of me. In the picture, I indicate it with a red arrow (wrong place):

I would like to write, my password, on the center screen (Asus 27"). I know that more than one will think “what’s the difference” is just to write the password, but for me it is to get knowledge of how Linux works in the boot process. I know that the X server has to start first, then the window manager, in my case KWin. I have followed the Display Manager multi-monitor configuration tutorial, it is excellent, I also read on the ArckWiki Multihead, as well as other sources and places on the internet, but there is something that escapes me because I either don’t know or didn’t understand it and I can’t get my 27” screen to be the primary (I think it is called that). Below is my dm-multimonitor.sh file:

File: /etc/X11/xorg.conf.d/dm-multimonitor.sh
#!/bin/sh
# get the correct actual monitor names with
# xrandr | awk ' /connected/ { print $1, $2 }'
mon1=DP-2
mon2=DP-5
# wait 3
if xrandr | grep "$mon2 disconnected"; then
xrandr --output "$mon2" --off --output "$mon1" --auto
elif xrandr | grep "$mon1 disconnected"; then
xrandr --output "$mon1" --off --output "$mon2" --auto
else
xrandr --output "$mon1" --primary --mode 2560x1440 --pos 1366x0 --output "$mon2" --mode 1366x768 --pos 0x672
fi

If anyone can point me to where I can find the information related to this, I would appreciate it.

Kayo · 28 September 2024 14:54

It is a pretty long running issue in sddm since version 0.20

github.com/sddm/sddm

Update to 0.20: Session starts focus on wrong monitor

opened 12:38AM - 27 Jun 23 UTC

satheevrin

Upon updating sddm to the most recent release, I have now noticed that whenever …I start my session, focus starts on my secondary monitor and not my primary one. (The secondary monitor being to my right, while my primary monitor is in front of me). I have had to downgrade sddm to its previous version for the timebeing (which fixed this behaviour, obviously) and ignore it with my package manager, but I thought it would be helpful for me and maybe everyone else using Arch to bring this here. I have tested this in a virtual machine and have been able to reproduce it there. Any idea what could be done to fix this and yet still use the new version? I would like the behavior to go back to focusing my text on my primary monitor than it would my secondary. I have a thread here explaining more of the problem that led me to the git project here: https://bbs.archlinux.org/viewtopic.php?pid=2107020

There are a few ideas at the issue link how to configure /usr/share/sddm/scripts/Xsetup

Requires this line to be added into /etc/sddm.conf to work:

DisplayCommand=/usr/share/sddm/scripts/Xsetup

Be sure to get your monitor names with this command while being in a X11 session:

xrandr | grep -w connected

(I know you use X11, but I wanted to state that just in case somebody that normally uses Wayland also has this multi-monitor sddm issue and sees this thread. Monitor names are different across session types and the script uses X)

petsam · 28 September 2024 23:59

Normally, you should be able to move your mouse to both monitors, and use any monitor independently.
As you describe it, it sounds like there is a primary monitor, but not the preferred one, which means that SDDM recognizes two monitors, and the setup is not a cloned type.
Can’t you do that on SDDM? What exactly is the behavior?

I have updated the script (on my PC) to include a logging feature.
Maybe it can help on troubleshooting.

#!/usr/bin/bash

#### Debug info
[ -n "$1" ] && _Debug="$1"
[ "$_Debug" ] && _log="$(mktemp -u -p /tmp dmXsetup-XXXX.log)"
[ "$_Debug" ] && date | tee -a "$_log"
declare -a AllMOnitors MyParams

PreferedMonitor="HDMI-1"
FallbackMonitor="HDMI"

# Create a list with connected monitors
mapfile -t AllMOnitors < <( xrandr --current | grep -w connected | cut -d" " -f 1 )

#### Debug info
[ "$_Debug" ] && echo -e "\nAllMOnitors:\t${AllMOnitors[*]@Q}\n" | tee -a "$_log"
[ "$_Debug" ] && xrandr --current --listmonitors | tee -a "$_log"
[ "$_Debug" ] && echo -e "\n" | tee -a "$_log"

# Use PreferedMonitor, if it is found
for _output in "${AllMOnitors[@]}"; do
        [ "$_output" = "$PreferedMonitor" ] && LeftMonitor="$_output" && break
done

#### Debug info
[ "$_Debug" ] && echo -e "Prefered LeftMonitor:\t${LeftMonitor@Q}" | tee -a "$_log"

# If PreferedMonitor is not found, find first monitor of preferred type
if [ -z "$LeftMonitor" ]; then
        for monitor in "${AllMOnitors[@]}"; do
                if [[ "$monitor" == ${FallbackMonitor}* ]]; then
                        LeftMonitor="$monitor"
                        break
                fi
        done
fi

#### Debug info
[ "$_Debug" ] && echo -e "Fallback LeftMonitor:\t${LeftMonitor@Q}" | tee -a "$_log"


# If none found, find auto-set, or configured in xorg conf files as primary
if [ -z "$LeftMonitor" ]; then
        LeftMonitor="$(xrandr --current | grep -w connected | grep -w primary | cut -d" " -f1 2>/dev/null )"
fi

#### Debug info
[ "$_Debug" ] && echo -e "Xorg/auto LeftMonitor:\t${LeftMonitor@Q}" | tee -a "$_log"

# If still noone is found, use 1st listed
if [ -z "$LeftMonitor" ]; then
        LeftMonitor="${AllMOnitors[0]}"
fi

#### Debug info
[ "$_Debug" ] && echo -e "Desparate LeftMonitor:\t${LeftMonitor@Q}" | tee -a "$_log"

if [ -n "$LeftMonitor" ]; then
        MyParams+=( "--output $LeftMonitor --auto --primary" )
        PrevMon="$LeftMonitor"
else
        # If still failing to set Left/Primary monitor, use auto and exit Xsetup script
        xrandr --auto
        exit 0
fi

#### Debug info
[ "$_Debug" ] && echo -e "\nFinal LeftMonitor: ${PrevMon@Q}\tParameters=${MyParams[*]@Q}\n" | tee -a "$_log"

        #### Debug info
        [ "$_Debug" ] && echo -en "Monitor setup:\t${PrevMon@Q}" | tee -a "$_log"

# Form xrandr params, with all monitors from left to right
for mname in "${AllMOnitors[@]}" ; do
        [ "$mname" = "$LeftMonitor" ] && continue ;
        MyParams+=( "--output $mname --auto" )
        [ -n "$PrevMon" ] && MyParams+=( "--right-of $PrevMon" )
        PrevMon="$mname"
        #### Debug info
        [ "$_Debug" ] && echo -en " ${PrevMon@Q}" | tee -a "$_log"
done

#### Debug info
[ "$_Debug" ] && echo -e "\nRun command: xrandr ${MyParams[*]}\n" | tee -a "$_log"

[ "$_Debug" = "print" ] || xrandr ${MyParams[*]}

[ "$_Debug" ] && xrandr --current --listmonitors | tee -a "$_log"

Usage:

Create a file with the above content, changing the values for your setup

PreferedMonitor="HDMI-1" # Target primary monitor
FallbackMonitor="HDMI" # Type of output, in case number changes during reboot

Make it executable and copy it at /etc/X11/xorg.conf.d/dm-multihead.sh
Test what the script would print in your user session. It does not change current monitor layout.

sh /etc/X11/xorg.conf.d/dm-multihead.sh print

Configure SDDM to run in x11, creating (or modifying) a custom file at /etc/sddm.conf.d/ with any filename you want (i.e. /etc/sddm.conf.d/X11setup.conf) with the following contents:

 [General]
DisplayServer=x11

[X11]
# Use debug parameter to create a log file at /tmp .
DisplayCommand=/etc/X11/xorg.conf.d/dm-multihead.sh debug
# DisplayCommand=/etc/X11/xorg.conf.d/dm-multihead.sh

Reboot and after logging into your user session, check for the script logs in journal and in /tmp (look for something like /tmp/dmXsetup-XXXX.log)

Depending on the logs, you may change the monitor names accordingly.

Kayo · 29 September 2024 01:57

I just tested the somewhat hacky method of shutting the secondary monitor off and then assigning the primary and secondary monitor in /usr/share/sddm/scripts/Xsetup
(The focus still starts at the other screen if not shutting the monitor off via the script)

Following the instructions at the issue link in my other post, and finding the monitor names while in a X11 session using xrandr | grep -w connected command, I added this in /usr/share/sddm/scripts/Xsetup

xrandr --output DisplayPort-1 --off
xrandr --output DisplayPort-0 --auto --primary
xrandr --output DisplayPort-1 --auto --noprimary

Also, I did not have to add the script path to any file as it is already defined in the default configuration file located at /usr/lib/sddm/sddm.conf.d/default.conf

I’m just hoping the experimental Wayland greeter doesn’t need these kind of workarounds once it comes out of the experimental stage. Not sure why sddm is ignoring some settings, but I’ve seen similar workarounds posted on the internet so it seems to be a long running issue.

elite · 29 September 2024 04:51

It can also help to note down witch display is on which port. DP1 - 4 or HDMI 1 - 4 the primary normally sets it self to what every your gpu decides is its main display. At least thats where i would start

LucenLuc · 29 September 2024 17:22

I will take it one step at a time:

@elite Yes, I know which display my GPU activates as main, in my case it’s the ASUS 27’, in xandr: DP-2. It’s where I see my firmware (BIOS), for example. Thanks for pointing that out it’s a pretty important detail and that’s why I wanted to name you first.

@Kayo Ah! it’s a bug. I thought it was because I wasn’t doing something right! Indeed I realised after several days that even if I changed the settings, it had no effect. From the beginning I had my 17’ Philips monitor on my right and to move the mouse to that monitor I had to go to that direction, when physically it’s on my left (I’ve seen that’s how it appears to many people by default). Until I remembered that the X server is started first, so if I wanted to change the SDDM configuration, I would have to start in X11 and from there look at the xrandr output and indeed there it showed me another device name for my Philips monitor: DP-5, when in the Wayland session it shows DP-3.

╰─λ xrandr | grep -w connected
DP-2 connected primary 2560x1440+1366+0 (normal left inverted right x axis y axis) 598mm x 336mm
DP-5 connected 1366x768+0+672 (normal left inverted right x axis y axis) 410mm x 230mm

Unfortunately, your method of turning the second monitor off and on didn’t work for me. According to what I have put in this comment, I have put it like this:

File: Xsetup
#!/bin/sh
# Xsetup - run as root before the login dialog appears
xrandr --output DP-5 --off
xrandr --output DP-2 --auto --primary
xrandr --output DP-5 --auto --noprimary

did I do something wrong?

@petsam The behaviour I have is that of two independent monitors. Asus 27‘ monitor which is the main one (or so I try) xrandr = DP-2 and the secondary Philips 19’ monitor, xrandr = DP-5. Currently I can move my mouse smoothly from the primary to the secondary monitor, going to the left, and if I type the password it is only typed on the monitor which is selected. On the other hand if I use ‘system settings - Login screen (SDDM) - Apply Plasma preferences’. It has no effect. In my language:

I tried to use the script you provided, but it gives me the following error when I run:

[🔍] × sh /etc/X11/xorg.conf.d/dm-multihead.sh print
sh: /etc/X11/xorg.conf.d/dm-multihead.sh: No existe el fichero o el directorio

This is the script that I understood that I have to do:

!/usr/bin/bash

#### Debug info
[ -n "$1" ] && _Debug="$1"
[ "$_Debug" ] && _log="$(mktemp -u -p /tmp dmXsetup-XXXX.log)"
[ "$_Debug" ] && date | tee -a "$_log"
declare -a AllMOnitors MyParams

PreferedMonitor="DP-2"
FallbackMonitor="DP"

# Create a list with connected monitors
mapfile -t AllMOnitors < <( xrandr --current | grep -w connected | cut -d" " -f 1 )

#### Debug info
[ "$_Debug" ] && echo -e "\nAllMOnitors:\t${AllMOnitors[*]@Q}\n" | tee -a "$_log"
[ "$_Debug" ] && xrandr --current --listmonitors | tee -a "$_log"
[ "$_Debug" ] && echo -e "\n" | tee -a "$_log"

# Use PreferedMonitor, if it is found
for _output in "${AllMOnitors[@]}"; do
        [ "$_output" = "$PreferedMonitor" ] && LeftMonitor="$_output" && break
done

#### Debug info
[ "$_Debug" ] && echo -e "Prefered LeftMonitor:\t${LeftMonitor@Q}" | tee -a "$_log"

# If PreferedMonitor is not found, find first monitor of preferred type
if [ -z "$LeftMonitor" ]; then
        for monitor in "${AllMOnitors[@]}"; do
                if [[ "$monitor" == ${FallbackMonitor}* ]]; then
                        LeftMonitor="$monitor"
                        break
                fi
        done
fi

#### Debug info
[ "$_Debug" ] && echo -e "Fallback LeftMonitor:\t${LeftMonitor@Q}" | tee -a "$_log"


# If none found, find auto-set, or configured in xorg conf files as primary
if [ -z "$LeftMonitor" ]; then
        LeftMonitor="$(xrandr --current | grep -w connected | grep -w primary | cut -d" " -f1 2>/dev/null )"
fi

#### Debug info
[ "$_Debug" ] && echo -e "Xorg/auto LeftMonitor:\t${LeftMonitor@Q}" | tee -a "$_log"

# If still noone is found, use 1st listed
if [ -z "$LeftMonitor" ]; then
        LeftMonitor="${AllMOnitors[0]}"
fi

#### Debug info
[ "$_Debug" ] && echo -e "Desparate LeftMonitor:\t${LeftMonitor@Q}" | tee -a "$_log"

if [ -n "$LeftMonitor" ]; then
        MyParams+=( "--output $LeftMonitor --auto --primary" )
        PrevMon="$LeftMonitor"
else
        # If still failing to set Left/Primary monitor, use auto and exit Xsetup script
        xrandr --auto
        exit 0
fi

#### Debug info
[ "$_Debug" ] && echo -e "\nFinal LeftMonitor: ${PrevMon@Q}\tParameters=${MyParams[*]@Q}\n" | tee -a "$_log"

        #### Debug info
        [ "$_Debug" ] && echo -en "Monitor setup:\t${PrevMon@Q}" | tee -a "$_log"

# Form xrandr params, with all monitors from left to right
for mname in "${AllMOnitors[@]}" ; do
        [ "$mname" = "$LeftMonitor" ] && continue ;
        MyParams+=( "--output $mname --auto" )
        [ -n "$PrevMon" ] && MyParams+=( "--right-of $PrevMon" )
        PrevMon="$mname"
        #### Debug info
        [ "$_Debug" ] && echo -en " ${PrevMon@Q}" | tee -a "$_log"
done

#### Debug info
[ "$_Debug" ] && echo -e "\nRun command: xrandr ${MyParams[*]}\n" | tee -a "$_log"

[ "$_Debug" = "print" ] || xrandr ${MyParams[*]}

[ "$_Debug" ] && xrandr --current --listmonitors | tee -a "$_log"

And I haven’t continued, am I missing or do I have to do something?

…And thaks a lot, folks!

Scoobin · 9 October 2024 03:57

Did you make any further progress with this? I’m currently having the same issue. It’s not a massive problem just a user experience thing. Thanks to this thread though I did manage to solve my bigger issue, that my external (primary) monitor would strangely turn off when I got to the login prompt, so I had to use my laptop (secondary) monitor. Only Fedora I found did everything correctly but I couldn’t figure out how. But anyway on Garuda both monitors are on but SDDM still thinks laptop is primary. Once logged in Plasma gets it correct.

Hopefully KDE gets SDDM more in line with the logged in experience. Using the ‘Apply Plasma Settings’ to SDDM under system settings only managed to give me a consistent mouse cursor. When I was on Manjaro that Apply button actually broke SDDM and I had to roll-back the snapshot.

LucenLuc · 10 October 2024 11:25

No, not really. My knowledge is limited, and I have not been able to find out more. I know they have deployed a new version of KDE Plasma, 6.2.0, but I don’t hear that they have fixed it yet, although I haven’t tested this latest version yet. Here’s their Changelog:

Edit.- But as mentioned above, it has more to do with fixing the bug in SDDM.

system · 24 October 2024 11:25

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.