Fedora 39 on the Framework Laptop 13

[junaruga]

I noticed all the "Fedora 39 Community Forum links such as https://community.frame.work/t/fedora-39-official-fedora-39-thread/37465/3 (/3!) to this page on the Linux compatibility page are not accurate. It should be https://community.frame.work/t/fedora-39-on-the-framework-laptop/37465/.

[Nils]

Electron does support running on wayland directly and produces crisp text with fractional scaling then. The problem is that each electron-based app packages things differently, so you’ll have to jump through different hoops to get the requisite options to the particular app. It usually involves some combination of the options:

--enable-features=UseOzonePlatform --ozone-platform=wayland --enable-features=WaylandWindowDecorations

Hopefully this gives you sufficient keywords to search how your particular app needs to be massaged. Chrome/Chromium has a flag in chrome://flags now that allows setting Preferred Ozone platform to wayland, so slowly apps are catching on and making a bit easier to set. Chromium as packaged by Fedora already defaults to Wayland.

@Matt_Hartley

@v_d

blurrry apps with fractional scaling at 125% (really noticeable on electron apps like Slack)

• I do not use Electron applications myself (Slack, Code, etc), but this may be of some help .

[Matt_Hartley]

@junaruga

I noticed all the "Fedora 39 Community Forum links such as https://community.frame.work/t/fedora-39-official-fedora-39-thread/37465/3 (/3!) to this page on the Linux compatibility page are not accurate. It should be https://community.frame.work/t/fedora-39-on-the-framework-laptop/37465/.

Ah, it may have been mis-linked. I’ll submit a request to the web team with a correction later. Thanks for the heads up.

[junaruga]

@Matt_Hartley

Ah, it may have been mis-linked. I’ll submit a request to the web team with a correction later. Thanks for the heads up.

Thanks for submitting the request! For the “Framework Laptop 13 (13th Gen Intel® Core™) Compatibility” section, the Fedora 39 Community Forum link [1] is especially unique with a mysterious URL argument.

• [1] https://community.frame.work/t/fedora-39-official-fedora-39-thread/37465/3?_gl=1*174zmb6*sg_ga4w_production_ga*MjEyODM3MDcxMC4xNjk4ODUyMzM3*sg_ga4w_production_ga_PYG8X65YJJ*MTcwMTM3MzM0NC4zMC4wLjE3MDEzNzMzNDQuNjAuMC4w

[Nicholas_Faiz]

I have the following issues running Fedora 39 on my AMD Ryzen 13’':

• occsional screen flashing, especially if I watch videos in an enlarged mode or with some games. I tweaked the BIOS to fix this, enlarging the amount of memory available to the GPU, but the problem has persisted. It’s fixed with a reboot, but this is a little annoying.

• some videos won’t play.

I’m sure both are due to driver issues. I haven’t had time to really explore them. I was wondering if anyone else had found a fix for these issues?

Thanks,
Nicholas

[Leonard]

Welcome Nicholas! Yes, this is a known issue. You can find Framework’s recommendation here. People report good results after enabling this kernel parameter.

You can also follow this bug report; it looks like kernel 6.8 will fix the issues altogether (no kernel parameter needed any longer). For more info, see also this thread: [TRACKING] Graphical corruption in Fedora 39 (AMD 3.03 BIOS)

[phrwn]

When editing the ticket, add the Framework top-level ticket id 2240811 to the item: Blocks.

Sorry, where is this field? I see ‘Treeview+ depends on/blocked’, but not ‘Blocks:’ in the edit menu.

EDIT: nevermind - found it under ‘Show Advanced Fields’.

[v_d]

Hi all, the graphical glitches after suspend are back for me. They had disappeared for a while with the advised boot parameter:

sudo grubby --update-kernel=ALL --args="amdgpu.sg_display=0"

But now they’re back again. After every suspend, my screen has graphical colored artifacts that cover the whole surface, may disappear after a few touch presses but then come back. I’ve rerun the same command, with no effect.

I don’t even know if the configuration works, perhaps grub2 has been updated? If I do sudo cat /boot/grub2/grub.cfg | grep amd I get nothing, and from the grubby man page this seems to be the file that’s supposed to be edited.

[dimitris]

@v_d

sudo cat /boot/grub2/grub.cfg | grep amd

I also get nothing on that, but it still is applied so I guess the man page is wrong?

(replace linecmd with cmdline in the command below. I had to fake this to get around this forum posting bug)

$ cat /proc/linecmd |egrep -o 'amdgpu.+'
amdgpu.sg_display=0

Do you get the same?

[Daniel_Hollas]

Try running

sudo grubby --info=ALL

This should list all available kernels and their parameters. You can find out which kernel you’re currently running with

uname --all

[v_d]

I’ve done it and it shows the setting as activated.

One thing I’ve noticed: if I suspend again by pressing the power key, and then try to log in again, there are chances the graphic artifacts are gone.

[Daniel_Hollas]

What kernel version are you running? I think the colored glitches were a slightly different issue from the white blobs originally reported. See this comment and discussion above.

[TRACKING] Graphical corruption in Fedora 39 (AMD 3.03 BIOS)

