EDIT:
On a 1st-gen Framework 16, running Debian forky with kernel 6.18.5-1, after replacing the original motherboard with a Ryzen AI 300 model, Wayland works fine but Xorg shows only a black screen. Before the motherboard upgrade, Xorg worked without any problems or special configuration.
ORIGINAL POST:
I installed a new motherboard on my gen1 Framework 16 , with the AMD Ryzen AI 9 HX 370 w/ Radeon 890M chip. Quick deets: Debian forky, kernel 6.18.5-1.
Upon install, I noticed two things:
- the laptop no longer sounds like a jet engine (guess the gen 1 mobo was bad, eh?)
- the console booted into a black screen instead of the greeter.
Seeing no need to fix #1, I prooceeded to #2.
In brief, I found that amdgpu didn’t seem top be working, so I tried removing that and upgrading to the latest available kernel (6.18,5), and when that didn’t work I installed the latest amdgpu. Supposedly the DKMS is not necessary, but I found errors indicating that it was missing, so I modfiied the kernel module source until it built (two changes: an expected preprocessor constant HAVE_MIGRATE_DISABLE was not set, and a particularly thorny copy of a const-star-const-star memory location needed a cast - come on AMD, no wonder your stuff never works!). As a side note, the various kernel parameters (amdgpu.dcdebugmask amdgpu.dc amdgpu.gpu_recovery) had no effect.
That got wayland working, but SDDM only boots to a black screen (even with the .conf file moddified to specify wayland, and a command line option used to force the use of /etc/sddm.conf), and X ddoes the same. Presumably SDDM is refusing to use Wayland instead of X, so we’ll simplify this to “X is the problem” until that is ruled out. Who needs a greater anways, when you have “XDG_SESSION_TYPE=wayland dbus-run-session startplasma-wayland” ?
OK, so here are the symptoms: when X is started from the command line (using startx, xinit, X, etc), the VT is switched to a new one, which then remains blank. Switching to an available VT and killing X allows things to be inspected: nothing improper in journalctl or dmesg. Killing the process writes Xorg.0.log, which has no EE flags. The curious thing is that X org keeps logging until 2 ms before it receives the quit signal. What is it doing? Well, it appears to be continuously cycling through screens, doing stuff like this over and over:
[ 36.183] (II) systemd-logind: got fd for /dev/input/event11 13:75 fd 38 paused 1
[ 36.183] (II) systemd-logind: releasing fd for 13:75
[ 36.218] (II) config/udev: Adding input device Framework Laptop 16 Numpad Module System Control (/dev/input/event6)
[ 36.218] () Framework Laptop 16 Numpad Module System Control: Applying InputClass “evdev keyboard catchall”
[ 36.218] () Framework Laptop 16 Numpad Module System Control: Applying InputClass “libinput keyboard catchall”
[ 36.218] (II) Using input driver ‘libinput’ for ‘Framework Laptop 16 Numpad Module System Control’
[ 36.220] (II) systemd-logind: got fd for /dev/input/event6 13:70 fd 38 paused 1
[ 36.220] (II) systemd-logind: releasing fd for 13:70
At this point, I need to stop debugging this and start getting some work done. Wayland has some issues (Chromium-based apps won’t run, window shading isn’t supported) and using KDE instead of the stalwart Enlightenment (Wayland support doesn’t work! come on, Rasterman!) has some issues, largely due to the Applesque approach of continuing to remove configuration options until the user experience is nice and predicatble for, presumable, tech support calls.
OK, enough blather. My question: is this standard behavior, i.e. is Xorg not currently compatible with this chip? Please don’t just chime in with “works for me”: if it works for you, let me know your kernel version (uname -a) and Linux distro (lsb_release -a) so I can use those as data points next time I have an evening free to debug this.
thanks for reading 