Originally posted by birdie
View Post
https://forums.tomshardware.com/thre...-bios.3711200/ Those amd fan speed issues I am sorry they are not the open source driver. They are firmware/bios on AMD the cards. Some vendors AMD cards are good on reporting fan speed others are bad. Yes the disable 0 rpm there is no card setting with AMD that is pure software override so that is use fancontrol. Fancontrol appears error prone because the depending on the vendor of the card depends if you need to set in bios manual or automatic fan curve to get correct reporting and worst sometimes the manual fan curve has to be a particular fan curve so fan speed reporting is right.
Yes the failure to get correct fan speed out of cards with AMD based graphics cards happens under windows as well. Yes software override to 0 rpm is how it done under windows as well with AMD, Here a horrible fact AMD reference cards don't have 0 rpm mode this is in fact added by MSI and others. Yes we have developers working on Linux from AMD but we don't have the ODM who made the cards providing developers to fix up their own made quirks..
Sorry fancontrol trouble under AMD will not be improved by attempting to implement that in kernel. AMD hardware has some bugs.
You need to go back and read that intel bug report you have been asked to do a particular thing that you have not. I have had equal issue with intel and 1440 mode before but it turned out to be a particular monitors screwed edid yes that monitor works fine when you use a third party box to replace edid equal but correctly formated edid yes the one log that is asked for will show up that problem. Windows is little more lax on edid stuff. So not sure if your intel problem is really intel driver problem or simply your monitor is screwed up. Yes even with Nvidia at times you need to override the monitors edid to get correct monitor options. Yes annoying Intel, AMD and Nvidia all tolerate different forms of edid screwed up. Yes all of them work if with monitor edid if the monitor is sending exactly to the specification.
So that intel graphics refusing todo a particular output with a particular monitor you can change that amd and nvidia with the right screwed up monitor the same fault will show up. As I openly admitted graphics drivers generally are not bug free. There are types of bugs that a universal no matter the GPU vendor one of them is edid issues resulting in not being able to use particular output modes when you pair X driver with Y monitor.
Originally posted by birdie
View Post
Remember not all your graphics issues come from the kernel driver. The open source drivers horrible as it sounds gives you broader mix and match options because you can mix and match the userspace part of the driver with the kernel part of the driver. Yes I will give you its a pain to replace the complete kernel.
Also you have claimed something false. https://backports.wiki.kernel.org/index.php/Main_Page "Either a stable kernel with outdated drivers or a bleeding edge kernel with bleeding edge regressions and bugs." Yes this is a false statement. Stable kernel has backported driver option so stable kernel with the drivers it released with and the backported drivers with the stable kernel. Yes RHEL and Ubuntu have backported drivers under different names HWE from ubuntu used the backport enable quite a bit.
I will give you the upstream kernel does not give the clearest instructions on all the steps need to back-port individual drivers in included kernel documentation resulting in people like you birdie thinking it not feature. Its a feature that RHEL, Ubuntu, SUSE and many other distribution kernel makers are using.
So you statement that drivers must be developed separately is based on the idea that upstream drivers cannot be shuffled back into stable branch kernels right? If that is the case you badly wrong because system to-do that does exist and is maintained and the backport patches is small part part of that.
Yes Android and RHEL kernels do backport drivers from the bleeding edge to their stable kernels. Funding for the backports code large percentage comes from IBM/Redhat.
I would not say that drivers are too big or complicated to be in-lined in operating system development. The one cause of in-lining is that the user-space and kernel space have to have a stable ABI between the two. Driver mainlined in Linux basically mandates that you must be able to mix and match kernel modules with user-spaces.
The issue of having to use the latest bleeding edge Linux kernel to test out newest version of a driver is more a case of taking path of least effort not what is really possible. Yes the effort to make backporting drivers from bleeding edge back to stable kernels as simple as possible has not been done. Making a stable kernel ABI for drivers does not solve the issues either.
You see these different failures all in the same line with Windows fairly much every time Microsoft does a major kernel update. Linux distributions do these kernel updates more often so break out of tree drivers more often. Do the not include drivers with Windows break commonly the answer is yes they do. Does Nvidia end up having to release new drivers for windows altering for the new kernel releases changes yes they do. Do end users end up suffering with broken systems under Windows when Windows updates kernel because their drivers are miss aligned with their kernel yes they do.
birdie like it or not drivers developed separately to the kernel as Windows does have some serous stability downsides. I will give you there need more developed middle ground. As in drivers developed inline with kernel with a user-friendly back-port system to older kernel versions I would see as ideal solution.
The reality here I don't see any advantage in the purely independent driver development there is more than enough documentation of the issues be it Linux or Windows or Freebsd that it is problematic. The fact its problematic is why the stable kernel ABI for drivers falls flat on face under closer inspection.
Birdie think about this when do you want driver developers to find out about a internal kernel ABI/API change your choices are:
1) when the kernel is being developed (this is inline driver development freebsd/linux include drivers)
2) when user attempt to use the driver and then reports the issue(this is your developed separately this is windows and nvidia closed source)
Remember we are talking millions of lines of code in some drivers. Remember option 2 the user may have basically a no interface machine. I will give you that you want more options to use more driver versions when you run into trouble. Inlined development reduces the amount of trouble you have to deal with because inlined development addresses particular problem of ABI/API changes.
Birdie you came to this with the idea that the Linux way is wrong without considering what the Linux way does right because of inlining drivers. The amount of API/ABI changes the Linux kernel does is massive yet it only the out of tree drivers that are being hit by it should have had you asking yourself a few questions how and what is the particular advantage here. Remember API/ABI changes happen intentionally and not intentionally in all commercial operating systems that have attempted the stable kernel ABI for drivers route resulting in driver failure.
Middle ground between inlining drivers and multi versions of drivers would be useful as in all drivers inlined into kernel development so API/ABI issues turn up early for developers to address hopefully before hitting end users and a functional and userfriendly back-port system to allow those using older kernels to use the newer mainline drivers. Yes there is a functional backport system for Linux kernel drivers from mainline back to older kernels is it user-friendly to those without major kernel development skill the answer is no its not and that is where I see the problem is.
Comment