Amd Radeon R9 (Tonga 200 series) and two monitors 24" + 32"

[WCSN]

Good morning!
I bought a vintage 32" DELL UP3214Q monitor Amd Radeon R9 285 Video supports version 1.2The system has two monitors 24" - 1920x1080_60Hz and 32" - 3840x2160_30Hz or _60Hz if the monitor is connected via DisplayPort ver. 1.2 The 32" monitor can be switched to normal DP1.0 or DP1 mode.2. In DP1.2 mode, the 32" monitor can be set to 3840x2160_60Hz. It works fine in Windows. But not in FreeBSD 14.2.

# pciconf -lcv
...
vgapci0@pci0:11:0:0:    class=0x030000 rev=0x00 hdr=0x00 vendor=0x1002 device=0x6939 subvendor=0x1043 subdevice=0x0486
    vendor     = 'Advanced Micro Devices, Inc. [AMD/ATI]'
    device     = 'Tonga PRO [Radeon R9 285/380]'
    class      = display
    subclass   = VGA
    cap 09[48] = vendor (length 8)
    cap 01[50] = powerspec 3  supports D0 D1 D2 D3  current D0
    cap 10[58] = PCI-Express 2 legacy endpoint max data 256(256) RO NS
                 max read 512
                 link x16(x16) speed 2.5(8.0) ASPM L1(L0s/L1)
    cap 05[a0] = MSI supports 1 message, 64 bit enabled with 1 message
    ecap 000b[100] = Vendor [1] ID 0001 Rev 1 Length 16
    ecap 0001[150] = AER 2 0 fatal 1 non-fatal 1 corrected
    ecap 0015[200] = Resizable BAR 1
    ecap 0019[270] = PCIe Sec 1 lane errors 0xfffe
    ecap 000f[2b0] = ATS 1
    ecap 0013[2c0] = Page Page Request 1
    ecap 001b[2d0] = Process Address Space ID 1
    ecap 000e[328] = ARI 1

Set DP1.0: normally, there are two monitors in maximum modes. The system defines two DVI-D-0 and DisplayPort-0 inputs.

# xrandr -q
Screen 0: minimum 320 x 200, current 5760 x 2160, maximum 16384 x 16384
DVI-D-0 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 521mm x 293mm
   1920x1080     60.00*+  71.91    50.00    59.94
   1680x1050     59.88
   1600x900      60.00
   1280x1024     60.02
   1440x900      59.90
   1280x800      59.91
   1280x720      60.00    50.00    59.94
   1024x768      70.07    60.00
   800x600       72.19    60.32    56.25
   720x576       50.00
   720x480       60.00    59.94
   640x480       72.81    66.67    60.00    59.94
   720x400       70.08
DisplayPort-0 connected 3840x2160+1920+0 (normal left inverted right x axis y axis) 698mm x 392mm
   3840x2160     30.00*+
   1920x1200     59.88
   1920x1080     60.00
   1600x1200     60.00
   1680x1050     59.95
   1280x1024     75.02    60.02
   1280x800      59.81
   1152x864      75.00
   1024x768      75.03    60.00
   800x600       75.00    60.32
   640x480       75.00    59.94
   720x400       70.08
DisplayPort-1 disconnected (normal left inverted right x axis y axis)
DisplayPort-2 disconnected (normal left inverted right x axis y axis)
HDMI-A-0 disconnected (normal left inverted right x axis y axis)

Set DP1.2 :

# xrandr -q
Screen 0: minimum 320 x 200, current 5760 x 2160, maximum 16384 x 16384
DisplayPort-0 disconnected (normal left inverted right x axis y axis)
HDMI-A-0 disconnected (normal left inverted right x axis y axis)
DVI-D-0 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 521mm x 293mm
   1920x1080     60.00*+  71.91    50.00    59.94
   1680x1050     59.88
   1600x900      60.00
   1280x1024     60.02
   1440x900      59.90
   1280x800      59.91
   1280x720      60.00    50.00    59.94
   1024x768      70.07    60.00
   800x600       72.19    60.32    56.25
   720x576       50.00
   720x480       60.00    59.94
   640x480       72.81    66.67    60.00    59.94
   720x400       70.08
