Alejandro(alejandro_aero[cambiar-por-arroba]yahoo.es)
alex@marte:~$ lspci
0000:00:00.0 Host bridge: Intel Corp. 82845 845 (Brookdale) Chipset Host Bridge (rev 11)
0000:00:01.0 PCI bridge: Intel Corp. 82845 845 (Brookdale) Chipset AGP Bridge (rev 11)
0000:00:1d.0 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 02)
0000:00:1d.1 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 02)
0000:00:1d.2 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 02)
0000:00:1d.7 USB Controller: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB 2.0 EHCI Controller (rev 02)
0000:00:1e.0 PCI bridge: Intel Corp. 82801 PCI Bridge (rev 82)
0000:00:1f.0 ISA bridge: Intel Corp. 82801DB/DBL (ICH4/ICH4-L) LPC Bridge (rev 02)
0000:00:1f.1 IDE interface: Intel Corp. 82801DB/DBL (ICH4/ICH4-L) UltraATA-100 IDE Controller (rev 02)
0000:00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 02)
0000:00:1f.6 Modem: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 02)
0000:01:00.0 VGA compatible controller: nVidia Corporation NV17 [GeForce4 420 Go] (rev a3)
0000:02:07.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link)
0000:02:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
0000:02:0b.0 CardBus bridge: Toshiba America Info Systems ToPIC95 PCI to Cardbus Bridge with ZV Support (rev 32)
0000:02:0b.1 CardBus bridge: Toshiba America Info Systems ToPIC95 PCI to Cardbus Bridge with ZV Support (rev 32)
0000:02:0d.0 System peripheral: Toshiba America Info Systems SD TypA Controller (rev 03)
No tiene misterio alguno, enciendes el ordenador y funciona. Eso sí, el ajuste de brillo merece un comentario que se hará en la sección de ACPI (2.12) 2
La tarjeta de vídeo que lleva este portátil funciona perfectamente en la consola de texto de Linux, y en las X con el driver de 'vesa'. También está soportada por el driver de Xfree 'nv' que por estar diseñado específicamente para nuestra tarjeta sería más recomendable si no fuese porque tiene un problema más o menos molesto.. si cargamos el driver nv, y desde una sesión X volvemos a una sesión de texto observaremos que el cuadro de texto del framebuffer (yo uso uno) se ha desplazado hacia abajo; por lo que nos perderemos la última línea de texto (lo que conlleva que no vemos las órdenes que escribimos) y en la primera línea de texto tendremos extraños caracteres parpadeando... (bueno, realmente es muy molesto, pero se puede trabajar... más o menos); desconozco si el problema persiste si no se usa un framebuffer, aunque lo más probable es que no...
Tenemos además, la opción del driver de código cerrado de Nvidia; que tiene sus pros y sus contras:
Bien, lo primero, una aclaración, si instalamos el parche para ACPI y habilitamos los extra para Toshiba (ver sección de ACPI, 2.12) la combinación de teclas Fn+F5 funcionará para cambiar las salidas activas si la usamos desde la consola; en las X, como éstas capturan las combinaciones de teclas, no lo hará, o lo hará de manera muy deficiente (a mí a veces no me responde, y otras se carga las X; así que no recomendaría usarla, e irse a una consola de texto)
Otra cosa, el driver de NVidia trata de detectar automáticamente lo que está conectado a la tarjeta, y activará la salida que crea más conveniente.
En lo que respecta a la TV, la autodetección no funciona, pero con el monitor la tarjeta usará el monitor y ``despreciará'' el LCD en caso de que encuentre uno conectado. Esto es, el LCD se apagará (y quedará con un aspecto fe0 y no sé si hasta dañino...porque cuando se apaga el ordenador no queda ``así'') y nuestra salida será por el monitor conectado, a alguno le parecerá lo correcto, personalmente yo no es lo que esperaba, por suerte, el driver de Nvidia tiene soporte para poder usar las dos a la vez. Sin embargo, una advertencia, debido a problemas técnicos del driver (consultar documentación) sólo se pueden activar las extensión XV para el primer dispositivo conectado, por lo que si usamos dos monitores a la vez, éstas se deshabilitarán (nota; a la hora de escribir esto, el último driver de NVidia disponible es la versión 61.11 y parece que han implementado un workaround para esto, aunque el overlay de vídeo no funciona ``a tope'',ya sí permite variar brillos y demás); yo he encontrado que esto, por ejemplo, impide el cambio por hardware del brillo con el que mplayer reproduce una película.. (por ejemplo) por lo que he elegido no tener siempre configurada la salida de monitor, y activarla cuando realmente la vaya a necesitar.
¿Cómo se hace? Usando ``TwinView'', (sobre el cual tenéis un buen artículo en castellano en un artículo de Linuca ) Es muy recomendable revisar la documentación del driver de NVidia ya que viene perfectamente explicado en ésta. En los anexos incluiré ejemplos de archivos de configuración de las X (es lo próximo en la lista TODO para la revisión 0.7)
Funciona sin problema alguno en las X usando el protocolo PS/2 (se comporta como un ratón enchufado al puerto serie)
El teclado del toshiba funciona perfectamente en la consola de texto, sin embargo en las X tiene ciertos problemas.
El primero, y desde luego muy molesto es que parece ser que el controlador de toshiba para el teclado, cuando se escribe a un buen ritmo, envía el mensaje de tecla presionada/tecla soltada dos veces, en lugar de hacerlo sólo una vez; ¿Resultado? se escribe dos veces la misma letra, obteniendo algo como:
alex@marte$: lls alex@marte$: lss
o peor aún
alex@marte$: llss
Existe, sin embargo, un 'workaround' para esto, se trata de usar la extensión de accesibilidad que incorporan las X para personas discapacitadas; en concreto usaremos una extensión conocida como SlowKeys que rechaza las pulsaciones de teclas demasiado rápidas.
El teclado de Toshiba dice que la tecla se ha pulsado y soltado dos veces; pero lo hace con una diferencia entre ambos eventos de 0 ms, así que no habrá problemas en eliminar las pulsaciones repetidas en los 5 ms siguientes a la pulsación, ya que no existe ser humano que pueda teclear así de rápido (si es usted capaz de hacerlo le aconsejo que se ponga en contacto con la organización que lleva el tema de los records guiness)
Personalmente hasta comprarme el portátil jamás había usado las extensiones de accesibilidad; así que el script que estoy usando en mi Xsession es el mismo que rob miller publicó en un artículo acerca de Linux en un Toshiba de otra familia ( pero que tiene el mismo problema)
Líneas en Xsession que 'arreglan el problema' 3
xkbset m xkbset exp =m xkbset sl 5 xkbset exp =sl xkbset -f slowaccept xkbset exp =f =slowaccept
Nota de actualización (revisión 0.6): Parece ser que la gente del kernel se ha hecho consciente de este problema con nuestros teclados y en teoría, esto no debería ser problema para los kernels de la serie 2.6; ya que en teoría han arreglado el problema.
También parece ser que este problema se soluciona no cargando la extensión de Xwindow xkb, para ello, en la sección ``Keyboard'' de nuestro archivo de configuración de las X tendremos que añadir una línea que rece:
La tarjeta de sonido que incorpora este portátil está de moda en nuestros tiempos (no es de gran calidad, pero es barata y más o menos funciona, además, es un portátil.. no te olvides) se trata de una tarjeta basada en el chipset de para tarjetas integradas en placa, así que será del tipo AC97.
Este tipo de tarjetas están soportadas en el mismo kernel via driver OSS desde ya hace tiempo... cualquier kernel de la serie 2.4 debería soportarlas. Sin embargo, este modelo en concreto parece tener problemas algunos problemas, he podido leer que esta revisión de tarjeta tiene problemas con kernels anteriores al 2.4.21 (que es la última versión estable en la fecha de redacción de este artículo)
Lo cierto es que tanto el módulo del kernel 'i810_sound' (OSS) como el módulo 'snd-intel8x0' (ALSA) se niegan a cargarse con el kernel estándar de Debian (2.4.18-bf24), sin embargo este problema desaparece al usar el kernel 2.4.21 (y se supone que posteriores; consultar la página del kernel www.kernel.org)
Una vez cambiado al kernel 2.4.21 la tarjeta funciona perfectamente. El autor prefiere los drivers ALSA ya que estos habilitan la operación Full Duplex de la tarjeta, lo cual es imprescindible si se pretende usar software de videoconferencia o similar.
La unidad funciona perfectamente 'out of the box', sin embargo, para poder usar la grabadora en Linux debemos activar la emulación SCSI en el kernel.
La unidad es maestro del canal secundario de la controladora IDE, así que debemos pasar el parámetro 'hdc=ide-scsi' al kernel en el momento del arranque, o configurar una línea append en nuestro lilo a tal efecto.
Cabe destacar una cosa curiosa. Al activar la emulación SCSI la unidad le dice al sistema que cuenta con 7 LUN (en el mundo SCSI, es algo así como el equivalente al número de bandejas que tiene un cargador de CDs) de modo que en algún software (como k3b) por ejemplo, detectará 7 unidades conectadas al ordenador (lo cual es correcto, pues desde /dev/scd0 hasta /dev/scd6 se asocian al CD). La solución a este ``problema'' es sencilla, además de pasar la configuración de SCSI al kernel, pasaremos 'max_scsi_luns=1'4
Por lo que una línea append de lilo quedaría más o menos:
append='hdc=ide-scsi max_scsi_luns=1'
Actualización en la revisión 0.6: En la serie 2.6 del kernel, es posible grabar CDs usando una grabadora IDE si tenemos una versión más o menos reciente de cdrecord y le pasamos al kernel la opción
append='hdc=ide-cd'
De esta manera, nuestro dispositivo (en este ordenador, /dev/hdc) podrá usarse como grabadora sin tener que pasar por emular un dispositivo SCSI; mucho más cómodo y menos ``rebuscado''. Incluso es posible que ni siquiera sea posible pasar esta opción de ide-cd y que el kernel lo autodetecte en próximas versiones (ahora mismo acaba de salir la 2.6.8)
Funciona sin problemas si hemos entrado al pseudo-setup que obtenemos pulsando ESC cuando arranca el PC y le asignamos al puerto una dirección I/O. (Para más detalles, consultar el manual del usuario del portátil).
Digno de mención es el hecho de que si arrancamos Windows en la misma máquina, éste ``desconfigurará'' el puerto quitándole la I/O asignada.. por lo que si queremos usar el paralelo con posterioridad en linux, debemos volver a entrar al menú de la ``BIOS''. Esto se puede evitar si en la aplicación de windows, o en la pseudobios que incorpora el portátil al pulsar ESC le pedimos que deje la configuración de hardware sin tocar.
El ordenador carece de disquetera interna, sin embargo, toshiba incluye una USB externa por si hace falta (lo cierto es que yo tuve problemas para encontrar un disquete con qué probarla... los tiempos cambian)
La unidad en concreto se identifica en el subsistema USB como 'TEAC FD-05PUB'. Para hacer uso de ella en Linux debemos insertar el módulo 'usb-storage' caso de que nuestro kernel no lleve el soporte incorporado, y la unidad quedará asociada a un dispositivo del tipo /dev/sd? si bien normalmente lo hará al /dev/sda.
Una vez cargado el módulo la unidad se puede usar como cualquier otra, pudiendo montarla o desmontarla como si de un disco duro se tratase.
Para formatear el disquette no podremos recurrir a las herramientas normales, ya que estas suelen estar restringidas a dispositivos con número principal de 2 (major char number) que identifican a disqueteras ``tradicionales''. Si queremos hacer un formato de bajo nivel, usaremos sformat, y si queremos crear un disquete FAT, podremos usar: mkfsiso.msdos -I /dev/sda
El adaptador para tarjetas PCMCIA funciona sin problema alguno (siempre y cuando tengamos soporte compilado en el kernel). Eso sí, debemos contar con las utilidades para gestión de PCMCIA de linux, en el caso de Debian se llaman ``pcmcia-cs''
El sistema USB funciona también sin problema alguno, y es del tipo Intel UHCI
En Debian conviene añadir una entrada en el /etc/fstab para montar el pseudo sistema de archivos USB:
none /proc/bus/usb usbdevfs defaults 0 0
De esta manera podremos consultar el estado de nuestros dispositivos USB en /porc/bus/usb
Es recomendable, si tu distribución no lo hace ya, descargarse e incorporar a los scripts de inicio 'hotplug' un paquete que en función de lo que se conecte al bus USB carga módulos en el kernel para dar soporte al dispositivo
La tarjeta que incorpora el portátil es una tarjeta muy común y conocida, una Realtek 8319 que está perfectamente soportada; yo prefiero incluir el soporte para la tarjeta en el propio kernel, pero el módulo es 8319too
La serie del kernel 2.4 tiene un soporte para ACPI bastante primitivo, y además, la BIOS de este modelo en concreto figura en su ``Black-list'' lo cual significa que bajo ningún concepto un kernel estándar de la serie 2.4 cargará el control ACPI en un portátil de este modelo.
Sin embargo, en la serie 2.5 el soporte ACPI está bastante más desarrollado, llevado de la mano del Linux ACPI Project; así mismo, este proyecto publica parches para el 2.4, de los que haremos uso para traer soporte ACPI a nuestro portátil; se pueden conseguir en: http://acpi.sourceforge.net/, y más información sobre el driver específico de Toshiba aquí
Además, este parche trae extensiones de ACPI para algunos fabricantes en concreto, entre ellos Toshiba, lo cual nos será extremadamente útil, por lo que es muy aconsejable activar dichas extensiones.
Para aquellos que sean afortunados (o sufridores, según se mire) usuarios de la serie 2.6; ya tienen probablemente el mejor soporte ACPI habido hasta ahora en linux (la serie 2.6 se mantiene sincronizada con acpi.sourforge.net)
Estas extensiones especiales se hallarán bajo /proc/acpi/toshiba y son básicamente 4:
Para controlar el brillo del LCD debemos usar un comando del tipo:
echo ``brightness:4'' > /proc/acpi/toshiba/lcd
Para que el comando funcione debemos ser root (o crear un programa que haga esto y al que otorgaremos permisos Suid)
El autor del artículo ha creado un programa como ese para que todos los usuarios puedan manejar el brillo del LCD; y para practicar un poco de C, (más bien para lo segundo que lo primero). Se incluye el código completo aquí por si a alguien le resulta interesante o útil, las críticas (constructivas) son bien recibidas :-) si bien la aproximación sugerida a continuación es mucho más limpia y útil
Timo Hoenig ha escrito un programa llamado 'fnfx' ,con web aquí para gestionar las acciones de las teclas de función, mediante este programa podremos asignar programas a las teclas de acceso rápido (es genial para abrir una ventana de navegador o para llamar al cliente de correo) así como controlar el volumen, y habilitar el uso de las combinaciones Fn+F7 y Fn+F8 para controlar el brillo del LCD.
El código es elegante(es fácil impresionarme en temas de código) y está dividido en un cliente y un daemon, y el programa funciona realmente bien.
Un pequeño ``truco'' que al principio me hizo pensar que las teclas del frontal del portátil no funcionarían; para que estas teclas se puedan usar debéis tener iluminado el piloto de ``Digital'' o ``audio'' en el frontal. ¿Qué como se hace esto? Mantén pulsado la tecla ``mode'' hasta que uno de los LEDs se enciendan, podréis comprobar en /proc/acpi/toshiba/keys que ahora esas teclas si mandan señal y pueden ser manejadas con fnfx.
Por poner un ejemplo, usando fnfx, estas teclas y dcop, se puede manejar juk (un reproductor de Música) desde el frontal del equipo.
En principio, creí que este dispositivo no funcionaría en linux, ya que aunque según las espcificaciones del fabricante dicen que el chip es un LPC47N227 (SMC SuperIO chip) soportado por el módulo smc-ircc, al tratar de insertar este módulo en el kernel, y pese a dar un mensaje del tipo ``found SMC superIO chip LPC47N227'' falla al cargarlo diciendo que el dispositivo no existe (extraño, ¿eh?)
El caso es que como esto me intrigaba (realmente no uso el IR para nada) me puse a investigar un poco y descubrí en google dónde estaba el problema. Según parece, el chip de IR está conectado al puente ISA, y nuestra genial BIOS no inicializa los parámetros del chip, ni le asigna IRQ, ni DMA, ni dirección de I/O..... esto en windows no es problema, porque los drivers de toshiba se esperan esto y asignan los valores cuando se carga el driver.
El problema está en que linux ``cree'' que la BIOS ha inicializado todo el hardware (supongo que otros SO a parte de linux hará algo parecido) en lo que respecta a IRQ, I/O y DMA.
Afortunadamente, una vez localizado el problema, una serie de personas se puso a solucionarlo, y se escribieron un par de programas para inicializar el chipset de ir, uno de ellos, el toshsat-1800 de <nombre de autor aquí>(merece crédito, pero....) y el tosh-5100-smcinit de Rob Miller.
Una vez descubiertos estos problemillas, me lancé a probar ambos programas, descubriendo, decepcionado que estos programas no funcionan con un Toshiba 2450. Por fortuna, soy un hombre intrépido y con unos conocimientos bastante básicos de C, así que me lancé a la inspección de las fuentes ...¡et vòila! Haciendo un pequeño cambio en el número de identificación que el programa espera del chipset (0x248c por 0x24c0) las cosa marcha!
Si ejecutamos el programa (yo le he llamado tosh2450-smcinit respetando la nomenclatura original de Rob Miller) antes de cargar el módulo smc-ircc (en los kernel de la serie 2.6 el nombre ha cambiado a smsc-ircc2; desconozco el motivo, pero así es), el kernelo lo cargará sin más (por esto, es importante compilar el kernel con soporte a través del módulo y no en el mismo kernel)
Esta versión del programa para arrancar el chipset IR está colgado en mi página web (con fuente)
Pego ahora aquí, las líneas en /etc/modules.conf relativas al subsistema de IR que hace que el módulo se cargue en inicio en mi Debian Sid ( también pego irda.conf, aunque es un dato más bien irrelevante)
### update-modules: start processing /etc/modutils/irda alias tty-ldisc-11 irtty alias char-major-161 ircomm-tty alias char-major-60 ircomm_tty # for dongle alias irda-dongle-0 tekram alias irda-dongle-1 esi alias irda-dongle-2 actisys alias irda-dongle-3 actisys alias irda-dongle-4 girbil alias irda-dongle-5 litelink alias irda-dongle-6 airport alias irda-dongle-7 old_belkin # for FIR device #pre-install smc-ircc /usr/sbin/tosh_irda_init #alias irda0 smc-ircc #Caso de kernel 2.6 pre-install smsc-ircc2 /usr/sbin/tosh_irda_init alias irda0 smsc-ircc2
Nótese la línea de pre-install antes de cargar el módulo smc-ircc. Esto sirve para ejecutar el programa para inicializar el chipset antes de cargar el módulo. (en mi sistema está como tosh_irda_init)
#irda.conf Version: 1.0 IRDADEV=irda0 #DONGLE= # specify dongle type DISCOVERY=-s ENABLE=yes # if you do not need to start irattach, set "no"
A día de hoy, los drivers de smartlink soportan los winmodems de Intel ICH4, por lo que una versión más o menos reciente de los drivers que se pueden encontrar Aquí manejan el winmodem y posibilitan su uso sin problema.
Debo decir, que el winmodem lo probé por el gusanillo de hacerlo funcionar, y lo hice muy poco. Todo esto, lo hice con un kernel 2.6.0 o similar, y los drivers funcionaban; no sé si seguirán compilando limpiamente como hacían antes, pero deberían hacerlo. Me consta que funcionan, así que... aquí lo pongo. Cuando lo probé, el modem marcaba y podía establecer comunicaciones, así que......
Según parece este lector es un dispositivo propio y exclusivo de Toshiba, o sea, es un desarrollo propio y el chipset es propiedad de Toshiba, como estos no han facilitado un driver para esta unidad, y tal vez debido a su poca extensión, no existe 'driver' para el kernel disponible en estos momentos (5/09/2003)
Compilar con ``gcc lcd.c -o lcd'' , copiar a /usr/bin y entregar el SUID de root. Permite establecer el brillo del lcd directamente, mediante una orden del tipo ``lcd 3''.
#include#include /*Programa la hostia chungo para que todos los * usuarios puedan cambiar el brillo de su LCD * eso sí, hay que otorgar el suid a este * programita * * By Ballfire. admiradores me encuentren en alejandro_aero-en-yahoo.es * Susituir el -en- por @ (pa los lentos ... ) * Tol código es GPL, hasta la última coma, oyes! XD * * All code is licensed under GPL 2.0 or later, published by * the Free Software Foundation ! */ /*V0.4 Con suerte esta será la versión definitiva de este * programilla, ha alcanzado a la perfección su objetivo * (establecer el brillo de forma directa) usando medios * más o menos estándard (esto va por la chapuza de la * versión 0.3 :-) ) * Asín que salvo fallo gordo, no hay motivo para tocarlo * más */ #define RUTA_LCD "/proc/acpi/toshiba/lcd" main (int argc, char *argv[]) { FILE *acpi, *acpi_lec; //para escribir y leer en RUTA_LCD int brillod, brillos; register int cuenta = 0; // lo usaremos para contar los caracteres del argumento char buffer[256] = " "; // lo inicializamos a " " pa qe no haga cosas chungas XDd acpi_lec = fopen (RUTA_LCD, "r"); if (acpi_lec == NULL) { printf ("\nFallo de lectura\n"); printf ("Estás seguro de que has instalado el parche ACPI al kernel?\n\n"); exit (1); } //las tres siguientes líneas de código están fuertemente inspiradas //en el programa lcd.c que forma parte //de fnfx. AUTOR: Timo Hoenig //licencia: GPL fgets (buffer, 32, acpi_lec); fgets (buffer, 32, acpi_lec); /*Con esto comprobamos los niveles de brillo disponibles * en mi portátil son 8 niveles, pero en otros * sistemas podrían ser más o menos. */ sscanf (buffer, "brightness_levels: %d", &brillod); fclose (acpi_lec); acpi = fopen (RUTA_LCD, "w"); if (acpi == NULL) { printf ("\nFallo al abrir lcd para escritura\n"); printf ("¿Eres root? \n¿Has puesto el SUID a este programa?\n"); printf ("\n¿Has aplicado el parche de ACPI y configurado el kernel?\n"); printf ("\nSi todas las respuestas son sí, por favor, contacta"); printf (" con el autor\n"); exit (1); } if (argc != 2) { //pa los ceporros printf ("\nUso: lcd BRILLO\n\n"); exit (1); } if (!strcmp (argv[1], "-v")) { printf ("lcd V 0.4\npor Ballfire\n"); exit (0); } if (!strcmp (argv[1], "moo")) { printf ("\nLo siento, esto no es apt\nno tiene superpoderes de vaca\n\n"); exit (0); } /*Esta pequeña rutina que me he currao cuenta los caracteres del argumento * hasta que encuentra el carácter terminador, ¿a que mola? * */ do { argv[1]++; cuenta++; } while (*argv[1] != '\0'); if (cuenta > 20) { printf ("\nTus argumentos son sospechosamente largos.\n"); printf ("Es indiferente, esto queda archivado\n\n"); //en esta línea me salto la tipografía porque es muy larga :-P syslog (LOG_INFO, "LCD: Se ha producido una llamada a lcd de más de 20 carácteres de argumentos"); exit (1); } /* Yo diría que 20 es bastante permisivo cuando se supone que // el argumento es un número, así que no mires con esa cara // Alguno se preguntará por la necesidad de logear algo como esto // Sabiendo quién lo ha programado... no me fio un pelo :-) */ for (; cuenta > 0; cuenta--) argv[1]--; /*Como para contar la longitud de la cadena hemos desplazado el puntero, esto * lo devolverá a su lugar, como la cadena es extremadamente corta, no hay problema * ummm, por cierto... sí.... sizeof,.. ya... */ /* Debido a que el sistema ACPI rechaza todo aquello que no sea una orden // válida (esto es, un número entre 0 y un máximo dependiente de la máquina) // no necesitamos hacer comprobaciones extra a la cadena // aún cuando el resultado de atoi sea algo completamente sinsentido // el kernel debería rechazar la petición. */ // Por cierto, en la v0.3 sí se hacía por la chapuza // que representaba usar system() // brillos--->brillo solicitado // brillod--->niveles de brillo disponibles brillos = atoi (argv[1]); if (brillos < brillod) { //printf ("correcto\n"); fprintf (acpi, "brightness: %s", argv[1]); //printf ("brightness: %s \n",argv[1]); } else { printf ("\nHas realizado una petición inválida. El argumento que debes pasar\n"); printf ("es un número entre 0 y %d\n", brillod - 1); } fclose (acpi); return 0; }
(En la lista de cosas por terminar)
NOTA: esto es sólo un ejemplo, deberías crear tu propia configuración basándote en el README del driver de NVidia. ( http://www.nvidia.com/object/linux.html )
Section "Monitor"
Identifier "Generic Monitor"
HorizSync 39-50
VertRefresh 0-60
EndSection
Section "Screen"
Identifier "sincrt"
Device "NVidia Ngo"
Monitor "Generic Monitor"
DefaultDepth 16
SubSection "Display"
Depth 16
Modes "800x600" "640x480"
EndSubSection
Option "TwinView"
Option "ConnectedMonitor" "DFP,TV"
Option "TwienViewOrientation" "Clone"
Option "TVOutFormat" "SVIDEO"
Option "SecondMonitorHorizSync" "30-50"
Option "SecondMonitorVertRefresh" "50-60"
Option "TvStandard" "PAL-B"
Option "MetaModes" "640x480,640x480"
EndSection
Section "ServerLayout"
Identifier "Default Layout"
Screen "sincrt"
InputDevice "Generic Keyboard"
InputDevice "Configured Mouse"
InputDevice "Generic Mouse"
EndSection
Podría pasar que si tienes el soporte para laptop Toshiba configurado en el kernel no se activase inmediatamente la salida de CRT del equipo. Para solucionar este problema tan tonto (tonto hasta que das con él, claro) nos vamos a una consola (CTRL+ALT+F1) y pulsamos FN+F5 hasta que tengamos salida de la consola en el LCD y en el monitor (CRT); hecho esto, volvemos a la sesión X (CTRL+ALT+F7 en mi configuración) y ya deberíamos tener salida en ambos dispositivos. :-)
Section "Device"
Identifier "NVidia Ngo"
Driver "nvidia"
Option "ShadowCursor" "on"
Option "NoLogo"
EndSection
Section "Screen"
Identifier "sincrt"
Device "NVidia Ngo"
Monitor "Generic Monitor"
DefaultDepth 24
SubSection "Display"
Depth 16
Modes "1024x768" "800x600" "640x480"
EndSubSection
SubSection "Display"
Depth 24
Modes "1024x768" "800x600" "640x480"
EndSubSection
Option "TwinView"
Option "TwinViewOrientation" "Clone"
Option "SecondMonitorHorizSync" "27-96"
Option "SecondMonitorVertRefresh" "50-160"
Option "Metamodes" "1024x768,1024x768;800x600,800x600"
Option "ConnectedMonitor" "DFP,CRT"
EndSection
Notas:
1.-El asterisco indica que no funciona sin tocar nada.
2.-Los portátiles Toshiba se caracterizan por tener una BIOS no compatible con APM, así que para el control de energía usan ACPI exclusivamente.
3.-Será necesario tener instalada la aplicación xkbset; que controla las extensiones de teclado para Xwindow:
4.-Esto podría interferir con la operación de otros dispositivos SCSI, así que no siempre será beneficioso tenerlo activado...
5.- Realmente no es toda la configuración, sólo un cacho
6.- Sólo las secciones relevantes, lee la documentación para más detalles
[REDACTED]Tras un tedioso proceso de retoque del HTML producido por Latex2Html