Bug 512146 - During installation of fedora kde and after rebooting after installation and update, display is black with out of range message
Summary: During installation of fedora kde and after rebooting after installation and ...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: output configuration (other bugs)
Version First Reported In: 6.5.2
Platform: Fedora RPMs Linux
: NOR major
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-11-15 18:00 UTC by Lemma
Modified: 2025-12-05 23:54 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In: 6.5.4
Sentry Crash Report:


Attachments
drm_info, xrandr and screen doctor o, outputs (39.77 KB, text/plain)
2025-11-20 18:37 UTC, Lemma
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lemma 2025-11-15 18:00:50 UTC
its very common issue, kde wayland not works for many monitors.
its kde plasma specific issue not with any linux distro.
i tried different distros with kde plasma and same issue happen.
during installation it my monitor show out of range msg.
after booting with safe graphics in grub menu, it works but showed lower resolutions and screen looks dull and everything just feels choppy.
when we remove safe graphics, out of range comes back.
it specially Happen with wayland, when i install x11 session and use x11 my system works.
Comment 1 TraceyC 2025-11-18 23:14:51 UTC
Thanks for filing this bug report. Unfortunately there isn't enough information for us to try to figure out what's happening. Please add information as requested in the bug report template. Copy and paste this with the information into a new comment.

Also, please provide information about your monitor with 

kscreen-doctor -o


SUMMARY


STEPS TO REPRODUCE
1. 
2. 
3. 

OBSERVED RESULT


EXPECTED RESULT


SOFTWARE/OS VERSIONS
Windows: 
macOS: 
(available in the Info Center app, or by running `kinfo` in a terminal window)
Linux/KDE Plasma: 
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
Comment 2 Lemma 2025-11-19 03:27:40 UTC
Summary:
On Fedora 43 (KDE Plasma 6.5.2), booting into the default Wayland session (SDDM) results in a monitor "Out of Range" signal. This occurs on older Intel Ivy Bridge hardware using a VGA connection. The issue is specific to Wayland; forcing an X11 session for SDDM resolves the issue.
System Information
Operating System: Fedora Linux 43
KDE Plasma Version: 6.5.2
KDE Frameworks Version: 6.18
Qt Version: 6.10
Graphics Platform: Wayland (Default)
Processors: Intel Core i5-3470 (Ivy Bridge)
GPU: Intel HD Graphics 2500 (Integrated)
Monitor: Standard VGA Monitor (Max Resolution: 1024x768 @ 60Hz)
Connection Type: VGA (Analog)

note: i face same issue in ubuntu with older version of kde

Description:
After a fresh installation or update to Fedora 43, the system boots past the BIOS and GRUB. When the boot sequence hands off to the Display Manager (SDDM), the monitor goes black and displays a hardware-level "Out of Range" error message.
This indicates that KWin/Wayland is attempting to drive the VGA monitor at a refresh rate or resolution unsupported by the hardware (likely attempting 75Hz+ on a 60Hz-only panel), whereas X11 correctly identifies the safe limits.

Steps to Reproduce:
Install Fedora 43 KDE Spin on a system with Intel Ivy Bridge iGPU and a VGA monitor (1024x768 native).
Ensure the system defaults to Wayland for SDDM (standard behavior).
Boot the computer.
Wait for the graphical login screen to load.
Observed Result
The monitor displays an "Out of Range" error message. No graphical interface is visible. TTY switching (Ctrl+Alt+F3) is required to regain control.
Expected Result
The SDDM login screen should appear at the monitor's native resolution (1024x768 @ 60Hz).

Workaround Verified:
The following actions resolve the issue, confirming it is a mode-setting negotiation error in Wayland:
Forcing X11: Configuring /etc/sddm.conf.d/ with DisplayServer=x11 allows the login screen to load correctly.
Comment 3 TraceyC 2025-11-20 00:34:04 UTC
Thanks for providing the extra details, and the information about your system. We still need you to attach or copy the output of

