[RESPONDED] AMD 13" + Ubuntu, multiple questions

The AMD 13" is my first Linux laptop (Ubuntu 22.04 LTS) since 2008 and I got a couple of questions…
First off, I followed the official installation guide, I’m on the OEM kernel (6.1.0-1024-oem) and BIOS 3.03 as of yesterday. Oh and I’m on X11 and not Wayland (not even sure how I could change that).

So, here’s my questions:

  1. In this guide it is stated that I should use power-profiles-daemon. Okay, fine. I am on verison 0.10.1-3 of that, which seems to be the most recent. Is there anything else I should or could do? There are three profiles in my Ubuntu settings: Power Saver, Balanced and Performance.
  2. Coming back to power, I have issues trying to put the laptop to sleep. I am very unfamiliar with all the sleep states that are available nowadays and honestly I really don’t want to know too much. I only want the laptop to go to sleep when I shut the lid and wake up when I open it again. In the meantime it should draw the absolute minimum power necessary. But in my case, when I close it, the screen stays on and it keeps running. Shoosing “Suspend” in the top right menu appears to send the laptop to sleep, but opening the lid again only makes the keyboard backlight and power button LED wake up, nothing on the screen. I have to press power a couple of seconds to reboot the laptop. Not something I call ideal. Any ideas what I could do here?
  3. Since the AMD 7840 is an APU it has Radeon grpahics included. In my Ubuntu settings though, the “Graphics” shows “llvmpipe” which is the software renderer. I get this when checking in a terminal:
$ sudo lshw -c video
  *-display UNCLAIMED       
       description: VGA compatible controller
       product: Advanced Micro Devices, Inc. [AMD/ATI]
       vendor: Advanced Micro Devices, Inc. [AMD/ATI]
       physical id: 0
       bus info: pci@0000:c1:00.0
       version: c4
       width: 64 bits
       clock: 33MHz
       capabilities: pm pciexpress msi msix vga_controller bus_master cap_list
       configuration: latency=0
       resources: iomemory:800-7ff memory:8000000000-800fffffff memory:90000000-901fffff ioport:1000(size=256) memory:90500000-9057ffff
       product: EFI VGA
       physical id: 3
       logical name: /dev/fb0
       capabilities: fb
       configuration: depth=32 resolution=2256,1504

I tried installing the official Radeon drivers for Ubuntu following the installation guide and using the Vulkan option (amdgpu-install --vulkan=amdvlk), but that failed during amdgpu-dkms. Crash log excerpt here:

 make[2]: *** [scripts/Makefile.build:258: /var/lib/dkms/amdgpu/6.2.4-1646729.22.04/build/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.o] Er>
 make[2]: *** Waiting for unfinished jobs....
 make[1]: *** [scripts/Makefile.build:508: /var/lib/dkms/amdgpu/6.2.4-1646729.22.04/build/amd/amdgpu] Error 2
 make: *** [Makefile:2016: /var/lib/dkms/amdgpu/6.2.4-1646729.22.04/build] Error 2
 make: Leaving directory '/usr/src/linux-headers-6.1.0-1024-oem'

DKMSKernelVersion: 6.1.0-1024-oem
Date: Tue Oct 24 21:50:56 2023
DuplicateSignature: dkms:amdgpu-dkms:1:>
Package: amdgpu-dkms 1:
PackageVersion: 1:
SourcePackage: amdgpu-dkms
Title: amdgpu-dkms 1: amdgpu kernel module failed to build

I am really not an expert user, but it appears the Radeon drivers have some issues with the OEM kernel? Anyone able to shed some light on this and how I can get that GPU to really be utilized?

  1. The above issue leads me to my final question: anyone here have experience with Davinci Resolve Studio on Linux for editing videos? I have bought it years ago for Windows and want to use it on my Framework AMD 13". But so far I was not able to get it running, mainly because it refuses to recognize a GPU (see above). Any guide I found so far requires installing the Radeon drivers for Resolve to work, so I am stuck now. I know that kdenlive exists, but I would really prefer sticking to my familiar workflow and would like to share projects between machines.
  2. During the installation, I had to do some troubleshooting to get the fingerprint sensor running. For this I had to do some manual fwupdtool commands and realized it was on 1.7.9 while the most recent version of fwupd is 1.9.6 already. How can I update this? Because doing the usual sudo apt update && sudo apt upgrade does not do it. Do I even need to update it? The output tells me I should…
