Issues with Samsung G8 OLED 240Hz on Linux: Refresh Rate & Screen Wake Problems

Hardware Hub
, ,
1

Hello everyone,

I recently purchased two Samsung G8 OLED screens (model G80SD, 4K, 240Hz) and connected them via DisplayPort to my AMD 7900GRE GPU on an AM5 platform. While they’re fantastic displays, I’m encountering two major issues:

1. Refresh Rate on Linux (Fedora Silverblue)

On Linux, the screens are only detected as 120Hz, whereas on Windows 11 (dual-boot setup), they properly show up as 240Hz.
From my research, this seems to be a known issue with these and similar Samsung displays, possibly due to incomplete EDID data. For example, here’s a related discussion: Arch Linux Forums.

I understand that tinkering with EDID can solve the problem, but I’m hesitant to go down that route since I’ve read it carries the risk of bricking the screens if done incorrectly.

Does anyone know of safer or alternative solutions to enable 240Hz on Linux?

2. Screen Wake Issues

When the PC wakes from sleep, the screens behave strangely:

  • They blink and appear to reinitialize.
  • My open windows all shift to the secondary screen (which is also where GRUB and the login screen appear by default).

This wasn’t an issue with my previous triple-screen setup. All windows used to stay on their assigned screens, so I’m wondering:

  • What’s causing this behavior?
  • How can I stop my windows from moving around when waking from sleep?

Bonus Question:

Would using a LevelOneTech DP 1.4 KVM help resolve these issues?

  • I’ve read it copies EDID on a hardware level and keeps screens “connected” even when the PC sleeps. Could this implicitly fix the refresh rate and wake issues?

Any insights or solutions would be greatly appreciated. Thanks!

2

Most of the models L1T sells do not have that built in.

Is a stand alone box for that

I would talk with @ Level1_Amber prior to any purchase tho

3

edid engine is for hdcp reasons not monitor cloning reasons because monitor cloning is hard to do without introducing free sync incompatibility artifacts.

anyway it sounds like the root problem is a shitty cable. get s 6 foot club3d cable and retry before adding a KVM to the mix

1 Like
4

I am currently using KabelDirect cables which are premium cables, (I had enough problems with shitty cables in the past) I do not sell out on cables :-). But I also have a club 3d cable of 2meter (I am in europe) which is a bit longer then 6foot, And the experience is the same.
I am not saying the cables are not the problem, but seems unlikely.

Are you also saying that the quality of the cables can have a different impact between operating systems? 240hz on windows but not on linux?

5

yep, can be cabling and cable training. try a ferrite core then could be external interference.

the dp phy training algo isn’t the same between OSs and even the physical port on the card can make a difference

1 Like
6

I just checked and it seems my cables are 3m long so that is almost 10foot. So I am guessing indeed that might be the problem…

so would it be wise to go immediately for the FIBBR DisplayPort 2.1 3meter(10foot) cable?

7

yep

8

I bought the fibbr cables ( to be exact these: FIBBR 16K DisplayPort 2.1 glasvezelkabel, 3 m, 40 Gbit/s, DP naar DP-kabel (16K @30Hz, 10K @30Hz, 8K @60Hz, 4K @144Hz), 3D, G-Sync & FreeSync voor 3090 gaming monitor, grafische kaart, laptop, tv : Amazon.de: Computers & accessoires)
And it does not make a difference, 120hz on my fedora linux silverblue and 240hz on windows 11. It also does not matter what port on the gpu I am using.
With this cable it should work no?
I also tried adding ferrite cores on my existing copper cables, no difference at all.
This is what Drm_info returns:

   ├───Connector 1
