| Projekt: | Trisquel |
| Version: | 9.0 |
| Komponente: | Kernel/drivers |
| Kategorie: | Fehlerbericht |
| Priorität: | critical |
| Zugewiesen: | nicht zugewiesen |
| Status: | by design |
El controlador RTL 8723Be no es libre, por alguno motivo este fue mal cargado en H-node.org y se encuentra ademas en los repos de Trisquel.
La FSF el departamento de desarrollo lo bloquea comparto la explicación que me aporto Alexandre Oliva ya que no soy entendido en el área.
En el resto de las distribuciones este controlador ya es problemático tiene ademas problemas de baja señal.
Note: I don't own this device, I'm only helping by giving some context.
To give some context, this was also reported on a XMPP chat room for users of free/libre distros ( usuários-gnu under conference.jabber.de ).
With kernel 4.15 from Trisquel 9 the device works, but in kernel 5.10 from any Linux-libre mirror, say Jason Self's, it doesn't work.
To make this even more delicate, there are people claiming in h-node that it's supposed to work but for that a “dummy name” would have to be provided on the source where the firmware file name to load is specified.
If possible, please investigate the issue or provide help on how to test and solve this.
I also just reported this to the Linux-libre kernel mailing list, but it didn't appear in the archives (I'll wait some days before I consider it an issue with their SMTP server).
Buenos día como estas? ¿tienes alguna novedad sobre este tema?
Expanding a bit on what is said in the screenshot: The driver for "RTL 8723Be" has two pieces, the kernel module (which is free software) and a non-free binary firmware blob that is required for the device to work. Linux-Libre disables the capacity of the kernel modules to load non-free firmware blobs, regardless of whether the user installs them by their own choice. The Trisquel kernels are deblobbed with the Linux-Libre scripts, but with a modification that preserves the capacity of some drivers to load the nonfree firmware if it is installed. The source is patched to prevent the kernel modules from *requesting* the user to install the file, and it does not print the filename in kernel messages. Meaning, that the kernel at no point suggests the user to install nonfree files, but would use them if the user independently chooses to install them.
The only reason only some drivers (the ones for the most popular devices) receive that treatment is because the patch is maintained manually and it takes a lot of work to keep updated through kernel updates. I didn't research too much which RTL devices were worth applying this method to, since the code was similar for all, I patched them in bulk.
In short, the report is invalid (the repos do not contain the nonfree blob file), but I understand how it is easy to have thought otherwise.