DVI-D-1 disconnected (normal left inverted right x axis y axis)
DisplayPort-1 connected 1920x2160+3840+0 (normal left inverted right x axis y axis) 698mm x 392mm
   1920x2160     59.99*+
   1920x1080     59.99
DisplayPort-2 connected 1920x2160+1920+0 (normal left inverted right x axis y axis) 698mm x 392mm
   1920x2160     59.99*+
   1920x1200     59.88
   1920x1080     60.00
   1600x1200     60.00
   1680x1050     59.95
   1280x1024     75.02    60.02
   1280x800      59.81
   1152x864      75.00
   1024x768      75.03    60.00
   800x600       75.00    60.32
   640x480       75.00    59.94
   720x400       70.08

And my system normal work if M32" set to DP1.0 for exept 60Hz only 30Hz . This small truble is nervus .
I changed xorg.conf in different ways until I settled on the configuration of xorg.conf attached in the attachment. The image file and the current monitor configuration are also attached there.FreeBSD believes that the M32 is two monitors each at 1920x2160 and indeed they "work together" as one at 3840x2160 and 60Hz.DE Lxde and Openbox start normally, as does sddm. KDE - plasmashell is not displayed.Software: Drivers (all needed) and any drm/mesa have been installed and updated to the latest version as of the date of publication of this post. Any needent options added to rc.conf, loader.conf and other places.

If you have any ideas on how to normalize with the plasma situation or, if possible, bring it to the "two monitors" state.
Thanks for any ideas.

 

[astyle]

For starters, your GPU is Hawaii, not Tonga: https://www.techpowerup.com/gpu-specs/radeon-r9-290x.c2460

Second, no need to mess with xorg.conf - what you need to do is install graphics/drm-kmod. Once that pulls in the dependencies, enter this into your
/etc/rc.conf: kld_list=/boot/modules/radeonkms.ko (iirc, it may be kld_list=/boot/modules/amdgpu.ko). Then reboot.

This is best done as part of a fresh install, because order of steps really matters here. There's stuff that needs to be in place before you mess with the GPU drivers, and there's stuff that really needs to be left alone until AFTER you get done with GPU drivers. Deviate from that, and you'll end up banging your head against the wall with no results.

If OpenBox starts normally, but KDE does not: That really points to the need to enter this line into your /etc/rc.conf: dbus_enable=YES. The Handbook mentions that, BTW. Then reboot.

 

[WCSN]

For starters, your GPU is Hawaii, not Tonga: https://www.techpowerup.com/gpu-specs/radeon-r9-290x.c2460

Second, no need to mess with xorg.conf - what you need to do is install graphics/drm-kmod. Once that pulls in the dependencies, enter this into your
/etc/rc.conf: kld_list=/boot/modules/radeonkms.ko (iirc, it may be kld_list=/boot/modules/amdgpu.ko). Then reboot.

This is best done as part of a fresh install, because order of steps really matters here. There's stuff that needs to be in place before you mess with the GPU drivers, and there's stuff that really needs to be left alone until AFTER you get done with GPU drivers. Deviate from that, and you'll end up banging your head against the wall with no results.

If OpenBox starts normally, but KDE does not: That really points to the need to enter this line into your /etc/rc.conf: dbus_enable=YES. The Handbook mentions that, BTW. Then reboot.

Tanks for answear. All your solutions is right but they already make before.
And videochip on my system is Tonga. About it say pciconf and GPU-Z.
My system normal work only when monitor set (settings menu himself of monitor) on mode DP1.0. Problems havent if monitor set to DP1.2 and only in FreeBSD.

 