│   │   ├───Object ID: 101
│   │   ├───Type: DisplayPort
│   │   ├───Status: connected
│   │   ├───Physical size: 700×390 mm
│   │   ├───Subpixel: unknown
│   │   ├───Encoders: {1}
│   │   ├───Modes
│   │   │   ├───3840×[email protected] preferred driver phsync nvsync 
│   │   │   ├───3840×[email protected] driver phsync pvsync 16:9 
│   │   │   ├───3840×[email protected] driver phsync pvsync 16:9 
│   │   │   ├───3840×[email protected] driver phsync pvsync 16:9 
│   │   │   ├───3840×[email protected] driver phsync pvsync 16:9 
│   │   │   ├───3840×[email protected] driver phsync pvsync 16:9 
│   │   │   ├───3840×[email protected] driver phsync pvsync 16:9 
│   │   │   ├───2560×[email protected] driver phsync nvsync 
│   │   │   ├───2560×[email protected] driver phsync nvsync 
│   │   │   ├───1920×[email protected] driver phsync nvsync 
│   │   │   ├───1920×[email protected] driver phsync pvsync 16:9 
│   │   │   ├───1920×[email protected] driver phsync pvsync 16:9 
│   │   │   ├───1920×[email protected] driver phsync pvsync 
│   │   │   ├───1920×[email protected] driver phsync pvsync 16:9 
│   │   │   ├───1920×[email protected] driver phsync pvsync 16:9 
│   │   │   ├───1600×[email protected] driver phsync nvsync 
│   │   │   ├───1680×[email protected] driver nhsync pvsync 
│   │   │   ├───1600×[email protected] driver phsync pvsync 
│   │   │   ├───1280×[email protected] driver phsync pvsync 
│   │   │   ├───1280×[email protected] driver phsync pvsync 
│   │   │   ├───1440×[email protected] driver nhsync pvsync 
│   │   │   ├───1280×[email protected] driver nhsync pvsync 
│   │   │   ├───1152×[email protected] driver phsync pvsync 
│   │   │   ├───1280×[email protected] driver phsync pvsync 
│   │   │   ├───1280×[email protected] driver phsync pvsync 16:9 
│   │   │   ├───1280×[email protected] driver phsync pvsync 16:9 
│   │   │   ├───1024×[email protected] driver phsync pvsync 
│   │   │   ├───1024×[email protected] driver nhsync nvsync 
│   │   │   ├───1024×[email protected] driver nhsync nvsync 
│   │   │   ├───800×[email protected] driver phsync pvsync 
│   │   │   ├───800×[email protected] driver phsync pvsync 
│   │   │   ├───800×[email protected] driver phsync pvsync 
│   │   │   ├───720×[email protected] driver nhsync nvsync 16:9 
│   │   │   ├───720×[email protected] driver nhsync nvsync 16:9 
│   │   │   ├───640×[email protected] driver nhsync nvsync 
│   │   │   ├───640×[email protected] driver nhsync nvsync 4:3 
│   │   │   └───640×[email protected] driver nhsync nvsync 
│   │   └───Properties
│   │       ├───"EDID" (immutable): blob = 130
│   │       ├───"DPMS": enum {On, Standby, Suspend, Off} = On
│   │       ├───"link-status": enum {Good, Bad} = Good
│   │       ├───"non-desktop" (immutable): range [0, 1] = 0
│   │       ├───"TILE" (immutable): blob = 0
│   │       ├───"CRTC_ID" (atomic): object CRTC = 83
│   │       ├───"scaling mode": enum {None, Full, Center, Full aspect} = None
│   │       ├───"underscan": enum {off, on, auto} = off
│   │       ├───"underscan hborder": range [0, 128] = 0
│   │       ├───"underscan vborder": range [0, 128] = 0
│   │       ├───"max bpc": range [8, 16] = 16
│   │       ├───"Colorspace": enum {Default, BT709_YCC, opRGB, BT2020_RGB, BT2020_YCC} = Default
│   │       ├───"HDR_OUTPUT_METADATA": blob = 0
│   │       ├───"vrr_capable" (immutable): range [0, 1] = 1
│   │       ├───"Content Protection": enum {Undesired, Desired, Enabled} = Undesired
│   │       ├───"HDCP Content Type": enum {HDCP Type0, HDCP Type1} = HDCP Type0
│   │       └───"subconnector" (immutable): enum {Unknown, VGA, DVI-D, HDMI, DP, Wireless, Native} = Native

and :
cat /sys/class/drm/card1-DP-1/edid | monitor-parse-edid

Name: Odyssey G80SD
EISA ID: SAMe035
EDID version: 1.4
EDID extension blocks: 2
Screen size: 69.7 cm x 39.2 cm (31.48 inches, aspect ratio 16/9 = 1.78)
Gamma: 2.2
Digital signal
Max video bandwidth: 2340 MHz

	HorizSync 255-255
	VertRefresh 48-240

	# Monitor preferred modeline (60.0 Hz vsync, 133.3 kHz hsync, ratio 16/9, 139 dpi)
	ModeLine "3840x2160" 533.25 3840 3888 3920 4000 2160 2163 2168 2222 -hsync +vsync

	# Monitor supported CEA modeline (60.0 Hz vsync, 67.5 kHz hsync, ratio 16/9, 69 dpi)
	ModeLine "1920x1080" 148.5 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync

	# Monitor supported CEA modeline (120.0 Hz vsync, 135.0 kHz hsync, ratio 16/9, 69 dpi)
	ModeLine "1920x1080" 297 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync

	# Monitor supported CEA modeline (60.0 Hz vsync, 45.0 kHz hsync, ratio 16/9, 46 dpi)
	ModeLine "1280x720" 74.25 1280 1390 1430 1650 720 725 730 750 +hsync +vsync

	# Monitor supported CEA modeline (59.9 Hz vsync, 31.5 kHz hsync, ratio 3/2, 26x31 dpi) (bad ratio)
	ModeLine "720x480" 27 720 736 798 858 480 489 495 525 -hsync -vsync

	# Monitor supported modeline (60.0 Hz vsync, 88.8 kHz hsync, ratio 16/9, 93 dpi)
	ModeLine "2560x1440" 241.5 2560 2608 2640 2720 1440 1443 1448 1481 -hsync +vsync

	# Monitor supported modeline (120.0 Hz vsync, 183.0 kHz hsync, ratio 16/9, 93 dpi)
	ModeLine "2560x1440" 497.75 2560 2608 2640 2720 1440 1443 1448 1525 -hsync +vsync

	# Monitor supported modeline (60.0 Hz vsync, 67.5 kHz hsync, ratio 16/9, 69 dpi)
	ModeLine "1920x1080" 148.5 1920 2008 2052 2200 1080 1084 1089 1125 +hsync +vsync