sudo fwupdtool get-updates
Loading…                 [-                                      ]08:02:22:0007 FuEngine             failed to get releases for UEFI dbx: No releases found: Not compatible with org.freedesktop.fwupd version 1.7.9, requires >= 1.9.1
08:02:22:0009 FuEngine             failed to get releases for UEFI dbx: No releases found: Not compatible with org.freedesktop.fwupd version 1.7.9, requires >= 1.9.1
Loading…                 [***************************************]
Devices with no available firmware updates: 
 • System Firmware
 • WD BLACK SN850X 1000GB
 • Fingerprint Sensor
 • UEFI dbx
No updates available for remaining devices

Yeah… lots of questions as you can see. Thanks for your time, I hope somebody can point me into the right direction for them.

I’m on exactly this right now, I am on Wayland. If you have confirmed you’re on 3.03, which means you did update it yourself from this thread, then there is no reason a fully updated Ubuntu 22.04.3 install on 6.1.0-1024-oem should be on Wayland.

I’d log out, select the little gear, avoid choosing X, try again.

This would be correct. When on Battery, I highly recommend selecting Power Saver. On power, you can choose whatever you like, Performance for example.

You may not on the right BIOS if you’re not seeing a clock screen when lifting your lid to resume. In s2idle, which is what we use for this laptop, the behavior on 3.03 on Ubuntu 22.04.3 is close lid, suspends. Lift lid, wakes to a clock screen.

Please recheck your BIOS as there are multiple points that make this feel like 3.02 behavior. Then make absolutely sure you’ve updated it.

If you run this:
sudo lsmod | grep amdgpu

and see this:

amdgpu              13041664  28
iommu_v2               24576  1 amdgpu
gpu_sched              49152  1 amdgpu
drm_buddy              20480  1 amdgpu
drm_ttm_helper         16384  1 amdgpu
ttm                    98304  2 amdgpu,drm_ttm_helper
drm_display_helper    188416  1 amdgpu
drm_kms_helper        208896  4 drm_display_helper,amdgpu
i2c_algo_bit           16384  1 amdgpu
drm                   598016  17 gpu_sched,drm_kms_helper,drm_display_helper,drm_buddy,amdgpu,drm_ttm_helper,ttm
video                  65536  1 amdgpu

Same with:

sudo lshw -C video | grep amdgpu

Seeing this:

configuration: depth=32 driver=amdgpu latency=0 resolution=2256,1504

And this may be where all of the other stuff with Wayland/X, Suspend and related are falling down. You should not, whatsoever, need to have done this and it may have made things…complicated.

To be clear, you do not install anything outside of what appeared in the guide. Doing so, adds something that I am not going to be able to replicate.

The OEM C install is all that is needed, you do not need to compile anything and doing so means you would be best off starting off fresh with a new install in my opinion.

Again, with the LTS, we do not want to be installing stuff outside of the exist repos, it will created added layers of complexity making support difficult

You would have followed this guide, the second section in red, and followed the link to here.

Follow these steps exactly, try a couple times if needed be - reboot. Again, due to all the other stuff done, I’d fresh install and start over, though.

Hopefully this provides some actionable guidelines.

Short version, our guides are setup end to end, but it’s critical not to start compiling random things as it will goof things up. :slight_smile:

1 Like

That’s the weird thing: I don’t have the little gear on my login screen. Every “switch from X11 to Wayland” guide I found online told me to do that but I can’t click something I don’t have.
There’s a bug report outlining this behavior and I will try this suggested workaround and update my reply once I did.

Getting into BIOS on startup shows “JFP30.03.03” in the settings and there’s also this:

	Vendor: INSYDE Corp.
	Version: 03.03
	Release Date: 10/17/2023
	Address: 0xE0000
       product: AMD Ryzen 7 7840U w/ Radeon  780M Graphics
       vendor: Advanced Micro Devices [AMD]
       physical id: 4
       bus info: cpu@0
       version: 25.116.1

