Re: [Trisquel-users] So is this true about AMD on Trisquel?
And on the lingo, driver is one thing, microcode and firmware another. And as you've noticed people use all three in a confusing mash.
Re: [Trisquel-users] So is this true about AMD on Trisquel?
They have clear definitions: driver is the code running on the main CPU. There are drivers in the kernel (DRM: direct rendering manager; radeon), X server (DDX; xf86-video-ati), Mesa (DRI; e.g. r600g). Firmware and microcode are different words for the same (Linux calls it firmware, developers and documentation microcode): code uploaded by the kernel driver and run on the GPU. The open source drivers have no nonfree code running on the main CPU (except for code stored in the VGA ROM: AtomBIOS), unlike the fully nonfree driver that AMD develops too. This leads to confusing claims as if no nonfree code was used for 3D acceleration on Radeons. There were some improvements: xf86-video-radeonhd worked nearly without the VGA ROM, not running AtomBIOS code, there was more documentation available for these purposes then. AMD worked against this.
Re: [Trisquel-users] So is this true about AMD on Trisquel?
Well then why the heck do they even celebrate these drivers like a win for GNU/Linux users? You can't even use them wihtout proprietary code! I don't understand supposed Linux enthusiasts writers that are doing this then... I mean if anything it'll get current Free software users to accidently convert to closed code. At least that's how it's worked for me, lol. I sadly don't have an Intel chipset, I prefer AMD (don't ask why, I just do, lol). I use a high end ASUS motherboard as well, so it can use four videocards at once, but doesn't contain an integrated video card. This kinda stinks! So my only hope of 3D acceleration in Trisquel is using Intel integrated graphics (NOT my prefered choice) or antique Nvidia cards like the 9500GT? Thanks for your respose by the way.
Re: [Trisquel-users] So is this true about AMD on Trisquel?
That's just what not valuing freedom leads to. You've got people thinking it's fine because of where the proprietary firmware is being run, and it doesn't help that the main distribution of the kernel Linux includes these proprietary blobs. For example, one of the people responsible for the OpenPandora once justified proprietary firmware as more open than proprietary drivers because you can get the firmware to work with any OS. If all you value is openness, this makes sense. If you value freedom, a proprietary firmware requirement is no better than a proprietary driver requirement. Indeed, using an old Nvidia card (that works with Nouveau) is the best choice. I don't think there's even an active reverse-engineering effort for Radeon cards, so you can expect them to be essentially pieces of junk forever.
Re: [Trisquel-users] So is this true about AMD on Trisquel?
Some time ago when I did not care about freedom, I was using AMD CPUs. When I switched to Trisquel I realized that AMD does not want users to have freedom. AMD could easly solve the problem by burning the firmware into a ROM or hardwiring the command processor. I think releasing the source code would not help here in this specific case, as there is no free compiler that handles hardware description languages and works with real hardware. I also learned how to reverse engineer the nonfree firmware that drives the Yamaha FB-01. In this case the nonfree program was burned into a ROM, so that old device is not a problematic one. The CPU is a well known one, and free disassembly tools are avialable. I also know how to design a CPU, which can be implemented on an FPGA. I know that there is a reverse engineering project that tries to replace the nonfree tools required to program an FPGA. Recently I baught a refurbished OpenPandora. First I deleted all nonfree firmwares, and installed the free firmware for the TPE-N150USB. Now I can use the wireless network without giving up my freedom. I think the hardest part here is GPU, as there are no free drivers and no free fireware for the GPU. There is a reverse engineering project at[1], but this seems to be dead. But I can play some games such as Wesnoth and Tetris without using nonfree software. Unlike the Raspberry Pi no nonfree startup software is required, instead a boot-ROM is used instead. I think using a ROM for the boot firmware is the best solution as it prevents the user from accidently bricking the computer. Currently I do not have time to reverse engineer the GPU as I'm working on a free software replacement for the mbrola speech synthesizer. I can do so without reverse engineering, as the algorithms used by mbrola are well documented. Reverse engineering would be needed if you want to use mbrola voices with a free program. However the licence of the mbrola project does not allow to use of the voices with a different program than mbrola itself. [1] https://www.fsf.org/blogs/community/new-high-priority-project-powervr-drivers
Re: [Trisquel-users] So is this true about AMD on Trisquel?
I have a Replicant tablet with PowerVR. I really hope someone reverse engineers it. BTW, the Raspberry Pi's GPU blob was actually freed by Broadcom. :) https://libv.livejournal.com/26434.html
Re: [Trisquel-users] So is this true about AMD on Trisquel?
At least the ME microcode for R600 (and probably earlier CP microcode) is simple code with separate instructions for reading or writing registers, Rob Clark of Freedreno partially reverse engineered the instruction format. Newer Radeons have different ISAs. (ME is microengine, CP is control processor which has e.g. ME; it's not related to the Intel management engine used for AMT.) Lack of existing free compilers is not an issue here: it needs a very simple assembler and some ISA documentation. It's not like CPU microcode or FPGA data. Some time-consuming work is needed to reverse engineer the ISA and replace the microcode, all interested people that I know have other projects and do not have enough free time to do this. (There was an important kernel change regarding microcode dependency: now modesetting won't work on recent Radeons without the microcode, since the driver uses features that require it. I don't know the details of these changes.)
