Görkem

One practical note for anyone following a tutorial and hitting this: check what version the tutorial was written against before doing anything else.

Board packages update silently in the background, so a fresh install today is not the environment the tutorial's author had. The mismatch is not visible anywhere on the page.

When a copied example fails to compile in a way that looks impossible, the version of the package is the first thing to check, and it is right there in the boards manager.

One thing worth ruling out before touching the proxy, because it costs a minute and it is occasionally the whole answer: whether the problem started with a version upgrade.

A live-channel regression in a release is not rare, and the symptom is exactly this — everything works, the banner appears, nothing in the log. If the timing lines up with an update, checking the project's issue tracker for that version, and briefly rolling back to confirm, tells you whether you are configuring around a bug.

That is worth doing first because every proxy setting you change while chasing an upstream bug is a setting you will not remember to change back.

Which you need, concretely:

Install nothing if you want a desktop, video, and games. The in-kernel driver plus your distribution's graphics stack is the best-supported path and the one everything is tested against.

Install the vendor package if you need the compute stack for machine learning or professional applications that require it.

Two things that are commonly mistaken for needing a driver:

• Firmware. The card needs binary firmware blobs, which come from a separate package, usually installed by default. A card that shows a very low resolution or fails to initialise is often missing firmware rather than a driver.
• A card newer than your kernel. In-kernel support arrives with kernel versions, so a card released after your distribution's kernel may genuinely not be supported yet. The fix there is a newer kernel, which several distributions offer as an option, not a vendor driver.

That second one is the real case behind most "I need the latest driver" situations.

The reason it works already is the important part: the driver for that card is in the kernel. It is not something you install, it ships with the system, and for AMD cards it is developed by the chip maker in the open and merged upstream.

So the default state is a working, supported, well-integrated driver, and for the overwhelming majority of users that is where the story ends.

What the downloads add:

• The card manufacturer's download page is nearly always the Windows driver, or an outdated copy of the vendor package. Board partners do not write Linux drivers. This one you can ignore.
• The chip maker's packaged driver is a professional stack aimed at compute workloads and specific certified distributions. It brings userspace components — compute runtimes, professional application support — rather than a different display driver.

So the question is not which driver, it is whether you need those extra userspace pieces.

A diagnostic that saves a lot of guessing, because it separates the layers cleanly:

Run the vendor's own query tool inside the container. If it lists the card, steps 1 to 3 are fine and your problem is the application's configuration. If it reports nothing, the problem is below the application and you can stop reading its documentation.

For transcoding specifically, the equivalent is asking the media tool to list its available hardware accelerators from inside the container. Same logic: it either sees the device or it does not, and that single answer tells you which half to work on.

Doing this before changing settings turns a vague problem into a bounded one.