Cinnamon/Muffin issue with how the hardware cursor plane is sized and positioned across CRTCs when outputs have different scale factors (

[ultra40-beep]

Hardware: ASUS Zenbook 14 UX3405MA, Intel Meteor Lake-P / Arc Graphics (i915), iiyama XCB3494WQSN-B5 external monitor (3440x1440 @ 120Hz)
Setup: Fractional scaling enabled, "Scale content up" mode, eDP-1 at 1440x900 (effective ~2x scale of native 2880x1800), DP-1 at 3440x1440 @ 1x, side-by-side with vertical Y-overlap between the two
Symptom: On DP-1, anywhere within the Y-range that overlaps eDP-1's vertical extent, the mouse cursor pulses visible/invisible at roughly 1Hz — happens whether stationary or moving, over windows and bare desktop alike. Below that overlap band (where only DP-1's CRTC applies), the cursor is stable. Crossing the overlap boundary, the cursor briefly renders as a flattened horizontal line.
What was ruled out: Confirmed via /sys/kernel/debug/dri/.../DP-1/i915_psr_status that the monitor doesn't support PSR or Panel Replay at all, so this isn't a PSR-related timing issue. Refresh-rate mismatch (59.97Hz vs 60Hz) was tested and ruled out — the pulsing persists even at a clean 120Hz harmonic rate. Forcing software cursor rendering via Option "SWcursor" "true" changes the artifact's character (disappearing → pulsing/horizontal-line) but doesn't eliminate it — suggesting this is specifically about how the cursor plane/sprite is composited across two CRTCs with mismatched scale factors in their overlapping region.

