Ir al contenido

Buscar en La Comunidad

Mostrando resultados por etiquetas 'Workaround'.

  • Buscar Por Etiquetas

    Añade etiquetas separadas por comas.
  • Buscar Por Autor

Tipo de Contenido


Foros

  • Contacto con el staff
    • Novedades / Anuncios del foro
    • Sugerencias
    • Problemas relacionados con el foro
  • Zona general de charla
    • Presentaciones
    • Charla
    • Zona de Humor, Curiosidades y Otros
    • Mascotas Vagos
    • Noticias del Mundo
    • Tecnología
    • Ayuda y consultas de carácter general
  • Zona GNU/Linux
    • Ayuda, consultas y soporte GNU/Linux
    • Distribuciones GNU/Linux
    • Repositorios. Software GNU/Linux
    • Personalización
    • Raspberry Pi
    • Arduino
    • Manuales / Tutoriales / Guías GNU/Linux
    • Programación
    • Noticias GNU/Linux
    • Hablando de GNU/Linux
  • Zona Gaming
    • Juegos GNU/Linux
    • Noticias Gamer
    • Charla Gamer
  • Zona Móvil
    • Ayuda y soporte para dispositivos móviles
    • Apps Móviles
    • Manuales / Tutoriales / Guías Móviles
    • Roms para dispositivos Móviles
    • Noticias sobre dispositivos Móviles
    • Hablando sobre dispositivos Móviles
  • Zona Mozilla
    • Ayuda, consultas y soporte Mozilla
    • Aplicaciones Mozilla
    • Roms Firefox OS
    • Manuales / Tutoriales / Guías Mozilla
    • Noticias Mozilla
    • Hablando de Mozilla
  • Microsoft
    • Papelera del Foro

Encontrar resultados en...

Encontrar resutados que...


Fecha de Creación

  • Start

    Fin


Última Actualización

  • Start

    Fin


Filtrar por numero de...

Joined

  • Start

    Fin


Grupo


Página Web


Diaspora


Pump


GNU Social


Google +


Twitter


Facebook


Xmpp


Skype


Steam


Desura


MediaGoblin


Youtube


Vimeo


Picasa


Flickr


Email


Lugar


Intereses

