Linux 7.4 traerá más rendimiento en batería para portátiles

El kernel de Linux se juega su reputación en el escritorio en detalles que nadie mira hasta que fallan. La batería que no se limita al 80%, el ventilador que no responde al perfil de rendimiento, la GPU discreta que no se apaga y deja el portátil caliente sin hacer nada. Es por ello, que la próxima versión del kernel resuelve un puñado de esos casos concretos, y la lista de máquinas que cubre dice bastante sobre dónde está creciendo el parque de equipos con Linux.

Todas estas mejoras se están acumulando en la rama for-next de los drivers de plataforma x86, el cajón donde viven los controladores que hablan con el firmware propietario de cada portátil. Son nueve cambios cerrados, todos ya en esa rama de integración, y ninguno de ellos es espectacular por separado. Juntos son la diferencia entre un equipo que funciona y uno que funciona bien.

El detalle que más llama la atención no es ninguno de los parches, sino el reparto. De los nueve dispositivos beneficiados, dos son consolas portátiles de fabricantes asiáticos especializados y tres son portátiles de gama gaming. Los equipos de oficina aparecen, pero no dominan. Cuando el kernel dedica esfuerzo a curvas de ventilador y a tacómetros, está reconociendo que una parte relevante de su base instalada dejó de ser el portátil corporativo hace tiempo.

Nueve cambios que se notan al usarlos

El patrón se repite en todos los casos. Un identificador de placa o de modelo que hasta ahora no estaba en la tabla del driver, y que por eso dejaba sin respuesta funciones que el hardware sí expone. Añadirlo no cambia el rendimiento del equipo, pero cambia lo que puedes controlar.

La entrada del OneXPlayer 3 es la más completa del lote. El driver OXPEC recibe un «quirk» para el nuevo modelo con procesador Intel que desbloquea cinco funciones de golpe: el bypass de batería, que permite alimentar el equipo directamente sin desgastar la celda; los límites de capacidad; las curvas de ventilador y el tacómetro que las hace medibles; y la posibilidad de anular el botón turbo. En una consola portátil, esas cinco cosas son la diferencia entre jugar veinte minutos y jugar dos horas.

Los handhelds dejan de ser un caso raro

Pero en la lista hay dos casos llamativos. AYANEO y OneXPlayer, estos no son fabricantes que casualmente aparecen en el kernel, y seguramente muchos saltan de alegría por ello. Ambas son compañías cuyo producto principal es una consola portátil con Windows, y que han descubierto que una parte de su clientela instala Linux y distribuciones como Bazzite para sacarle más partido al hardware. Que ambas reciban soporte de batería y ventiladores en la misma ventana de merge no es casualidad.

Después de todo, el efecto de estas adiciones es acumulativo. Cada consola que entra en la tabla del driver deja de necesitar parches fuera del árbol, y eso reduce la fricción para quien compra el equipo pensando en Linux. El coste de mantener un parche local contra cada versión nueva del kernel es alto, y eliminar esa fricción, es la diferencia entre una comunidad que sostiene el soporte y una que se cansa de un producto que no funciona bien.

En el lado de los portátiles, el parche del ASUS Armoury merece una mención aparte. Añade una vía alternativa para activar y desactivar la GPU discreta en máquinas como la serie ProArt H7606, que son equipos orientados a trabajo creativo y no a juegos. En esas máquinas apagar la gráfica dedicada cuando no hace falta es lo que decide si la batería aguanta una jornada de trabajo ligero.

Control de batería, la función que más se echa de menos

Si hay una carencia recurrente entre usuarios de Linux que usan portátil, esa es el umbral de carga. La función existe en el firmware de casi todos los fabricantes y permite cortar la carga al 80% para alargar la vida útil de la celda, algo que importa especialmente en equipos que pasan el día enchufados. En Windows la expone el software del fabricante. En Linux dependía de que el driver correspondiente conociera el modelo concreto.

Los dos MSI de la lista y el AYANEO 2S entran por esa puerta. El MSI Katana 15 B13VFK y el GL65 Leopard 9SCXK reciben el umbral mediante el driver de controlador embebido de MSI, y el AYANEO 2S lo recibe por el suyo. Es la clase de parche que no aparece en ninguna nota de versión destacada y que un usuario nota el primer día.

El caso de TUXEDO es distinto y también ilustrativo. El driver Uniwill habilita la retroiluminación del teclado y el control de la lightbar en sus portátiles, que son equipos diseñados y vendidos con Linux como sistema principal. Que un fabricante cuya propuesta de valor es precisamente Linux tenga que esperar a una ventana de merge para que su teclado se ilumine apunta a un cuello de botella que no está en el fabricante.