[astyle]

Tanks for answear. All your solutions is right but they already make before.

Does that include the dbus? dbus is essential for starting KDE.

 

[WCSN]

Does that include the dbus? dbus is essential for starting KDE.

Yes. This need make on first time.

% cat /etc/rc.conf | grep dbus
dbus_enable="YES"

 

[astyle]

And videochip on my system is Tonga. About it say pciconf and GPU-Z.

If your GPU is in fact Tonga, it's defnitely NOT a 290X: This page lists all the cards with a Tonga GPU.

Closest match would be R9 285. There's also an R9 285X, but that one was never released.

Amd Radeon R9 290X

That's definitely Hawaii. And looking at https://cgit.freebsd.org/ports/tree/graphics/gpu-firmware-amd-kmod/pkg-plist, both Hawaii and Tonga firmwares are there, so using amdgpu in /etc/rc.conf is correct.

I'd suggest running kldstat | grep amdgpu when you succeed. I'm pretty sure that Hawaii firmware blobs will show up.

 

[WCSN]

If your GPU is in fact Tonga, it's defnitely NOT a 290X: This page lists all the cards with a Tonga GPU.

Closest match would be R9 285. There's also an R9 285X, but that one was never released.


That's definitely Hawaii. And looking at https://cgit.freebsd.org/ports/tree/graphics/gpu-firmware-amd-kmod/pkg-plist, both Hawaii and Tonga firmwares are there, so using amdgpu in /etc/rc.conf is correct.

I'd suggest running kldstat | grep amdgpu when you succeed. I'm pretty sure that Hawaii firmware blobs will show up.


% kldstat | grep amdgpu
29 1 0xffffffff83800000 6688e8 amdgpu.ko
36 1 0xffffffff836c3000 9b58 amdgpu_tonga_mc_bin.ko
37 1 0xffffffff836cd000 6378 amdgpu_tonga_pfp_bin.ko
38 1 0xffffffff836d4000 6378 amdgpu_tonga_me_bin.ko
39 1 0xffffffff836db000 4378 amdgpu_tonga_ce_bin.ko
40 1 0xffffffff836e0000 5a88 amdgpu_tonga_rlc_bin.ko
41 1 0xffffffff836e6000 42388 amdgpu_tonga_mec_bin.ko
42 1 0xffffffff83729000 42388 amdgpu_tonga_mec2_bin.ko
43 1 0xffffffff8376c000 4a78 amdgpu_tonga_sdma_bin.ko
44 1 0xffffffff83771000 4a78 amdgpu_tonga_sdma1_bin.ko
45 1 0xffffffff83776000 517a0 amdgpu_tonga_uvd_bin.ko
46 1 0xffffffff837c8000 295e0 amdgpu_tonga_vce_bin.ko
47 1 0xffffffff83e69000 21e80 amdgpu_tonga_smc_bin.ko

 

[astyle]

Well, Tonga chipset is the important part...

In which case, your installation of KDE Plasma most likely does not have everything installed. Do you have x11/plasma6-plasma-desktop installed? That one should pull in enough dependencies to have a functional KDE desktop.

 

[WCSN]

Well, Tonga chipset is the important part...

In which case, your installation of KDE Plasma most likely does not have everything installed. Do you have x11/plasma6-plasma-desktop installed? That one should pull in enough dependencies to have a functional KDE desktop.

... Yes.
I said above. If M32 set on DP1.0 - KDE work normally but M32 3840x2160 only 30Hz ... if M32 set on DP1.2 can use 60Hz but have strange situation with DisplayPorts /// see above ...

 

[WCSN]

For starters, your GPU is Hawaii, not Tonga: https://www.techpowerup.com/gpu-specs/radeon-r9-290x.c2460

Second, no need to mess with xorg.conf - what you need to do is install graphics/drm-kmod. Once that pulls in the dependencies, enter this into your
/etc/rc.conf: kld_list=/boot/modules/radeonkms.ko (iirc, it may be kld_list=/boot/modules/amdgpu.ko). Then reboot.