kscreen-doctor -o

The "out of range" error most likely means that kwin-wayland is trying to use a resolution your display doesn't support. We need that output to get the information necessary to investigate what kwin-wayland is doing.
Comment 4 Lemma 2025-11-20 04:21:33 UTC
When out of range error happened i can't really get "kscreen-doctor-o" outputs.
i get kwin log from tty:

Nov 20 03:35:23 localhost-live systemd[2249]: Starting plasma-kwin_wayland.service - KDE Window Manager...
Nov 20 03:35:23 localhost-live systemd[2249]: Started plasma-kwin_wayland.service - KDE Window Manager.
Nov 20 03:35:25 localhost-live kwin_wayland[2513]: No backend specified, automatically choosing drm
Nov 20 03:35:30 localhost-live kwin_wayland[2513]: kwin_core: EDID colorimetry xy(0, 0) xy(0, 0) xy(0, 0) xy(0, 0) is invalid
Nov 20 03:35:33 localhost-live kwin_wayland_wrapper[2637]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Nov 20 03:35:33 localhost-live kwin_wayland_wrapper[2637]: > Warning:          Could not resolve keysym XF86RefreshRateToggle
Nov 20 03:35:33 localhost-live kwin_wayland_wrapper[2637]: > Warning:          Could not resolve keysym XF86Accessibility
Nov 20 03:35:33 localhost-live kwin_wayland_wrapper[2637]: > Warning:          Could not resolve keysym XF86DoNotDisturb
Nov 20 03:35:33 localhost-live kwin_wayland_wrapper[2637]: Errors from xkbcomp are not fatal to the X server
Nov 20 03:35:33 localhost-live kwin_wayland_wrapper[2646]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Nov 20 03:35:33 localhost-live kwin_wayland_wrapper[2646]: > Warning:          Unsupported maximum keycode 708, clipping.
Nov 20 03:35:33 localhost-live kwin_wayland_wrapper[2646]: >                   X11 cannot support keycodes above 255.
Nov 20 03:35:33 localhost-live kwin_wayland_wrapper[2646]: > Warning:          Virtual modifier Hyper multiply defined
Nov 20 03:35:33 localhost-live kwin_wayland_wrapper[2646]: >                   Using 0, ignoring 0
Nov 20 03:35:33 localhost-live kwin_wayland_wrapper[2646]: > Warning:          Virtual modifier ScrollLock multiply defined
Nov 20 03:35:33 localhost-live kwin_wayland_wrapper[2646]: >                   Using 0, ignoring 0
Nov 20 03:35:33 localhost-live kwin_wayland_wrapper[2646]: > Warning:          Could not resolve keysym XF86RefreshRateToggle
Nov 20 03:35:33 localhost-live kwin_wayland_wrapper[2646]: > Warning:          Could not resolve keysym XF86Accessibility
Nov 20 03:35:33 localhost-live kwin_wayland_wrapper[2646]: > Warning:          Could not resolve keysym XF86DoNotDisturb
Nov 20 03:35:33 localhost-live kwin_wayland_wrapper[2646]: Errors from xkbcomp are not fatal to the X server
Nov 20 03:35:42 localhost-live kwin_wayland_wrapper[3246]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Nov 20 03:35:42 localhost-live kwin_wayland_wrapper[3246]: > Warning:          Unsupported maximum keycode 708, clipping.
Nov 20 03:35:42 localhost-live kwin_wayland_wrapper[3246]: >                   X11 cannot support keycodes above 255.
Nov 20 03:35:42 localhost-live kwin_wayland_wrapper[3246]: > Warning:          Virtual modifier Hyper multiply defined
Nov 20 03:35:42 localhost-live kwin_wayland_wrapper[3246]: >                   Using 0, ignoring 0
Nov 20 03:35:42 localhost-live kwin_wayland_wrapper[3246]: > Warning:          Virtual modifier ScrollLock multiply defined
Nov 20 03:35:42 localhost-live kwin_wayland_wrapper[3246]: >                   Using 0, ignoring 0
Nov 20 03:35:42 localhost-live kwin_wayland_wrapper[3246]: > Warning:          Could not resolve keysym XF86RefreshRateToggle
Nov 20 03:35:42 localhost-live kwin_wayland_wrapper[3246]: > Warning:          Could not resolve keysym XF86Accessibility
Nov 20 03:35:42 localhost-live kwin_wayland_wrapper[3246]: > Warning:          Could not resolve keysym XF86DoNotDisturb
Nov 20 03:35:42 localhost-live kwin_wayland_wrapper[3246]: Errors from xkbcomp are not fatal to the X server
Nov 20 03:35:42 localhost-live kwin_wayland_wrapper[3247]: The XKEYBOARD keymap compiler (xkbcomp) reports:
Nov 20 03:35:42 localhost-live kwin_wayland_wrapper[3247]: > Warning:          Unsupported maximum keycode 708, clipping.
Nov 20 03:35:42 localhost-live kwin_wayland_wrapper[3247]: >                   X11 cannot support keycodes above 255.
Nov 20 03:35:42 localhost-live kwin_wayland_wrapper[3247]: > Warning:          Virtual modifier Hyper multiply defined
Nov 20 03:35:42 localhost-live kwin_wayland_wrapper[3247]: >                   Using 0, ignoring 0
Nov 20 03:35:42 localhost-live kwin_wayland_wrapper[3247]: > Warning:          Virtual modifier ScrollLock multiply defined
Nov 20 03:35:42 localhost-live kwin_wayland_wrapper[3247]: >                   Using 0, ignoring 0
Nov 20 03:35:42 localhost-live kwin_wayland_wrapper[3247]: > Warning:          Could not resolve keysym XF86RefreshRateToggle
Nov 20 03:35:42 localhost-live kwin_wayland_wrapper[3247]: > Warning:          Could not resolve keysym XF86Accessibility
Nov 20 03:35:42 localhost-live kwin_wayland_wrapper[3247]: > Warning:          Could not resolve keysym XF86DoNotDisturb
Nov 20 03:35:42 localhost-live kwin_wayland_wrapper[3247]: Errors from xkbcomp are not fatal to the X server
Nov 20 03:41:58 localhost-live kwin_wayland[2513]: kwin_core: Failed to delay sleep: Sender is not authorized to send message
Nov 20 03:41:58 localhost-live kwin_wayland[2513]: kwin_wayland_drm: Atomic modeset test failed! Permission denied
Nov 20 03:41:58 localhost-live kwin_wayland[2513]: kwin_wayland_drm: Setting dpms mode failed!