So yeah, definitely 3.03.
Is there a way for me to log what the suspend is doing? Like start a tail -f of something and > it into a file before I hit “suspend” and then wait half a minute or so after trying to wake it before I have to hard reboot it so I can check afterwards?

I get crickets. Nothing. Even when I just grep “gpu”, there’s nothing. See also my lshw -C video output in my original post.

Believe me, I wasn’t too keen on messing about with that. But my goal was to get Davinci Resolve Studio running under Linux. Which apparently works under Ubuntu with the Radeon drivers and some tweaks. But not out of the box since the developers cannot be bothered doing a good version for Linux despite me and thousands of people paying for the software.
I hate having to resort to dual boot into Windows. Or even completely switch to it. Ugh.
So I tried my luck with the drivers.

Not trying to sound harsh, but “just reinstall everything” is like Windows tech support advice from 20 years ago. I remember reinstalling win98se about 5x a year back in the day because I didn’t know better back then. Haven’t touched my Win11 install for an eternity because I now know how to repair things in case something goes wonky on that platform.
Reinstalling the OS is like the nuclear option to me. Basically the “throw your hands in the air and give up” solution. I always hated this type of advice and I will only do that once everything else has failed. I want to understand the machine in my hands and how it works. One of the reasons I bought the DIY edition. And I want to be able to fix it when necessary.

I acknowledge that for someone trying to provide support, the easiest way to service customers is when everyone follows the same recipe. Sorry about that :innocent:

I am pretty sure I won’t be the last person to say “hey, there’s official Radeon drivers for my distro, I want to try them out” and then ends up with errors and apparently no GPU driver at all. There must be a way to get the system back to a state where my lsmod | grep amdgpu shows the same as yours and not nothing without hitting the “I give up” switch (reinstall).

I followed both guides, but the steps in the second one (Github) threw me for a loop a couple of times. Things didn’t seem to take and then after a couple of reboots it suddenly worked. This and “try a couple times” is not reassuring at all, especially when dealing with new hardware.
The problem is that following a guide is one thing. When the user is confronted by multiple error messages and the thing not working at once, they assume something is wrong and begin looking for ways to fix it. When an OS screams at me something is outdated, I look for a way to update it.
The guide itself says “Top line of the output will show something like compile org.freedesktop.fwupd 1.8.17 If it is indeed older than 1.8.8, follow the next steps.”
→ why is there an apparently outdated fwupd version at all? Is this an LTS thing or an OEM C thing? Why do I need to do some quirk stuff when the obvious solution would be to update fwupd? What’s wrong with wanting to update it?
This does not make sense to me. As I said above, I would very much like to understand why things are the way they are.

@FlowWork Matt has told you what you needed to do in order to arrive at a thoroughly tested “good” state in order to rule out other potential issues.

That is harsh, and you’ve just come off ornery and combative.

No, it isn’t. It’s making sure that you’re starting in a fresh state to allow for proper troubleshooting.

This is common and sometimes is required to have things “stick”. Things do get fidgety with software, and for example, running software installers multiple times, regardless of OS, resolves issues.

Matt has done nothing but attempt to assist you and if you read back what you’ve written, while continuously stating you aren’t trying to be one way, you absolutely ARE being that way.

If you don’t want to follow the guides that have been standardized and tested to provide a known “good” experience based on extensive efforts by multiple people without the “but”, we won’t be able to assist further. If you follow the instructions, and get stuck, it’s okay to ask for clarification, but railing against it or adding snarky comments doesn’t move the conversation forward in any meaningful way.

Please bring this back to a constructive place, or I will have Matt disengage as he is in demand and needed elsewhere.


You are right.
@Matt_Hartley, I apologize for including that in my reply, it came from a place of frustration and was uncalled for.

I do appreciate Matt’s time spent on his reply and I am thankful for all the work he does for the Framework Linux community (for instance working with me and others on the “stuttering” issue that was solved by BIOS 3.03), but there was this part of his reply that made me feel the opposite of being assisted and increased my already present frustration:

This was in reply to me writing about how I tried installing the official Radeon drivers. There is a very specific reason I attempted this and it was written in my fourth item: trying to get Davinci Resolve running on Linux on my AMD Framework 13". That’s why, in my perception at the time, that entire paragraph came across as being told off for attempting to do something that’s not by the book/in the guides. I felt my actual need was being ignored.