This is best done as part of a fresh install, because order of steps really matters here. There's stuff that needs to be in place before you mess with the GPU drivers, and there's stuff that really needs to be left alone until AFTER you get done with GPU drivers. Deviate from that, and you'll end up banging your head against the wall with no results.

If OpenBox starts normally, but KDE does not: That really points to the need to enter this line into your /etc/rc.conf: dbus_enable=YES. The Handbook mentions that, BTW. Then reboot.

Sorry, I mistake. My card R9 285

 

[astyle]

Yeah, and I just remembered something: Open Source graphics drivers usually don't support the very latest DP/HDMI standards. That's an unfortunate limitation (in comparison to Windows drivers for the same GPUs).

Your best bet is to go with the earlier available version of DP / HDMI.

If M32 set on DP1.0 - KDE work normally

I'd suggest prioritizing visibility of the KDE desktop over maxing out the capability of the monitor. Otherwise, it's gonna be trial and error tyring to find that sweet spot.

 

[WCSN]

Yeah, and I just remembered something: Open Source graphics drivers usually don't support the very latest DP/HDMI standards. That's an unfortunate limitation (in comparison to Windows drivers for the same GPUs).

Your best bet is to go with the earlier available version of DP / HDMI.


I'd suggest prioritizing visibility of the KDE desktop over maxing out the capability of the monitor. Otherwise, it's gonna be trial and error tyring to find that sweet spot.

But I'm not looking for a golden mean, namely the maximum possible - 60Hz - this my target. Also... It works in Windows. Actually, in xfce4, OpenBox also works fine, as it turned out. But xfce4, OpenBox. This DE are not among my favorites. Also, as it turned out, xfce4 can change font scaling SEPARATELY for each monitor - KDE can't are.
I'll be waiting updates for KDE.

 

[WCSN]

I can load Plasma Wayland.
If click RBmouse - plasma crashed and have very strange: for 32" monitor TWO screens

 

[astyle]

OK, nice... Thing is, that right-click crash bug is solvable by setting a special compilation flag. If you're willing to study this thread to understand it better, here's the link: https://forums.freebsd.org/threads/trying-to-run-kde-6-plasma-with-wayland.93951/page-22

BTW, I'd like to ask: How well does the screensaver work for you? (If the screen turns itself off after 5 minutes, I should be able to just wiggle my mouse or press a key, and be back to normal. In my case, Plasma Wayland crashes in this scenario, I can't leave the screen alone for more than 5 minutes).

 

[WCSN]

"...screensaver work for you?"

Screensaver ... fully holded X11 and Wayland... but I say: only DP 1.2 mode. And if only load sddm on login - if last login sddm: X11 holded too. Only Ctrl-Alt-F[1-8] and 'service sddm restart'. Black screen also if load 'openarena' or any other OpenGL game.
If monitor in DP 1.0 mode - all work norm. But 30Hz

 

[astyle]

What I meant was not so much 'screensaver' but more power management... like, screen turns itself off after 5 minutes. Normally, screen should turn itself back on if you wiggle the mouse or press a key on the keyboard. Under Xorg, that works reliably. Under Wayland, that crashes, no reaction to keyboard or mouse, so I have to SSH in and reboot.

 

[WCSN]

That's exactly how I understood it - power management. I don't use a screensaver, only power management. Above, I talked specifically about power management. And the behavior under wayland is the same. And yes reboot or ssh and "service sddm restart"

 

[astyle]

Seriously, all it takes is restarting SDDM??? I guess that's an idea to check out on my end.

Just thinking about it, that makes some sense - after all, it is the Display Manager, so it's logical for SDDM to handle the task of powering the display...

Last I checked, SDDM does not play well with Wayland - and there's work to be done to make it play well with Wayland. But my info is kind of old, so I expect to see progress in that direction.

 