notice the VertRefresh 48-240
Seems to be really missing on linux

9

So the option is there

You can append:
video=<port-name>:<resolution-w>x<resolution-h>@<refresh-rate> to grub under GRUB_CMDLINE_LINUX_DEFAULT and lock a port to the resolution and refresh rate you want from boot

I’d start with 1 port and test before doing both

Worst case, this is easily reversible from Grub recovery

Doesn’t solve the root negotiation problem, but doesn’t risk bricking a monitor (wtf?)

10

Thanks for the suggestion. I am on Silverblue, so I tried the equivalent with kargs
sudo rpm-ostree kargs --append=video=DP-1:3840x2160@240
But It did not work.
why the wtf?

11

I was able to solve my problem

the root cause: Samsung G8 OLED screen.

I returned those 2 screens and replaced them with LG UltraGear OLED 32GS95UV-B

and all my problems went away.

I booted my pc to linux and it was immediately on 240hz.

I put the screens to sleep and no more shifting of all my windows to 1 screen.

And because I wanted to know, i swapped out my new fibbr cables with my old kabledirect copper cables, and still had use of my full 240hz …

@wendell so in the case ( perhaps one of the few cases) the problem was not the cable, but just the monitor.
The samsung g8 oled does not work on 240hz in linux out of the box… And I could not get it to work…

12

I have this same monitor and I have been experiencing exactly these two issues on Linux. @wendell this is not a cable problem—the first issue is a known bug in edid-decode. A fix [1] has been merged and confirmed to work but it will probably take a few months to propogate downstream.

As far as I know it is still unknown what is causing the sleep issue, and it may well be a firmware bug on Samsung’s end. Many people in this reddit thread [2] have reported similar symptoms for a similar model on Windows which were fixed by switching to HDMI—unfortunately for us Linux users with AMD GPUs, AMD is legally barred [3] from releasing an up-to-date HDMI driver on Linux. If anyone has confirmed whether a DisplayPort passthrough device fixes the issue I would be interested to know, since this would likely be cheaper than buying a new monitor.

I am not able to post properly formatted links, so they are included in plaintext below:
[1] https://git.linuxtv.org/edid-decode.git/commit/?id=bc17c383597d45a3ade2395b83a3d91ecb95bc3c
[2] https://old.reddit.com/r/ultrawidemasterrace/comments/12yvvoj/samsung_g8_oled_does_your_monitor_wake_from_sleep/
[3] https://gitlab.freedesktop.org/drm/amd/-/issues/1417#note_2303163

2 Likes
13

An update for those who might be following this: I confirmed that manually setting the EDID file fixes the refresh rate problem but not the wake-from-sleep problem.

I also tested this same monitor with a Windows machine, and found that wake-from-sleep works correctly. It therefore seems like a Linux driver issue, so I filed a bug [1] in what I hope is the appropriate place.

[1] https://gitlab.freedesktop.org/drm/amd/-/issues/3952

1 Like
14

How did you get the EDID?

I have this monitor and I tried extracting the EDID from Windows using MonitorInfoView, then injecting EDID using kernel command line and I am only able to get 120hz on Linux on both AMD and NVIDIA (119.88 max for nvidia), it also breaks VRR on both as in the VRR option completely disappears from both Gnome and KDE.

Without EDID, AMD can do 120hz max, VRR is available but broken as the screen constantly flashes black due to FPS dropping too low (known issue). 60hz VRR works fine.
Without EDID, NVIDIA can only do 60hz max, VRR works with no issues.

15

Managed to figure this out myself.

I found a program called EnTech Monitor Asset Manager 2.9. With this I set monitor to 240hz VRR on windows (no idea if this is needed or not?) and then selected the RealTime entry for the monitor and clicked File → Save As and save as dibin file.

Loaded this EDID file in linux via kernel command line (drm.edid_firmware=DP-2:edid/g80sd-dibin240-edid.bin), now I get 240hz VRR on driver 570.86.16 on my 5080 using Displayport connection.

EDIT: Apparently this was just a transient issue, possibly with the monitor? The new EDID was actually invalid so “loading” it just started with no custom EDID and 240hz/VRR worked. I am unable to reproduce the stuck on 60hz issue, but loading a valid custom EDID does break VRR for Nvidia at least.