there are errors here , which might helpful to you.
Again I repeat " THIS 'OUT OF RANGE' ERROR SPECIFIC TO KDE PLASMA, I TRY KUBUNTU, KDE NEON, ARCH WITH KDE, I FACE SAME ISSUE.
GNOME WITH WAYLAND WORKS FINE IN MY SYSTEM, SO ITS NOT ABOUT WAYLAND IS NOT WORKING IN MY SYSTEM.

If you want ,i can test other distros kwin log.
Comment 5 TraceyC 2025-11-20 17:13:09 UTC
(In reply to Lemma from comment #4)
> When out of range error happened i can't really get "kscreen-doctor-o"

Unfortunately, it would be necessary to SSH in from another system to do that. If that isn't possible, don't worry about it for now.

> i get kwin log from tty:

Thank you, that's potentially helpful. The kwin developers will take a look from here.
> Again I repeat " THIS 'OUT OF RANGE' ERROR SPECIFIC TO KDE PLASMA, I TRY

I need to ask you to tone down your replies. I was gathering enough information to make this report actionable. There is no need for this. Thank you for your understanding.
Comment 6 Zamundaaa 2025-11-20 17:46:22 UTC
This is almost certainly a driver issue, neither KWin nor Xorg determine which modes are usable, that's the kernel driver's job.

Please attach the output of
> drm_info
and
> xrandr --verbose
in the Xorg session.
Comment 7 Lemma 2025-11-20 18:37:33 UTC
Created attachment 186999 [details]
drm_info, xrandr and screen doctor o, outputs
Comment 8 Zamundaaa 2025-11-27 21:24:31 UTC
ah, there it is: the kernel reports 1024×768@75.03 as supported. That's unfortunate... you can report it at https://gitlab.freedesktop.org/drm/i915/kernel/-/issues

Best I can think of for what we can do on our side is to be way more conservative with VGA, to never choose non-preferred modes by default for that connector type specifically.

As for your situation, if you can ssh into the computer, running
WAYLAND_DISPLAY=wayland-0 kscreen-doctor output.1.mode.1
after logging into the Wayland session should make the display work (in case the order of modes is different in the Wayland session, you can try mode.2 or mode.3 as well)
Comment 9 Bug Janitor Service 2025-11-27 21:31:34 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/8496
Comment 10 Lemma 2025-11-28 01:25:50 UTC
Kernel reports 1024x768@75.03, i think its monitor issue, windows driver also report 75hz as supported.
Comment 11 Lemma 2025-11-28 01:34:52 UTC
(In reply to Bug Janitor Service from comment #9)
> A possibly relevant merge request was started @
> https://invent.kde.org/plasma/kwin/-/merge_requests/8496

for me configuring /etc/sddm.conf.d/ with DisplayServer=x11 allows the login screen to load correctly, and then copy kscreen folder to .local/share with correct monitor data works.

i get kscreen folder from linux mint kde plasma 5.4.0 x11 session, which load correct data for my monitor.
Comment 12 TraceyC 2025-12-01 17:38:01 UTC
I've seen the same error with a TV connected over HDMI. Would it make sense to do a similar workaround for HDMI in addition to VGA? I can get kscreen-doctor output if you need it.
Comment 13 Zamundaaa 2025-12-02 17:00:43 UTC
Git commit d45ea670c1b8fa07c079a5a426155fd10d2c5a58 by Xaver Hugl.
Committed on 02/12/2025 at 16:37.
Pushed by zamundaaa into branch 'master'.

outputconfigurationstore: be more conservative with VGA displays

While choosing higher refresh rates is very safe with digital connections, it can be
quite risky with VGA and lead to the display not showing an image.

M  +5    -1    src/outputconfigurationstore.cpp

https://invent.kde.org/plasma/kwin/-/commit/d45ea670c1b8fa07c079a5a426155fd10d2c5a58
Comment 14 Zamundaaa 2025-12-02 17:44:39 UTC
Git commit be2e23085628c3da703abc2c6a83d9e0bb84c741 by Xaver Hugl.
Committed on 02/12/2025 at 17:11.
Pushed by zamundaaa into branch 'Plasma/6.5'.

outputconfigurationstore: be more conservative with VGA displays

While choosing higher refresh rates is very safe with digital connections, it can be
quite risky with VGA and lead to the display not showing an image.


(cherry picked from commit d45ea670c1b8fa07c079a5a426155fd10d2c5a58)

Co-authored-by: Xaver Hugl <xaver.hugl@kde.org>

M  +5    -1    src/outputconfigurationstore.cpp

https://invent.kde.org/plasma/kwin/-/commit/be2e23085628c3da703abc2c6a83d9e0bb84c741
Comment 15 Zamundaaa 2025-12-05 16:57:34 UTC
(In reply to TraceyC from comment #12)
> I've seen the same error with a TV connected over HDMI. Would it make sense
> to do a similar workaround for HDMI in addition to VGA? I can get
> kscreen-doctor output if you need it.
I don't think so, HDMI is digital and the driver can and needs to know which modes work. If that doesn't work, it needs to be reported to the graphics vendor.