But that is in a large part my own fault. I should have led the post by stating that my main goal is to get Resolve running on my Linux AMD Framework and that I’m looking for people that might have already succeeded in doing so, and not hide this information in the fourth item.

I realize that my anger should not be directed at Framework in general or you, Matt, specifically, but at Blackmagic Design for not creating a Linux version of Davinci Resolve that is able to recognize APUs (or even dedicated AMD GPUs from what I was able to research) without paying customers having to resort to fiddling with drivers and configs.

Again, I apologize for how I replied to you above.

I disagree with this based on my roughly 30 years experience with Windows systems and MS-DOS prior to that. There is always a very specific reason why something does not “stick”, although it might not be immediately apparent to the user. Yes, doing multiple installations can result in it working, but it does not remove the underlying issue preventing the installation. You just get lucky at one point.
Which is why I start hunting for these reasons when I encounter problems during setup or installations. Because I can usually find them on an OS I am familiar with, which Linux isn’t, unfortunately. Continued below this:

While the guides did end up leading to me having a usable system before I tinkered with the drivers (and it is still largely usable despite my tinkering), I believe the fingerprint troubleshoot guide can be improved by:

  • Adding a brief explanation why fwupd is on an older version than 1.8.8 (in my case 1.7.9) after following the Ubuntu installation guide to the letter and that this does not require updating in order for a 13" AMD model to be able to update firmware at a later point.
  • Add a sentence explaining that it might be necessary to do multiple reboots or have to do the installation of the .cab file multiple times

This would have prevented me spending (or wasting, rather) half an hour trying to find out how to update fwupd or trying to troubleshoot the seemingly not working installation.

Also, a minor thing: It appears the guide was moved from Github to its own dedicated page, but there are some display errors on Firefox where blockquotes are being used:
It does appear correct in Chrome with the source HTML showing “::before == $0” instead of just “::before”.

To conclude this:

  • I will go back to a fresh Ubuntu install to make sure the suspend issues were not caused by my experimentation. If the issues persist, I will open either a new topic or add my information to another one already present (I haven’t checked yet if this is the case).
  • @Matt_Hartley, I don’t expect a Framework support person to troubleshoot a third party software (Davinci Resolve). Since there are obviously other issues requiring your attention more in line with supported configurations, please ignore this topic. Thank you for your time and again I’m sorry for how the conversation went.
  • I submitted my suggestions for improving the fingerprint troubleshooting guide above. Maybe they are of help to other users. But I understand if you don’t want to clutter the guide.
  • Whoever can make that decision, please consider that there might be users who want to use X11 instead of Wayland or feel the need to install the official AMD Radeon drivers, since there are multiple guides out there recommending to do the latter to get certain GPU bound applications to work. People coming from Windows will be especially prone to manually installing drivers, because that’s a standard troubleshooting practice there. I suggest either adding a “don’t do this!” warning anywhere in the Linux installation guide for Framework AMD or (should it be possible and such a thing ever exist) link to a guide that helps users revert back to the “good” configuration without having to resort to doing a fresh install.


1 Like

The best option is to follow a source I personally trust. Venn, of “Linux Game Cast” has an option I’ve used on other computers in the past. I know Venn personally (appeared as a guest on his show once upon a time) and this is the absolutely best tutorial I have any time with. It’s for .1, not .3, but "should yield worthwhile results as Venn “lives on” Resolve.

As indicated in this tutorial, it will require a clean install to get the driver setup.

Appreciate that. I ended up redoing it entirely as it needed a clean up. But I do appreciate any contributions.

Appreciate your feedback. We work with AMD pretty closely. They will be the first to tell you, use the provided driver first if at all possible. AMDPGU driver is used and recommended for gaming and other tasks as it is something we can troubleshoot. The older, not all that well supported proprietary driver is a tricky and to my knowledge, not something we see mentioned here all too often.

As good configuration would be to follow the guides as they are for installation, which will put users on the AMDGPU driver. I purposely do not even mention this on the guides as the use case for the proprietary driver is rare, but if it comes up, we’d address it in a ticket.