inxi -Fxxxz
cinnamon --version
uname -r
xrandr
System:
Kernel: 6.17.0-35-generic arch: x86_64 bits: 64 compiler: gcc v: 13.3.0
clocksource: tsc
Desktop: Cinnamon v: 6.6.7 tk: GTK v: 3.24.41 wm: Muffin v: 6.6.3 vt: 7
dm: LightDM v: 1.30.0 Distro: Linux Mint 22.3 Zena base: Ubuntu 24.04 noble
Machine:
Type: Laptop System: ASUSTeK product: ASUS Zenbook 14 UX3405MA_UX3405MA
v: 1.0 serial:
Mobo: ASUSTeK model: UX3405MA v: 1.0 serial:
uuid: UEFI: American Megatrends LLC. v: UX3405MA.311
date: 06/06/2025
Battery:
ID-1: BAT0 charge: 65.9 Wh (100.0%) condition: 65.9/75.1 Wh (87.8%)
volts: 8.6 min: 8.0 model: ASUSTeK ASUS Battery type: Li-ion serial: N/A
status: full cycles: 5
CPU:
Info: 16-core (6-mt/10-st) model: Intel Core Ultra 9 185H bits: 64
type: MST AMCP smt: enabled arch: Meteor Lake rev: 4 cache: L1: 1.6 MiB
L2: 18 MiB L3: 24 MiB
Speed (MHz): avg: 838 high: 2095 min/max: 400/4800:5100:3800:2500 cores:
1: 2000 2: 1988 3: 400 4: 2095 5: 400 6: 400 7: 400 8: 400 9: 2002 10: 400
11: 2002 12: 400 13: 1108 14: 1260 15: 400 16: 400 17: 400 18: 400 19: 400
20: 400 21: 400 22: 400 bogomips: 135168
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
Device-1: Intel Meteor Lake-P [Intel Arc Graphics] vendor: ASUSTeK
driver: i915 v: kernel arch: Gen-13 ports: active: DP-1,eDP-1
empty: DP-2,HDMI-A-1 bus-ID: 00:02.0 chip-ID: 8086:7d55 class-ID: 0300
Device-2: Shinetech USB2.0 FHD UVC WebCam driver: uvcvideo type: USB
rev: 2.0 speed: 480 Mb/s lanes: 1 bus-ID: 3-9:3 chip-ID: 3277:0055
class-ID: fe01 serial:
Display: x11 server: X.Org v: 21.1.11 with: Xwayland v: 23.2.6 driver: X:
loaded: modesetting dri: iris gpu: i915 display-ID: :0 screens: 1
Screen-1: 0 s-res: 4880x1595 s-dpi: 144 s-size: 861x281mm (33.90x11.06")
s-diag: 906mm (35.66")
Monitor-1: DP-1 pos: bottom-r model: Idek Iiyama PL3494WQ serial:
res: 3440x1440 dpi: 110 size: 797x334mm (31.38x13.15") diag: 864mm (34")
modes: max: 3440x1440 min: 720x400
Monitor-2: eDP-1 pos: primary,top-left model: Samsung 0x419d res: 1440x900
dpi: 121 size: 302x189mm (11.89x7.44") diag: 356mm (14") modes: 2880x1800
API: EGL v: 1.5 hw: drv: intel iris platforms: device: 0 drv: iris
device: 1 drv: swrast gbm: drv: iris surfaceless: drv: iris x11: drv: iris
inactive: wayland
API: OpenGL v: 4.6 compat-v: 4.5 vendor: intel mesa
v: 25.2.8-0ubuntu0.24.04.1 glx-v: 1.4 direct-render: yes renderer: Mesa
Intel Arc Graphics (MTL) device-ID: 8086:7d55
API: Vulkan v: 1.3.275 layers: 3 surfaces: xcb,xlib device: 0
type: integrated-gpu driver: N/A device-ID: 8086:7d55 device: 1 type: cpu
driver: N/A device-ID: 10005:0000
Audio:
Device-1: Intel Meteor Lake-P HD Audio vendor: ASUSTeK
driver: sof-audio-pci-intel-mtl bus-ID: 00:1f.3 chip-ID: 8086:7e28
class-ID: 0401
API: ALSA v: k6.17.0-35-generic status: kernel-api
Server-1: PipeWire v: 1.0.5 status: active with: 1: pipewire-pulse
status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
Network:
Device-1: Intel Meteor Lake PCH CNVi WiFi driver: iwlwifi v: kernel
bus-ID: 00:14.3 chip-ID: 8086:7e40 class-ID: 0280
IF: wlo1 state: up mac:
Device-2: Realtek RTL8153 Gigabit Ethernet Adapter driver: r8152 type: USB
rev: 2.1 speed: 480 Mb/s lanes: 1 bus-ID: 3-1.4:7 chip-ID: 0bda:8153
class-ID: 0000 serial:
IF: enx94bdbe2251fd state: down mac:
Bluetooth:
Device-1: Intel AX211 Bluetooth driver: btusb v: 0.8 type: USB rev: 2.0
speed: 12 Mb/s lanes: 1 bus-ID: 3-10:4 chip-ID: 8087:0033 class-ID: e001
Report: hciconfig ID: hci0 rfk-id: 2 state: up address: bt-v: 5.3
lmp-v: 12 sub-v: 3a27 hci-v: 12 rev: 3a27 class-ID: 7c010c
Drives:
Local Storage: total: 953.87 GiB used: 24.75 GiB (2.6%)
ID-1: /dev/nvme0n1 vendor: Micron model: MTFDKBA1T0QFM-1BD1AABGB
size: 953.87 GiB speed: 63.2 Gb/s lanes: 4 tech: SSD serial:
fw-rev: V3MA101 temp: 46.9 C scheme: GPT
Partition:
ID-1: / size: 913.75 GiB used: 24.75 GiB (2.7%) fs: ext4 dev: /dev/dm-0
mapped: vgmint-root
ID-2: /boot/efi size: 511 MiB used: 6.1 MiB (1.2%) fs: vfat
dev: /dev/nvme0n1p1
Swap:
ID-1: swap-1 type: partition size: 1.91 GiB used: 0 KiB (0.0%) priority: -2
dev: /dev/dm-1 mapped: vgmint-swap_1
Sensors:
System Temperatures: cpu: 62.0 C mobo: N/A
Fan Speeds (rpm): cpu: 2698
Info:
Memory: total: 32 GiB note: est. available: 30.71 GiB used: 4.35 GiB (14.2%)
Processes: 435 Power: uptime: 13m states: freeze,mem,disk suspend: s2idle
wakeups: 0 hibernate: platform Init: systemd v: 255 target: graphical (5)
default: graphical
Packages: pm: dpkg pkgs: 2362 Compilers: gcc: 13.3.0 Shell: Bash v: 5.2.21
running-in: gnome-terminal inxi: 3.3.34
Cinnamon 6.6.7
6.17.0-35-generic
Screen 0: minimum 320 x 200, current 4880 x 1595, maximum 16384 x 16384
eDP-1 connected primary 1440x900+0+0 (normal left inverted right x axis y axis) 302mm x 189mm
2880x1800 60.00 + 120.00*+
2880x1620 60.00
2560x1600 60.00
2560x1440 60.00
2048x1536 60.00
1920x1440 60.00
1856x1392 60.00
1792x1344 60.00
2048x1152 60.00
1920x1200 60.00
1920x1080 60.00
1600x1200 60.00
1680x1050 60.00
1400x1050 60.00
1600x900 60.00
1280x1024 60.00
1400x900 60.00
1280x960 60.00
1440x810 60.00
1368x768 60.00
1280x800 60.00
1152x864 60.00
1280x720 60.00
1024x768 60.00
1024x768i 60.00
960x720 60.00
928x696 60.00
896x672 60.00
1024x576 60.00
960x600 60.00
832x624 60.00
960x540 60.00
800x600 60.00
840x525 60.00
864x486 60.00
700x525 60.00
800x450 60.00
640x512 60.00
700x450 60.00
640x480 60.00
720x405 60.00
720x400 60.00
684x384 60.00
640x400 60.00
576x432 60.00
640x360 60.00
640x350 60.00
512x384 60.00
512x384i 60.00
512x288 60.00
416x312 60.00
480x270 60.00
400x300 60.00
432x243 60.00
320x240 60.00
360x202 60.00
360x200 60.00
320x200 60.00
320x180 60.00
320x175 60.00
DP-1 connected 3440x1440+1440+155 (normal left inverted right x axis y axis) 797mm x 334mm
3440x1440 59.97 + 120.00* 99.98
2560x1440 120.00
2560x1080 100.00 60.00 59.94
1920x1080 119.96 99.92 120.00 100.00 119.88 60.00 60.00 50.00 59.94 30.00 29.97
1680x1050 59.95
1280x1024 75.02 60.02
1440x900 59.89
1280x960 60.00
1280x800 59.81
1280x720 60.00 50.00 59.94
1024x768 75.03 70.07 60.00
832x624 74.55
800x600 72.19 75.00 60.32 56.25
720x576 50.00
720x480 60.00 59.94
640x480 75.00 72.81 66.67 60.00 59.94
720x400 70.08
DP-2 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)

Claude transcript
Claude finished the response

I am running this configuration of laptop and i have a problem with the mouse cursor flickering and intermittently disapearing when hovering in open panes. help me fix the issue -ASUS ASUS Zenbook 14 UX3405MA_UX3405MA v1.0 laptop
Intel Corporation Meteor Lake-P [Intel Arc Graphics] card driver i915 hardware acceleration enabled (open GL / Open GL ES / Vulkan / Video Playback (VA-API))
Asus MW203 mouse
iiyama XCB3494WQSN additional screen
Linux Mint 22.3 - Cinnamon 64-bit operating system
Display fractional scaling enabled in scale content up mode
BIOS UX3405MA.311 5.32
08:23
Diagnosed dual graphics issues and synthesized targeted troubleshooting steps

This combination — Intel Arc/Meteor Lake iGPU, Cinnamon's X11 fractional scaling, and a multi-monitor setup with mismatched resolutions/scales — is a known troublemaker for cursor rendering. There are two likely culprits, and the fixes are cheap to try, so it's worth going through them in order.

1. Force software cursor rendering (most likely fix for "disappears when hovering")

On Mint, Cinnamon runs on X11 using the modesetting driver for Intel GPUs. With mixed-scale multi-monitor setups, the hardware cursor plane often fails to render correctly on one or both outputs, causing the flicker/disappear behavior you're describing. Forcing the cursor to be drawn in software (rather than via the GPU's hardware cursor plane) frequently fixes this:
bash

sudo mkdir -p /etc/X11/xorg.conf.d
sudo nano /etc/X11/xorg.conf.d/20-intel.conf

Add:

Section "Device"
Identifier "Intel Graphics"
Driver "modesetting"
Option "SWcursor" "true"
EndSection