Encontramos 13 resultados

  1. Buenas a todos, recientemente me encontre con un problema que me ha quebrado la cabeza las ultimas semanas, y es que, aunque los usuarios de arch disponemos de AUR, que nos facilita la instalacion/compilacion de una bastisima coleccion de software y herramientas, me encontre con un problema que no me habia pasado hasta ahora. resulta que llevo todo este tiempo intentando compilar kernel liquorix, que nunca me habia fallado, pero esta vez, tanto liquorix, como zen y demas kernels que veo en AUR, me dan error a la hora de verificar las firmas pgp. despues de mucho indagar encontre la solucion, y quiero dejarlo aqui, a modo de recordatorio para mi mismo, porque ya me ha pasado tanto en el portatil, sobremesa, y el notebook del curro. y he tenido que tirar de los comandos uno a uno. bueno, en el caso de querer compilar un kernel de linux, si te encuentras con el error de las firmas, y por mas que añadas la firmas te sigue dando el mismo fallo, la solucion es la siguiente. entramos en el directorio de gnupg: cd .gnupg/ luego: gpg --export-ownertrust > otrust.tmp borramos: rm trustdb.gpg y por ultimo: gpg --import-ownertrust < otrust.tmp ahora ya tenemos creado ese "deposito temporal nuevo" donde podremos importar todas esas claves que nos falten y necesitemos, para importar la clave, en este caso, de linus torvals, para poder compilar el kernel de linux... gpg2 --keyserver hkp://keys.gnupg.net --recv-keys 79BE3E4300411886 porque pasa esto?, la verdad es que no lo se, yo en otras ocasiones he podido compilar el kernel de liquorix sin tener que recurrir a todo esto, pero ahora no puedo, no se si debe de ser algo nuevo que hayan implementado en gpg, o en AUR, pero esta seria la solucion, en el caso del kernel de linux. salu2 PD: ademas de liquorix, mi favorito, encontre este kernel, que es el que estoy probando ahora en mi manjaro OpenRC del escritorio, ya os contare...https://aur.archlinux.org/packages/linux-covolunablu-gaming/
  2. Buenas tardes, estoy con Ubuntu 16.04 instalado en un Compaq 610. Buscando como mejorar un poco la gráfica encontré que Intel tiene una herramienta muy interesante, la Intel Graphics Update Tool for Linux* OS v2.0.2. Fuente: https://01.org/linuxgraphics Esta herramienta actualiza los drivers de las tarjetas gráficas Intel tanto en Ubuntu 16.04 como en Fedora 24, arquitecturas de 32 y 64 bits. Pues bien al hacer: $ lspci | grep VGA obtengo: 00:02.0 VGA compatible controller: Intel Corporation Mobile GME965/GLE960 Integrated Graphics Controller (rev 0c) Para instalar la herramienta agregamos la llave pública del repositorio Ubuntu 16.04 $ wget --no-check-certificate https://download.01.org/gfx/RPM-GPG-KEY-ilg-4 -O - | \ $ sudo apt-key add - $ sudo apt-get update $ sudo apt-get upgrade Información adicional Ubuntu https://01.org/linuxgraphics/documentation/running-update-tool-using-gdebi Fedora 24 Luego de agregar las firmas, elegimos el paquete según arquitectura y distribución: Descargamos el correspondiente, y en mi caso solo tuve que hacer doble click en el archivo .deb, y el instalador de software de Ubuntu instaló el paquete (requirió la clave de administrador). Una vez instalado, ubicamos el "intel-graphics-update-tool" en Unity con el Dash buscamos Intel, y en Genome Aplicaciones, Herramientas del sistema, Preferencias. Doble click sobre él y se inicia el proceso Nota: como siempre, agradezco sí el tema lo requiere, sean modificadas etiquetas o reubicado, por parte de moderadores o Admin del Foro. Espero sea de utilidad JPablos
  3. En realidad las impresoras HP andan muy bien con Linux, hasta mejor que en Windows, la conecto, la reconoce sola, y lista para imprimir. Hace poco dejó de funcionar por unos momentos (a lo mejor era por un error pavo, como que estaba pausada), entonces la eliminé de la lista de impresoras para reinstalarla, el problema es que no se reinstaló sola EDIT: Al parecer se puede instalar la impresora instalando el programa hplip con aptitude (aptitude install hplip). Lo que hice yo fue usar un script de instalación para ese programa Lo pude arreglar con esta guía para HP, esta muy buena porque es muy completa para los recién iniciados, aunque en realidad el instalador es tan fácil que ni miré la guía. Me hubiera gustado una solución más simple, pero igual el instalador de impresoras HP me funcionó muy bien El único inconveniente es que cuando pregunta si abrir la GUI o seguir en la consola al abrir la GUI se trabó el probrama, entonces tuve que hacer todo de nuevo para intentar en el modo consola. Cuando intenté con el modo consola dió error pero me recomendó usar hp-setup, a partir de ahí no tuve más problemas
  4. Buenas tardes, dicen que "Echando a perder se aprende", pues bien hoy he aprendido cómo recuperar mi sistema (Ubuntu 16.04) luego de echarlo a pique por "trastear" con el entorno gráfico. Reinicié mi equipo, con la sorpresa de no tener entorno gráfico, esta es la secuencia: Nuevo reinicio, busco "Opciones avanzadas para Ubuntu" Selecciono "... Linux 4.4.0-36-generic (recovery mode)" Paso a "consola root", trasteo algunos comandos..., y ahí vino la debacle, Ejecuté "apt-get autoremove", y este comando borró todo lo que pudo. Repito los pasos 1 y 2, intento "Continuar con el arranque normal" Salgo en modo texto, autentico mi usuario, y aplico la solución, a saber sudo dpkg --configure -a sudo apt-get -f install sudo apt-get update sudo apt-get dist-upgrade sudo apt-get install --reinstall ubuntu-desktop sudo init 6 ** sudo init 6 reinicia el equipo El equipo arrancó de manera normal, tuve que recuperar algunos paquetes previamente instalados, y ahora va de nuevo como la seda. Espero esta información sea de utilidad Nota: agradezco de antemano si el tema requiere alguna modificación de etiquetas o reubicación, estas sean hechas. Un saludo JPablos
  5. Buenas tardes, hace poco he instalado en un portátil "Compaq 610" Win7 / Ubuntu 16.04. El asunto es que en Ubuntu, el brillo de la pantalla era muy intenso, acudí a: "Configuración del sistema" / "Brillo", para poder ajustar el brillo, pero aún con el deslizable muy cerca del inicio, el brillo era intenso. Buscando una solución, encontré la siguiente: Abrir el archivo /etc/default/grub para edición sudo gedit /etc/default/grub Ubicar la línea GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" Editar la línea para que ahora contenga GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_backlight=vendor" Guardar cambios en el archivo, cerrar el editor Actualizar el GRUB update-grub Reiniciar el sistema, y listo. Ahora el botón Brillo cumple bien su función. Fuente de la solución Espero sea útil. Un saludo a los integrantes del Foro JPablos
  6. Buenas noches, luego de la actualización de virtualbox, me dí con que no se iniciaba, pruebo desde la terminal y me salía el error: VirtualBox: supR3HardenedMainGetTrustedMain: dlopen("/usr/lib/virtualbox/VirtualBox.so",) failed: libQt5X11Extras.so.5: cannot open shared object file: No such file or directory Por lo visto se actualizaron o faltaba dicha librería asi que directamente lo que hacemos es instalarla con pacman: sudo pacman -S qt5-x11extras Y listo, probamos nuevamente y se inicia correctamente. Espero que les haya servido! Abrazo de gol!
  7. Este software y su estupenda función de grabar opengl ya son conocidos en esta comunidad http://gnulinuxvagos.es/topic/4808-captura-opengl-de-juego-de-steam-con-simplescreenrecorder/?hl=simplescreenrecorder yo personalmente no me lo pensé dos veces y decidí probar esta maravillosa función haciendo un poco el g********* en garrys mod. Seguí todos los pasos que publicó Shiba y el creador del software pero... ¡¡NO ARRANCABA EL JUEGO!! No arrancaba una vez introducido en las opciones de lanzamiento: El problema estaba causado por unas librerías faltantes (Nuestras maravillosas amigas) que impedían que el juego iniciase. Aquí os traigo la solución 1. Lo primero que tenemos que hacer es comprobar si se encuentran en la carpeta /usr/lib/ las librerías: Si se encuentran en esta carpeta podreis saltaros el siguente paso. Id al paso 3 2. Descargamos las librerías para ubuntu 12.04. Tranquilos, da igual que distro y que versión sea, funcionará igualmente. Link de descarga: https://launchpad.net/~maarten-baert/+archive/ubuntu/simplescreenrecorder/+files/simplescreenrecorder-lib_0.3.3-1%7Eppa1%7Eprecise1_i386.deb Una vez hecho esto descomprimimos el .deb Dentro del .deb nos encontraremos los siguientes archivos: Extraemos el archivo data.tar.gz Nos aparecerá una carpeta llamada usr. dentro de esta estará la carpeta lib que a su vez contendrá la carpeta i386-linux-gnu que contiene las librerías que necesitamos. Movemos los archivos (con un mv) o los copiamos (con un cp) a la carpeta de nuestro linux. 3. Ahora movemos unas cuantas librerías que steam necesita para poder usar el grabador OpenGL. Si sigue sin funcionar probad a copiar la carpeta la libreria también. Así debería funcionar. Listo Ahora... solo queda seguir los pasos para grabar: http://gnulinuxvagos.es/topic/4808-captura-opengl-de-juego-de-steam-con-simplescreenrecorder/?hl=simplescreenrecorder
  8. Hace unos días, en uno de eso brotes psicóticos que tengo, decidí hacer borrón y cuenta nueva y compilar Enlightenment 0.19 desde cero, ya que hasta ahora venía arrastrando librerías desde la época de e17. Uno de los requisitos indispensables del nuevo núcleo de E19, que ahora incluye el motor de composición y otras muchas cosas, es la necesidad de contar con librerías para simulación de físicas en tiempo real, que en este caso se consigue con Bullet Pero, al compilar EFL 1.9 por un lado y la última versión de Bullet por otro, acabamos con un error que nos tira todo abajo. ¿Qué ocurre? PIC es la abreviatura de Position-Independent Code. Bueno, pues ya tenemos una ligera idea del por qué, ahora sólo queda saber: ¿Cómo proceder? De manera global, e insisto en lo de global, porque aunque se podría especificar junto con el resto de opciones de configuración/make, posiblemente no funcione Establecemos el flag -fPIC, tal como nos indica el mensaje de error CFLAGS="-fPIC" export CFLAGS Ahora toca volver a configurar y compilar TODO . En esta ocasión deberíamos obtener un resultado satisfactorio. http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3
  9. Trago amargo como el que más, la consecuencia más que probable si trasteamos en exceso con nuestro pobre ZTE Open compilando, modificando y poniendo a prueba Firefox OS hasta lo inimaginables es que, en algún momento, nuestro terminal acabe como un pisapapeles con pantalla táctil NOTA: Hablamos de un caso hipotético, cualquier parecido con la realidad es pura coincidencia Para ponernos en situación y asustar un poquito al personal, la propia ZTE tuvo un pequeño "lapsus" cuando hizo pública la actualización a Firefox OS 1.1, lo que provocó el Brickeo de algunos dispositivos que, tras terminar el proceso de instalación, no volvieron a arrancar. La "solución" propuesta por telefónica fue recurrir al servicio técnico para la sustitución del terminal por uno ya actualizado, algo engorroso y a la vez imposible de realizar para aquellos que no han obtenido el teléfono a través de telefónica o le han hecho algún tipo de modificación que anule la garantía (liberación, cambio del SO original, actualizaciones no oficiales, etc), en esta situación estaremos sólos, desamparados y sin teléfono . La verdad es que llegar a brickear un ZTE Open bastante complicado, ya que siempre existen opciones para trabajar con él, pero se puede dar el caso de que todo salga mal. Con nuestro ZTE Open Rooteado, la imagen del ClockworkMod instalada, nos disponemos a compilar una versión personalizada de Firefox OS pero.... durante el proceso algo sale mal y el teléfono no arranca, pero bueno, siempre hay opciones, así que nos decidimos por instalar una imagen oficial para devolver el teléfono a su estado original y empezar de nuevo con el flasheo. Sin embargo, puestos a que todo salga mal, la imagen oficial resulta ser precisamente la que nombramos antes y el flasheo resulta un fracaso. Ahora el teléfono sigue sin arrancar, pero al realizar el flasheo fallido hemos perdido la posibilidad de acceder al teléfono como root, la administración remota ha sido deshabilitada, con lo cual ya no podemos valernos de ADB y el ClockWorkMod ha sido sustituido por la imagen Recovery de fábrica. Nos quedaría un último as bajo la manga, el modo FastBoot, el cual nos permitiría flashear una nueva imagen de Firefox OS directamente y se activa pulsando simultáneamente el botón de Encendido, subir y bajar Volumen, es decir, todos los botones físicos del teléfono. Pero ¡Oh sorpresa! ZTE lo ha bloqueado y lo único que conseguimos es una pantalla negra y un piloto rojo encendido ¿Y ahora qué? . Lo único que nos queda es el modo recovery, pero en la versión de fábrica sólo permite la instalación de imágenes muy concretas y firmadas, así que aunque lo intentemos, sin el ClockworkMod nos encontraremos con un error tras otro al tratar de flashear una nueva imagen de Firefox OS a través del menú recovery. Admitámoslo. ¡La hemos cagado! Es de madrugada, se nos han agotado las opciones, nuestra la visión se nubla, no quedan paredes sin marcas de cabezazos, nuestro pobre ZTE ha pasado a mejor vida y nosotros hemos sido sus ejecutores Pero ¿Y si hubiera una manera?¿Hacemos un último intento a la desesperada? Pues qué quieren que les diga, de perdidos al río ¿No? La imagen que logrará saltarse las limitaciones del limitado Recovery de ZTE y traerá de nuevo a la vida nuestro terminal es la que nos proporcionan en http://firefox.ztems.com/ Es pequeña,antigua y muy limitada, pero nos servirá como punto de partida para recuperar toda la funcionalidad del teléfono. Evidentemente la que nos interesa es la que corresponde al modelo Open, no al Kiss, no nos vayamos a equivocar aquí porque entonces sí que estaremos perdidos La imagen se instala como cualquier otra, colocando el archivo Zip en la tarjeta de memoria, iniciando el teléfono en modo recovery (Botón de encendido + subir volumen) yendo al menú de actualización y seleccionando el zip a instalar, aunque tendremos un pequeño problema a la hora de copiar la imagen a la tarjeta del teléfono, ya que éste no funciona, vamos a necesitar otro lector de tarjetas Micro SD para poder hacerlo Eso sí, una vez recuperado el teléfono, mejor no perder tiempo en volver a recuperar todas las herramientas, ClockworkMod, rooteo, habilitar la depuración remota para acceder vía ADB... Recordemos que esta vez nos hemos librado por los pelos, no tentemos a la suerte :lol: :lol:
  10. Por el título se cae de maduro que si estamos realizando la instalación vía USB, es totalmente comprensible que no se detecte ningún disco de instalación, pero en ocasiones ocurre que la aplicación que utilizamos para descomprimir la imagen iso en nuetro dispositivo USB para posteriormente instalarla o el propio instalador comete un error o deja algún cabo suelto y a mitad del proceso de instalación nos damos cuenta que no podemos seguir, porque "No es posible cargar los componentes desde el cdrom" El instalador nos ofrecerá la opción de cargar el módulo que corresponde a nuestra unidad para poder usarla, cosa que no nos sirve de mucho porque para eso tendríamos que poder acceder previamente a los componentes del disco de instalación ¿Cómo salimos de este bucle tan absurdo y a la vez frustrante? Pues con otro bucle Dejamos el instalador corriendo y nos vamos a una de las tty (Control + Alt + Fx) para darle al instalador lo que nos pide: mkdir /cdrom mount -t vfat /dev/sdb /cdrom Ahora ya tenemos nuestro "cdrom" virtual cuyo contenido es el de la unidad USB, con lo cual habremos dado al instalador lo que necesitaba para poder continuar con el proceso de instalación de nuestra Debian (o Debian-based)
  11. Para los osados que se encuentren ahora mismo probando las versiones en desarrollo de Firefox OS en algún terminal "inari", entre los que está el ZTE Open, seguramente se hayan topado una regresión bastante molesta surgida en la versión 1.4 y que ha pasado inadvertida hasta que ha entrado posteriormente en la versión 1.3 donde ha causado más de un dolor de cabeza. El bug en cuestión provoca una serie de "pantallazos blancos" a la hora de iniciar cualquier aplicación, abrir algún menú o en cualquier desplazamiento por la pantalla o, directamente hacen que el entorno gráfico se venga abajo provocando un reinicio tras otro de la interfaz. El problema, según se comenta en bugzilla, es debido a los últimos cambios del HWComposer y/o algún conflicto con los controladores gráficos del ZTE. La forma más sencilla de prevenir este mal hasta que el parche sea incluido en una de las próximas actualizaciones es a través del menú de ajustes, deshabilitando el "Hardware composer": Ajustes -> Información -> Más Información -> Desarrollador -> Enable hardware composer Pero claro, si ya hemos actualizado y sin poder ver lo que ocurre en pantalla o sufriendo continuos reinicio ¿Cómo llegamos hasta ese menú? En este caso tendremos que llevar a cabo una pequeña chapuza previa para dejar fuera de juego el compositor. Para ello nos valdremos, una vez más, de ADB adb shell mv /system/lib/hw/hwcomposer.msm7627a.so /system/lib/hw/hwcomposer.msm7627a.s_ Como ven lo único que hemos hecho ha sido cambiar el nombre de la librería correspondiente al compositor dejándolo, momentáneamente, fuera de juego. Ahora, tras reiniciar el dispositivo, veremos que todo ha vuelto a la normalidad y podremos acceder al menú de ajustes para deshabilitar por fin el hwcomposer. Luego desharemos la chapuza, no vaya a ser que alguien la vea adb shell mv /system/lib/hw/hwcomposer.msm7627a.s_ /system/lib/hw/hwcomposer.msm7627a.so Aunque no es habitual, este tipo de cosas son las que pueden ocurrir por arriesgarse con versiones en desarrollo. Nada que no se resuelva con una pequeña búsqueda y trasteando un poco https://bugzilla.mozilla.org/show_bug.cgi?id=952916
  12. Hace apenas un día nos hacíamos eco de los problemas de Nvidia para dar soporte a las últimas versiones del Kernel Linux debido a los últimos cambios realizados en éste y que impedían el correcto acceso a la memoria por parte del driver de Nvidia y hace apenas unas horas la compañía verde nos sorprendía con una nueva versión de los drivers de la serie 331.x que da soporte tanto a Linux 3.11 como a la versión 3.12 lanzada esta semana, incluye la corrección para el problema de memoria antes mencionado y además nos trae algunas mejoras muy interesantes. La novedad más destacada de esta nueva versión 331.20 son las librerías NvFBCOpenGL (NVIDIA OpenGL-based Framebuffer Capture). Esta librería permite tener una interfaz de alto rendimiento y muy baja latencia que permite capturar y odificar el Framebaffer compuesto de una pantalla de las Xs. La pega es que tanto NvFBC son NvIFR exclusivas de Nvidia, no APIs abiertas. El soporte EGL sigue mejorando y ahora también se incluye soporte para los sistemas de 32 bits y el instalador de Nvidia es capaz de detectar y corregir conflictos con EGL GLAMOR (libglamoregl.so) utilizada para la aceleración 2D OpenGL. Se añade soporte para el módulo de memoria unificada de Nvidia (nvidia-uvm.ko) Además de todo esto se han corregido numerosos bugs y hecho otros cambios en el instalador de Nvidia y en Nvidia-settings, podemos ver la lista completa de cambios en su página oficial 331.20 Linux X86 http://es.download.nvidia.com/XFree86/Linux-x86/331.20/NVIDIA-Linux-x86-331.20.run Linux X86_64 http://es.download.nvidia.com/XFree86/Linux-x86_64/331.20/NVIDIA-Linux-x86_64-331.20.run Linux ARM (32 bits) http://es.download.nvidia.com/XFree86/Linux-x86-ARM/331.20/NVIDIA-Linux-armv7l-gnueabihf-331.20.run FreeBSD X86 http://es.download.nvidia.com/XFree86/FreeBSD-x86/331.20/NVIDIA-FreeBSD-x86-331.20.tar.gz FreeBSD X86_64 http://es.download.nvidia.com/XFree86/FreeBSD-x86_64/331.20/NVIDIA-FreeBSD-x86_64-331.20.tar.gz Solaris http://es.download.nvidia.com/solaris/331.20/NVIDIA-Solaris-x86-331.20.run 319.72 Al mismo tiempo, también ha sido lanzada una nueva versión de la serie 319.72 que incluye soporte para nuevas tarjetas: Quadro K510M Quadro K610M Quadro K1100M Quadro K2100M Quadro K3100M Quadro K4100M Quadro K5100M GeForce 705A GeForce GT 730A Linux X86 http://es.download.nvidia.com/XFree86/Linux-x86/319.72/NVIDIA-Linux-x86-319.72.run Linux X86_64 http://es.download.nvidia.com/XFree86/Linux-x86_64/319.72/NVIDIA-Linux-x86_64-319.72.run Linux ARM (32 bits) http://es.download.nvidia.com/XFree86/Linux-x86-ARM/319.72/NVIDIA-Linux-armv7l-gnueabihf-319.72.run FreeBSD X86 http://es.download.nvidia.com/XFree86/FreeBSD-x86/319.72/NVIDIA-FreeBSD-x86-319.72.tar.gz FreeBSD X86_64 http://es.download.nvidia.com/XFree86/FreeBSD-x86_64/319.72/NVIDIA-FreeBSD-x86_64-319.72.tar.gz Solaris http://es.download.nvidia.com/solaris/319.72/NVIDIA-Solaris-x86-319.72.run 304.108 Y ya que estoy y para no abrir tema nuevo, los cambios también están empezando a llegar a los controladores "legacy" para tarjetas antiguas, empezando por los de la serie 304 que cubren hasta las veteranas Geforce 6 Linux x86 http://www.nvidia.com/download/driverResults.aspx/69365/en-us Linux x86_64 http://www.nvidia.com/download/driverResults.aspx/69366/en-us Solaris http://www.nvidia.com/download/driverResults.aspx/69367/en-us FreeBSD x86 http://www.nvidia.com/download/driverResults.aspx/69368/en-us FreeBSD x86_64 http://www.nvidia.com/download/driverResults.aspx/69369/en-us
  13. Aún siendo privativos, los controladores de Nvidia pueden sufrir una vuelta de tuerca por parte de desarrolladores de la comunidad que, como ocurre en este caso, han querido sobrepasar algunos límites impuestos. Antes de proceder, recordad que no todos se verán beneficiados por las mejoras o eliminación de límites provistos por estos parches, así que debemos proceder con cautela. Nvlinpatch Este parche permite sobrepasar el límite de 400MHz de pixel clock. Para aquellos que buscan salidas de 1440p a 120Hz, los controladores de Nvidia para Linux no permiten esto desde que fue impuesto el límite varias versiones atrás. Cómo parchear nuestro controlador: Al contrario que otros parches que actúan directamente sobre el instalador , Nvlinpatch será usado después de haber realizado la instalación de los controladores de Nvidia, actuando directamente sobre el módulo nvidia.ko El procedimiento es sencillo, sólo tendremos que obtener el parche desde github y aplicarlo especificando la ruta hasta nvidia.ko git clone https://github.com/CFSworks/nvlinpatch cd nvlinpatch ./nvlinpatch.py /lib/modules/`uname -r`/kernel/drivers/video/nvidia.ko Después de un rato, el límite del pixel clock habrá desaparecido Nvml_fix Este parche es un "workaround" que nos permite utilizar la librería NVML, actualmente disponible sólo para tarjetas Quadro/Tesla con cualquier gráfica Geforce. Nvdia daba soporte para nvidia-smi y NVML antiguamente, pero varias versiones atrás, este soporte se vio limitado sólo a tarjetas destinadas a estaciones de trabajo. Este parche hace posible que podamos utilizar aplicaciones diseñadas para tarjetas Quadro/Tesla con cualquier hardware Geforce. Al igual que antes, el parche se aplica después de haber instalado los controladores de Nvidia, aunque en este caso, una vez obtenido el parche desde github tendremos que compilar la librería nvlm git clone https://github.com/CFSworks/nvml_fix cd nvml_fix make Esto nos creará una carpeta built, en cuyo interior se encontrará la librería libnvidia-ml.so.1 para nuestra versión de los controladores. Ya sólo nos quedaría mover dicha librería a su lugar dentro de /usr/lib cp built/VERSIÓN/libnvidia-ml.so.1 /usr/lib Si fuera necesario compilarla para 32 bits en sistemas de 64, podemos utilizar el flag: make CFLAGS=-m32 Y mover la librería resultante a /usr/lib/i386-linux-gnu
×
×
  • Crear Nuevo...