No, Linux makes it “a maintenance headache”. On Windows, it’s perfectly fine. Pretty much the same, as an integrated one, except it offers more options & possibilities.
Linux just muddies the waters by making it seem like certain manufacturers, computers & graphics cards are a pain, when in fact, it’s just Linux being the kid sitting the farthest back in the class, doodling on the table, rather than listening & learning.
Well said, Linux is the problem, not the graphics card.
@nevj
I have my wife’s old PC that is running an AMD R7 graphics card, will see how Debian and or Linux will use this card.
Its the graphics card manufactureres and driver software writers that constitute the problem.
The Linux kernel is fine, the graphics card hardware is fine, the issues are with
That is wrong. That’s the propaganda from the Linux elitists, who make you think that.
The reality is, that GNU/Linux developers (the majority of them) does not care about user-friendliness, GUI, UX, etc…
This is why Linux is bad for end-consumers.
Since Linux is bad for end-consumers, there is no pragmatic market for the product.
Since there is no market for it, it is not economically possible or at least not viable to produce drivers.
Therefore, if GNU/Linux elitist developers would get their heads out of each others’ arses & start caring about GUI, UX, & user-friendliness, then a market for Linux end-consumerism would grow to the point, where it becomes economically viable to create Linux drivers.
Simple as that.
So, please do not blame a manufacturer for not throwing money out of the window, because Linux elitisits are too close-minded to understand how important GUI, UX & user-friendliness is.
This is also the reason why I always recommend KDE. KDE is so far the only GNU/Linux related project that got its head out of everyone’s arse, by actually improving user experience!
Linux kernel does no such thing.
GNU/Linux distro makers do not seem to be able to do what Windows does, when it comes to graphics drivers. Why? I can see amateur distros having a problem, but large semi-commercial outfits like RHEL or Ubuntu should be able to deal with it the same way Windows does.
Put the problem where it originates… with the distro makers. All the component makers do a fine job, it is the assemly line that is failing
GUI, UX & user-friendliness should be the second most important thing OF ALL.
Yes, it does nothing. It just sits there, producing memory bugs & leaks with its C-centric code.
It’s amazing, how people think Linux is so secure. If Linux would have the same amount of end-consumers, as Windows, it would be the most infected operating system on earth, far more than any Windows machine.
Indeed.
My point is, both Linux & GNU/Linux are failing in that regard.
The Linux community & its results in Linux are the foundation of any GNU/Linux distribution. So, you cannot separate them, like they are not related, at all.
For example, if the Linux community would wake up to reality, it would be much easier for GNU/Linux developers to follow those new better practices!
I did - in 2020 - as an experiment, sort of… After not doing Solaris for 5 years, my employer won a contract to support a HUGE Solaris site - so - I thought - hmmm - “I’ll break out my SunBlade 2500” (Silver - Dual UltraSparc III, 16 GB RAM, 2 x 300 GB 10K rm SCSI HDD), and “re-acquaint myself with Solaris and get PovRAY working on it”. Experimented with PovRAY on various Linuxes, ARM and Intel / AMD - piece of cake!
No! Not on Solaris! Spent HOURS over a fortnight or so, trying to compile it… But no!
The Source Code for POVray to compile for Linux is still called the UNIX source code. But - it compiles (not that there’s any need - as most major distros have BINARIES!) pretty much out of the box on Linux - on Sparc UNIX (Solaris)? Nada! Tens and tens of very version specific pre-requisite libraries needed and only got so far and I gave up…
I was going to try and do all that again on a Solaris 8 “branded” Zone, but gave up…
I also read somewhere that it was much easier to compile on Solaris 11, but the UltraSparc III can only run Solaris 10, nothing after… Thanks Oracle! For nothing! Way back when, before Oracle killed Sunfreeware, I could have got a PKG binary for POVRay to install on Solaris 10.
Here’s something I rendered on that DG-UX AViiON way back when (1992?) :
Yeah tiny - from back when “hi-res” was your 14" VGA CRT at 256 colours and 640x480 
(yeah - at that time - there were Sun and SGI workstations rocking 21" 1200x1024 costing $20,000).
Never said it wasn’t, but the fact is that Linux hardware support is still very lacking.
I am currently doing the opposite, compiling on Linux code that worked on Solaris. Biggest issues are include file changes and 32 bit specific code on C. Not povray , but it is image processing stuff. There are also issues with bsd Makefiles versus gnu make.
This is in Devuan
root@trinity:/home/nevj# 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:03:00.0
version: c7
width: 64 bits
clock: 33MHz
capabilities: pm pciexpress msi vga_controller bus_master cap_list
configuration: latency=0
resources: memory:c0000000-cfffffff memory:d0000000-d01fffff ioport:e000(size=256) memory:fb600000-fb6fffff memory:c0000-dffff
Not quite the same as yours , it does not list a driver
But I have the driver module loaded
$ lsmod | grep amd
amdgpu 6610944 0
gpu_sched 45056 1 amdgpu
ttm 114688 1 amdgpu
drm_kms_helper 278528 1 amdgpu
drm 618496 4 gpu_sched,drm_kms_helper,amdgpu,ttm
i2c_algo_bit 16384 1 amdgpu
It is called amdgpu
There is another module called radeon but I did not load that, I copied what Solus and Void did and only loaded amdgpu
So it looks like Devuan is not activating the driver, and is just running in VGA mode.
I will try again in Void.
Had trouble with Void, this is Solus
root@trinity /home/nevj # lshw -c video
*-display
description: VGA compatible controller
product: Navi 24 [Radeon RX 6400/6500 XT/6500M]
vendor: Advanced Micro Devices, Inc. [AMD/ATI]
physical id: 0
bus info: pci@0000:03:00.0
version: c7
width: 64 bits
clock: 33MHz
capabilities: pm pciexpress msi vga_controller bus_master cap_list rom
configuration: driver=amdgpu latency=0
resources: irq:67 memory:c0000000-cfffffff memory:d0000000-d01fffff ioport:e000(size=256) memory:fb600000-fb6fffff memory:c0000-dffff
So in Solus the driver amdgpu is listed.
It looks like Solus is actually loading and using the driver
root@trinity /home/nevj # lsmod | grep amd
amdgpu 9043968 10
iommu_v2 24576 1 amdgpu
gpu_sched 53248 1 amdgpu
drm_buddy 20480 1 amdgpu
i2c_algo_bit 16384 1 amdgpu
drm_ttm_helper 16384 3 drm_vram_helper,vboxvideo,amdgpu
ttm 90112 3 drm_vram_helper,amdgpu,drm_ttm_helper
drm_display_helper 180224 1 amdgpu
drm_kms_helper 204800 6 drm_vram_helper,drm_display_helper,vboxvideo,amdgpu
drm 667648 12 gpu_sched,drm_kms_helper,drm_vram_helper,drm_display_helper,vboxvideo,drm_buddy,amdgpu,drm_ttm_helper,ttm
root@trinity /home/nevj #
There are a few more modules loaded in Solus, but they dont exist in Debian
Thanks , that has helped me a lot.
I now know that in Debian and Devuan, the driver is loaded into the kernel, but fails to initialize, and sometimes the system hangs during boot with a blank screen, sometimes it somehow completes the boot and brings up a dte screen, probably in some primitive vga mode.
I found a Debian bug report that says that certain versions of the kernel, namely 5.10.0-19 , hang when trying to initialize amdgpu module. Guess what, my Debian’s current kernel is 5.10.0-19 !!!
I have 3 other kernels in Debian 5.10.0-17 5.10.0-20 and 5.10.0-8. All of those hang too. The bug report says 5.10.0-18 works… I dont have it. Might try a download.
The Solus kernels are much newer 6.0.11-225 and 5.15.81-193.
Have to go and investigate Void issue. Slim login screen is having trouble.
Thanks
Neville
@nevj
The card is being recognized but the driver is not being loaded. We need to know what lshw is for Debian? My card is a little older and is using the Linux Bonaire name, looks your RX6400 should have the Linux NAVI name. AMDGPU - Gentoo Wiki, scroll down your card is near the bottom.
If Debian isn’t working, then I doubt if Solus or Void will.
Return the card for a little older model, if you can?
Here it is ( done from Solus)
$ lspci -k
...
03:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Navi 24 [Radeon RX 6400/6500 XT/6500M] (rev c7)
Yes Navi 24… What does that tell me?
Got this from Gentoo manual
Older kernels
Older kernels which do not support the amdgpu driver will not provide the AMDGPU option. For VEGA and newer chips there is no video output without DC (Display Code), which was first included in vanilla Kernel 4.15. In both cases a fairly recent kernel can provide the required drivers. For very new AMD graphics cards and APUs trying an unstable (denoted by a ~) kernel may provide the required kernel-sources.
So looks like to get Devian and Devuan working consistently, I have to try a newer kernel. That may be hazardous, but can try.
Thanks
Neville
That is the Linux name for your card. You have a new card, so you will need the latest kernel. You have to ask yourself, is it worth it, or just try and find a compatible AMD card. Kernel upgrades or not fun and can go very wrong.
Agree but they are easily reversed
I wonder if the older radeon driver would work?
I might be able to change Debian from stable to testing… that would achieve a kernel upgrade. Or just install testing alongside it.
It will not be that long before the next Debian release… the current Debian 11 was released in Aug21. I could just wait. It is not critical.
I am not going looking for another card. I will wear what I have.
I wonder why/how it sometimes works without the driver?
There must be some generic vga or vesa driver present in the system
That’s not “working” - it’s basically an emergency mode.
The very last thing, one should never do either way, is to succumb to Linux’ slavery demand.
Hardware has the last word, especially if it’s too damn expensive. The operating system has to fit the hardware, not the oher way around!
It looks perfectly OK on the screen.
I could not tell by looking at it, I needed Daniels lshw -c video to tell me it had no driver
Do you know what drives this ‘emergency mode’ ?
Not sure how it works exactly, but there is always a fallback mode, for example is you use something like nomodeset in the boot parameters’ section.
Many people use it as a “fix” for their non-working graphics card & consider it “working” then, even though it is NOT a fix, but an emergency fallback mode, which basically throttles your graphics card’s power so much, it is a huge insult & your graphics card should sue your for it.
Problem is Debian and Devuan dont always reach fallback mode.
50% of the time they hang during boot
I could just ignore it and wait for next Debian release.
My Debian controls grub… I have to keep it running
but
I have redundancy… you laughed at this recently… I have hd0 and hd1 disks. Both have grub on them. Debian controls grub on hd1. Void controls grub on hd0. Therefore I am protected. I have 2 ways of booting, 2 ways of updating grub. Void works with the new card, so I am safe.
What I will do is