Save, reboot, and test. This is a tiny performance cost but usually invisible on modern hardware, and it's the single most common fix for exactly this symptom on Intel + dual monitor + scaling setups.

2. Disable PSR (Panel Self Refresh)

Meteor Lake's i915 driver has long-standing PSR/PSR2 bugs that specifically cause flickering tied to cursor movement near screen edges or over certain content — Intel's own kernel devs have disabled PSR2 selective fetch on other generations for this exact reason. Try:
bash

sudo nano /etc/default/grub

Edit the line to:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i915.enable_psr=0"

Then:
bash

sudo update-grub
sudo reboot

If this doesn't help (or makes things worse on Meteor Lake, which some users report), try i915.enable_psr=2 instead as an alternative — some Meteor Lake users found PSR=0 caused freezes while PSR=2 fixed flicker without that downside.

3. Isolate whether fractional scaling is the trigger

Since you have fractional scaling in "scale content up" mode with two different displays at different native resolutions, temporarily set both displays to an integer scale (100% or 200%) in Settings > Display and see if the flicker disappears. If it does, the issue is in Cinnamon/Muffin's handling of fractional scaling with mixed monitors — this is an open, acknowledged bug in current Cinnamon versions on multi-monitor fractional setups. If it goes away, you may need to live with either non-fractional scaling, or set the laptop panel and the iiyama monitor to scales that don't require the "scale content up" workaround (e.g., both at 100%, or both at an integer multiple).

4. Try a different cursor size/theme

A related open Cinnamon bug involves the cursor rendering at the wrong size or flickering specifically under fractional scaling. Go to Settings > Mouse and Touchpad and try bumping the cursor size up explicitly (rather than "auto"), or switch the cursor theme (e.g., to Bibata or Adwaita) — this sidesteps a known size-calculation glitch.

5. Update your kernel

Meteor Lake/Arc support matures quickly across kernel releases. In Update Manager > View > Linux Kernels, check if a newer kernel than your current one is available (Mint 22.3 typically ships a 6.8 or 6.11-based kernel) and try the latest in that list — many i915 fixes for Meteor Lake land in point releases.

6. Confirm via logs

After reproducing the flicker, run:
bash

sudo dmesg | grep -i -E "fifo|underrun|psr"

If you see FIFO underrun or PSR-related errors, that confirms #2 above is the right direction.

I'd start with #1 since it directly targets cursor-plane rendering and is the most common fix reported for "cursor flickers/vanishes over windows" on Intel multi-monitor setups, then layer in #2 if any flicker remains. Let me know what you find and I can help narrow it down further.

with fix 1 installed the cursor behavior is better but in some areas of open pains the cursor appears to pulse at a bout a 1 second frequency (visible/invisible) when stationary
08:40
Synthesized cursor flicker hypotheses and charted diagnostic pathways

Good progress — that pulsing is a different (but related) symptom, and it points at PSR (Panel Self Refresh) interacting with the now-software-rendered cursor. Software cursor draws the pointer by repeatedly blitting it into the framebuffer; PSR periodically puts the panel into a low-power "frozen frame" state and then does a full refresh to resync, and on Meteor Lake that resync cycle commonly lands around the ~1 second mark you're seeing. Each resync can momentarily show a stale frame without the cursor blitted in yet, giving that visible/invisible pulse.

There's a second, less likely possibility: GTK/text-input carets blink at roughly 1Hz by default, and on some Intel setups a software cursor sitting near/over a blinking caret gets "erased" by the app's own redraw of that screen region until the next cursor-move event repaints it. Worth ruling out.

Try these in order:

Disable PSR now (this was step 2 from before, which you haven't applied yet):

bash

sudo nano /etc/default/grub

Change the line to:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i915.enable_psr=0"

bash

sudo update-grub
sudo reboot

This is the most likely fix for a steady ~1Hz pulse — PSR's idle/refresh timer commonly operates in that range.

If PSR=0 doesn't fully fix it, add framebuffer compression and DC-state disabling too, since these power features interact with PSR on Meteor Lake:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i915.enable_psr=0 i915.enable_fbc=0 i915.enable_dc=0"

Update grub and reboot again.

Test the caret-blink hypothesis — hold the stationary cursor over a plain area with no blinking caret (empty desktop, an image, a static webpage) versus directly over/near a text field with an active blinking cursor. If the pulsing only happens near the blinking caret, it's the second mechanism rather than PSR. You can confirm by temporarily disabling cursor blink:

bash

gsettings list-recursively | grep -i cursor-blink

This will show you which schema applies (likely org.cinnamon.desktop.interface or org.gnome.desktop.interface — Cinnamon often mirrors both). Then set cursor-blink to false in that schema and see if the pointer pulsing stops.

Confirm via logs after reproducing it:

bash

sudo dmesg | grep -i -E "psr|fifo|underrun"

If PSR entry/exit messages line up with the timing of the pulse, that's your confirmation.

Start with #1 — given the ~1 second regularity, PSR is the strongest suspect, and it's the one variable we haven't touched yet. Let me know what happens after that reboot.

just checked and the cursor appears stable on the main laptop screen so the problem seems to be connected with the xcb3494qwqsn deisplay
08:44
Pinpointed external monitor's adaptive sync as culprit

That actually fits well — I looked up the iiyama XCB3494WQSN-B5, and it's a 3440×1440 @ 120Hz VA panel with AMD FreeSync Premium (Adaptive Sync), plus a USB-C dock input. Two things on that monitor specifically could be driving the pulsing that the laptop's own panel doesn't have: Adaptive-Sync/VRR, and (if you applied the earlier PSR fix) "Panel Replay" — which is essentially the DisplayPort/Adaptive-Sync equivalent of PSR, and Intel's i915 driver applies it to external monitors that advertise FreeSync/Adaptive-Sync support, separately from the laptop's internal eDP panel.

A couple of quick things to check:

Did the i915.enable_psr=0 change actually get applied yet? From your message it sounds like you may have jumped to isolating which screen before testing that. If you haven't rebooted with that grub change yet, do that first — enable_psr=0 in current kernels also disables Panel Replay, which is the most likely candidate for a periodic resync specifically on an Adaptive-Sync-capable external display.

If PSR=0 is already in effect and the pulsing on the iiyama persists, the next most likely cause is the monitor's own FreeSync/Adaptive-Sync feature negotiating with the GPU independently of that kernel setting:

Turn off Adaptive Sync/FreeSync in the monitor's OSD menu (usually under a "Setup" or "Game" menu, sometimes simply labeled "FreeSync" or "Adaptive Sync"). This is worth testing even though it might seem unrelated to a stationary-cursor issue — VRR panels often drop to a lower refresh rate when idle and use "low framerate compensation" duplicate frames to stay within range, and that resync cycle can cause exactly this kind of periodic visibility glitch with a software-composited cursor.
Check the current mode/refresh rate Cinnamon is driving that monitor at:

bash

xrandr --verbose | grep -A1 -i "connected|vrr"

Look for the iiyama's output name, its current resolution/Hz, and whether a vrr_capable property is present and set to 1.

Try forcing a fixed, non-default refresh rate in Settings > Display for that monitor — e.g. if it's currently at 120Hz, try 100Hz (or vice versa) and see if the pulsing frequency changes or disappears. If it scales with the refresh rate setting, that confirms it's refresh-rate/VRR related rather than a fixed timer like PSR.
If you're connecting via the monitor's USB-C dock input, try a direct DisplayPort cable instead (bypassing the dock) for a quick test — dock/hub-based DP connections sometimes add their own buffering quirks that a direct cable avoids.

Let me know which of these change anything — particularly whether toggling FreeSync on the monitor itself has any effect, since that's the strongest lead given this panel's spec sheet.

there is an option on the screen for FREESYNC PREMIUM which if turned off kills the scree. there is also an option called HDR which is off. Both settings are in a panel aclled EXTRA 1
09:03
Diagnosed display signal loss from FreeSync toggle, prioritized safer kernel parameter testing

That "screen goes dark when FreeSync is toggled" reaction is actually useful information — it strongly suggests the GPU is actively driving this monitor in Adaptive-Sync mode, and the abrupt setting change broke the link handshake mid-stream rather than gracefully renegotiating. That's a fairly common quirk on FreeSync monitors over DP/USB-C with Linux, since the driver doesn't always re-handshake cleanly when the display-side VRR capability changes underneath it.

To get the screen back:

Try unplugging and re-plugging the video cable (or the USB-C dock cable) once — this forces a fresh EDID read and mode negotiation.
If that doesn't work, power-cycle the monitor itself (off/on via its power button, not just standby).
If still blank, switch the monitor's input source away and back (e.g., to HDMI and back to DP/USB-C) via its OSD using the physical buttons — most OSDs are still navigable even with "no signal" on the main input.
As a last resort, reboot the laptop with the monitor connected — it'll do a full re-negotiation on boot.

Once it's back, I'd suggest leaving FreeSync in whatever state it ends up in for now rather than toggling it again repeatedly, since each toggle risks another signal drop.

Given the disruption that causes, let's de-risk the next test. Before going further with the monitor's OSD, can you confirm: did you actually apply the i915.enable_psr=0 grub change and reboot yet? That one is fully software-side, reversible by editing grub back and rebooting, and doesn't risk killing the signal. If enable_psr=0 is already active and the pulsing persists, that tells us Panel Replay wasn't the (sole) cause and FreeSync itself is more likely the culprit — at which point it's worth the OSD toggle, but ideally only once, with the recovery steps above ready.

If you haven't done the PSR test yet, that's the safer next step — apply it, reboot, and check the iiyama again before touching FreeSync further.

output from current refresh mode '' davide@asus-laptop:~$ xrandr --verbose | grep -A1 -i "connected|vrr"
eDP-1 connected primary 1440x900+0+0 (0x47) normal (normal left inverted right x axis y axis) 302mm x 189mm
Identifier: 0x42

vrr_capable: 1 
    range: (0, 1)

--
DP-1 connected 3440x1440+1440+155 (0x84) normal (normal left inverted right x axis y axis) 797mm x 334mm
Identifier: 0x43

vrr_capable: 1 
    range: (0, 1)

--
DP-2 disconnected (normal left inverted right x axis y axis)
Identifier: 0x44

vrr_capable: 0 
    range: (0, 1)

--
HDMI-1 disconnected (normal left inverted right x axis y axis)
Identifier: 0x45
davide@asus-laptop:~$
09:05
Analyzed display capabilities and diagnosed Panel Replay as likely culprit

That vrr_capable: 1 on both outputs is mostly just an EDID-reported capability flag — on X11/Cinnamon, the compositor (Muffin) doesn't actively schedule frames around VRR the way Wayland compositors do, so this property being set doesn't by itself mean VRR is driving anything. But the fact that toggling FreeSync off in the monitor's OSD killed the signal tells us the i915 driver has negotiated an Adaptive-Sync link with DP-1 at the protocol level, independent of what the compositor is doing — and that's exactly the precondition for Panel Replay, the DP/Adaptive-Sync equivalent of PSR, which i915 can enable on its own for power saving on VRR-capable external displays.

So this still points back to the PSR/Panel Replay test as the next concrete step:

If you haven't already applied i915.enable_psr=0 and rebooted, do that now. It's the cleanest test — fully reversible by editing grub back, no risk to the monitor connection like the OSD toggle was.
After rebooting, check the pulsing on DP-1 again.
While you're at it, you can confirm what the driver is doing on that connector with:

bash

sudo dmesg | grep -iE "psr|panel.?replay|DP-1|DP1"

Look for lines mentioning PSR or Panel Replay being enabled/active on the DP-1 pipe — that'll confirm whether this mechanism is in play before and after the enable_psr=0 change.

As a secondary check (no reboot needed), you can look at the live state via debugfs — find the right card/pipe directory and grep its display info:

bash

sudo find /sys/kernel/debug/dri -iname "psr" 2>/dev/null

If that turns up a psr_state or similar file under one of the pipes, cat it while the cursor is pulsing — it'll show whether PSR/Panel Replay is actively entering/exiting around that ~1 second interval.

Given the connector-level Adaptive-Sync negotiation we just confirmed, enable_psr=0 disabling Panel Replay on DP-1 is the strongest remaining candidate — let's get that tested before going back into the monitor's FreeSync setting again.

i915.enable_psr=0 applied
09:06
Anticipated testing results and debugged system status

Good — now check the iiyama (DP-1) again: is the ~1-second pulsing still happening with i915.enable_psr=0 active?

While you're testing, it's worth grabbing the confirmation data too, since it'll tell us definitively whether PSR/Panel Replay was actually disabled on that connector:
bash

sudo dmesg | grep -iE "psr|panel.?replay"

and
bash

sudo find /sys/kernel/debug/dri -iname "psr" 2>/dev/null

If the second command finds a file (e.g. i915_psr_status under one of the /sys/kernel/debug/dri/0/crtc-* or similar directories), sudo cat it — with PSR disabled it should report something like "PSR mode: disabled" rather than showing active entry/exit cycling.

Let me know:

Whether the pulsing on DP-1 has stopped, lessened, or is unchanged.
What those two commands show.

That'll tell us whether to consider this solved, or move on to the FreeSync/OSD route (more carefully this time, with the recovery steps in hand).

output from the 2 tests - davide@asus-laptop:$ sudo dmesg | grep -iE "psr|panel.?replay"
[sudo] password for davide:
davide@asus-laptop:$ sudo find /sys/kernel/debug/dri -iname "psr" 2>/dev/null
/sys/kernel/debug/dri/0000:00:02.0/i915_edp_psr_status
/sys/kernel/debug/dri/0000:00:02.0/i915_edp_psr_debug
/sys/kernel/debug/dri/0000:00:02.0/i915_params/enable_psr2_sel_fetch
/sys/kernel/debug/dri/0000:00:02.0/i915_params/psr_safest_params
/sys/kernel/debug/dri/0000:00:02.0/i915_params/enable_psr
/sys/kernel/debug/dri/0000:00:02.0/DP-2/i915_psr_status
/sys/kernel/debug/dri/0000:00:02.0/DP-2/i915_psr_sink_status
/sys/kernel/debug/dri/0000:00:02.0/DP-1/i915_psr_status
/sys/kernel/debug/dri/0000:00:02.0/DP-1/i915_psr_sink_status
/sys/kernel/debug/dri/0000:00:02.0/eDP-1/i915_psr_status
/sys/kernel/debug/dri/0000:00:02.
09:12
Investigated PSR status files and formulated diagnostic commands

Let's pin down what those status files say. The enable_psr param controls both PSR (for eDP) and Panel Replay (for Adaptive-Sync DP displays like the iiyama), so check the param itself plus the per-connector status:
bash

sudo cat /sys/kernel/debug/dri/0000:00:02.0/i915_params/enable_psr
sudo cat /sys/kernel/debug/dri/0000:00:02.0/DP-1/i915_psr_status
sudo cat /sys/kernel/debug/dri/0000:00:02.0/eDP-1/i915_psr_status

Note: the debugfs connector names (DP-1, DP-2, eDP-1) are the kernel's own connector enumeration and don't necessarily map 1:1 to xrandr's DP-1/DP-2 naming — so it's worth checking both DP-1 and DP-2 debugfs entries to find which one is your iiyama (the i915_psr_status output usually states whether the panel/sink supports PSR or Panel Replay, which will tell you immediately — the eDP-1 one is your laptop panel, so whichever of DP-1/DP-2 also reports PSR/Panel Replay support is almost certainly the iiyama).

While you run those, also let me know the main thing: with enable_psr=0 active, is the ~1Hz pulsing on the iiyama still happening, gone, or reduced? That observation plus the status output together will tell us whether PSR/Panel Replay was the cause.

still pulsing
09:12
Pivoted from PSR hypothesis toward cursor-blink and compositor redraw theories

Okay — that rules out PSR/Panel Replay as the cause (worth reverting i915.enable_psr=0 later since it didn't help and costs you some battery life, but no rush).

"About a 1 second frequency" is actually a strong clue pointing somewhere else: GTK's default text-cursor blink cycle is roughly 1.2 seconds (on/off), which is right in that ballpark. The theory: with software cursor rendering (from fix 1), the mouse pointer is drawn by blitting it into the framebuffer. If a blinking text caret is redrawing the same screen region independently, that redraw can occasionally "erase" the mouse pointer sprite until the next cursor-move event repaints it — giving exactly the visible/invisible pulse you're seeing, but only over areas where something is actively redrawing at ~1Hz.

Two quick, low-risk tests to narrow this down — no monitor settings involved this time:

1. Correlation test (no commands needed): On the iiyama, hold the stationary cursor over a completely static area — empty desktop wallpaper, or a static image with no text cursor — versus over a text field/terminal prompt with an active blinking caret. Does the pulsing only happen in the second case?

2. Disable text-cursor blinking and see if the pulsing stops entirely, regardless of location:
   bash

gsettings list-recursively | grep -i cursor-blink

This will show you the schema(s) in use (likely org.cinnamon.desktop.interface and/or org.gnome.desktop.interface, both with keys cursor-blink and cursor-blink-time). Then for each schema that has it:
bash

gsettings set cursor-blink false

e.g.:
bash

gsettings set org.cinnamon.desktop.interface cursor-blink false

Reboot isn't needed — just retest the pulsing on DP-1 afterward.

Also worth noting while you're testing: is your Cinnamon panel/taskbar located on the iiyama screen, and does its clock display seconds? A seconds-ticking clock redrawing once per second on that monitor (but not on the laptop's panel, if the panel only lives on one screen) would produce the exact same ~1Hz redraw-vs-cursor conflict, independent of any text caret. If the panel is on DP-1, try moving it to eDP-1 (or switching the clock to minutes-only) as an additional quick test.

Let me know what the correlation test and the cursor-blink toggle show.

1 Pulsing happens over panes and blank desktop BUT appears to ONLY OCCUR at and above the horizontal overlap with the laptop screen. (Cursor movement from 2nd screen only possible if the cursor is at or above the virtual level of the main screen). Results of test are > davide@asus-laptop:$ gsettings list-recursively | grep -i cursor-blink
org.cinnamon.desktop.interface cursor-blink true
org.cinnamon.desktop.interface cursor-blink-time 1200
org.cinnamon.desktop.interface cursor-blink-timeout 10
org.gnome.desktop.interface cursor-blink true
org.gnome.desktop.interface cursor-blink-time 1200
org.gnome.desktop.interface cursor-blink-timeout 10
org.mate.interface cursor-blink true
org.mate.interface cursor-blink-time 1200
davide@asus-laptop:$ gsettings set org.cinnamon.desktop.interface cursor-blink false
davide@asus-laptop:~$
Taskbar is on both screens clock not set to display seconds.
09:27
Diagnosed refresh-rate mismatch causing cursor pulsing at monitor overlap

That geometric detail is the best clue yet, and it changes the picture significantly. The fact that pulsing only happens in the Y-range where eDP-1 and DP-1 are both "active" (i.e., where the laptop screen's CRTC and the iiyama's CRTC are scanning out simultaneously across that shared vertical band) — but not in the lower portion of DP-1 that has no eDP-1 counterpart — points away from PSR, FreeSync, or text-cursor blink entirely.

This pattern is consistent with a refresh-rate beat frequency: if eDP-1 and DP-1 are running at different (and not cleanly harmonic) refresh rates, the X server's software-cursor redraw — which has to be coordinated across whichever CRTCs are "live" in a given screen region — can produce a slow visible beat pattern where the two refresh cycles drift in and out of phase. A beat between, say, 60Hz and 120Hz would be silent (clean 2:1 ratio), but something like 60Hz vs 59.97Hz, or 90Hz vs 120Hz, can easily produce a beat in the 0.5–2 second range — right in line with what you're seeing.

(You can leave cursor-blink false as-is for now — doesn't seem to be the cause, but no harm either.)

Next step — check the actual refresh rates of both displays:
bash

xrandr

(no --verbose, just plain xrandr). Look for the line marked with * under each of eDP-1 and DP-1 — that's the currently active mode and Hz for each.

Once you post that, the test will likely be: go to Settings > Display, and set both displays to the same refresh rate (e.g., if eDP-1 is at 60Hz and DP-1 is at 120Hz, try setting DP-1 to 60Hz, or eDP-1 to a rate that matches DP-1 if your laptop panel supports it). If the pulsing stops or changes character when the rates match, that confirms the beat-frequency theory, and you can then decide whether to live with matched refresh rates or look at it as a Cinnamon/Muffin bug to report (mismatched-refresh multi-monitor handling under X11 has open issues).

Post the xrandr output and we'll go from there.

davide@asus-laptop:$ xrandr
Screen 0: minimum 320 x 200, current 4880 x 1595, maximum 16384 x 16384
eDP-1 connected primary 1440x900+0+0 (normal left inverted right x axis y axis) 302mm x 189mm
2880x1800 60.00*+ 120.00 +
2880x1620 60.00
2560x1600 60.00
2560x1440 60.00
2048x1536 60.00
1920x1440 60.00
1856x1392 60.00
1792x1344 60.00
2048x1152 60.00
1920x1200 60.00
1920x1080 60.00
1600x1200 60.00
1680x1050 60.00
1400x1050 60.00
1600x900 60.00
1280x1024 60.00
1400x900 60.00
1280x960 60.00
1440x810 60.00
1368x768 60.00
1280x800 60.00
1152x864 60.00
1280x720 60.00
1024x768 60.00
1024x768i 60.00
960x720 60.00
928x696 60.00
896x672 60.00
1024x576 60.00
960x600 60.00
832x624 60.00
960x540 60.00
800x600 60.00
840x525 60.00
864x486 60.00
700x525 60.00
800x450 60.00
640x512 60.00
700x450 60.00
640x480 60.00
720x405 60.00
720x400 60.00
684x384 60.00
640x400 60.00
576x432 60.00
640x360 60.00
640x350 60.00
512x384 60.00
512x384i 60.00
512x288 60.00
416x312 60.00
480x270 60.00
400x300 60.00
432x243 60.00
320x240 60.00
360x202 60.00
360x200 60.00
320x200 60.00
320x180 60.00
320x175 60.00
DP-1 connected 3440x1440+1440+155 (normal left inverted right x axis y axis) 797mm x 334mm
3440x1440 59.97*+ 120.00 99.98
2560x1440 120.00
2560x1080 100.00 60.00 59.94
1920x1080 119.96 99.92 120.00 100.00 119.88 60.00 60.00 50.00 59.94 30.00 29.97
1680x1050 59.95
1280x1024 75.02 60.02
1440x900 59.89
1280x960 60.00
1280x800 59.81
1280x720 60.00 50.00 59.94
1024x768 75.03 70.07 60.00
832x624 74.55
800x600 72.19 75.00 60.32 56.25
720x576 50.00
720x480 60.00 59.94
640x480 75.00 72.81 66.67 60.00 59.94
720x400 70.08
DP-2 disconnected (normal left inverted right x axis y axis)
HDMI-1 disconnected (normal left inverted right x axis y axis)
davide@asus-laptop:$
09:31
Diagnosed refresh rate mismatch causing periodic sync artifacts

That 59.97Hz on DP-1 versus 60.00Hz on eDP-1 is the smoking gun, and it fits the geometry clue perfectly. Two CRTCs running at almost-but-not-quite-matching rates drift in and out of phase relative to each other over time — and where Cinnamon's software cursor compositing has to consider both CRTCs (the region where the two displays sit at the same virtual Y-level and the cursor can cross between them), that drift can manifest as periodic visibility glitches. Below that band, only DP-1's CRTC is relevant, so there's nothing to drift against.

The good news: DP-1 has 120.00Hz available at its native 3440x1440 resolution, and 120 is an exact 2:1 multiple of eDP-1's 60.00Hz — a clean harmonic with zero long-term phase drift, versus 59.97 which isn't a clean ratio of 60 at all.

Test it:
bash

xrandr --output DP-1 --mode 3440x1440 --rate 120.00

Or via the GUI: Settings > Display, click the iiyama, and change its refresh rate dropdown from 59.97Hz to 120Hz, then Apply.

Since your monitor is natively rated for 120Hz anyway, this isn't really a compromise — it's likely what it should have been negotiating in the first place; 59.97 looks like an odd fallback the driver picked.

Check the pulsing on DP-1 after this change. If it's gone, you've found the cause — a non-harmonic refresh-rate mismatch between the two CRTCs interacting with the software cursor compositor. If it persists but feels different (faster/slower beat, different pattern), that's still useful data — it'd tell us the beat-frequency theory is on the right track but we need to also adjust eDP-1's rate (which is more constrained, since 1440x900 only lists 60.00).

While you're in there, it's also worth reverting i915.enable_psr=0 afterward if 120Hz fixes things, since PSR wasn't the culprit and disabling it costs some battery life on the go.

seems fixed at 1200 Hz - how do i revert i915 setting?
09:35
Identified typo, planned grub reversion steps, ensured refresh rate persistence

Glad that nailed it — 120Hz being an exact harmonic of your laptop panel's 60Hz removes the phase drift entirely, which lines up with the theory.

To revert the PSR change:
bash

sudo nano /etc/default/grub

Edit the GRUB_CMDLINE_LINUX_DEFAULT line back to remove i915.enable_psr=0 — either delete the whole option or revert the line to its original "quiet splash" (whichever it was before). Then:
bash

sudo update-grub
sudo reboot

One thing worth checking before you're done: if you set the 120Hz refresh rate via the Cinnamon Display Settings GUI (Settings > Display > Apply > Keep changes), it should persist across reboots and logins automatically. If you set it via the xrandr --output DP-1 --mode 3440x1440 --rate 120.00 command directly in the terminal, that setting is session-only and will revert to 59.97Hz on next login/reboot. If you used the command-line route, go into Settings > Display now and explicitly set/confirm 120Hz there so Cinnamon saves it to its monitor configuration — that way it'll stick.

So to summarize where things landed: keeping fix 1 (SWcursor in xorg.conf), reverting the PSR kernel parameter, and locking in 120Hz on the iiyama via Display Settings should give you a stable setup. Worth a final check after the reboot that both the original flicker and the 1Hz pulsing stay gone with PSR back to default.

After reboot > 1200 Hz refresh rate set via Display and it persists so OK. 1915 reverted. Cursor still pulsing
09:47
Diagnosed PSR reactivation as likely culprit requiring reconfiguration

That's actually informative rather than a setback — it suggests the fix wasn't just the 120Hz refresh rate, but the combination of 120Hz and PSR disabled. Here's why that makes sense in hindsight:

At 59.97Hz with PSR disabled: pulsing present (refresh-rate beat against eDP-1's 60Hz).
At 120Hz with PSR disabled: pulsing gone (clean 2:1 harmonic, no beat).
At 120Hz with PSR re-enabled: pulsing back.

That last data point suggests that once the panel is running at a "clean" Adaptive-Sync-friendly rate (120Hz, within the iiyama's 48-120Hz FreeSync range), i915's Panel Replay can now successfully engage on DP-1 — whereas at the odd 59.97Hz it may not have activated cleanly either way, masking PSR's effect. With Panel Replay now actually active at 120Hz, its periodic resync becomes the visible cause again.

Next step: re-apply i915.enable_psr=0, but keep the 120Hz setting.
bash

sudo nano /etc/default/grub

Add i915.enable_psr=0 back to GRUB_CMDLINE_LINUX_DEFAULT:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i915.enable_psr=0"

bash

sudo update-grub
sudo reboot

After reboot, check DP-1 again. If pulsing is gone, the working configuration is: SWcursor (fix 1) + 120Hz on DP-1 + PSR disabled — all three together.

If you want to confirm the Panel Replay theory before/instead of just re-testing, you could also check, right now with PSR enabled and at 120Hz:
bash

sudo cat /sys/kernel/debug/dri/0000:00:02.0/DP-1/i915_psr_status

If it shows Panel Replay as enabled/active (rather than just "supported"), that confirms it's now engaging at 120Hz where it wasn't before — and re-disabling PSR is the right call.

Given the battery-life trade-off of enable_psr=0 (mainly relevant on the internal panel/battery, less so when docked to an external monitor on AC power), this might be a setup worth toggling depending on whether you're mobile or at your desk — but let's first confirm it actually fixes things again at 120Hz before deciding how to manage that trade-off.

before reboot but after edit result = davide@asus-laptop:$ sudo cat /sys/kernel/debug/dri/0000:00:02.0/DP-1/i915_psr_status
Sink support: PSR = no, Panel Replay = no, Panel Replay Selective Update = no, Panel Replay DSC support = not supported
davide@asus-laptop:$
09:52
Eliminated PSR theory, pivoted toward testing hardware cursor viability

That debugfs output is actually decisive: Sink support: PSR = no, Panel Replay = no means the iiyama doesn't support either mechanism at all on DP-1. PSR/Panel Replay was never a factor for this monitor — so the earlier enable_psr=0 test (both times) was testing something that couldn't have applied to DP-1 anyway. You can safely drop that line from grub entirely:
bash

sudo nano /etc/default/grub

Remove i915.enable_psr=0, save, then:
bash

sudo update-grub

No reboot needed yet — fold this into the next test below.

That theory's dead, so let's reconsider. Here's a new angle worth testing: fix 1 (SWcursor) was applied to solve the original flicker, which existed at the old 59.97Hz refresh rate. Now that DP-1 is running at a clean 120Hz (a proper 2:1 harmonic of eDP-1's 60Hz), it's possible the original cause is gone too — and SWcursor itself, now unnecessary, is the thing causing this new ~1Hz pulsing. Software cursor compositing causing exactly this kind of localized periodic flicker is a documented issue on Intel and AMD alike.

Test: temporarily disable SWcursor and see how things behave at 120Hz.
bash

sudo mv /etc/X11/xorg.conf.d/20-intel.conf /etc/X11/xorg.conf.d/20-intel.conf.disabled
sudo reboot

After reboot, check DP-1 for both:

The pulsing (does it stop now that SWcursor is gone?)
The original flicker/disappearing-cursor symptom from the very start of this thread (does it come back now that you're at 120Hz instead of 59.97Hz, or does the harmonic refresh rate alone keep it away?)

There are three possible outcomes:

Both fixed → 120Hz alone solved everything, SWcursor was a band-aid for the refresh mismatch and can stay off permanently.
Pulsing gone, original flicker returns → we need a different approach than blanket SWcursor (maybe per-output cursor handling, or revisit at this point).
Pulsing persists even without SWcursor → it's not cursor-rendering-mode related at all, and we're looking at something else entirely (worth then checking if it happens with no mouse movement vs. just hovering, and whether it's visible to the naked eye in a screen recording for closer inspection).

Let me know which scenario you land in.

pulsing persists in pane and desktop / no difference if stationary or moving. At upper and lower overlap cursor shows fine horizontal line.
10:03
Diagnosed hardware cursor plane bug across mixed-DPI displays

That horizontal-line artifact at the overlap boundaries is a really useful new data point — it points toward a hardware cursor plane scaling/positioning bug rather than a timing/refresh issue. Here's the likely picture: your setup is mixed-DPI (eDP-1 at effectively 2x scale showing as virtual 1440x900, DP-1 at 1x showing as 3440x1440, per your "fractional scaling - scale content up" config). When the GPU's hardware cursor plane — sized/positioned for one output's scale — crosses into territory governed by the other output's CRTC (the Y-overlap band), the plane's dimensions get miscalculated, occasionally collapsing the cursor into a thin horizontal line and periodically dropping out entirely. This is a documented class of bug in Cinnamon/Muffin with mixed-scale multi-monitor setups (there's an open upstream issue covering cursor-size problems with fractional scaling on Mint 22.2/22.3).

Given that, SWcursor (fix 1) is structurally the right fix for this specific bug — it removes the hardware cursor plane from the equation entirely, so there's nothing to miscalculate across the CRTC boundary. The fact that "SWcursor ON + PSR=0 + 120Hz" was the one config that worked, while "SWcursor OFF" (even at 120Hz) brought back the artifact, fits this: SWcursor was doing the real work.

The PSR=0 part is harder to explain mechanistically since DP-1's sink doesn't support PSR/Panel Replay at all — it can only affect eDP-1's timing. But since it's part of the only combination that's tested clean so far, let's not discard it yet; eDP-1's PSR entry/exit may be perturbing Muffin's overall frame/redraw scheduling enough to matter for the cross-output cursor compositing.

Let's restore the known-working combination and confirm it holds:
bash

sudo mv /etc/X11/xorg.conf.d/20-intel.conf.disabled /etc/X11/xorg.conf.d/20-intel.conf
sudo nano /etc/default/grub

Add i915.enable_psr=0 back:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash i915.enable_psr=0"

bash

sudo update-grub
sudo reboot

After reboot, check DP-1 thoroughly — stationary and moving cursor, over panes and desktop, and specifically at the upper/lower overlap boundaries where you saw the horizontal-line artifact.

If this is clean again, I'd suggest this as your settled configuration: SWcursor + 120Hz (harmonic refresh) + PSR disabled on the eDP-1 side. The PSR=0 cost is minor (it only affects the internal panel's power-saving, and mainly matters on battery away from the dock), and SWcursor's performance cost is negligible on modern hardware. If you want, once it's confirmed stable, I can also point you toward where to report the underlying mixed-DPI cursor-plane bug upstream so it might get fixed properly and you could eventually drop these workarounds.

still pulsing let me drop workarounds (instructions needed) and report the bug
10:15
Synthesized revert procedures and compiled bug report guidance

Fair enough — this has gone deep enough that documenting it properly is more useful than more rounds of toggling. Here's the cleanup, then the report.

Reverting the workarounds

Remove the SWcursor config:
bash

sudo rm /etc/X11/xorg.conf.d/20-intel.conf

Edit grub back to its original state:
bash

sudo nano /etc/default/grub

Set the line back to:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

Then:
bash

sudo update-grub
sudo reboot

One thing I'd suggest keeping: the 120Hz refresh rate on DP-1. It's the monitor's native rate, it's a clean 2:1 harmonic with the laptop panel's 60Hz, and it didn't cause any problems on its own — only the SWcursor/PSR combination muddied the picture. No reason to go back to 59.97Hz.

After reboot you'll be back to the original symptom (cursor flickering/disappearing on hover over DP-1, in the Y-band that overlaps the laptop panel) — which is fine, since that's the actual bug to report.

Reporting the bug

This looks like a Cinnamon/Muffin issue with how the hardware cursor plane is sized and positioned across CRTCs when outputs have different scale factors (your "scale content up" fractional scaling setup, eDP-1 effectively at ~2x and DP-1 at 1x). There's already a related open issue — linuxmint/cinnamon #13344, "Mouse cursor size issues with fractional scaling" — though that one was filed by an Nvidia user, so your report would add useful Intel/multi-CRTC-overlap data to the same underlying problem area.

File at: https://github.com/linuxmint/cinnamon/issues/new

If you want to cover the bases, the cursor plane/CRTC logic for X11 sessions actually lives in Muffin (Cinnamon's window manager/compositor fork), so it may also be worth a cross-post or link at: https://github.com/linuxmint/muffin/issues

Suggested content for the report — gather this first:
bash

inxi -Fxxxz
cinnamon --version
uname -r
xrandr

Then describe:

Hardware: ASUS Zenbook 14 UX3405MA, Intel Meteor Lake-P / Arc Graphics (i915), iiyama XCB3494WQSN-B5 external monitor (3440x1440 @ 120Hz)
Setup: Fractional scaling enabled, "Scale content up" mode, eDP-1 at 1440x900 (effective ~2x scale of native 2880x1800), DP-1 at 3440x1440 @ 1x, side-by-side with vertical Y-overlap between the two
Symptom: On DP-1, anywhere within the Y-range that overlaps eDP-1's vertical extent, the mouse cursor pulses visible/invisible at roughly 1Hz — happens whether stationary or moving, over windows and bare desktop alike. Below that overlap band (where only DP-1's CRTC applies), the cursor is stable. Crossing the overlap boundary, the cursor briefly renders as a flattened horizontal line.
What was ruled out: Confirmed via /sys/kernel/debug/dri/.../DP-1/i915_psr_status that the monitor doesn't support PSR or Panel Replay at all, so this isn't a PSR-related timing issue. Refresh-rate mismatch (59.97Hz vs 60Hz) was tested and ruled out — the pulsing persists even at a clean 120Hz harmonic rate. Forcing software cursor rendering via Option "SWcursor" "true" changes the artifact's character (disappearing → pulsing/horizontal-line) but doesn't eliminate it — suggesting this is specifically about how the cursor plane/sprite is composited across two CRTCs with mismatched scale factors in their overlapping region.

A short phone-camera video of the pulsing (rather than a screen recording, which may not capture compositor-level cursor plane artifacts faithfully) would strengthen the report if you're willing to attach one.

This is genuinely a niche, well-isolated bug at this point — your debugging has actually done most of the diagnostic work already, which makes it a strong report.
You are out of free messages until 1:20 PM

Claude is AI and can make mistakes. Please double-check responses.