Un soporte poco universal

Entender de dónde salen estos parches explica por qué no llegan todos a la vez. Un portátil moderno expone buena parte de sus funciones de firmware a través de un subsistema llamado WMI, la interfaz que los fabricantes usan para publicar métodos propietarios, y a través del controlador embebido, el chip que gestiona la carga de la batería, la velocidad de los ventiladores y la temperatura. Ninguna de esas dos vías está estandarizada. Básicamente, cada fabricante tiene su propio desastre, con algunas excepciones, como el caso de Lenovo, que tienen muy bien soporte desde hace muchos años.

Eso significa que cada fabricante decide qué métodos pública, con qué nombre y con qué parámetros, y en muchos casos cambia el identificador de placa entre revisiones del mismo modelo. Por eso los drivers acumulan tablas de identificadores, y por eso la unidad de trabajo del kernel en este terreno es el quirk (conocido por pocos, odiado por muchos): una excepción concreta para una máquina concreta. El driver del fabricante no sabe qué hacer con la placa 8A17 del OMEN 17-ck1xxx hasta que alguien añade esa entrada.

El detalle que hace útil la lista es que la mayoría de estas funciones ya existen en el hardware. No hay descubrimiento de ingeniería inversa detrás de la mayoría de los nueve casos: hay una interfaz que ya responde, y un driver que todavía no le pregunta. Eso explica que el esfuerzo rinda tanto por parche, y también que la cobertura dependa de que aparezca alguien con esa máquina concreta dispuesto a redactar el envío.

De ahí que dos de los nueve cambios se refieran a modelos concretos de MSI y no a la gama entera. La entrada del Katana 15 B13VFK solo aplica al firmware reciente de ese modelo, y el GL65 Leopard 9SCXK recibe la suya porque su combinación de placa y firmware es distinta. Para el usuario, eso significa algo práctico: dos portátiles de la misma familia y el mismo año pueden tener funciones diferentes si el firmware no coincide.

¿Qué pasa con Linux 7.3 mientras tanto?

Conviene situar estas fechas porque la numeración se mueve rápido. La séptima candidata de Linux 7.3 se publicó el 12 de octubre de 2026 y, si nada se tuerce, la versión estable saldrá a finales de mes. Ubuntu 26.10 ya se distribuye con Linux 7.3 desde el 14 de octubre, apenas un par de días después, algo extraño, considerando que la rama aún es considerada inestable.

La ventana de merge de Linux 7.4 se abre a finales de octubre de 2026, cuando el 7.3 ya esté cerrado. El kernel estable 7.4 llegará previsiblemente a finales de diciembre, y a partir de ahí empieza otra cuenta: cada distribución decide cuándo lo adopta. Ubuntu lo hará en su versión de abril de 2027, que además será de soporte largo. Quien use una distribución de ciclo continuo o rolling release lo verá antes.

Ese desfase explica por qué estos parches importan aunque no lleguen mañana. Un usuario de Arch, Fedora o de CachyOS probará el umbral de carga del AYANEO 2S en cuestión de semanas. Un usuario de la LTS actual puede esperar medio año o más, y dependerá de si su distribución hace backport de la función concreta. Es habitual que los parches de plataforma x86 se arrastren a versiones anteriores cuando son pequeños y aislados, pero no está garantizado.

El kernel como producto de consumo

Durante años, la promesa de Linux en el escritorio se apoyó en una idea razonable: si el hardware funciona, el sistema funciona. La lista que se acumula para Linux 7.4 demuestra que la segunda mitad de esa frase es la difícil. El hardware funciona, y el sistema funciona, pero la comunicación entre ambos depende de una tabla de identificadores que alguien tiene que mantener a mano.

Lo que cambia con esta tanda de parches es la proporción de máquinas donde esa comunicación ya está resuelta de fábrica. Y hay una consecuencia de segundo orden que conviene vigilar: cuanto más se apoye el soporte en drivers de plataforma específicos por modelo, más frágil será el resultado cuando el fabricante saque una revisión de placa con un identificador nuevo. La alternativa, forzar a los fabricantes a exponer interfaces estándar, avanza mucho más despacio que la lista de quirks.

Para el usuario que compra una consola portátil o un portátil gaming pensando en Linux, la señal práctica es que el soporte llega, pero llega tarde y llega por acumulación. Comprobar si tu modelo exacto está en la tabla del driver antes de comprar sigue siendo más útil que cualquier promesa de compatibilidad general.