[astyle]

Well, wow.

Restarting SDDM did the trick for power management, but the session was lost. Everything I was working on (A re-compilation of www/firefox in Konsole) was lost, I was given a brand-new session. That is kind of a showstopper that does need to be addressed.

When I type in my password at a locked screen, I expect to be able to come back to whatever I was working on.

 

[WCSN]

Yeah, that's what you mean... Alas, no, the session will be lost when the sddm is restarted. Actually, restarting sddm is generally not the right solution - the X-server is also restarted - in this case, the session will be lost. Perhaps you need to reboot the graphics shell (plasmashell, gnomeshell or another DE-shell), but launch a new DE-shell in an ssh session...??? Need to think. Might it be enough to reboot the DE module associated with power managements?

Yes, I replaced the graphics card with a Radeon RX 6550XT However, this did not affect the behavior of the graphics subsystem in any way, as described here .

 

[astyle]

Yeah, that's what you mean... Alas, no, the session will be lost when the sddm is restarted. Actually, restarting sddm is generally not the right solution - the X-server is also restarted - in this case, the session will be lost. Perhaps you need to reboot the graphics shell (plasmashell, gnomeshell or another DE-shell), but launch a new DE-shell in an ssh session...??? Need to think. Might it be enough to reboot the DE module associated with power managements?

Yes, I replaced the graphics card with a Radeon RX 6550XT However, this did not affect the behavior of the graphics subsystem in any way, as described here .

Well, you did point me in the right direction - the problems we are discussing are NOT related to GPUs, but rather, SDDM.

It looks like part of the issue is that SDDM is starting in Xorg mode from get-go. Switching to Wayland is not very clean, AFAIK. Rebooting plasma-shell? now that's an idea.

Edit: In my case, restarting plasma-shell doesn't work for me, it just dumps core... maybe that's because I start it as root after restarting the SDDM service?

Edit 2: Update: No, starting plasmashell as regular user made no difference. Dumped core, nothing launched. Same results as root. I think plasmashell only works when the shell itself crashes but the app windows remain up and functional.

 

[WCSN]

>> ... maybe that's because I start it as root after restarting the SDDM service?

Yes, it can be run from the user who launched the DE and there is information about the user's context, and there is also no $DISPLAY in the console session, that is, DISPLAY=:0.0 In the general case, probably so
> plasmashell --replace --display :0.0 &

 

[astyle]

>> ... maybe that's because I start it as root after restarting the SDDM service?

Yes, it can be run from the user who launched the DE and there is information about the user's context, and there is also no $DISPLAY in the console session, that is, DISPLAY=:0.0 In the general case, probably so
> plasmashell --replace --display :0.0 &

This is the output:

astyle@way-kde6:~ $ plasmashell --replace --display :0.0 &
astyle@way-kde6:~ $ Authorization required, but no authorization protocol specified

qt.qpa.xcb: could not connect to display :0.0
qt.qpa.plugin: From 6.5.0, xcb-cursor0 or libxcb-cursor0 is needed to load the Qt xcb platform plugi
n.
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling th
e application may fix this problem.

Available platform plugins are: wayland, wayland-egl, vkkhrdisplay, vnc, xcb, offscreen, minimal.

I tried it before restarting SDDM, after - it made no difference, output was the same, and nothing started, screen did NOT power back on, and manual intervention resulted in a core dump. :/

I saw exact same stuff happen months ago, when people were struggling to start Plasma Wayland at all.

Looking on https://github.com/sddm/sddm , I see that SDDM's last release was in February of 2024, and it's the version that we have in Ports...

The project still seems to be iffy on Wayland, but troubleshooting is a bit beyond me... And yet, I still see SDDM as the last remaining piece of the Wayland puzzle. I'm even willing to live with crappy session handling (Firefox has its own session tracker, which actually come in handy in this situation).