In Jan, when resuming from suspend, I was getting the pink-blocky-flickering screen quite a bit. Suspending-and-resuming again would typically fix it. Haven’t seen that issue for at least a couple weeks though, and I think the only thing I changed was the kernel. Maybe try upgrading? I’m running 6.7.6-200.fc39.x86_64 and it’s feeling … I hate to jinx it, but it’s feeling pretty darn stable. I still have sg_disable set of course.

[Scott_Bronson]

Right now? 6.7.7-200.fc39.x86_64 and it’s fast and stable. Loving it.

Back then? Probably 6.5.something. I got both white and pink flashing on resume. I think the white lashing went away with sg_display=0, and the pink flashing went away with kernel 6.7. Just guessing though, I didn’t see it often enough to be sure.

[v_d]

I’m running 6.7.5-200.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Feb 17 17:20:08 UTC 2024 x86_64 GNU/Linux and oppositely to what says @Scott_Bronson I still have the pink flashing.

Here is the output of sudo grubby --info=ALL, so the sg_display=0 parameter is indeed there, but now I understand the white glitches (I don’t have anymore) are not the same issue than the pink flashing on resume (I’ve just experienced with the 6.7.5 kernel).

kernel="/boot/vmlinuz-6.7.5-200.fc39.x86_64"
args="ro rootflags=subvol=root rd.luks.uuid=luks-3cdb93d1-dc24-48d0-a7d8-91e43ea29677 rhgb quiet amdgpu.sg_display=0"
root="UUID=5c6e3623-f207-45b0-9597-17810cd93b3c"
initrd="/boot/initramfs-6.7.5-200.fc39.x86_64.img"
title="Fedora Linux (6.7.5-200.fc39.x86_64) 39 (Workstation Edition)"
id="b867acbfbb4042f88603463e4c70c3c6-6.7.5-200.fc39.x86_64"
index=1
kernel="/boot/vmlinuz-6.7.4-200.fc39.x86_64"
args="ro rootflags=subvol=root rd.luks.uuid=luks-3cdb93d1-dc24-48d0-a7d8-91e43ea29677 rhgb quiet amdgpu.sg_display=0"
root="UUID=5c6e3623-f207-45b0-9597-17810cd93b3c"
initrd="/boot/initramfs-6.7.4-200.fc39.x86_64.img"
title="Fedora Linux (6.7.4-200.fc39.x86_64) 39 (Workstation Edition)"
id="b867acbfbb4042f88603463e4c70c3c6-6.7.4-200.fc39.x86_64"
index=2
kernel="/boot/vmlinuz-6.7.3-200.fc39.x86_64"
args="ro rootflags=subvol=root rd.luks.uuid=luks-3cdb93d1-dc24-48d0-a7d8-91e43ea29677 rhgb quiet amdgpu.sg_display=0"
root="UUID=5c6e3623-f207-45b0-9597-17810cd93b3c"
initrd="/boot/initramfs-6.7.3-200.fc39.x86_64.img"
title="Fedora Linux (6.7.3-200.fc39.x86_64) 39 (Workstation Edition)"
id="b867acbfbb4042f88603463e4c70c3c6-6.7.3-200.fc39.x86_64"
index=3
kernel="/boot/vmlinuz-0-rescue-b867acbfbb4042f88603463e4c70c3c6"
args="ro rootflags=subvol=root rd.luks.uuid=luks-3cdb93d1-dc24-48d0-a7d8-91e43ea29677 rhgb quiet amdgpu.sg_display=0"
root="UUID=5c6e3623-f207-45b0-9597-17810cd93b3c"
initrd="/boot/initramfs-0-rescue-b867acbfbb4042f88603463e4c70c3c6.img"
title="Fedora Linux (0-rescue-b867acbfbb4042f88603463e4c70c3c6) 39 (Workstation Edition)"
id="b867acbfbb4042f88603463e4c70c3c6-0-rescue"

EDIT : btw, running some things from RPM fusion, like the MESA drivers as indicated here Howto/Multimedia - RPM Fusion (see section « Hardware codecs with AMD (mesa) ») might be related.

[Daniel_Hollas]

From the linked issue, it seems that this colored flashing was fixed in kernel 6
7.6 and above so I would just try updating to the newest kernel.

[v_d]

Oh yeah, thanks, haven’t noticed it’s 6.7.6 compared to 6.7.5 for me, the minor version number counts after all Updating now.

[Nicholas_Von_Wolff]

Installed Fedora Kinoite 39/40 (KDE) on my new FW13 AMD and the fingerprint reader worked without any workarounds or additional package installs. KDE even enabled the sudo integration which was nice. Now I just need so see if I can do the boot decryption with the fingerprint reader, though that would likely have similar vulnerability issues as using the TPM to do decryption.

It’s too bad KDE isn’t the defualt DE or Framework | Linux Compatibility on the Framework Laptop could be updated to show the fingerprint ready working out of the box.

[principis]

@Nicholas_Von_Wolff

It’s too bad KDE isn’t the defualt DE or Framework | Linux Compatibility on the Framework Laptop could be updated to show the fingerprint ready working out of the box.

Gnome is the default DE for Fedora, so I wouldn’t expect it to be different.

[Scott_Bronson]

The fingerprint reader works out-of-the-box on Fedora 40 Gnome. If it doesn’t work OOTB on Fedora 39 Gnome then that should be resolved just by waiting a couple weeks.

[Eli_Gaultney]

This did it for me today with a fresh install of Fedora 39.