Ir al contenido

Buscar en La Comunidad

Mostrando resultados por etiquetas 'drivers'.

  • 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 33 resultados

  1. Pues es una pregunta tonta que hago en función de que pocas veces he tenido tantas opciones mirando el Drivers adicionales de Ubuntu, solia ir con tarjetas ya sin soporte. A ver os pongo una imagen y quisiera saber si escogeriais otro que aquel que yo tengo que es el de codigo abierto → Los juegos yo creo que me van bien y recuerdo haber dejado los nouveau para poder en Blender hacer uso del cuda que creo yo que al instalar otros drivers no me dejaba poner esa opción o no se configuraba pero que recuerde no tenia tantas entradas de posibles drivers compatibles. Pues es eso un poco para aprender si seria mejor para esto una version o para aquello otra. Eso es amigos. Saludos a todos.
  2. Hace poco mi ratón ergonómico, que ya llevaba unos cuantos años de servicio a cuestas, pasó a mejor vida y, aunque traté de revivirlo, llegó un momento en que había más estaño que ratón y tuve que asumirlo. Tocaba un cambio. Buscando un poco en en aras de optar por un hardware "Linux-friendly", no sólo en la parte que corresponde estrictamente al funcionamiento, sino por el apoyo del fabricante hacia GNU/Linux, me decanté por Roccat, una compañía que se dedica casi en exclusiva al diseño de periféricos destinados a gamers. Como tampoco soy un jugador muy exigente y no era cuestión de empeñar un riñón para unos pocos ratos que paso jugando, el elegido fue uno de sus modelos más básicos (entiéndase barato ) el Roccat LUA. Muy ligero, preciso, tres botones y alguna pijería con leds azules ¿Para qué más? En realidad, los controladores libres para dispositivos Roccat fueron desarrollados hace ya unos años por el germano erazor_de e incluidos en Linux en 2010, si no me equivoco. Por tanto, a estas alturas, nada más conectar el ratón al equipo debería cargarse el módulo correspondiente para lidiar con este tipo de hardware ¿Verdad? shiba@Shiba87:~$ lsmod | grep roccat hid_roccat_lua 2626 0 hid_roccat_common 4383 1 hid_roccat_lua Como se puede ver, en mi caso ya he dicho que se trata del modelo LUA, por tanto el módulo que me muestra cargado es el específico para ese tipo de ratones. Ocurriría lo mismo si habláramos de un Arvo, un Kova, un Pyra o cualquier otro Roccat. Siendo así creo que nos podemos saltar la parte de cómo instalar los controladores libres, que aunque no están desarrollados por Roccat, cuentan con su apoyo y los podemos encontrar en su web oficial, funcionan perfectamente y salvo que tengamos una versión de Linux anterior a la 2.6.35, debería ser completamente "Plug & Play". Lo que nos interesa ahora es una herramienta para poder aprovechar al máximo las capacidades de este tipo de ratones/teclados. Lamentablemente, por el lado de las herramientas libres no vamos a encontrar nada tan vistoso y profesional como el software oficial, pero su equivalente OpenSource tampoco se queda corto y funciona bastante bien, así que ¿Para qué complicarse cuando incluso ellos mismos lo recomiendan? Arch Debian Ubuntu Compilar manualmente Uso y configuración Antes que nada y como mera formalidad, vamos a añadir nuestro usuario al recientemente creado grupo "roccat", para que los permisos no nos den problemas luego, especialmente aquellos que decidieron compilar manualmente. Lo habitual sería que ahora tuviéramos una flamante entrada en el menú de nuestro entorno, pero en cualquier caso podemos lanzar el configurador que nos interese roccat_keyboard_launcher o roccat_mouse_launcher Sólo debemos tener en cuenta si es ratón o teclado. El configurador concreto que nos hace falta se abrirá automáticamente en función del modelo que detecte conectado. O, en mi caso, con un modelo de ratón muy básico, un asistente acorde a las circunstancias
  3. Dónde puedo buscar información sobre qué placa de video elegir para comprar? Por lo que sé uno puede usar drivers libres o propietarios, y cada uno tiene nombres: Intel: Creo que solamente hay drivers libresAMD: Libre: radeon Propietario: fglrx (Catalyst) Nvidia: Libre: nouveau Propietario: nvidia? Cómo hacen ustedes para elegir GPU? Por lo que leí nvidia tiene los mejores drivers propietarios pero los peores drivers libres. Dónde puedo obtener información actualizada sobre como viene la cosa? O una lista de todas las GPU soportadas para cada driver Varía mucho el rendimiento de los drivers al comparar distitas GPU del mismo fabricante? O se puede decir que por ejemplo todos los GPU nvidia tienen buenos drivers sin excepciones?
  4. 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
  5. Qué adaptador bluetooth me recomiendan? Quiero uso de esos dongles USB. Lo que más me importan son los drivers, tienen que ser libres y que vengan en Debian para no renegar, me gustaría saber cuál es el más ampliamente utilizado. O si no dónde puedo ver qué chips soporta Debian con sus drivers libres? No se donde están los drivers, si en un paquete o en el kernel
  6. Aunque hace tiempo que me decidí por no sucumbir a polémicas a la hora de escribir, en este caso quiero hacer una excepción, porque es un tema que nos llega de cerca a muchos y que podría ser decisivo para el futuro de los entornos gráficos en GNU/Linux Hace muy poco, Nvidia liberó por fin una nueva serie de controladores que, no sólo nos traían Vulkan de manera estable y completamente funcional, sino que nos brindaban soporte para el servidor gráfico Wayland a través de EGL. Algo que llevábamos esperando desde hace ya mucho tiempo. Sin embargo, aunque en principio esta noticia sobre Nvidia suponía un salto importante a la hora de empezar a adoptar masivamente el servidor gráfico Wayland, dejando por fin "de lado" al veterano X11, junto a los controladores oficiales se han liberado una serie de parches de código abierto, que fueron enviados a la comunidad de desarrolladores de Wayland, que no han sido visto con buenos ojos por parte de los desarrolladores del servidor gráfico. Este código, pensado en principio para permitir que Weston, el compositor base de Wayland pueda correr sobre los controladores gráficos oficiales de Nvidia (privativos), ha sido rechazado. El origen de la polémica parece ser la implementación que ha hecho Nvidia, pues se valen directamente de EGL, haciendo uso de las extensiones EGLDevice y EGLStreams para manejar los buffers, mientras que la implementación oficial de Weston utiliza MESA GBM (Generic Buffer Manager). Si bien para algunos, incluida la propia Nvidia, esta aproximación supone un acercamiento más "agnóstico", en lugar de tener que desarrollar una versión alternativa de GBM para su línea de controladores, desde el otro lado sólo ven problemas con la alternativa propuesta por la californiana, al hacer uso de extensiones poco usuales o complicar/simplificar demasiado ciertos aspectos del renderizado. Aunque en principio esto no impide que entornos con compositores propios, como Enlightenment, Hawaii, Orbital, Orbment o incluso alguno de los más conocidos como KDE O Gnome, puedan dar soporte a Nvidia, implementándolo por cuenta propia en sus compositores, dentro del seno de Wayland y de cara al compositor Weston, por ahora las cosas están siendo discutidas de manera muy acalorada y no parece que veamos pronto ningún movimiento, al menos hasta que todos los pormenores hayan sido hablados y el código de Nvidia minuciosamente estudiado. https://lists.freedesktop.org/archives/wayland-devel/2016-March/027547.html
  7. Aunque fue lanzado en la madrugada del Lunes, ya que estamos en verano me van a permitir tomarme una pequeña licencia a la hora de escribirlo, porque con este calor... ya se sabe Una vez más, Linus Torvalds, junto a otros muchos desarrolladores de todo el mundo que trabajan en el kernel Linux (Que no en el kernel DE Linux, ya que eso es un sinsentido ), nos traen una nueva versión cargada de novedades y características la mar de interesantes. Se incluye soporte inicial para la arquitectura GPU Polaris de AMD, lo que incluye a la última RX 480 Al mismo tiempo, AMDGPU recibe mejoras de rendimiento con GPUVM, optimizaciones de PowerPlay, así como otras muchas mejoras de carácter general. En el caso de Nouveau, se incluye soporte para las Maxwell GM108, junto con mejoras para el sensor de consumo energético ARM incluye nuevas plataformas, como el primer LG ARM (LG1312), Aspeed, OXNAS-MPS2 y algunos nuevos SoC adicionales. Con la llegada de ACPI 6.1 se añade Schedutil como controlador principal de la frecuencia de la CPU. Éste se diferencia de los administradores utilizados hasta ahora, principalmente, en que toma la información provista por el administrador directamente para la toma de decisiones, no teniendo que hacer el seguimiento por si mismo y puede invocar controladores para un mejor ajuste del rendimiento de la CPU. Nuevo controlador PMC (Power Manager Control) para los procesadores Intel Reporte de energía acumulada para las APU AMD Carrizo En cuanto a sistemas de archivos, tenemos un gran número de correcciones para Ext4, así como también para Btrsf, F2FS y XFS En periféricos tampoco nos quedamos atrás, añadiendo soporte para ratones y teclados Corsair K70R, K95RGB, M65RGB, K70RGB y K65RGB Valve nos trae soporte para el mando Xbox One Elite de Microsoft, ya incluido en Steam OS durante el pasado Junio Más soporte HDMI para Skylake, nuevo chip Realtek y mucho más hardware de Audio que se añade a la lista. Soporte para la creación de controladores de unidades USB virtuales en USB/IP Histograma de eventos en ftrace Como siempre, para conocer al detalle la interminable lista de novedades, lo mejor es dirigirse a Kernel Newbies y, si no podemos esperar a compilar esta nueva versión de Linux con nuestras propias manos, siempre podemos obtener el código fuente en Kernel.org
  8. Envuelto en un halo de secretismo nos llega este anuncio por parte de Nvidia, que prepara un evento virtual en streaming para mañana a las 2PM hora del pacífico, lo que para los que estamos al otro lado del charco significa tener que esperar hasta el Sábado a las 3 de la mañana Twitch será el escenario elegido por la Californiana para tan extraño evento del que no tenemos más detalles. Los rumores apuntan a la puesta en el mercado de sus gráficas con GPUs de arquitectura Pascal, o al menos dos de las más potentes, conocidas hasta ahora por los sobrenombres 1070 GTX y 1080 GTX. Esto supondría nuevos controladores y toda una avalancha de nuevas tecnologías asociadas, pero como ya he dicho, por ahora todo son conjeturas y realmente no tenemos ni idea de lo que pueden tener preparado para alegrarnos el fin de semana . https://www.twitch.tv/nvidia
  9. Desde el año pasado, las noticias sobre Vulkan y los comunicados por parte de fabricantes y desarrolladores que apoyaban el nuevo estándar no han parado de llegar. Entre ellos, las numerosas conferencias, presentaciones y demás información provista por parte de Nvidia siempre incluyeron todas las tarjetas gráficas de escritorio Geforce soportadas por las series de controladores actuales dentro del hardware que podría disfrutar de las ventajas de Vulkan. Esto significaría que, todas las gráficas comprendidas entre la serie GTX 400 (Fermi) y la actual GTX 900 (Maxwell) entrarían dentro de los planes de soporte para Vulkan. Sin embargo, en un inesperado giro de los acontecimiento vimos como la primera versión de controladores beta de Nvidia con soporte para Vulkan partía directamente desde la serie GTX 600 (Kepler), dejando a la arquitectura Fermi fuera de la ecuación. Aunque en un primer momento se especuló que podría tratarse simplemente de un retraso, las diapositivas utilizadas durante las conferencias de este mes de Febrero han sido modificadas, revelando un cambio de planes que para muchos está fuera de lugar. Fermi ya no contará con soporte para Vulkan y la única razón para ello es la apreciación de Nvidia de no haber suficientes usuarios que aún utilicen estas tarjetas, estimando que sólo el 10% aún poseen una de estas GPUs. Durante el seminario online celebrado el pasado 18 de Febrero, uno de los ingenieros confirmó nuevamente que Fermi, a pesar de no existir ningún impedimento técnico, no tendrá finalmente soporte para Vulkan. No sabemos cómo afectará esta decisión a las series actuales de controladores que sí cuentan con soporte para las gráficas Fermi, si se bifurcarán, se descontinuarán o pasarán a ofrecernos paquetes de drivers más complejos con contenido completamente distinto según la arquitectura de la GPU detectada. Si algo ha caracterizado a Nvidia hasta la fecha, es su gran soporte, el mantenimiento de sus controladores tanto para series antiguas como para las que ya llevan más de un lustro en el mercado, la integración inmediata de los nuevos estándares gráficos, librerías, tecnologías... pero esta vez han sacado lo peor de sí mismos, dejando a muchos de sus fieles consumidores con un palmo de narices. Otra de las especulaciones al respecto es que podría tratarse de una respuesta estratégica frente a la decisión por parte de AMD de no dar soporte a sus gráficas GCN 1.0 y, ya que la competencia no lo va a hacer, para qué molestarse ellos ¿No? Está claro que el negocio es el negocio y un nuevo estándar gráfico es una oportunidad de oro para los fabricantes, pero hay ciertos límites que no deberían traspasarse y esta vez parece que la única que ha mantenido el tipo es Intel, siendo precisamente la que menos tiene que ganar en todo esto. Tras muchas noticias positivas, este varapalo la verdad es que no me lo esperaba y muchos usuario que ya están quejándose en los portales y foros oficiales de la compañía, tampoco. Quien me conoce sabe que no dejo pasar una a AMD por su mal hacer y las malas decisiones que suele tomar, pero esta vez es Nvidia quien se merece mi total desaprobación. Esta no es forma de tratar a sus clientes y espero que cambien de parecer, porque alguno optará por seguirles el juego y comprar una nueva tarjeta, pero los Shibas no perdonan y son muy, pero que muy rencorosos... https://devtalk.nvidia.com/default/topic/917161/fermi-support-/ http://on-demand.gputechconf.com/gtc/2016/events/vulkanday/Vulkan_Overview.pdf
  10. Mucho se ha hecho de rogar, pero finalmente tenemos lo que tanto hemos esperado. Nvidia acaba de liberar una nueva serie de sus controladores oficiales que traen, como siempre, muchas novedades interesantes, pero es que esta vez son más que eso. La nueva serie 364 culmina lo que comenzó con la serie experimental 355 y nos brinda soporte oficial estable para la nueva API gráfica de Khronos, Vulkan, en su actual versión 1.0.6, además de completar el proceso de adopción de EGL introduciendo las primeras librerías que dan soporte completo al servidor gráfico Wayland. Se cambia el patrón de instalación para hacer uso de las librerías GLVND GLX en lugar de las librerías GLX antiguas Se añade soporte inicial para DRM KMS (Direct Rendering Manager Kernel Modesetting) Esto significa la inclusión de un nuevo módulo nvidia-drm.ko, que se inscribe tanto con soporte PRIME como DRM KMS Se añade soporte para numerosas extensiones EGL EGL_EXT_platform_waylandencargada de hacer que aplicaciones Wayland corran en la implementación EGL de Nvidia EGL_WL_bind_wayland_displayencargada de hacer que compositores Wayland corran en la implementación EGL de Nvidia EGL_EXT_device_drm EGL_EXT_output_drm EGL_EXT_stream_consumer_egloutputPara permitir que los compositores Wayland muestren su contenido a través de EGLDevice, EGLOutput y EGLstreams. Se añade la librería libnvidia-egl-wayland.so, que permite a los compositores Wayland el uso de EGLDevice, EGLOutput y EGLstreams para compartir el buffer de EGL con las aplicaciones Wayland Suporte estable para la API Vulkan 1.0 Se mejora la precisión de X colormap desde 8 bits significativos a 11 en GPUs Geforce Se añade una nueva característica RandR, CscMatrix, la cual especifica una matriz de conversión de espacio de color de 3x4. Esta matriz se aplica después de X colormap y antes de gamma ramp. Es compatible con GPUs GF119 o más recientes. Así mismo se mejora el manejo de X gamma ramp en GPUs GF119 o más recientes. RandR gamma ramp cuenta siempre con 1024 entradas y ahora se aplica al cursor, VDPAU capas de estaciones de trabajo como añadido a la ventana de root de las Xs. Los registros del controlador de Nvidia han sido rediseñados con el nuevo subsistema DRM de Linux para dar soporte a PRIME. Como consecuencia de esto, es necesario contar con Linux 3.13 o superior para instalar esta nueva serie de controladores. Se mejora la interacción de aplicaciones que utilizan el cursor de hardware mientras G-SYNC está activo. Se incluye también soporte para nuevas GPUs GeForce 920MX GeForce 930MX Y, por supuesto, numerosos parches y correcciones Sobra decir que al margen de la ingente cantidad de novedades y mejoras, tanto Wayland como Vulkan son dos cosas que llevábamos mucho tiempo esperando y que por fin tenemos a nuestro alcance para sacarle todo su potencial. Nos queda aún el sabor agridulce por la falta de soporte a gráficas Fermi, esperemos que finalmente de parecer, pero igualmente hay que reconocer que, si bien no como a todos nos gustaría, Nvidia sigue siendo única a la hora de ofrecer soporte a los linuxeros más exigentes.
  11. Este año, como muchos sabemos, ha sido probablemente el punto álgido en la historia de GNU/Linux en lo que respecta a videojuegos. Hemos visto casi duplicarse el número de títulos nativos y "nativos" con respecto al años pasado, han sido lanzados Steam OS y Steam Machines, así como los esperadísimos periféricos de Valve, tenemos Vulkan, la nueva API gráfica del grupo Khronos a la vuelta de la esquina, Nvidia ha empezado tímidamente a abrirse con los desarrolladores de nouveau, AMD parece que por fin se ha comprometido en algo con AMDGPU... en definitiva, un año de grandes cambios que no han dejado indiferente a nadie. Sin embargo, como tantas veces hemos comentado, durante el mismo periodo, ahora mismo estamos en un punto de inflexión. Las cosas están cambiado para mejor, pero aún nos queda mucho camino por recorrer antes de cantar definitivamente ¡Victoria!. Los desarrolladores de Hardware, los problemas de la industria del videojuego, las horrendas políticas y decisiones de Microsoft, pero sobre todo la gran apuesta de Valve, han sido los detonantes que nos han llevado hasta donde estamos hoy. Este primer impulso, esta apuesta declarada y sincera, cual efecto dominó, ha hecho que poco a poco se vayan sumando y participando más estudios, portadores, desarrolladores, fabricantes, testers... una auténtica revolución digital que en breve supondrá un antes y después no sólo para GNU/Linux, sino para la industria del videojuego en General. Pero como ya dije, aún quedan muchísimas cosas por hacer y, por supuesto, grandes detractores que intentarán que no les pisen el negocio empleando para ello los medios que hagan falta. Debemos ser conscientes de cómo es la situación actual y, aunque muchos no podamos ser de gran ayuda, siempre podremos aportar nuestro granito de arena para ayudar a que sigamos avanzando. El estado de los juegos "nativos" para GNU/Linux Mucho se ha hablado de este tema, de hecho, no hace mucho que Ars Technica publicó un sesgado y manipulado estudio comparativo al respecto aclamando la supremacía de otro sistema que es el que mayormente paga sus facturas y que, si bien no podemos decir que es del todo falso, sí que hay que saber interpretarlo para poder sacar conclusiones coherentes a partir del mismo. EN primer lugar debemos tener en cuenta que la industria del videojuego, aunque parezca lo contrario, se mueve muy lentamente y aunque ya tenemos a nuestra disposición una nueva generación de hardware y consolas, los títulos con los que nos están abasteciendo siguen siendo más de la generación anterior que de esta. Los motores gráficos de "nueva generación", Unreal Engine 4, Cryengine 4, Unigine Engine 2, Source 2... apenas se han utilizado en un par de títulos o no se han usado en absoluto, por tanto, los desarrolladores de videojuegos que quieren expandirse a otras plataformas se ven en la tesitura de no contar con motores gráficos de antigua generación que no fueron diseñados con ese fin. Llegados a este punto hay varias opciones, actualizarse a los nuevos motores, rediseñar por completo el motor gráfico utilizado y optimizarlo para hacerlo funcionar con OpenGL o, la más recurrida, hacer alguna chapuza para salir al paso. Dado que los videojuegos que ya llevan unos años en el mercado no son susceptibles de ser rediseñados o recibir una actualización completa de su motor gráfico, la opción más clara para estudios y desarrolladores es realizar alguna chapuza que les permita conseguir su objetivo de ser multiplataforma sin perder demasiado tiempo y dinero en el intento. Incluso para los títulos lanzados recientemente o a punto de ser lanzados se cumple esto último, porque si bien son novedades, su desarrollo se remonta años atrás, cuando aún no se pensaba en el desarrollo multiplataforma. De hecho, en la industria actual existen vicios muy feos a la hora de desarrollar software, que podrían resumirse en: Trabajar únicamente para la plataforma más limitada/desfavorable y hacer ports y adaptaciones una sobre otra para el resto de las plataformas a las que se aspire. Es decir, que actualmente los usuarios de Play Station 4 ven títulos fresco y recién desarrollados para su plataforma, los usuarios de Windows reciben un port de esta versión, con sus limitaciones y sus chapuza y nosotros recibiríamos un tercer refrito de ésta última, sumando limitaciones de los dos anteriores o, en el caso de ser un título que también aparezca en OS X, cuyo soporte poara OpenGL es muy limitado, recibiríamos el 4º port extremadamente capado y limitado. Por mucho potencial que tenga GNU/Linux, por mucho que haya mejorado en tema de drivers, APIs, frameworks... la realidad es esta y hasta que la industria no se adapte a los nuevos tiempos tendremos que ser transigentes con algunas cosas y ser conscientes que en la mayoría de los casos no vamos a poder disfrutar de una experiencia 100% plena en comparación con otras plataformas. Irónicamente, dada la "calidad" de los desarrollos actuales muchas veces pasará desapercibido para la mayoría Dentro de los ports o adaptaciones tenemos un amplio abanico de posibilidades, entre los que destacan los siguientes: Ports realizados por el propio estudio Este tipo de adaptación es realizada por el propio estudio que desarrolló el juego originales, aunque no necesariamente por el mismo equipo de desarrolladores, y los medios empleados para realizar la tarea varían enormemente según el caso. Desde un equipo profesional completo dedicado a dicha tarea a contar con un único becario en prácticas que tiene que lidiar con todo el trabajo. Como ya dijimos antes, en ningún caso se llevará a cabo el rediseño del título para trabajar en una nueva plataforma bajo otras APIs, simplemente se modificarán las partes que sean necesarias y se utilizarán algunas capas de abstracción para aquellas donde no resulte rentable. Para esto existen herramientas como ToGL, IndirectX y otras muchas que ayudan a los desarrolladores a transformar las partes que ha sido diseñadas exclusivamente para DirectX en su equivalente OpenGL de manera sencilla y prácticamente automática. Evidentemente, aunque el resultado siempre serán binarios nativos, esta conversión no 100% eficaz y siempre tendrá un impacto mayor o menor en el rendimiento gráfico final. Un claro ejemplo de esto son los títulos de Valve, Left 4 Dead 2, Half Life 2, Dota 2... cuyas adaptaciones ha sido realizada por los creadores original y que ya nos han mostrado en más de una ocasión que su rendimiento incluso ha mejorado y ya en algún caso como Dota 2 se han atrevido a actuliazar el motor gráfico a uno de nueva generación. Pero insisto en que no siempre es así Ports subcontratados Esta es, sin duda, la opción más recurrida últimamente. Estaríamos ante la misma situación que en el caso anterior, un port nativo en el que se emplean algunas herramientas de conversión que no son del todo eficaces, pero que es realizado por un estudio que no tiene nada que ver con el desarrollo original. Este sería el caso de Feral Interactive, Aspyr Media o de grandes veteranos como Ryan Gordon o Timothee besset, que son subcontratados para obrar la magia de llevar un software a otras plataformas. Este método tiene sus ventajas, ya que son equipo de expertos que se dedican en exclusiva a este trabajo, pero al mismo tiempo ocurre que son personas al desarrollo original y están forzados a trabajar con código escrito por otros (cono todo lo que eso implica). En general este tipo de ports suelen ser bastante aceptables, no sólo por la experiencia que tienen los que lo realizan, sino porque una vez lanzado seguirán teniendo alguien que los respalde y corrija posibles problemas. Ejemplos en este caso tenemos Middle earth: shadow of Mordor, Grid Autosport, Alien Isolation, Sid Meier’s Civilization: Beyond Earth, Borderlands Pre sequel... títulos muy logrados que si bien no podemos esperar que estén 100% optimizados podemos estar seguros que al menos funcionaran bien y nos permitirán jugar de manera adecuada. Otro ejemplo opuesto de este tipo de ports lo tenemos con Batman arkham knight, un título que ha dado muchísimo de que hablar este año, no sólo por ser el cierre de la exitosa saga desarrollada por Rocksteady Studios, sino por haber sido portado a Windows de manera tan horrible y nefasta por Iron Galaxy Studios,que acabó siendo retirado del mercado, para ser relanzado recientemente en un estado no muy diferente al del primer port, que fue llevado a cabo desde un desarrollo exclusivamente PS4 (OpenGL) a WIndows (DirectX) y cuya adaptación para GNU/Linux iba a dejarse en manos de un tercer estudio, Feral Interactive, que ya ha dicho que no se ensuciarán las manos con semejante esperpento y seguirán trabajando a partir del original para intentar traernos una versión jugable, posiblemente durante el segundo trimestre de 2016. Este caso es posiblemente el más representativo que podemos encontrar de cómo funciona la industria a día de hoy y de lo que nos espera a corto/medio plazo hasta que la transición se complete. Ports ficticios Si bien ya he dicho que es muy raro ver un título realmente nativo para GNU/Linux y tenemos que resignarnos a contar con ports que son mayormente nativos pero con algunas chapuzas, en este último caso hablamos directamente de títulos que no son ports en absoluto. Otro de los métodos a los que recurren los grandes estudios a la hora de llevar su software a otras plataformas consiste en no esforzarse en absoluto por ofrecer software nativo y en lugar de ello utilizar Wrappers que hagan de intermediarios entre su software original sin modificar y la plataforma en la que quieren ejecutarlo. Sé que esto puede resultar un poco complicado de entender, pero creo que puedo resumirlo en única palabra de tal manera que todo el mundo lo entienda. WINE. No obstante, aunque es un clásico encontrar aplicaciones que dicen ser nativas y que venden como tal y que al observarlas se ve claramente como corren sobre una versión muy concreta de Wine, en la industria del videojuego quien se está encargando de esto es un Wrapper muy similar desarrollado por Virtual Programming llamado eON. Si bien para el estudio es una forma rápida y barata de llevar su software a otras plataformas y, al igual que con Wine, hay casos en los que las cosas parecen funcionar bien, lo más habitual es que este tipo de estrategias se caractericen por sufrir todo tipo de errores extraños, crasheos, fallos inexplicables y una experiencia de juego... digamos que "sorprendentemente entretenida e imprevisiblemente cautivadora" :lol: Es aquí donde debemos plantarnos y decir NO. Antes dije que había que ser algo transijentes dada la situación actual y apoyar a aquellos que hacen un esfuerzo por traernos software nativo a la plataforma del Ñu y el Pingüino. Sin embargo estaremos de acuerdo en que esto último no sólo no es un esfuerzo, sino que es directamente un engaño, por tanto no deberíamos ser partícipes para que no se perpetúe esta tendencia. Por mucho juegos que de manera "rápida" podría suponer para nosotros, el coste a pagar es demasiado elevado. Queremos juegos, sí, pero juegos con un mínimo de calidad. El renacer de las APIs gráficas Hemos hablado largo y tendido durante el último año sobre Vulkan, la API gráfica abierta, multiplataforma y a bajo nivel del grupo Khronos, que llega para sustituir a la veterana OpenGL con la intención de llevar los desarrollo gráficos al nivel tecnológico actual. Capacidad para exprimir aún más el hardware para obtener mejor rendimiento, desarrollos más sencillos, multiplataforma, bajo un estándar abierto ideado por los pesos pesados de la industria partiendo de la idea original que tuvo AMD con Mantle. Smartphones, consolas, televisores, PCs... todos se beneficiarán de este salto de gigante en lo que respecta a la industria de los gráficos renderizados por ordenador. Pero volvemos a lo mismo que hemos estado tratando desde el principio. Estamos en punto de inflexión donde todo está cambiando, pero aún no lo ha hecho. Vulkan no llegará mañana, ni dentro de un mes ni de dos, será una transición lenta y paulatina que terminará con el nacimiento de una nueva industria, nuevas formas de desarrollo y software que responderá a esta nueva tendencia, para bien o para mal, aunque todo apunta a que el cambio será positivo. Pero para eso, aún tendremos que esperar un poco más Los principales implicados Sin duda alguna quien dio el empujón definitivo que hacía falta para que todo esto ocurriera y que ha invertido muchísimo en GNU/Linux, al punto de crear su propia distribución, Steam OS y empezar a comercializar equipos destinados a jugar desde GNU/Linux, Steam Machines, a todo el catálogo disponible en su tienda de distribución digital de videojuegos Steam. El lanzamiento, que se produjo durante el pasado mes de Noviembre, fue bastante silencioso y, al mismo tiempo, fue salpicado por la polémica suscitada por muchos medios tecnológicos que distan mucho de ser imparciales y/o profesionales. Lo cierto es que tanto Steam OS como las Steam Machines acaban de nacer y aún nos queda mucho antes de ver cómo se hacen un hueco en el mercado. Aún así y a pesar de todo, las ventas ventas tanto de equipos como de periféricos han sido realmente buenas, lo que se opone frontalmente a lo dicho por tantos detractores. Otra cosa que he podido observar, que se repite mes tras mes desde hace dos años y que demuestra que el ser humano es el único animal que tropice no dos, sino inumerables veces con la misma piedar, son los artículos haciendo referencia a una ficticia cuota de mercado de jugadores linuxeros que ¡Fíjate que curiosa, sorprendente y cruel casulidad del destino! Se ha mantenido inamovible en el 1%. Hace tiempo que Valve respondió a esto de una manera clara, pero parece que muchos siguen sin enterarse y lo utilizan como dato significativo para justificar, probar o desmentirr las más disparatadas teorías. Lo cierto es que los datos que se recogen en las estadísticas de Steam son puramente anecdóticos y no pueden ser tomados al pie de la letra. La recopilación de datos se realiza de manera aleatoria a modo de "sondeo" que busca hacerse una idea de las especificaciones de los equipos de los jugadores que utilizan regularmente Steam, por lo que la inmensa mayoría de los usuarios de Steam no han sido jamás incluidos y su hardware/software es, tanto para Valve como para nosotros, un misterio. Al mismo tiempo, la propia compañía ya confirmó que, en lo que respecta a la parte específica para GNU/Linux, esto iba aún más allá y, aunque han hecho varios intentos, no han conseguido una manera eficaz de "medir" a los usuarios linuxeros, dada la inmensa variedad de distribuciones, configuraciones, versiones, etc, por lo que la mayoría de los linuxeros que, por casualidad, son contabilizados, finalmente tampoco acaban apareciendo representados en las estadísticas. Las estadísticas directas de venta tampoco son fiables, dado que están sujetas a muchísimas variables, juegos comprados antes de contar con versión nativa para GNU/Linux no cuentan, si han sido jugados durante X tiempo en otra plataforma, tampoco, si se obtuvieron a través de un medio ajeno a Steam y luego autentificados en éste tampoco les es posible saber dónde tenías pensado jugarlo al comprarlo... En definitiva, es triste ver como después de 24 años todavía sigamos erre que erre con el cuento del 1% Ampliamente conocida por todo linuxero amante de los videojuegos, la californiana es, por desgracia, la única que a día de hoy permite disfrutar en GNU/Linux de los títulos de última generación. Si bien lo hace a través de software mayormente privativo, algo que no nos agrada demasiado, es una compañía que casi siempre cumple en cuanto a rendimiento, especificaciones, soporte y la adopción temprana de nuevas tecnologías, al punto de asimilarlas antes de ser anunciadas oficialmente. Al mismo tiempo, su carácter cerrado hace que no se integre del todo en el ecosistema linuxero, tanto a nivel de usuario como entre los desarrolladores, aunque parece que durante los últimos años ha empezado a volverse más abierta, pero de manera tímida y principalmente en lo que respecta a su gama de procesadores Tegra y no tanto a sus series de escritorio Geforce y Quadro. Si bien es cierto que los precarios controladores gráficos libre Nouveau han avanzado mucho en el último año gracias a varios aportes de la propia Nvidia, a'un nos queda mucho camino por recorrer. Seguimos ante una propuesta privativa, con todo lo que ello implica, pero sin duda alguna, a la hora de rentabilizar una gran inversión como lo es una tarjeta gráfica dedicada, por ahora sigue siendo nuestra única opción. Si bien Intel se limita a ofrecer gráficas integradas en sus procesadores que no se acercan ni remotamente al rendimiento que pueden ofrecer las GPUs dedicadas, su caracter Open Source es de sobra conocido por los linuxeros que no tienen grandes necesidades a nivel de gráficos y pueden desarrollar su actividad diaria con este tipo de gráficas sin ningún problema de soporte. Los controladores para este tipo de Hardware no están a la vanguardia en cuanto a tecnología o especificaciones OpenGL, pero es que tampoco hace falta dado el uso al que están destinadas. Eso sí, al igual que Nvidia, el soporte para Vulkan está más que asegurado antes de su salida. Nos adentramos en un terreno inhóspito que hará que se levante más de una ampolla y que tampoco podremos tratar en profundidad porque no acabaríamos nunca. AMD ha sido, durante mucho tiempo, el patito feo para todos los linuxeros. Controladores privativos ineficientes a la par que problemáticos, carentes de opciones, que llegan tarde y mal, que descontinúan series relativamente recientes de hardware muy temprano dejando a sus usuarios con un palmo de narices... y una contraparte de controladores libres muy trabajados por parte de la comunidad pero que no se acercan a brindarnos el rendimiento y características que esas GPUs podrían darnos. Muchos años de mal soporte, de tener que estar saltando entre controladores privativos y libres para aspirar a poder ejecutar un tipo de aplicación u otra, de sufrir con cada salida de una nueva versión de X.org o del propio Kernel Linux por no tener soporte hasta meses o incluso años después... han sido las razones por las que, la mayoría de los linuxeros que quieren disfrutar de la experiencia de juego nativa en la plataforma de Ñu y el Pingüino, no tocarían una gráfica AMD ni con un palo. Durante el último año también han cambiado muchísimo las cosas para AMD y se ha hablado largo y tendido de su nueva propuesta, los Controladores AMDGPU, una apuesta de unificación de esfuerzo entre desarrolladores libres y privativos que viene a cambiar las cosas o, al menos, eso es lo que nos han dicho. No obstante, esto ha llegado tarde, muy muy tarde, y si en el mundo de los videojuego estamos antes un inminente cambio, en lo que respecta a AMD aún estamos empezando. AMDGPU implica grandes cambios, pero también la ruptura definitiva entre lo moderno y lo antiguo. Sólo las gráficas de nuevas generación y las que salgan a partir de ahora podrán aspirar a beneficiarse de las bondades de los nuevos controladores, algo que a priori tiene mucha lógica desde el punto de vista del desarrollo, pero que para los usuarios cuyos equipos tengan más de año y medio les sentará como una auténtica puñalada. Así todo y aunque el nuevo enfoque de los controladores de AMD supone un antes y un después, facilitará muchísimo las cosas en todos los aspectos y unificará esfuerzos, seguimos sin saber si ciertos problemas de siempre podrán o no solucionarse, entre ellos el pobre rendimiento de estas gráficas en GNU/Linux. La unificación supone mejora, sí, pero si hasta ahora ninguna de las dos partes ha conseguido un rendimiento óptimo ¿Se conseguirá con AMDGPU? Otro punto donde también ha supuesto una desilusión para usuarios y gamers es, precisamente Vulkan. AMD ya confirmó que la nueva API gráfica no será soportada den entrada por los nuevos controladores y que el soporte llegará inicialmente a través de los Catalyst (Crimson) de manera tardía y, posteriormente, comenzarán los trabajos para incorporarlo al controladores unificado. Puede sonar confuso, incongruente o incluso contradictorio, pero como ya dije antes, esto acaba de empezar y ahora mismo hay muchísimas más dudas que respuestas y, si para otras cosas que ya llevan años de desarrollo detrás aún vamos a tener que esperar, en el caso de AMD y su prometedora propuesta de futuro, la espera será aún mayor. En el caso de las APUS, si bien no serán tan fáciles de domar como las Intel, los controladores libres siempre estarán ahí para echarnos una mano y, dado que no le pedimos grandes cosas, la falta de rendimiento y características puede pasar un poco desapercibidas para usuarios de a pie. Sin embargo, a la hora de plantearse invertir una gran suma de dinero esperando obtener a cambio un rendimiento acorde... las Radeon siguen sin ser una alternativa viable y no parece que vayan a serlo en un futuro cercano. Reflexión ¿Final? Si han llegado hasta aquí, tendrán el mismo sabor agridulce que tengo yo mientras escribo esto, pero tampoco puedo maquillar las cosas para hacer ver que estamos en los mundos de Yupi o en el más profundo y frío abismo, lo cierto es que estamos justo en medio, sufriendo una dolorosa pero necesaria transición que no sabemos cuánto llevará, pero que apunta a que será algo muy positivo para la industria, para los usuarios en general, pero sobre todo para GNU/Linux. Nos quedan un par de años de incertidumbre, de grandes alegrías y tristes decepciones que nos llevarán finalmente hasta una estabilidad que esperamos que sea la que todos deseamos. Lo que no se puede negar es que el avance qe podemos apreciar hasta el momento en todos los frentes es, simplemente, espectacular, así que hagamos lo que buénamente podamos para que sigamos avanzando en el mismo sentido, aunque no sea aportando fondos o código, simplemente apoyando a quienes nos apoyan y condenando lo que haya que condenar para que las cosas mejoren. Y por último y más importante, sean críticos y no se crean la mayoría de las cosas que les cuentan, especialmente si provienen de cierto perro forero linuxero que no hace más que desvariar
  12. Saludos. Me sucede lo siguiente: Me construí un controlador, un joystick doble de arcade para jugar al mame32, siguiendo este proyecto: http://vusb.wikidot.com/project:mamepanel Está terminado y funciona perfecto en una máquina con Windows, pero no lo construí para eso, la idea era hacerlo funcionar bajo Linux en una raspberry pi 2. Y bien, bajo Linux no reconoce los 2 joysticks del controlador, es como si solo tuviera un joystick, como si los 2 furan el mismo. He probado con diversas compliaciones de raspbian + paquete de emuladores, Retropie, Piplay…pero siempre obtengo el mismo problema, solo reconoce un joystick, y he leído que el problema se va a dar en cualquier Linux. Encontré una publicación de un tipo que tuvo el mismo problema y consiguió darle solución, aquí: http://myprojectsweblog.blogspot.com.es/2011/10/mamepanel-with-linux.html# La operación consiste en bajarse las fuentes del Linux, y hacer una modificación en un archivo que si no he entendido mal pertenece al módulo de drivers, después hay que recompilar el módulo. Bien yo he conseguido llegar hasta el paso de recompilar con la orden “make”, ahí no soy capaz de seguir, me da un error de directorio incorrecto, o bien el error “no rule to make target”, en cualquier caso soy incapaz. He estado unos cuantos días buscando información sobre como recompilar un módulo del kernel con la orden “make”, pero no he conseguido comprender del todo la orden, y que determina cada ruta, he realizado varias pruebas e intentos sin resultados. Soy muy novato en Linux, y la verdad, estoy un poco perdido, no se que se me está escapando. He tenido que usar el comando apt-get en vez de aptitude, descargar los Linux-headers-3.2 en vez de los que te indica la web (de la solución) y algunas modificaciones al proceso, (la versión de la compilación de Linux que uso es 4.1.7-v7+) pero básicamente y de momento mis problemas están en la orden make, que no termino de comprenderla del todo, de ahí no paso, y no sé si he podido hacer algo mal en algún paso previo. Me vendría muy bien una ayudita. Gracias de antemano.
  13. Hemos hablado largo y tendido sobre Vulkan, la API gráfica abierta del grupo Khronos que será el futuro de los gráficos generados por ordenador y que, según sus integrantes estará finalmente entre nosotros antes de que acabe el presente año. Mucho se ha hecho de rogar, aunque hay que comprender que una API multiplataforma que sea verdaderamente un estándar, funcione en cualquier dispositivo, asegure cierta retrocompatibilidad y nos brinde todas las ventajas en rendimiento que tanto hemos oído no es una tarea sencilla ni mucho menos. Se han sucedido los eventos y conferencias donde nos han puesto los dientes largos con charlas y demostraciones en vivo muy prometedoras, pero hasta seguíamos a la espera, sin saber cuándo podríamos por fin empezar a beneficiarnos de las ventajas de Vulkan. Tanto Intel como Nvidia han asegurado soporte desde el primer día para la API en GNU/Linux, pero parece ser que ni siquiera ellos pueden contener la emoción y la última versión de la serie 358 de Nvidia ha abierto la veda de Vulkan, añadiendo referencias, librerías y funciones relacionadas con dicha API. Los nuevos controladores 358 incluyen un gran número de librerías VK (vulkan Api), Pascal y Volta. Aunque por ahora sólo conocemos los cambios referentes a la versión para Windows (358.66), como viene siendo habitual, los controladores para el resto de plataformas llegarán en los próximos días. Sin bien estamos ante una noticia a medias, pues no tenemos nada concreto sobre Vulkan aún, tanto movimiento por parte de los fabricantes sólo puede hacernos pensar que debemos estar ya muy cerca del lanzamiento http://forums.laptopvideo2go.com/topic/31826-nvidia-geforce-driver-35866-adds-vulkan-pascal-and-volta-support/
  14. Nvidia sigue trabajando sin descanso para que sus controladores oficiales tengan pronto soporte completo para Wayland. Durante la serie anterior, la 355, ya dimos cuenta dew todas las mejoras en lo que respeta a EGL y la nueva forma de construir los módulos para el Kernel. Ahora, con la beta de la nueva serie 358 vemos otro paso más para acercarnos a Wayland. Esta vez se han centrado en la interconexión con DRM/KMS, añadiendo el nuevo módulo nvidia-nomodeset para trabajar en tandem con el módulo del kernel, usádolo como base para la interface mode-setting provista por el administrador de renderizado directo del kernel. lamentablemente y aunque son muy buenas noticias, esto sigue siendo un paso más y aún tendremos que esperar un poco más para que Wayland sea una pieza central de nuestra distribución GNU/Linux, al menos en el caso de utilizar una gráfica de Nvidia. Por supuesto, éste no ha sido el único cambio que vemos en los nuevos controladores: Se ha corregido una regresión que afectaba al rendimiento de OpenGL en configuraciones de X server sin monitor. Se ha corregido una fuga de memoria que se producía cuando se destruía una ventana GLX que seguía teniendo el contexto asociado. Se ha corregido un error que provocaba la creación de buffers de píxeles de EGL en el buffer frontal y el posterior en lugar de hacerlo únicamente en el posterior, como requiere EGL. Se ha añadido un nuevo módulo de kernel, nvidia-modeset.ko. Este nuevo componente del driver funciona en combinación con el módulo nvidia.ko para programar el motor de visualización de la GPU. nvidia-modeset.ko no proporciona ninguna funcionalidad visible para el usuario, ni interfaces con aplicaciones de terceros. Sin embargo, en una versión futura, este módulo servirá de base para la interfaz de configuración del modo de pantalla (modesetting) proporcionada por el gestor de renderizado directo (DRM) del kernel. Se han reducido los parpadeos y los retardos en las transiciones hacia o desde el modo G-SYNC. Como parte de este cambio, a partir de ahora los monitores que tengan indicadores de G-SYNC en la pantalla indicarán que se encuentran en modo G-SYNC. El indicador visual de G-SYNC en OpenGL puede activarse en nvidia-settings para señalar cuándo se está utilizando G-SYNC. El protocolo GLX de la siguiente extensión de OpenGL 3.0 ha pasado de ser un protocolo no oficial a ser un protocolo aprobado para ARB: GL_EXT_draw_buffers2 El protocolo GLX para los siguientes comandos de OpenGL 3.0: BindBufferRangeNV BindBufferBaseNV BeginTransformFeedbackNV EndTransformFeedbackNV GetTransformFeedbackVaryingEXT TransformFeedbackVaryingsEXT que forman parte de las siguientes extensiones: GL_NV_transform_feedback GL_EXT_transform_feedback ha pasado de ser un protocolo no oficial a ser un protocolo aprobado para ARB. Con los cambios anteriores, el protocolo GLX para OpenGL 3.0 ha pasado de ser un protocolo no oficial a tener la categoría de protocolo oficial para ARB. Se ha añadido un nuevo mecanismo de asignación de memoria para asignaciones de gran tamaño en el controlador de OpenGL. Este mecanismo permite liberar la memoria asignada al proceso cuando no se utiliza, lo que deja más espacio de direcciones virtuales disponible para la aplicación. Está activado de forma predeterminada en aplicaciones OpenGL de 32 bits con Linux 3.11+ y glibc 2.19+. La memoria asignada de esta manera consume espacio en /dev/shm. Esta función se inhabilita configurando la variable de entorno __GL_DevShmPageableAllocations con el valor 2. https://devtalk.nvidia.com/default/topic/884727/linux-solaris-and-freebsd-driver-358-09-beta-/?offset=1
  15. Hemos pasado meses oyendo hablar sobre Vulkan a través de las conferencias de numerosos fabricantes y desarolladores, a excepción de AMD que había permanecido en silencio, hasta ahora. La XDC2015 de Toronto ha sido el escenario propicio para que los californianos nos pongan al día sobre sus planes de futuro acerca de Vulkan y su nuevo concepto de controladores AMDGPU. Según nos cuentan están trabajando en optimizar el planificador GPU, nuevos componentes para el administrador de energía (para gráficas Volcanic Island) y de pantalla, así como el soporte para nuevo Hardware. Otro de los objetivos es que las partes relacionadas con Vulkan y OpenCL, que al parecer ya existen y utilizan DRI3, pasen a ser Open Source, aunque esto último no se hará de entrada sino de forma paulatina. A pesar de que se esperan numerosas e interesantes actualizaciones para los controladores AMDGPU, apenas hay cambios en cuanto a plan original que ya conocíamos en lo referente al Hardware. Las series actuales y antiguas de AMD no serán soportadas, sólo a partir de la arquitectura Tonga y APUS Carrizo o posteriores. Aunque tras conocer algunos detalles más sobre los planes de futuro de AMD, nos vamos con más dudas que respuestas, es interesante ver este cambio de rumbo hacia una estrategia más colaborativa y abierta entre la comunidad de desarrolladores libres y AMD. Esperemos que éste sea ya, por fin, el punto de inflexión que nos haga pasar del paupérrimo soporte ofrecido hasta ahora para los usuarios linuxeros a poder tener los merecidos controladores eficientes y capaces que llevamos tantos años esperando. http://www.x.org/wiki/Events/XDC2015/Program/deucher_zhou_amdgpu.pdf
  16. Hace muy poco hablamos del lanzamiento de la nueva serie de controladores privativos de Nvidia y de cómo iba a suponer un gran cambio en cuanto a cómo se compilan y construyen los módulos del kernel. Hay ha sido liberada la primera beta y, además de lo que ya sabíamos, con ella han llegado grandes novedades. El soporte a EGL está totalmente acabado y se añade como "experimental, lo que nos hace estar a un paso de poder disfrutar de Wayland con soporte oficial por parte de Nvidia. Además, ya se dejan ver algunas librerías "sospechosas" como puede ser libnvidia-egl-wayland.so. Las mejoras para vdpau ocupan el tercer lugar en la lista de novedades destacadas de esta serie: Se ha corregido un error por el que los datos de nivel de textura podían sobrescribir los del nivel inmediatamente inferior en vistas que no incluyesen el más alto de los dos niveles. Se ha corregido un error que podía provocar el bloqueo del panel de control de nvidia-settings al actualizar la disposición de pantallas. Se han corregido algunos informes erróneos sobre el soporte de las extensiones GLX: según los informes, era posible usar algunas extensiones para renderizado GLX indirecto, cuando en realidad solo se admiten para renderizado directo. Se ha añadido soporte para las siguientes extensiones de EGL:EGL_KHR_swap_buffers_with_damage EGL_NV_stream_consumer_gltexture_yuv Se ha sustituido el sistema de compilación de los módulos de kernel de NVIDIA y se han actualizado el paquete de instalación y el programa nvidia-installer de forma que utilicen el nuevo sistema de compilación y organización del código fuente de los módulos. Para obtener más información sobre el nuevo sistema de compilación y organización del código, consulta el archivo README en la dirección:ftp://download.nvidia.com/XFree86/packaging/linux/new-kbuild-for-355/ Se ha añadido a EGL soporte completo de OpenGL de forma experimental. Se ha marcado la opción DeleteUnusedDP12Displays como obsoleta.La versión 1.5.0 de la especificación de RandR (Resize and Rotate) de X contiene una nota por la que las salidas generadas de forma dinámica no se destruyen. Por tanto, esta opción ha quedado obsoleta y se suprimirá en futuras versiones del controlador. Se ha añadido soporte para los perfiles de VDPAU incorporados a VDPAU 0.9:VDP_DECODER_PROFILE_H264_BASELINE VDP_DECODER_PROFILE_H264_CONSTRAINED_BASELINE VDP_DECODER_PROFILE_H264_EXTENDED VDP_DECODER_PROFILE_H264_PROGRESSIVE_HIGH VDP_DECODER_PROFILE_H264_CONSTRAINED_HIGH Se ha corregido un error que impedía a más de una salida de RandR compartir modos añadidos por el usuario. Se ha corregido un error por el cual, al usar Xinerama, no se tenían en cuenta los intervalos de intercambio (swap) especificados en la aplicación para algunas pantallas. Se ha corregido un error por el que los modos de RandR suministrados por el usuario con combinaciones imposibles de los indicadores +HSync, -HSync, +VSync y -VSync dañaban la lista de modos. Se ha añadido la posibilidad de convertir un contexto de OpenGL (de la versión 3.0 adelante) en el contexto actual sin vincularlo a un objeto dibujable (drawable). https://devtalk.nvidia.com/default/topic/862392/unix-graphics-announcements-and-news/linux-solaris-and-freebsd-driver-355-06-beta-/
  17. A pesar de encontrarnos aún en temporada estival, parece que el incansable grupo de desarrolladores que trabajan en el kernel libre que Linus Torvalds compartió con el mundo hace ya casi un cuarto de siglo, no descansan ni para mojarse los tobillos en la orilla del mar, porque Linux 4.2 ya está con nosotros. Aunque muchas cosas han quedado pendientes para la próxima versión 4.3, nos encontramos ante una versión del kernel como muchas e interesantes novedades tanto en el apartado gráfico como en sistemas de ficheros, criptografía y otrso muchos aspectos. El driver AMDGPU DRM por fin ha sido incluido, con soporte para las Radeon R9 285 "Tonga" y las que aparecerán en el futuro, incluyendo las APUs Carrizo. Codificación de vídeo VCE1 para el controlador Radeon DRM Numerosos cambios más relacionados con DRM Atomic mode-setting Mejor manejo de DisplayPort MST Soporte para Adreno A306por parte del driver MSM DRM [*]Driver VirtIO GPU [*]Soporte inicial para los Intel Broxton Atom [*]El código relacionado con x86 sigue su preparación para ser reescrito en C, con miles de microoptimizaciones y mucha limpieza de código [*]Soporte para nuevos procesadores y placas ARM Freescale i.MX7D ZTE ZX296702 HiSilicon hi6220 [*]Soporte para la arquitectura del microcontrolador Renesas H8/300 [*]Por fin se incluye qspinlocks (queue spinlocks) gracias al trabajo de HP [*]Mejoras en el compensado NUMA y planificador deadline [*]Numerosas mejoras para KVM (Kernel-based Virtual Machine), incluyendo, write combining, virtualized performance counters en AMDo la integración VFIO en ARM. [*]Soporte para los procesadores ARCv2 y HS38 [*]Mejoras en encriptación Akcipher (Asymmetric Key Interface) soporte para algoritmos Chacha20, Poly1305 y RFC7539 DRBG es ahora la API criptográfica RNG por defecto Nueva implementación RSA Jitter entropy RNG Soporte para SHA-512 acelerado en ARM64, [*]Mejoras en NCQ TRIM y habilitación/&deshabilitación automática para SSDs con peor soporte [*]Mejoras de rendimiento para GFS2 [*]Numerosas correcciones para EXT4 [*]F2FS per-file encryption [*]Actualizaciones y mejoras para BTRFS [*]Soporte DAX para XFS [*]Comienzan los trabajos para mejorar la scalabilidad de FUSE [*]Soporte para ACPI 6 NV-DIMM (Non-Volatime Memory Device) y otras mejoras en el manejo de energía [*]Soporte para nuevos periféricos: Logitech M560 Sony Motion Controller Sony Navigation Controller de PlayStation 3/4 Weida WDT87XX touch-screen Ahora duncionan correctamente los LEDS del controlador inalámbrico de Xbox [*]Soporte para UEFI ESRT (EFI System Resource Table) [*]Mejoras de rencimiento para NBN (non-transparent bridging) Como siempre, el código fuente está ya disponible en Kernel.org Y una lista más detallada de los cambios y mejoras estará disponible en breve en Kernel Newbies
  18. Buenas tardes, como algunos sabreis hace un tiempo cambie mi grafica por una flamante strixx gtx960 de asus. al grano, mi principal problema es que el soporte para estas graficas y superiores no llego al driver privativo de nvidia hasta la version 346. por lo que el metodo de instalacion del driver usando la paqueteria de debian, no me funciona. hasta ahora, es un problema que siempre he solucionado con "liquorix" mediante el script "sgfxi". que me descarga la version mas reciente del controlador actualmente (352.30) creo recordar. que me ha estado funcionando bien hasta hoy. hoy, lidiando nuevamente con la paqueteria de testing, para terminar de corregir dependencias insatisfechas que aun me quedaban en mi plasma 5, se me ha actualizado el kernel de liquorix...(sin darme cuenta), cuando he querido reiniciar, ya no tenia entorno grafico. siempre que se me actualiza el kernel, me toca volver a ejecutar el script de liquorix, para volver a cargar el driver de nvidia, y hasta hoy no habia tenido muchos mas problemas. apesar de que en su dia, quite el repositorio de liquorix para que no se me actulizase mas el kernel, unas semanas despues lo volvi a añadir, utilizando la rama "sid-past" que se supone que es mas estable y liberan cada mas tiempo. el caso es que hoy, se me actualizo el kernel, y por mas que le intento instalar el driver de nvidia con liquorix, me encuentro siempre con el promp, y aunque lance "startx", lo unico que obtengo es un error del servidor grafico, que no ha podido iniciar. me he tirado toda la mañana cacharreando, intentando meter nouveau, intentando instalar el driver a mano, pero nada...no soy capaz. no se me ocurren mas cosas para seguir probando. lo que si que tengo seguro es que solo puedo usar un driver actual. los de debian no me valen, tambien pense en instalar el driver de nvidia proviniendo de sid "backports". pero eso aun no he sido capaz de hacerlo. en resumen es que me niego a formatear el equipo, cuando se que con el driver nuevo de nvidia me funciona perfectamente, pero no se como "resetear" liquorix y volver a empezar, o instalar el driver a mano....todo lo que he probado no ha funcionado. un saludo y gracias por leeros esto, no se me da muy bien expresarme y se que soy algo confuso explicando las cosas PD: NO VOY A INSTALAR UBUNTU PARA USAR SUS DRIVERS O SU INSTALADOR DE DRIVERS, para eso sigo teniendo mi antergos que funciona perfectamente con su ultima version del driver de nvidia. quiero arreglar mi debian. PD2: en mi empeño por usar los controladores de los repositorios de debian, con el procedimiento de instalacion de debian, he buscado los paquetes en la rama sid (unstable) y mi sorpresa (https://packages.debian.org/search?keywords=nvidia&searchon=names&suite=unstable&section=all) pues que a pesar de estar en la maldita rama SID, el controlador que manejan es 340....NO LO ENTIENDO! se supone que SID es lo mas actual e inestable y de repente veo el driver en la version 340???? decirme que me estoy equivocando, porque no doy credito a lo que veo!! PD3: vale, veo que que los paquetes que me podria servir se encuentran en "experimental" https://packages.debian.org/search?keywords=nvidia&searchon=names&suite=experimental&section=all, concretamente la version 352.30 que creo que es la misma que me instala liquorix. ahora, antes de meter yo la pata hasta el fondo con mis "cacharreos", como fuerzo la instalacion del driver de nvidia, de los repositorios "experimentales" de debian? Gracias a todos!
  19. Y aquí estamos otra vez con el consabido dilema. Después de una instalación limpia de Xubuntu 15.04, y por limpia me refiero a LIMPIA de verdad, pues esta vez han ido las dos particiones por el aire para no "arrastrar" nada. Me encuentro delante de la pantalla que más disgustos me ha dado siempre: ¿Me quedo con los Nouveau que funcionan bien y me olvido de problemas en futuras actualizaciones del kernel, pero perdiendo la posibilidad de jugar decentemente? ó ¿Me lanzo a la aventura y marco la casilla de los 346.59 (privativos, probados), para jugar (muy ocasionalmente) a algún juego de Steam, etc. pero perdiendo la salud y el poco pelo que me queda cada vez que vengan nuevas cabeceras?. Me está dando cierto respeto por cosas como esta: http://askubuntu.com/questions/614128/15-04-and-nvidia-login-loop Gracias y un saludo compañeros.
  20. Shiba87

    Linux ya es 4.0

    Linus Torvalds y su alergia a los números grandes han hecho que tras Linux 3.19 nos encontremos ante una salto de versión hasta la 4.0, que como era de esperar, no es sólo un número, viene con un gran número de mejoras y nuevas características, además de un nombre en clave bastante desconcertante. Linux 4.0 (Hurr durr I'ma sheep.) nos trae: Live kernel patchin. Gracias al trabajo de Red Hat en Kpatch y SUSE en kGraft, tenemos la posibilidad de aplicar parches en vivo . El controlador Radeon DRM cuenta ahora con soporte para audio sobre DisplayPort y mejor control de los ventiladores El controlador AMDKFD para soporte HSA empieza a dar soporte a las APU Carrizo Soporte inicial para el hardware gráfico Intel Skylake Los controladores Nouveau incluyen ahora soporte básico para re-clocking soporte para la GPU Tegra GK20A y se fusiona con el código para ARM, además de otros muchos cambios internos. En el caso del controlador DRM para las NVIDIA Tegra se añade soporte para atomic mode-setting y se mejora el desempeño al la suspender y restaurar alguno de estos dispositivos. Soporte para pNFS block server Mejora a la hora de crear RAID 5 y 6 con Btrfs Nueva funcionalidad OverlayFS Soporte para Intel Quark SoC Soporte para nuevo hardware ARM Soporte para IBM z13 Mejora en el soporte para los portátiles Toshiba Mejoras en el soporte de los dispositivos Logitech HID++ Como es habitual podemos descargar el código fuente de esta nueva versión desde Kernel.org y consultar en detalle todos los cambios a través del portal Kernel Newbies
  21. Como siempre, cuando me da por escribir algo aquí es porque estoy muy mal de lo mío o el fin del mundo se acerca así que mejor pónganse cómodos Hace tiempo observé un comportamiento peculiar de mi tarjeta gráfica al hacerle pasar benchmarks como el Unigine Valley. Dado que era algo tan concreto y no se presentaba en ningún otro momento ni era reproducible fuera de ese benchmark acabé por echarle la culpa al propio Unigine engine o específicamente al Valley. Recientemente estaba probando el Principle Of Talos y al pasar el Benchmark que aparece al terminar la versión Test, el viejo incordio ha hecho de nuevo acto de presencia y dado que aquí no hay Unigine por ninguna parte hay que empezar a replantearse las cosas. Tras probar con diferentes versiones de Linux y todas las series de Drivers con soporte para la GTX 560 Ti (desde la 304 hasta la 343), no hay gran variación al respecto, rendimiento mejor o peor, un poco antes o un poco después pero el problema sigue apareciendo. Para que nos entendamos bien trataré de explicarlo (No se asusten que también he hecho un vídeo, se pueden saltar mis desvaríos si quieren ). En un momento dado, mientras va avanzando el benchmark o mientras nos movemos nosotros dentro del entorno que nos ofrece, el rendimiento sufre un bajón importante hasta quedarse en apenas ~4 FPS o incluso menos. Esto no sería un hecho muy relevante , pues puede pasar que la gráfica toque techo en algún punto del benchmark, que para eso es, si no fuera por lo que ocurre a continuación y es que después de caer, ya puede terminar esa o puedes cancelar el Benchmark para que vuelva al principio que la gráfica NO se va a recuperar, seguirás con ~4 FPS aunque no te muevas en absoluto o pongas la cámara mirando a una piedra del suelo, si no cierras el benchamark o lo obligas de alguna forma a recrear la imagen en pantalla (cambiando resolución, calidad, etc) no habrá nada que te saque del mundo de las fotos paisajistas entrecortadas. Ninguno de los juegos (salvo el mencionado, claro ) que he probado han conseguido reproducir este error. Eso me hace pensar que.. bueno... hasta ahora los desarrolladores se han estancado con OpenGL 3 sin apenas florituras, mientras que los benchmarks tiran de las últimas versiones de OpenGL 4, hacen uso de la teselación... pero en ese sentido quiero recordar también que hace no mucho probé (y el vídeo está por alguna parte) los benchmarks de Unreal Engine 4 y con esos no pasa nada parecido, así que dicho de manera cortés y delicada, no tengo ni puta idea de qué cojones le pasa a esta mierda . Alguna "cosilla" he visto en devtalk, pero vamos, como si no hubiera encontrado nada https://devtalk.nvidia.com/default/topic/529521/linux/lasting-reproducible-frame-rate-drop-to-7fps-on-gtx-560-ti-313-18-driver/2/ ¿Ideas?¿Sugerencias?¿Teorías?¿No le pidas teselación y OpenGL 4 a una gráfica de 2011?
  22. Hace un par de semanas Nvidia comenzó a trabajar en una nueva línea de controladores 343.x que hasta ahora se encontraba en estado Beta. El reciente lanzamiento de la nueva línea de tarjetas gráficas, la segunda generación Maxwell, concretamente la Geforce 980 GTX y la Geforce 970 GTX, han hecho posible que ya podamos disfrutar de la versión estable de los nuevos controladores y, en esta ocasión, incluso antes que para otros sistemas operativos. Esta nueva línea de controladores se caracteriza, aparte de por las nuevas características que incorporan, por ser el punto de inflexión en el soporte de hardware "antiguo" de Nvidia pues partir de esta serie sólo habrá soporte para las gráficas Geforce 400 o más recientes, quedando las anteriores relegadas a la serie de controladores 340.x que tendrán soporte prolongado. Evidentemente, el primer cambio a destacar será la inclusión de las dos nuevas GPUs de la compañía: Se ha añadido soporte para las siguientes GPUs:GeForce GTX 970 GeForce GTX 980 Se ha corregido un error que hacía que el ajuste "sync to vblank" no se respetase en las aplicaciones EGL. Se ha corregido un error por el que algunos programas OpenGL encontraban un problema de falta de memoria al cambiar de modo. Se ha corregido un error que impedía al controlador OpenGL de NVIDIA respetar el valor de la variable de entorno __GL_SHADER_DISK_CACHE_PATH. Se ha corregido un error por el que, en ciertas consultas y asignaciones efectuadas en la interfaz de línea de comandos de nvidia-settings, las pantallas inhabilitadas se incluían implícitamente como destinos seleccionados a falta de una selección explícita de destinos. Se ha añadido un nuevo atributo a la API NV-CONTROL para consultar el uso que se está haciendo del motor de descodificación de vídeo. Se ha corregido un error por el que la opción de intercambio de ojos izquierdo/derecho de nvidia-settings no funcionaba en determinadas configuraciones estereoscópicas. Se ha solucionado un problema de sombreadores de Unigine Heaven 3.0 que podía producir anomalías en la imagen si se activaba el teselado mediante la implementación de un perfil de aplicación que utilizase el parámetro "GLIgnoreGLSLExtReqs". Véase la documentación de la variable de entorno __GL_IGNORE_GLSL_EXT_REQS para obtener más información. Se ha corregido una fuga de memoria que se producía al destruir superficies de EGL. Se ha añadido soporte para varias pantallas EGL simultáneas. Se ha retirado el soporte de las GPUs G8x, G9x y GT2xx, así como de los chips de placa base diseñados con ellas. Las versiones antiguas del controlador 340.* seguirán incluyendo soporte para nuevos kernels de Linux y servidores X (así como correcciones para errores críticos) hasta finales de 2019. Se ha corregido un error por el que nvidia-installer podía tratar de borrar sin éxito el directorio que contiene las interfaces del módulo kernel en paquetes preparados con --add-this-kernel. Se ha modificado nvidia-installer para que registre la desinstalación en un archivo distinto del registro de instalación y para que intente eliminar las versiones anteriores del controlador utilizando el programa de desinstalación de dichas versiones, si está disponible. Como es habitual, podremos obtener el instalador oficial de dichos controladores a través de la web de Nvidia para cualquiera de los sistemas *nix soportados GNU/Linux x86 GNU/Linux x86_64 GNU/Linux ARM Solaris FreeBSD x86 FreeBSD x86_64
  23. GTX Titan Z es el nombre de la última, a falta de una palabra peor, MONSTRUOSIDAD (sí, sí, con mayúsculas) de NVidia. Si hace algún tiempo nos sorprendieron con la Titán, la gráfica mononúcleo para Gaming más potente y cara del mercado y posteriormente subieron aún más el listoón con su versión renovada, la Titán Black, ahora se les ha ido completamente la cabeza y con la Titan Z han unido dos GPUs GK110 (Los de la Titan Black) en una misma placa, dando lugar así a algo que no sé bien como definir, pero monstruosidad se queda corto. Titán Z cuenta con 12GB de Memoria GDDR5 con un bus de 768 bits y una tasa de transferencia de 7 Gbps, 5.760 núcleos CUDA todo en una PCB de 269 x 111 x 53 milímetros, con un peso total de 1.364 gramos, un TDP de 375 W y aseguran que su refrigeración por aire es tan eficiente y silenciosa como la de su antecesora. Su precio es aún más monstruoso si cabe y será sólo accesible para un reducido grupo que sean más que entusiasmas del Gaming, pues es de al menos 2800€ http://www.geforce.com/whats-new/articles/introducing-nvidia-geforce-gtx-titan-z Y una vez nos hemos quedado ojipláticos con algo que no nos podríamos permitir ni en nuestros sueños más húmedos, hablemos de la nueva serie de controladores gráficos de Nvidia, que han sido lanzados para domar a semejante bestia. Los nuevos controladores 337.25 añaden soporte para las nuevas tarjetas gráficas GeForce GTX TITAN Z GeForce GT 740 GeForce 830M GeForce 840M GeForce 845M GeForce GTX 850M Se habilita el soporte para utilizar UBB (Unified Back Buffer) y 3D Stereo con la extensión de composición en las tarjetas Quadro Se incluye soporte para las siguientes extensiones EGL EGL_EXT_buffer_age; EGL_EXT_client_extensions; EGL_EXT_platform_base; EGL_EXT_platform_x11 Nueva extensión GLX_NV_delay_before_swaphttp://www.opengl.org/registry/specs/NV/glx_delay_before_swap.txt Soporte para Under/overclock para tarjetas de nuevas series (a partir de la 400) Soporte X.Org Server 1.16 (xserver ABI 18), que integra XWayland Actualizado la pantalla de configuración de nvidia-settings para identificar inequívocamente los monitores DisplayPort 1.2 mostrando la GUIDs de los mismos. Se elimina la opción "OnDemandVBlankInterrupts" se las opciones de configuración de las Xs Y, por supuesto, numerosas correcciones y parches Para aquellos que no puedan esperar a que sean empaquetados e incluidos en los repositorios de su distribución, pueden descargarlos, como es habitual, desde la página de Nvidia Linux x86 Linux x86_64 Linux ARM Solaris FreeBSD x86 FreeBSD x86_64 https://devtalk.nvidia.com/default/topic/748536
  24. Como hemos venido anunciando durante los últimos meses, nvidia se ha ido acercando cada vez más más al lado del Open Source y ya no sólo para sus procesadores Tegra sino también para sus gráficas de escritorio Geforce, ofreciendo su colaboración para con el proyecto Nouveau, llegando a liberar algunas especificaciones de su Hardware Los desarrolladores de Nouveau siguen trabajando en el soporte para administración de energía y "re-clocking" para el correcto ajuste de velocidad de la GPU y la memoria para varias generaciones de tarjetas Geforce, algo en lo que Nvidia parece haberse inmiscuido y aparte de responder a las cuestiones planteadas por los desarrolladores y posiblemente enviar parches y más documentación, la compañía ha decidido enviar tarjetas gráficas de muestra para que los desarrolladores tengan con qué trabajar, empezando con la recién lanzada Nvidia Geforce Gtx 750 Ti y la primera en dar el salto de la arquitectura Kepler a Maxwell Aunque todo sea dicho, este acercamiento no nos asegura que la liberación total de las especificaciones o Drivers llegue a ocurrir y desde la propia compañía han asegurado que el desarrollo en relación a los procesadores Tegra y el que corresponde a las gráficas de escritorio son asuntos completamente distintos y que serán tratados por separado. http://www.phoronix.com/scan.php?page=news_item&px=MTYwNzY
  25. Nvidia arranca con fuerza en esta nueva serie de controladores 334.x con la que afianza aún más su apuesta por EGL, pieza fundamental para el soporte del servidor gráfico Wayland, además de traernos otras muchas novedades Se han añadido librerías EGL 64-bit y OpenGL ES Se ha mejorado Nvidia-settings para que nos muestre un texto de ayuda y sugerencias cuando creamos perfiles de configuraciones EL directorio /proc para la GPU ha sido renombrado como /proc/driver/nvidia/gpus y el bus de localización se presenta en el formato "domain:bus:device.function" para coincidir con lspci Se ha modificado el módulo del kernel para que pueda ser cargado mediante "nvidia-modprobe" en lugar de la función de ayuda de XFree86 xf86LoadKernelModule() Se ha mejorado el soporte para las variables de entorno GL_SYNC_DISPLAY_DEVICE y VDPAU_NVIDIA_SYNC_DISPLAY_DEVICE en ciertas configuraciones Se ha mejorado el rendimiento del driver de las Xs cuando se manejan un gran número de superficies Añadido soporte experimental para ARGB GLX visuals cuando la composición y Xinerama están habilitados simultáneamente en X.Org 1.15 Se ha modificado el comportamiento por defecto del driver para que no elimine las salidas de RandR 1.2 correspondientes a Unidades DisplayPort 1.2 en desuso y se ha añadido la opción DeleteUnusedDP12Displays para poder volver a habilitarlo. Actualizado el panel de control de nvidia-settings para permitir la selección de los dispositivos de visualización utilizando RandR y apuntar los nombres de identificación al realizar consultas dirigidas a los dispositivos de visualización específicos. El resto de cambios y los enlaces de descarga podemos encontrarlos en la página oficial de Nvidia http://www.nvidia.com/download/driverResults.aspx/73100/en-us Y ya para rematar y por si fuera poco, hace algunos días el propio Linus Torvalds tuvo a bien dirigir unas palabras hacia el fabricante de gráficas y, al igual que en anteriores ocasiones, ha acabado levantándole un dedo, pero esta vez ha sido el pulgar, especialmente por su trabajo con los controladores libres para los Tegra K1 y su acercamiento a la comunidad de desarrolladores para colaborar con Nouveau https://plus.google.com/u/0/+LinusTorvalds/posts/TQDXxxr6ixm
×