3 votos

¿Cómo hacer que la consola del framebuffer de linux sea más estrecha?

Acabo de instalar una caja Debian Wheezy (Debian 7.0rc1). Por defecto, la consola se muestra usando el frame buffer, y debido a cierta configuración de hardware que no voy a mencionar, esto sale demasiado ancho en mi pantalla, por ejemplo, la columna más a la izquierda de la consola no se muestra.

¿Hay alguna manera de hacer que la consola sea una o dos columnas más estrecha? Es decir, no quiero que la fuente más estrecho o más ancho, quiero que haya menos columnas con la misma anchura, y que toda la pantalla de la consola renderizada ocupe menos anchura pero esté centrada de la misma manera.

Actualización: Basado en la respuesta de @mr.spuratic instalé y traté de usar fbset que no hace exactamente lo que pedí pero que teóricamente podría ayudarme a superar el problema. De todos modos, cuando trato de establecer el modo con él obtengo:

fbset FBIOPUT_VSCREENINFO: invalid argument

Notas:

  • Me gustaría una solución tanto a través de la manipulación de la configuración de Grub como sobre la marcha desde la consola después de haber arrancado.
  • Si hay información adicional que necesitas para dar una solución, coméntalo y pídelo.

1voto

frr Puntos 131

Me he preguntado dónde colocar este texto. La propia web es una posible candidata, o encontrar algún hilo en superuser.com que se acerque más a mi tema (y que posiblemente me haya ayudado). Así es como he llegado hasta aquí :-)

Mi problema particular era, cómo forzar un modo de vídeo particular a mis consolas de texto. Configuración del sistema: Debian 9 Stretch en hardware Haswell, su IGP manejada por el controlador i915 en Linux (ahora soportando KVM y DRI/DRM desde hace tiempo). Un estúpido conmutador KVM analógico, que le decía al PC a través de DDC/EDID que la resolución máxima era 1600x1200, pero que en realidad alimentaba una pantalla LCD capaz de 1280x1024 :-)

Empecé a jugar con vbetool y fbset que, sin embargo, están desfasados/no son aptos para el propósito, porque son incompatibles con KMS+DRM. El "inteldrmfb" parece ser sólo un shim sobre KMS+DRM (y, no parece estar incorporado en un módulo del kernel propio). Los parámetros de geometría son de sólo lectura. Bueno, al menos fbset puede mostrar pasivamente la resolución activa, lo que tiene algún valor informativo.

Sin embargo, parece que hay una manera para que usted y yo podamos establecer la resolución y el refresco vertical AKA velocidad de fotogramas desde la línea de comandos del kernel (parámetros del cargador de arranque en la línea que comienza con "linux", que resulta estar situado hacia el final de un moderno multi-línea Grub.conf sección).

Puedes jugar con los parámetros en el momento del arranque, si pulsas e mientras Grub cuenta el tiempo de espera. Sigue la ayuda a partir de ahí. Una vez que esté satisfecho con sus ediciones, pulse Ctrl+X o F10 para arrancar el perfil modificado. (Sus cambios son efímeros - aparecerán en /proc/cmdline en su kernel en ejecución en ese arranque, pero no se escriben en Grub.conf). Para el almacenamiento persistente de sus parámetros de arranque adicionales (argumentos de la línea de comandos del núcleo), en Debian debería introducirlos en /etc/default/grub en una variable llamada GRUB_CMDLINE_LINUX_DEFAULT . Y, corre update-grub .

Ahora, los argumentos. En primer lugar, necesitas i915.modeset=1 (siempre que su subsistema de gráficos sea un IGP de Intel). Si sufres el mismo problema que yo, es decir, que el kernel establece una resolución demasiado alta, es probable que ya tengas modeset=1 por defecto (compilado en el kernel). Mientras te peleas con la sintaxis de las maldiciones de cmdline, y a veces quieres sólo cualquier modo gráfico de trabajo, es posible que desee probar i915.modeset=0 . Eso aparentemente impide los cambios de modo gráfico por completo, y te quedas con una consola casi clásica de 80x25 caracteres, hasta el inicio de sesión de la consola. También notarás que no hay /dev/fb0, y no hay mensajes de depuración DRM en dmesg (sigue leyendo para más detalles).

Tenga en cuenta también la opción quiet . Funciona con o sin ajuste de modos. Aparentemente evita la impresión de mensajes del kernel mensajes del kernel a la consola (/dev/tty) = se obtiene una pantalla oscura en blanco durante unos segundos y luego es recibido con el prompt de inicio de sesión. Esto es un valor por defecto en Debian. (En realidad, en Debian moderno con systemd, probablemente obtenga los mensajes de arranque de systemd en su pantalla, en lugar de el registro del kernel...) El punto es, que si usted quiere los mensajes del kernel de vuelta, sólo debe borrar la palabra "quiet" de la línea de comando del kernel, y usar esa línea de comando para un solo arranque (pulse "e" en Grub, editar, ctrl+x para continuar) o permanentemente (editar /etc/default/Grub && update-Grub).

Ahora, finalmente, al punto: una vez que usted tiene i915.modeset=1 , también hay que añadir video=<xres>x<yres>@framerate . Como, en mi caso, video=1280x1024@60 o video=1024x768@60 . Hay más opciones posibles, véase el capítulo en Arch wiki . Por ejemplo, también se puede especificar la profundidad del color, o aplicar el modo a un solo puerto de salida de vídeo (llamado "conector" en las tripas del DRM). Tenga en cuenta que su modo especificado probablemente debe coincidir con uno de los modos conocidos por el kernel, es decir, uno de los "modelines EDID". El kernel mantiene una lista de estos bloques de datos, obtenidos bien a través de DDC de un monitor, bien de /lib/firmware, o posiblemente compilados. Es decir, no se puede especificar una geometría cualquiera.

En algunos howtos, encontrará sólo video=<xres>x<yres> como por ejemplo video=1024x768 . Esto tiene el efecto deseado, en el sentido de que la resolución aparece en la salida - pero se ha dejado la decisión sobre la velocidad de fotogramas a los controladores, que tienden a elegir la mayor velocidad de fotogramas posible (entre las "líneas de modo" disponibles en el conjunto de bloques EDID). Por ejemplo, en mi caso ha resultado que el controlador eligió 1024x768@85 que habría sido una buena opción en la era de los CRT, pero que está muy fuera de alcance para muchos LCD actuales. Tenga en cuenta que las pantallas LCD modernas y baratas (antes de FreeSync) suelen tener una velocidad de fotogramas de 60 Hz, así que esto es lo que tiene que establecer explícitamente, si su DDC está ausente o está loco.

Durante mi búsqueda de algunas respuestas, seguí tropezando con referencias a este parche de Dave Airlie - que trae el procesamiento de video= cmdline arg. Resulta que esto se ha fusionado en vanilla Linux hace algunos años.

En mi caso, el monitor se manejaba con 1600x1200 y reportaba "fuera de rango" porque no daba abasto. Mientras probaba varios argumentos de cmdline, probé sólo con video=1024x768 que resultó en "fuera de rango" en el monitor. Por fuera, por el vago mensaje de error, parecía que la línea de comandos arg no tenía ningún efecto. Sólo más tarde descubrí que lo único que me faltaba era un @60 sufijo :-)

La parte interesante aquí es, cómo Lo he descubierto. Hay otro argumento cmdline del kernel que hace que el subsistema DRI/DRM imprima un registro de depuración más hablador:

versión del kernel inferior a la 4.1:

drm.debug=0xe

kernel versión 4.1 o más reciente:

drm.debug=0x1e log_buf_len=1M

( fuente )

Adjunto un ejemplo de registro de depuración de mi máquina . Cosas en las que centrarse (palabras clave para buscar): Kernel command line , cmdline , adjusted mode , [drm:

Los "nombres de los conectores" se pueden deducir de aquí: ls /sys/class/drm/ y observe que la sintaxis de video=... cmdline arg no toma el prefijo "card-" que se puede ver en /sys/class/drm . La sintaxis de video= y los nombres de los conectores se describen con cierto detalle en el capítulo correspondiente del Wiki de Arch Linux .

Ahora permítanme cambiar de marcha / cambiar un poco el tema.

La pregunta original de este hilo era, cómo modificar la geometría del modo vídeo. He hecho esto antes en X y en Windows (usando el último Intel IEGD). En Linux bajo kvm+drm, la única manera de ajustar la geometría y la sincronización es aparentemente entregando su propio archivo EDID, que primero que primero hay que hacer a mano. Bueno, casi.

La construcción del EDID es descrito brevemente en un fragmento de la documentación incluida con el código fuente del kernel vainilla.

El Makefile y las definiciones EDID de ejemplo viven en su directorio principal .

Seleccione algún .S como ejemplo, copie a su propio archivo (ver la convención de nombres en la parte superior del Makefile), edita los tiempos, construye tu binario EDID y... espero que solucione tu problema :-)

Los tiempos y el recuento de píxeles requieren algunos cálculos matemáticos. Y, hay varios estándares históricos alternativos que que es mejor adherirse y que están en conflicto entre sí (son etapas de evolución de los estándares de temporización de las pantallas):

  • la era CRT GTF ,
  • la era LCD DMT o CVT ,
  • y luego CVT-RB (reducción del cegamiento).

O bien puedes calcular los números a mano, o hay algunas herramientas y tablas de modos estándar. Intenta buscar en Google "EDID calculator" o "modeline calculator" o algo parecido. Incluso hay una Herramienta de línea de comandos de Linux para el trabajo. Véase también el base de datos modeline .

Tu problema particular podría resolverse posiblemente desplazando el pulso HSYNC a la derecha (también puede intentar cambiar su polaridad), o haciendo que el pulso de sincronización y / o el tiempo total de cegado relativamente más amplio, o (como usted sugirió) disminuyendo la resolución de píxeles visibles/mostrados (en múltiplos de 8). Si se amplía el tiempo de supresión, es posible que haya que aumentar el reloj de píxeles, para mantener la velocidad de fotogramas original.

0voto

mr.spuratic Puntos 1406

Normalmente, un ajuste automático del monitor lo soluciona, y suele ser mucho menos molesto que las soluciones de software.

De lo contrario, compruebe el menú de información del monitor para ver qué resolución/refrigeración está ejecutando, y luego busque el modelo de monitor y fbset que es la herramienta utilizada para establecer los tiempos de bajo nivel que controlan los tiempos de visualización .

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: