Lo hice y lo entendí

El blog de Vicente Navarro
10 oct

Sobre las VIA EPIA (VI): Gráficos y vídeo acelerado por HW en Linux con la EX10000EG

Al final de Sobre las VIA EPIA (V): La EPIA EX10000EG en Linux, decíamos que la parte de los gráficos es la que más trabajo supone y que por eso lo dejábamos para una entrada separada. Así que, sin más dilación, pongámonos a ello. No está de más, por cierto, recordar que yo trabajo en una Debian Etch con un kernel personalizado 2.6.22.6.

El procesador gráfico que lleva la VIA EPIA EX10000EG es el UniChrome™ Pro II, integrado en el chipset CX700M2. Según VIA, este chipset es capaz de:

Integrated VIA UniChrome™ Pro II 3D/2D AGP graphics with MPEG-2/4 and WMV9 video decoding acceleration

No tengo ni idea de si tales afirmaciones son ciertas en Windows (no he probado esta placa con dicho sistema operativo) o son fruto de la benevolencia de alguien en el departamento de marketing de VIA, pero veamos hasta dónde podemos sacarle punta a dichas afirmaciones en Linux.

En principio, leyendo la Operating Guide de la placa, vemos que, aunque sea sobre el papel, VIA nos manifiesta un fuerte compromiso con el soporte de Linux en sus placas:

Linux Driver Support

VIA EPIA EX mainboards have a very high degree of support under Linux.

Support and drivers are provided through various methods including:

  • Drivers provided by VIA
    • Using a driver built into a distribution package
    • Visiting VIA Arena website at www.viaarena.com for latest updates on a monthly basis
  • Installing a third party driver (such as the ALSA driver from the Advanced Linux Sound Architecture project for integrated audio)

For OEM clients and system integrators developing a product for long term production, other code and resources may also be made available. You can submit a request either through the Developers portal on VIA Arena, or through your VEPD support contact. Alternatively, VIA can work further towards providing additional drivers to suite your specific needs.

Como hemos visto en entradas anteriores (Sobre las VIA EPIA (V): La EPIA EX10000EG en Linux, Sobre las VIA EPIA (III): Linux en una SP8000E), en las que nos hemos dejado absolutamente todos los elementos del hardware configurados a la perfección, podemos aceptar la afirmación anterior sin titubeos.

Sin embargo, aún nos queda configurar los gráficos en esta placa, y nos vamos a encontrar con varios problemas. El primero es que según leemos en la página de man(4) del driver via actual (7.1) de X.Org, este chipset no está soportado aún:

DESCRIPTION
       via is an Xorg driver for VIA chipsets that have  an integrated Unichrome graphics engine.
 
       The via driver supports the CLE266, KM/N400, K8M/N800, PM/N800  and  CN400  chipsets  from
       VIA,  including  2D acceleration and the Xv video overlay extensions.  Flat panel, TV, and
       VGA outputs are supported, depending on the hardware configuration.
 
       3D direct rendering is available using experimental drivers  from  Mesa  (www.mesa3d.org).
       There  is  also  an  XvMC client library for hardware acceleration of MPEG1/MPEG2 decoding
       (available on the CLE266, PM/N800, K8M/N800, and CN400 chipsets) that uses the Direct Ren-
       dering  Infrastructure  (DRI).   The  XvMC  client library implements a non-standard "VLD"
       extension to the XvMC standard.  The current Direct Rendering Manager (DRM) kernel  module
       is available at dri.sourceforge.net.

Si nos pasamos al driver openChrome, nos encontramos con que tenemos que usar la rama experimental para tener soporte del chipset CX700M2 pero que, desafortunadamente, aún no soporta aceleración MPEG2/4 por XvMC.

Nos queda el driver oficial de VIA. Cuando hice la tanda anterior de artículos alrededor de la SP8000E, dado que encontré buen soporte del procesador gráfico tanto en el driver oficial de X.Org como en el openChrome, ni me preocupé en probarlo, ya que en muchos foros leía comentarios bastante negativos al respecto. Sin ir más lejos, en The Different Unichrome family display drivers podemos leer:

The VIA proprietary drivers

The proprietary drivers from VIA contain support for most chipsets, mpeg2 and mpeg4 acceleration, but are of low quality and often unstable. In addition, the 3D driver leaves your system open for attack by malicious clients, and furthermore, applications that accelerate mpeg2 and mpeg4 must be run as root, which is a very bad idea if they contain vulnerabilities (and they do). Avoid using these drivers unless you know what you are really doing! The drivers can be found here. Also, these drivers are distribution specific and a driver for different distribution other than yours might not work.

El desarrollador del driver unichrome.sf.net (que no funciona en chipsets modernos como el CN400 o el CX700, por cierto), Luc Verhaegen, también dice:

Despite VIA’s failure to properly understand and cooperate with Free and Open Source Software communities, this driver is very important. Thanks to VIA’s code releases, however irregular, entangled and buggy, a lot is known about the unichromes, and it is possible to do just about anything you want with them.

Por cierto, Luc tuvo un rifirafe con la moderadora de los foros de VIA, Fiona Gatt en VIA stops providing source: XF40070 is binary only y XF40070 topic locked: Last post removed tras decir en su diario lindezas sobre el driver de VIA tales como:

So, let us review where VIAs stands with respect to free software:

  • Complete and prolonged (3y+) inability to work with actual free software developers.
  • Crappy code and sporadic releases, totally unfit for direct use.
  • Very bad handling of licensing, with proprietary licenses popping up once in a while.
  • An NDA that, when VIA says so, forces signee to breach the GPL.
  • Distributes tarball with the binary “libddmpeg.so” and labels the lot as “open source” in direct violation of The Open Source Definition.
  • No longer distributes a DRI driver now, after having provided DRI binaries for a bit inside their “open source” tarballs. This used to be all source at one point.

En esta ocasión, y puesto que la aceleración de vídeo es importante en mis pruebas, es impensable no probarlo. Así que, ¡vamos allá!.

Los preparativos del kernel

Antes de comenzar con las diferentes pruebas, hemos de verificar que tenemos varios módulos necesarios listos en nuestro kernel.

En primer lugar, es importante habilitar los módulos agpart y via_agp, que nos permiten tener un acceso rápido al procesador gráfico usando el puerto AGP. El primero de los módulos nos permite un acceso genérico al puerto AGP mientras que el segundo es específico para el procesador gráfico Unichrome integrado en el chipset de VIA. Los encontramos en:

Device Drivers → Character devices → /dev/agpgart (AGP Support)
Device Drivers → Character devices → /dev/agpgart (AGP Support) → VIA chipset support

Sin estos módulos, no nos sería posible usar el DRI (Direct Rendering Infrastructure), que nos permite que ciertas aplicaciones accedan directamente a la memoria de vídeo de forma segura. Para ello usa dos módulos del kernel (uno genérico: drm y otro específico del procesador de vídeo: via) que forman el DRM (Direct Rendering Manager), que viene a ser “la parte del DRI que tiene que estar en el kernel”.

El DRI nos permite, entre otras cosas, permitir acceso al hardware por parte de las GLX (OpenGL Extension to the X Window System) para acelerar el 3D o para acceder a la aceleración MPEG2/4.

Los módulos drm y via los encontramos en:

Device Drivers → Character devices → Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)
Device Drivers → Character devices → Direct Rendering Manager (XFree86 4.1.0 and higher DRI support) → Via unichrome video cards

Una vez cargados, podemos ver los cuatro módulos en la salida del lsmod:

via                    40000  0 
drm                    76372  1 via
via_agp                10432  1 
agpgart                32328  2 drm,via_agp

En la salida del dmesg también comprobamos que el chipset ha sido correctamente reconocido (desde el kernel 2.6.20):

Linux agpgart interface v0.102 (c) Dave Jones
agpgart: Detected VIA CX700 chipset
agpgart: AGP aperture is 64M @ 0xd8000000
[drm] Initialized drm 1.1.0 20060810
[drm] Initialized via 2.11.1 20070202 on minor 0
agpgart: Found an AGP 3.5 compliant device at 0000:00:00.0.
agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode

Y en efecto, en el fichero drivers/char/agp/via-agp.c encontramos:

/* VT3324 / CX700 */
{
        .device_id  = PCI_DEVICE_ID_VIA_VT3324,
        .chipset_name   = "CX700",
},

Podemos ver tanto los módulos de AGP como los de DRM juntos en la siguiente captura:

via-agp-drm

El driver VESA

El “driver de los pobres”, el driver que puede sacar de un apuro a todos aquellos cuyo procesador gráfico no esté soportado por X.Org, también funciona bien con las EX. Puesto que el driver Unichrome oficial de X.Org no soporta el CX700, esta es la única opción que tenemos para usar las X Window en cualquier distribución recién instalada.

Por supuesto, con este driver no tenemos aceleración 2D ni mucho menos 3D:

 $ glxinfo | grep OpenGL
OpenGL vendor string: Mesa project: www.mesa3d.org
OpenGL renderer string: Mesa GLX Indirect
OpenGL version string: 1.2 (1.5 Mesa 6.5.1)

$ glxgears -iacknowledgethatthistoolisnotabenchmark                          
866 frames in 5.9 seconds = 146.770 FPS
840 frames in 5.9 seconds = 142.989 FPS
840 frames in 5.9 seconds = 143.438 FPS

Y el uso de CPU se desmadra totalmente al reproducir una película en DVD (MPEG2), bien sea en xine, bien sea en mplayer. Curiosamente, en el caso del xine, el consumo excesivo de CPU viene por parte del Xorg y en el caso del mplayer viene, sobre todo, por sí mismo:

# top
 
top - 19:08:06 up  2:34,  5 users,  load average: 2.04, 0.58, 0.20 
Tasks:  98 total,   3 running,  95 sleeping,   0 stopped,   0 zombie 
Cpu(s): 94.4%us,  5.6%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st 
Mem:    450736k total,   433040k used,    17696k free,    21724k buffers 
Swap:  1317288k total,        8k used,  1317280k free,   256224k cached 
 
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                 
 2313 root      25   0  120m  38m 7928 R 81.5  8.8   1:38.44 Xorg                                   
 5383 vicente   15   0  234m  36m 6372 S 15.7  8.3   0:02.75 xine 

# top
 
top - 18:26:44 up 52 min,  4 users,  load average: 0.63, 0.54, 0.37 
Tasks:  95 total,   3 running,  92 sleeping,   0 stopped,   0 zombie 
Cpu(s): 99.0%us,  1.0%sy,  0.0%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st 
Mem:    450736k total,   444872k used,     5864k free,    15900k buffers 
Swap:  1317288k total,        0k used,  1317288k free,   314336k cached 
 
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                 
 2174 vicente   25   0 32396  14m 5988 R 72.7  3.2   0:15.73 mplayer                                
 3424 root      15   0 94756  21m 8264 S 26.2  4.8   0:34.87 Xorg 

Los modos VESA soportados son:

# egrep 'Mode:|BitsPerPixel' /var/log/Xorg.0.log | sed 'N; s/\n//;'
Mode: 101 (640x480)     BitsPerPixel: 8
Mode: 111 (640x480)     BitsPerPixel: 16
*Mode: 112 (640x480)    BitsPerPixel: 32
Mode: 171 (720x480)     BitsPerPixel: 8
Mode: 173 (720x480)     BitsPerPixel: 16
*Mode: 175 (720x480)    BitsPerPixel: 32
Mode: 1b9 (720x540)     BitsPerPixel: 8
Mode: 1ba (720x540)     BitsPerPixel: 16
*Mode: 1bb (720x540)    BitsPerPixel: 32
Mode: 17c (720x576)     BitsPerPixel: 8
Mode: 17e (720x576)     BitsPerPixel: 16
*Mode: 17f (720x576)    BitsPerPixel: 32
Mode: 103 (800x600)     BitsPerPixel: 8
Mode: 114 (800x600)     BitsPerPixel: 16
*Mode: 115 (800x600)    BitsPerPixel: 32
Mode: 105 (1024x768)    BitsPerPixel: 8
Mode: 117 (1024x768)    BitsPerPixel: 16
*Mode: 118 (1024x768)   BitsPerPixel: 32
Mode: 125 (1280x720)    BitsPerPixel: 8
Mode: 126 (1280x720)    BitsPerPixel: 16
*Mode: 127 (1280x720)   BitsPerPixel: 32
Mode: 179 (1280x768)    BitsPerPixel: 8
Mode: 17a (1280x768)    BitsPerPixel: 16
*Mode: 17b (1280x768)   BitsPerPixel: 32
Mode: 1b6 (1280x800)    BitsPerPixel: 8
Mode: 1b7 (1280x800)    BitsPerPixel: 16
*Mode: 1b8 (1280x800)   BitsPerPixel: 32
Mode: 107 (1280x1024)   BitsPerPixel: 8
Mode: 11a (1280x1024)   BitsPerPixel: 16
*Mode: 11b (1280x1024)  BitsPerPixel: 32
Mode: 13b (1400x1050)   BitsPerPixel: 8
Mode: 13c (1400x1050)   BitsPerPixel: 16
*Mode: 13e (1400x1050)  BitsPerPixel: 32
Mode: 120 (1600x1200)   BitsPerPixel: 8
Mode: 122 (1600x1200)   BitsPerPixel: 16
*Mode: 124 (1600x1200)  BitsPerPixel: 32
Mode: 166 (1920x1080)   BitsPerPixel: 8
Mode: 167 (1920x1080)   BitsPerPixel: 16
*Mode: 168 (1920x1080)  BitsPerPixel: 32

En entradas anteriores me quejaba de que el 1680×1050 no es uno de ellos pero, curiosamente, me acabo de dar cuenta de que en la SP8000E, una placa más antigua, sí que estaba soportado (Sobre las VIA EPIA (III): Linux en una SP8000E). VIA va para atrás, como los cangrejos…

El driver openChrome

Antes de comenzar, comentar que si en algún momento de nuestras pruebas queremos eliminar cualquier resto de las mismas para volver a una situación como la que tenemos nada más acabar de instalar el sistema, podemos hacerlo reinstalando las librerías de XvMC, de DRM, de DRI y el driver oficial de via de openChrome. No hace falta todo, pero ¡más vale asegurarnos!

 # apt-get --reinstall install libxvmc-dev libxvmc1 xserver-xorg-video-via libdrm-dev libdrm2 libgl1-mesa-dri x11proto-xf86dri-dev

La forma de obtener la rama experimental del código fuente de openChrome y compilarlo viene explicado en:

Ringmaster también lo contó hace poco para el driver normal (no el experimental) para su placa con CN700 en Instalar el controlador para el chipset VIA CN700 en Ubuntu linux.

Pero el usuario zoo de los foros de viaarena.com nos lo cuenta perfectamente resumido para nuestro CX700 en: OpenChrome experimental branch on CX700M2 (EPIA EX): usable alternative to the generic VESA driver and to the original VIA (yo salgo en ese hilo con el nick Castillo). En definitiva, tenemos que:

1. En Debian, instalar los paquetes de desarrollo necesarios (openChrome: Compiling the source code on Debian)

subversion
build-essential
gcc
automake1.9 [1]
libtool
pkg-config
libxvmc-dev
xserver-xorg-dev
x11proto-fonts-dev
x11proto-randr-dev
x11proto-render-dev
x11proto-xf86dri-dev
libdrm-dev
x11proto-gl-dev
libgl1-mesa-dev

[1] Hay que hacer un “update-alternatives --config automake” también

2. Obtener el código experimental y compilar

cd /usr/src/
svn co http://svn.openchrome.org/svn/branches/experimental_branch openchrome-experimental
cd /usr/src/openchrome-experimental
./autogen.sh --prefix=/usr
make
make install

Con esto, se reemplazan los siguientes ficheros del sistema:

/usr/lib/xorg/modules/drivers/via_drv.la
/usr/lib/xorg/modules/drivers/via_drv.so
/usr/share/man/man4/via.4
/usr/lib/libviaXvMC.la
/usr/lib/libviaXvMC.so.1.0.0
/usr/lib/libviaXvMCPro.la
/usr/lib/libviaXvMCPro.so.1.0.0
/usr/lib/libviaXvMCPro.la

3. Modificar el fichero /etc/X11/xorg.conf poniendo, en la sección de Device algo como:

Section "Device"
        Identifier    "VIA CX700M2"
        Driver        "via"
        Option        "ActiveDevice" "CRT"
        Option        "VBEModes" "true"
        Option        "EnableAGPDMA" "true"
EndSection

Tras esto, ya podemos reiniciar las X, (p.e. con “/etc/init.d/gdm restart“) y ya deberíamos de tener el sistema funcionando con el driver openChrome. Podemos curiosear ahora en el /var/log/Xorg.log y encontraremos bastante información interesante, como la versión del driver:

(II) LoadModule: "via"
(II) Loading /usr/lib/xorg/modules/drivers/via_drv.so
(II) Module via: vendor="X.Org Foundation"
        compiled for 7.1.1, module version = 0.2.1
        Module class: X.Org Video Driver
        ABI class: X.Org Video Driver, version 1.0

Los chipsets soportados:

(II) VIA: driver for VIA chipsets: CLE266, KM400/KN400, K8M800,
        PM800/PM880/CN400, VM800/CN700/P4M800Pro, K8M890, P4M900, CX700,
        P4M890
(II) Primary Device is: PCI 01:00:0
(--) Assigning device section with no busID to primary device
(--) Chipset CX700 found
(!!) VIA Technologies does not support or endorse this driver in any way.
(!!) For support, please refer to http://www.openchrome.org/ or
(!!) your X vendor.

Que el DRM está disponible y que las instrucciones más rápidas son las SSE:

(II) VIA(0): direct rendering enabled
(II) VIA(0): [Xv] Using PCI DMA for Xv image transfer.
Fulfilled via DRI at 20976640
(II) VIA(0): Benchmarking video copy. Less is better.
(--) VIA(0): Timed   libc YUV420 copy... 1573219. Throughput: 377.1 MiB/s.
(--) VIA(0): Timed kernel YUV420 copy... 1555560. Throughput: 381.4 MiB/s.
(--) VIA(0): Timed    SSE YUV420 copy... 1188578. Throughput: 499.1 MiB/s.
(--) VIA(0): Timed    MMX YUV420 copy... 1512182. Throughput: 392.3 MiB/s.
(--) VIA(0): Ditch 3DNow! YUV420 copy... Not supported by CPU.
(--) VIA(0): Timed   MMX2 YUV420 copy... 1243924. Throughput: 476.9 MiB/s.
Freed 20976640 (pool 2)
(--) VIA(0): Using SSE YUV42X copy for video.

Y la confirmación de que el XvMC no está soportado de momento para esta placa:

(WW) VIA(0): [XvMC] Not supported on this chipset.

Sin embargo, sí que podemos confirmar que la aceleración 3D está activada:

 $ glxinfo | grep OpenGL                                                       
OpenGL vendor string: VIA Technology
OpenGL renderer string: Mesa DRI UniChrome 20060710
OpenGL version string: 1.2 Mesa 6.5.1

$ glxgears -iacknowledgethatthistoolisnotabenchmark                            
3712 frames in 5.0 seconds = 742.289 FPS
3697 frames in 5.0 seconds = 739.224 FPS
3554 frames in 5.0 seconds = 710.780 FPS

Pero las extensiones AIGLX, necesarias para gestores de ventanas como Compiz aún no están soportadas:

$ compiz -replace
/usr/bin/compiz.real: No composite extension

El driver DRI que usa el driver openChrome es el estándar de UniChrome, el /usr/lib/dri/unichrome_dri.so.

Aquí tenemos algo de información adicional sobre el 3D y openChrome:

Para finalizar, comentar que a pesar de lo que recomiendan los distintos documentos sobre compilar e instalar el último drm disponible, no debemos hacerlo. Según mi experiencia, si lo intentamos tendremos dos problemas: Que tras instalarlo tendremos errores de compilación del driver openChrome si lo compilamos después que el nuevo drm (esto es lo que comento en el hilo del foro que mencionaba antes) y que tengo la sensación de que con la última versión del drm el sistema se cuelga muy a menudo, quedándose la pantalla totalmente congelada, aunque accesible por la red (también me ha ocurrido alguna vez, aunque mucho menos a menudo, incluso con el drm estándar de Debian Etch y del kernel 2.6.22.6 -no olvidemos que es un driver experimental-).

Notas sobre el XvMC

Retomando el tema del XvMC, aunque actualmente el driver no lo soporte, no quiero acabar esta sección del driver openChrome sin comentar algunas cosas al respecto por si en el futuro cambia la situación o por si alguien disfruta de otra placa con soporte de XvMC.

En openChrome: XvMC podemos obtener el parche necesario para que el mplayer use XvMC. Una vez usado y compilado, podríamos usar la aceleración MPEG2 con el siguiente comando:

mplayer -vo xvmc,xv -vc ffmpeg12mc, -dvd-device /path/a/un/dvd/ dvd://1

o usando el fichero de configuración ~/.mplayer/config:

# cat ~/.mplayer/config 
vo=xvmc,xv
vc=ffmpeg12mc,

Si queremos usar el xine con XvMC hemos de asegurarnos de que el siguiente fichero existe (es muy probable que sí porque ya lo lleva el paquete libxvmc1:

# cat /etc/X11/XvMCConfig 
libXvMC.so.1

# dpkg -S XvMCConfig                                                                
libxvmc1: /etc/X11/XvMCConfig

y en tal caso, el xine se compilará con soporte de XvMC. Para usarlo, hemos de arrancarlo con la opción “-V xxmc“:

xine -V xxmc -phq dvd:/path/a/un/dvd/1

Esto está documentado en /usr/share/doc/libxine1/README_xxmc.html, donde podemos leer, asimismo, que las siguientes opciones del fichero ~/.xine/config son muy recomendables:

video.device.unichrome_cpu_save:1
video.device.xvmc_more_frames:1
engine.performance.memcpy_method:sse

Si también estamos interesados en acelerar la reproducción en el MythTV: Aceleración por XvMC en MythTV

Un truco muy sencillo para saber si la aceleración por XvMC se está usando es mirar la lista de librerías dinámicas que el binario tiene abiertas. En ella tenemos que poder encontrar la libviaXvMCPro.so:

VIA EPIA SP8000E

# lsof | grep -i xvmc
xine      22802     vicente  mem       REG        3,1   203189    2502026 /usr/lib/libviaXvMCPro.so.1.0.0
xine      22802     vicente  mem       REG        3,1     9872    2506199 /usr/lib/libXvMC.so.1.0.0
xine      22802     vicente  mem       REG        3,1    14436    2506203 /usr/lib/libXvMCW.so.1.0.0

VIA EPIA EX10000EG

# lsof | grep -i xvmc
xine      3999     vicente  mem       REG       22,1      14436    8834817 /usr/lib/libXvMCW.so.1.0.0
xine      3999     vicente  mem       REG       22,1       9872    8834816 /usr/lib/libXvMC.so.1.0.0

El driver de VIA

Ya comentaba al principio que había leído en muchos sitios que el driver de VIA, aunque existía, no merecía ni el tiempo necesario en probarlo. En la SP8000E, con los excelentes resultados del driver openChrome, y dada la fama que precedía al driver de VIA, menos aún. Con la EX10000EG es diferente: ya he comentado que el driver openChrome aún no es muy estable y se cuelga de vez en cuando. Encima, aún no tiene aceleración de vídeo, de modo que no podemos pasar sin probar la alternativa oficial.

En el pasado, en realidad, sí que quise darle una oportunidad a pesar de la mala prensa, pero todo lo que encontré en la página de drivers de Linux de VIA Arena eran drivers precompilados para Fedora/Red Hat, Suse/OpenSuse o fuentes excesivamente orientadas a la compilación en dichas distribuciones, lo que desanima completamente a todo buen Debianita o incluso a los Ubunteros.

A día de hoy, como podemos ver en dicha página, ya tienen nuevas secciones dedicadas a Debian, Ubuntu y a código fuente, algo muy de agradecer.

Sin embargo, los scripts de compilación e instalación del driver son una auténtica chapuza, llenos de hacks con especificidades para cada una de las distribuciones soportadas y decisiones arbitrarias sobre dónde pueden poner SUS ficheros en MI sistema. Ya nos iremos encontrando estas ñapas en las próximas líneas.

La versión del driver actual es la72c (xorg40072c-kernel-src), aparecida el 5/6/07, y bastante más fácil de compilar que su predecesora la versión 71a (xorg40071a-kernel-src). Ambas las podemos encontrar en la página de fuentes Linux para el chipset CX700M2. La descripción del driver es:

This software package supports 2D, 3D, TV-Out, hardware video mpeg2/4 and hardware video overlay, and it has been tested inDebian 3.1r4/4.0, Fedora Core 4/5/6, Mandriva 2007/2007.1, openSUSE 10.2 and Ubuntu 6.10/7.04 Desktop. Other distributions only support 2D, TV-Out, hardware video mpeg2/4 and hardware video overlay except 3D. It supports VIA UniChrome Pro IGP chip family including CLE266/CN400/CN700/CN800/CX700(M/M2)/PM880/P4M800CE-Pro/VN800/VX700(M/M2). The MPEG4 Hardware Acceleration function is only supported with CN400/CX700M(M2)/PM880/VX700M(M2) chips, and the system memory is recommended to be 64MB or above.

Si descomprimimos el fichero zip con las fuentes del driver v72c (sugiero hacerlo, en /tmp/) nos encontramos con varios ficheros:

CLE266CN400CN-CX700CN800XORG40072-kernel-src_20061226c.tgz
DRI-Xorg.tgz
DRI-XF86.tgz

Los ficheros DRI* contienen la librería libGL.so.1.2 para X.Org y XFree86 que normalmente ya deberíamos tener en el sistema, así que no las necesitamos para nada:

# dpkg -S libGL.so
libgl1-mesa-dev: /usr/lib/libGL.so
libgl1-mesa-glx: /usr/lib/libGL.so.1
libgl1-mesa-glx: /usr/lib/libGL.so.1.2

Por tanto, el fichero importante es el ...XORG40072-kernel-src_20061226c.tgz, que podemos descomprimir, esta vez sí, en /usr/src/. Nos encontraremos con un directorio src con las fuentes -por fin- y un fichero Installation.txt que contiene información bastante detallada sobre los diversos parámetros que acepta el driver.

Entramos en src y encontramos el fichero ReleaseNote.txt con las instrucciones para compilar el driver. En el directorio VIA_VMILIB encontramos la librería core de la aceleración hardware de MPEG, la libddmpeg.so ya compilada y sin sus fuentes (ya lo veíamos en la introducción en los comentarios de Luc: VIA publica las fuentes de su driver pero no de según qué partes).

Para compilar el driver, es necesario tener las fuentes del kernel que estemos usando en /usr/src/linux, pero más nos vale hacer un buen backup, porque según tengo comprobado, el script de compilación del kernel toca cosas que estropean el kernel de forma que ya no se puede volver a compilar sin errores. Yo tengo lo siguiente:

drwxrwxr-x 20 root src 4096 2007-10-07 18:07 linux-2.6.22.6/
drwxrwxr-x 20 root src 4096 2007-10-07 18:07 linux-2.6.22.6_parche_via/
lrwxrwxrwx  1 root src    18 2007-10-09 10:55 linux -> linux-2.6.22.6_parche_via/

Por cierto, es conveniente -pero no necesario- que tengamos el V4L activado en el kernel, aunque no tengamos ningún hardware que lo use, ya que hay partes del driver que lo usan:

CONFIG_VIDEO_V4L1_COMPAT=y
CONFIG_VIDEO_V4L2=y

En mi caso, que uso Debian 4.0 con un kernel personalizado (2.6.22.6-VIC), lo primero que tengo que hacer es introducir la versión de mi kernel asociada a Debian 4.0 en la lista de asociaciones kernel-distribución que aparece al principio del fichero makedriver:

    2.6.18-4-486)
        DIR=Debian/4.0r0
        DIR1=Debian
        DIR2=4.0r0
        ;;
    2.6.22.6-VIC)
        DIR=Debian/4.0r0
        DIR1=Debian
        DIR2=4.0r0
        ;;
    *)
        DIR=NewKernel/1.0
        DIR1=NerKernel
        DIR2="$KERNELVERSION"
        ;;

También hay que hacer algunos cambios en el script vinstall. Por ejemplo, en Debian no hay /etc/rc.d/rc.local sino /etc/rc.local. Tampoco tenemos /usr/X11R6/lib/libXv.so.1.0, sino /usr/lib/libXv.so.1.0.0, así que las siguientes líneas:

AUTOLOADFILE=/etc/rc.d/rc.local
OLDAUTOLOADFILE=/etc/rc.d/rc.local.bak
LIBXV=/usr/X11R6/lib/libXv.so.1.0

Las cambiamos a:

AUTOLOADFILE=/etc/rc.local
OLDAUTOLOADFILE=/etc/rc.local.bak
LIBXV=/usr/lib/libXv.so.1.0.0

También tenemos que introducir, de nuevo, la correspondencia kernel-distribución:

    2.6.8-2-386)
        OS=Debian
        VER=3.1r4
        AUTOLOADFILE=$MODULESCONFDIR/modules
        XCONFIGFILE=/etc/X11/XF86Config-4
        ;;
    2.6.22.6-VIC)
        OS=Debian
        VER=4.0r0
        AUTOLOADFILE=$MODULESCONFDIR/modules
        XCONFIGFILE=/etc/X11/xorg.conf
        ;;
    2.6.18-4-486)
        OS=Debian
        VER=4.0r0
        AUTOLOADFILE=$MODULESCONFDIR/modules
        XCONFIGFILE=/etc/X11/xorg.conf
        ;;

Ahora ya podemos empezar a compilar el driver propiamente dicho, para lo cual usamos el comando “makedriver drm“, a menos que no queramos 3D, en cuyo caso podemos hacer sólo “makedriver“:

# ./makedriver drm
Which version driver you want to release (x86) ?
72c
Which CPU do you use ?
1. VIA C3-2(C5N/C5P), C7/C7D/C7M/Eden, Intel Pentium 2/3/4(x86)
2. VIA C3
3. AMD K7
4. AMD K8 with 32 bits OS(x86)
5. AMD K8 with 64 bits OS(x86_64)
1

Si todo va bien, tras este comando, encontraremos en el directorio /CLE266CN400CN-CX700CN800XORG40072c (en el directorio raíz… ¡porque VIA lo vale!) dos subdirectorios Utility y XServer, el primero con los ficheros de la s3utility y en el segundo, que debería de contener los siguientes ficheros tras la compilación:

# ll XServer/
total 3724
drwxr-xr-x 2 root root    4096 2007-10-09 11:42 ./
drwxr-xr-x 4 root root    4096 2007-10-09 11:42 ../
-rw-rw-rw- 1 root root  359097 2007-10-09 11:42 libddmpeg.so
-rw-r--r-- 1 root root   14912 2007-10-09 11:42 via-agp.ko
-rw-r--r-- 1 root root   37040 2007-10-09 11:42 via.ko
-rwxr-xr-x 1 root root 2252945 2007-10-09 11:38 via_dri.so*
-rwxr-xr-x 1 root root  626646 2007-10-09 11:42 via_drv.so*
-rw-r--r-- 1 root root  483407 2007-10-09 11:39 via_v4l_drv.ko

encontramos la librería de aceleración MPEG (que no ha sido compilada, como ya hemos comentado antes), el driver de VIA (via_drv.so), el driver de Mesa (via_dri.so) y tres módulos del kernel, el de V4L (via_v4l_drv.ko), el de DRM (via.ko) y el de AGP (via-agp.ko).

Como prueba de lo que comentaba antes de que el script makeinstall estropea las fuentes del kernel, nada mejor que intentar compilarlas de nuevo:

# cd /usr/src/linux
# make
scripts/kconfig/conf -s arch/i386/Kconfig
  CHK     include/linux/version.h
  CHK     include/linux/utsrelease.h
  CALL    scripts/checksyscalls.sh
  CHK     include/linux/compile.h
[...]
  Building modules, stage 2.
  MODPOST 315 modules
ERROR: "drm_ht_remove_item" [drivers/char/drm/drm.ko] undefined!
ERROR: "drm_ht_create" [drivers/char/drm/drm.ko] undefined!
ERROR: "drm_ht_insert_item" [drivers/char/drm/drm.ko] undefined!
ERROR: "drm_ht_remove" [drivers/char/drm/drm.ko] undefined!
ERROR: "drm_ht_find_item" [drivers/char/drm/drm.ko] undefined!
ERROR: "drm_ht_remove_key" [drivers/char/drm/drm.ko] undefined!
ERROR: "drm_ht_just_insert_please" [drivers/char/drm/drm.ko] undefined!
make[1]: *** [__modpost] Error 1
make: *** [modules] Error 2

¡Menos mal que hemos hecho un backup!

El via_dri.so, en realidad no ha sido compilado, sino que ha sido copiado un binario de uno de estos directorios:

# find . -name via_dri.so
./3D/DRI-Xorg_bin/Mandriva/2007.1/via_dri.so
./3D/DRI-Xorg_bin/Mandriva/2007.0/via_dri.so
./3D/DRI-Xorg_bin/Debian/4.0r0/via_dri.so
./3D/DRI-Xorg_bin/Debian/3.1r4/via_dri.so
./3D/DRI-Xorg_bin/FedoraCore/4/via_dri.so
./3D/DRI-Xorg_bin/FedoraCore/6/via_dri.so
./3D/DRI-Xorg_bin/FedoraCore/5/via_dri.so
./3D/DRI-Xorg_bin/SuSE/10.2/via_dri.so
./3D/DRI-Xorg_bin/Ubuntu/7.04/via_dri.so
./3D/DRI-Xorg_bin/Ubuntu/6.10/via_dri.so

Pero es mucho mejor que recompilemos el driver de VIA para Mesa en nuestro sistema en lugar de usar el binario precompilado:

# cd /usr/src/
# mkdir mesa
# cd mesa
# apt-get source mesa
[...]
# cd mesa-6.5.1
# make linux-dri
[...]
# cp -a /usr/src/CLE266CN400CN-CX700CN800XORG40072-kernel-src_20061226c/src/3D/DRI_FC6 src/mesa/drivers/dri/via
# cd src/mesa/drivers/dri/via
# make
# cp -a via_dri.so /CLE266CN400CN-CX700CN800XORG40072c/XServer

Y por fin llega el momento de instalar el driver pero, antes, es conveniente que hagamos un backup de los ficheros /etc/X11/xorg.conf y /etc/rc.local. Tras ello, vamos al directorio /CLE266CN400CN-CX700CN800XORG40072c y ejecutamos el script vinstall:

# ./vinstall
 -------- install start --------
Install Debian 4.0r0 VIA/S3G UniChrome family graphic driver!
Which CPU do you use ?
1. VIA C3-2(C5N/C5P), C7/C7M/C7D/Eden, Intel Pentium 2/3/4
2. VIA C3
3. AMD K7
4. AMD K8 with 32 bits OS(x86)
5. AMD K8 with 64 bits OS(x86_64)
6. Intel Pentium 4 with 64 bits OS(x86_64)
1
Please wait...
Do you want VMI-ONLY(1) path or V4L(2) path?(1/2)
1  

Now start to install VIA/S3G display utility...
Put the main program(s3utility) into the bin directory: /usr/local/bin
Utility installation is finished!
Now start to modify X config...
Found file '/etc/X11/xorg.conf'.
Found file './viax.conf', importing...
Original X config file was saved as /etc/X11/xorg.conf.viaold
X config is modified!
 -------- vinstall end --------
You can run vunistall to Rollback.

He elegido VMI-ONLY porque, según la documentación, es:

Note: VMI-ONLY path is a non-kernel dependency way to enable the VIA 2D/3D/HW MPEG/TV features.

y como no me fio ni un pelo de los módulos del kernel que crea e instala VIA, prefiero usar los del kernel por defecto que, como ya hemos visto, soportan tanto el AGP como el DRI de esta placa en la versión del kernel 2.6.22.

El script ha hecho lo siguiente:

  • Instalar /usr/lib/xorg/modules/drivers/via_drv.so
  • Instalar /usr/lib/dri/via_dri.so
  • Instalar /usr/lib/libddmpeg.so
  • Instalar la s3utility en /usr/local
  • Modificar el /etc/rc.local y el /etc/X11/xorg.conf
  • Instalar los módulos del kernel

Todo me parece bien excepto lo último, ya que, como hemos dicho, preferimos prescindir de los módulos de VIA. Para ello, reponemos nuestras fuentes del kernel sin adulterar por el script de VIA y volvemos a instalar los módulos correctos con un “make modules_install“.

Si repasamos el /etc/rc.local, veremos que el vinstall ha puesto un par de modprobe. No se puede decir que vayan a estropear nada, viendo que están después del “exit 0“, pero casi mejor los quitamos:

exit 0
modprobe via
modprobe via_v4l_drv

En el /etc/X11/xorg.conf, antes de ejecutar el vinstall yo había dejado las secciones de Device y Monitor vacías para ver qué me añadía la instalación, y esto es lo que ha quedado (en negrita lo que he añadido yo porque si no, no funcionaba):

Section "Device"
        Identifier  "Generic Video Card"
        BoardName   "via"
        VendorName  "VIA Tech"
        Driver      "via"
EndSection

Section "Monitor"
        Identifier      "Generic Monitor"
        Option          "DPMS"
        ModeLine "848x480" 47.4 848 888 976 1104 480 481 484 505
        ModeLine "1440x1050" 184.5 1440 1544 1704 1968 1050 1051 1054 1103
        ModeLine "1280x768" 118.5 1280 1368 1504 1728 768 769 772 807
        ModeLine "1440x1050" 160.0 1440 1536 1696 1952 1050 1051 1054 1096
[...]
EndSection

También pone todas las resoluciones a 1024×768, así que podemos querer cambiarlo:

Section "Screen"
        Identifier      "Default Screen"
        Device          "Generic Video Card"
        Monitor         "Generic Monitor"
        DefaultDepth    24
[...]
        SubSection "Display"
                Modes  "1280x1024" "1024x768"
                Depth           24
        EndSubSection
EndSection

Es el momento de reiniciar las X Windows, (p.e. con /etc/init.d/gdm restart) y ver qué tal luce el nuevo driver.

Si curioseamos en el /var/log/Xorg.log, encontramos la versión del driver:

(II) LoadModule: "via"
(II) Loading /usr/lib/xorg/modules/drivers/via_drv.so
(II) Module via: vendor="X.Org Foundation"
        compiled for 4.3.99.902, module version = 4.1.72
        Module class: X.Org Video Driver

Los chipsets soportados:

(II) via: driver for VIA chipsets: CLE266, KM400/KN400, K8M800/K8N800,
        PM800/PM880/CN400, P4M800PRO, CX700, K8M890, P4M890, CN750, P4M900

O la carga del driver de DRI con sus advertencias:

(WW) AIGLX: 3D driver claims to not support visual 0x22
(WW) AIGLX: 3D driver claims to not support visual 0x23
(WW) AIGLX: 3D driver claims to not support visual 0x24
(WW) AIGLX: 3D driver claims to not support visual 0x25
(WW) AIGLX: 3D driver claims to not support visual 0x26
(WW) AIGLX: 3D driver claims to not support visual 0x27
(WW) AIGLX: 3D driver claims to not support visual 0x28
(WW) AIGLX: 3D driver claims to not support visual 0x29
(WW) AIGLX: 3D driver claims to not support visual 0x2a
(WW) AIGLX: 3D driver claims to not support visual 0x2b
(WW) AIGLX: 3D driver claims to not support visual 0x2c
(WW) AIGLX: 3D driver claims to not support visual 0x2d
(WW) AIGLX: 3D driver claims to not support visual 0x2e
(WW) AIGLX: 3D driver claims to not support visual 0x2f
(WW) AIGLX: 3D driver claims to not support visual 0x30
(WW) AIGLX: 3D driver claims to not support visual 0x31
(II) AIGLX: Loaded and initialized /usr/lib/dri/via_dri.so
(II) GLX: Initialized DRI GL provider for screen 0

Toda esa ristra de mensajes de “libGL warning: 3D driver claims to not support visual ...” nos saldrá en adelante cada vez que usemos alguna aplicación que use el GLX, como el glxinfo o el glxgears:

$ glxinfo | grep -i opengl
OpenGL vendor string: VIA Technology
OpenGL renderer string: Mesa DRI UniChrome 20060710
OpenGL version string: 1.2 Mesa 6.5.1
OpenGL extensions

$ glxgears -iacknowledgethatthistoolisnotabenchmark
2203 frames in 5.0 seconds = 440.449 FPS
2210 frames in 5.0 seconds = 441.954 FPS
2211 frames in 5.0 seconds = 442.103 FPS

Podemos ver que este driver de DRI saca algunos FPS menos que el estándar UniChrome.

Las aplicaciones que pueden sacar provecho del driver de VIA

No se vayan todavía… ¡Aún hay más!

¿Os creíais que ya se estaba acabando la diversión? ¡Qué ingenuos! Se supone que el driver que tenemos funcionando soporta aceleración de MPEG2/MPEG4 por hardware, pero no lo hace por XvMC, no. Alguien de VIA pensaría que para qué soportar la API estándar de aceleración de vídeo en Linux que pueden aprovechar aplicaciones tan poco importantes como el MPlayer, el xine, el FFmpeg, el MythTV o el VLC Player, y que mejor implementaban su propio estándar dentro de la, a estas alturas famosa, librería libddmpeg.so. Y claro, si hacen su propio estándar, tendrán que hacer sus propias aplicaciones…

Y ahí es donde nacen el VeXP (VIA Enhanced Xine Player) y el VeMP (VIA Enhanced Mplayer), que podrían haber llamado también “MPlayer Chapuza Edition” o Xine damaged by VIA“. Ambos proyectos están hospedados en sourceforge.net, VeMP y VeXP.

El paquete del VeXP contiene, además del xine-ui y xine-lib, una especie de SDK que contiene una librería basada en la xine-lib para acceder a las capacidades de driver de VIA, así como unas aplicaciones de referencia y unos ejemplos. Desafortunadamente, tras compilar e instalar este engendro lo único que podemos obtener es un Segmentation fault:

# xine
This is VeXP (VIA Enhanced XINE Player X11 gui) - a free video player v0.99.3.
(c) 2000-2004 The xine Team.
Segmentation fault

Y no debe de ser cosa de la libxine, porque si la usamos con el totem podemos reproducir películas sin problemas pero sin aceleración. Es de suponer, por tanto, que la aceleración la activa de alguna forma, el xine-ui.

El tema del Segmentation fault le pasa a bastante gente de momento, como podemos leer en el hilo de los foros: VeXMP5 on Ubuntu Feisty, con comentarios incluso de un ingeniero de VIA. Este hilo cuenta varias de las cosas de las que vamos a hablar en las siguientes líneas.

Sólo nos queda, por tanto, el VeMP para poder obtener la tan ansiada aceleración de vídeo por HW. Descargamos las fuentes, las descomprimimos en /usr/src/VeMP-v1.5 y en teoría, debería ser tan sencillo como ejecutar el script VeMP-quickinstall.sh… pero ¿desde cuándo VIA nos lo va a poner fácil?

Resulta que en el código redefinen las funciones getline y round, lo que da problemas con las funciones oficiales. El error del getline aparece aquí:

cc -c -I../libvo -I../../libvo  -O4 -march=i586 -mtune=i586 -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64  -Ilibmpdemux -Iloader -Ilibvo -I/usr/include/freetype2   -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT        -o vobsub.o vobsub.c
vobsub.c:231: error: conflicting types for 'getline'
/usr/include/bits/stdio.h:103: error: previous definition of 'getline' was here

Así que tenemos que editar el fichero VeMP/vobsub.c y cambiar las dos veces que aparece “getline” en el código por cualquier otra cosa, como p.e. “getlinevemp“.

El error del round aparece aquí:

cc -c -I../libvo -I../../libvo  -O4 -march=i586 -mtune=i586 -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64  -I. -I.. -I../osdep -I/usr/include/freetype2 -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT    -I/usr/include/directfb -DMPG12PLAY  -o gtf.o gtf.c
gtf.c:28: error: static declaration of 'round' follows non-static declaration

Así que tenemos que editar el fichero VeMP/libvo/gtf.c y cambiar las 11 veces que aparece “round” en el código por cualquier otra cosa, como p.e. “roundvemp“.

Tras arreglar estos problemas, la compilación e instalación debería de finalizar sin otro inconveniente.

*******************************************
* The VeMP has been installed completely. *
*******************************************

For text mode users, please run "mplayer -vo vmifb <filename\playlist>".
For X window users, please run "mplayer -vo vmix11 <filename\playlist>".
The VeMP source code located at /usr/src/VeMP-v1.5/VeMP.

Como nos sugiere el script de instalación, a partir de ahora, para obtener la aceleración por hardware de MPEG, tenemos que usar la opción “-vo vmix11“:

# mplayer -vo help
MPlayer 1.0pre5-4.1.2 (C) 2000-2004 MPlayer Team

CPU: IDT/Centaur/VIA  (Family: 6, Stepping: 9)
Detected cache-line size is 64 bytes
CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2

Reading config file /usr/local/etc/mplayer/mplayer.conf: No such file or directory
Reading config file /root/.mplayer/config
Available video output drivers:
        xv      X11/Xv
        x11     X11 ( XImage/Shm )
        xover   General X11 driver for overlay capable video output drivers
        vmix11  X11 ( Via Mpeg Interface )
[...]

También podemos ponerla en el archivo ~/.mplayer/config:

 # cat .mplayer/config
vo=vmix11

Y por primera vez vemos en la salida del mplayer la famosa aceleración de MPEG2 y MPEG4:

==========================================================================
vo: X11 running at 1280x1024 with depth 24 and 32 bpp (":0.0" => local display)
Disabling DPMS

 HardWare Accelerate Supported: MPEG4 Yes, MPEG2 Yes
==========================================================================

Respecto a WMV9, entiendo que en Linux no haya aceleración, ya que al fin y al cabo demasiado hace el mplayer con usar dll’s de Windows para reproducirlo, ¡lo que no sé es si en Windows la habrá!

Ahora tenemos que tener en cuenta que este MPlayer hay que lanzarlo como root o no podremos usar la aceleración hardware, una limitación importantísima y grave problema de seguridad que VIA reconoce:

Because the limitation (non-root user fail to allocate memory at user space for video) of MPEG video driver the app (VeMP/VeXP) have to work at the root user mode.
The whole framework of VIA driver have to restructure at future version.
That is a big errort for VIA’s resources.
To fix this limitation has many obstacles to overcome.

Si intentamos usar el MPlayer con “-vo vmix11” con un usuario distinto de root tendremos el siguiente error:

MPlayer interrupted by signal 11 in module: preinit_libvo
- MPlayer crashed by bad usage of CPU/FPU/RAM.
  Recompile MPlayer with --enable-debug and make a 'gdb' backtrace and
  disassembly. Details in DOCS/HTML/en/bugreports_what.html#bugreports_crash.

Otra importante limitación es que la película sale siempre en primer plano, no siendo posible poner otra ventana por encima del reproductor de vídeo, como podemos ver en la siguiente captura (la película no sale en la captura porque el VeMP trabaja por overlay). Esto ocurre incluso ¡sin usar el driver vmix11!:

VeMP no sale en segundo plano

Y otra limitación: si tratamos de compilar y usar otras aplicaciones que usen el MPlayer por debajo, como por ejemplo el mplayer plug-in, para poder ver vídeos dentro del Firefox, simplemente no funciona. ¿Qué habrá cambiado VIA por dentro en el VeMP?

Por cierto, podemos ver que este mplayer usa la famosa librería de MPEG de VIA, aunque no esté funcionando como root:

# lsof | grep mpeg
mplayer   4111     vicente  mem       REG       22,1    359097    2179157 /usr/lib/libddmpeg.so
La S3 Utility

No olvidemos que con el driver también hemos compilado e instalado la S3 Display Utility, que podemos arrancar con el comando “s3utility” (con el usuario root), y con la que podemos configurar las salidas y los parámetros de la imagen:

S3 Utility Display S3 Utility Gamma

Nos podríamos preguntar dónde queda guardada esta configuración. El xorg.conf, desde luego, no es modificado por esta utilidad. En cambio, si nos fijamos en el directorio /etc/X11/, podemos ver que la primera vez que usamos el driver de VIA se crean unos ficheros vacíos .VIA*:

-rw-r--r--   1 root root     0 2007-10-09 13:05 .VIADuoView
-rw-r--r--   1 root root     0 2007-10-09 13:05 .VIAGAMMARC
-rw-r--r--   1 root root     0 2007-10-09 13:05 .VIARC
-rw-r--r--   1 root root     0 2007-10-09 13:05 .VIATVRC

Cuando comenzamos a usar la utilidad, dichos ficheros se van llenando (son ficheros binarios, la mayoría) y se crean unos pocos más .S3Utility*:

-rw-r--r--   1 root root   520 2007-10-09 13:07 .S3UtilityGammaSchemeFile
-rw-r--r--   1 root root   700 2007-10-09 13:07 .S3UtilityINFO
-rw-r--r--   1 root root   516 2007-10-09 13:07 .S3UtilityOverlaySchemeFile
-rw-r--r--   1 root root     0 2007-10-09 13:05 .VIADuoView
-rw-r--r--   1 root root  2742 2007-10-09 13:07 .VIAGAMMARC
-rw-r--r--   1 root root   516 2007-10-09 13:07 .VIAOVERLAYRC
-rw-r--r--   1 root root    22 2007-10-09 13:07 .VIARC
-rw-r--r--   1 root root    47 2007-10-09 13:07 .VIATVRC

En caso de tener problemas con el driver, puede venirnos bien tener esto en cuenta para borrar estos los ficheros y comenzar de nuevo.

El driver de framebuffer

No hay driver de framebuffer para los chipsets VIA más recientes en los kernels actuales. El driver VESA, que encontramos en:

Device Drivers → Graphics support → VESA VGA graphics support

y que conviene compilarlo fijo en el kernel, no como módulo, funciona bien, como en casi todos los sistemas. Algo lento, eso sí. Con él podemos usar la opción de inicio “vga=” y los Modos VESA aceptados por el kernel de Linux.

Si queremos usar un driver más específico, VIA tiene uno que sirve para la mayoría de chipsets, incluído el CX700M2, pero que, curiosamente, no sale en la página de drivers Linux para este chipset. Tenemos que buscarlo en la página de drivers Linux para el CN700: linux-fbdev-kernel-src_2.6.00.03a.tgz.

Este driver no tiene tanto problema para compilarlo. Comprobamos que tenemos las fuentes del kernel que estemos usando en /usr/src/linux, descomprimimos el driver en /usr/src, entramos al directorio y hacemos make y ya está.

El “make install” vuelve a copiar la archifamosa librería de MPEG, pone un fichero fb.modes a medida (cargándose el anterior sin preguntar, claro) e instala el módulo del kernel (y hace un depmod -a, claro):

 # make install
cp -a VIA-VMILIB/MDV2007FC4FC5/libddmpeg.so /usr/lib/
rm -f /etc/fb.modes
cp viafb.modes /etc/fb.modes
`viafb.ko' -> `/lib/modules/2.6.22.6-VIC/kernel/drivers/video/viafb.ko'

Para activarlo (viene documentado en el readme.txt) tenemos que cargar el módulo pasándole la resolución deseada:

# modprobe viafb mode=1280x1024 bpp=32 refresh=60 active_dev=DVI

En la salida del dmesg encontraremos:

VIA Graphics Intergration Chipset framebuffer 2.3 initializing
Console: switching to colour frame buffer device 160x64

Pero antes, tiene que estar el driver VESA desactivado, por lo que tenemos que arrancar el sistema quitando cualquier opción “vga=” que podamos tener.

Como con todos los drivers de framebuffer, también podemos cambiar la resolución posteriormente con el comando fbset.

Y no perdamos de vista que también podemos arrancar el servidor X usando el driver de framebuffer fbdev sólo con que pongamos en el /etc/X11/xorg.conf algo como esto:

Section "Device"
        Identifier  "Generic Video Card"
        BoardName   "via"
        VendorName  "VIA Tech"
        Driver      "fbdev"
EndSection

Sin embargo, aunque la aceleración de MPEG funciona, el movimiento de ventanas es muy lento y no se refrescan bien, el 3D no es acelerado y a veces se cuelga al cambiar a la consola. Así que lo dejamos en la sección de “curiosidades”.

Para concluir, comentar que la libddmpeg.so que lleva el driver de framebuffer es distinta de la que lleva el driver del servidor X, que es más reciente. Si hemos hecho un “make install” es posible que no funcione la aceleración de MPEG, según he comprobado. Podemos volver a poner la más reciente, pero en cualquier caso, casi vale la pena, si queremos probar el driver de framebuffer, usarlo desde donde lo hemos compilado con un “insmod viafb.ko” en vez de instalarlo.

La salida de TV

Como comentaba en la primera entrada de esta serie (Sobre las VIA EPIA (IV): Placas con procesador C7 / La EX10000EG), esta placa tiene varias salidas de televisión. Además, la BIOS está muy preparada para configurar qué dispositivo queremos que sea nuestro dispositivo primario desde el arranque.

Podemos documentarnos sobre los parámetros que afectan a la salida de vídeo en:

  • Para el driver openChrome, la página TV Out, el Via Unichrome TV Output HowTo y el “man 4 via“.
  • Para el driver de X de VIA, el “Installation.txt” incluido en las fuentes.
  • Para el driver de framebuffer de VIA, el “readme.txt” incluido en las fuentes.

La conexión a TV con el driver de VIA funciona muy bien, pero me temo que la salida de TV usando el chip VT1625 (el de las EX) no va bien del todo con el driver openChrome, como podemos leer en openChrome: TV Out, que nos remite a la página de parches para el VT1625:

Some VT1625 patches are also floating around. It would be nice to fill in a VT1625 tracker bug in track, in order not to loose them.
4/2/07 SVN rev 313 doesn’t work with any VT1625 using S-Video. Using the patch from Ken against revision 224 720x480Under works.

Si probamos esa versión 224 parcheada:

# cd /usr/src/
#  svn co -r 224 http://svn.openchrome.org/svn/branches/experimental_branch openchrome-experimental224
# cd openchrome-experimental224
# wget http://clients.teksavvy.com/~khuisman/openchrome/latestdiff
# patch -p0 < latestdiff 
patching file unichrome/via_vt162x.h
# ./autogen --prefix=/usr
# make

vemos que, desafortunadamente, aún no soportaba el chipset CX700:

(II) VIA: driver for VIA chipsets: CLE266, KM400/KN400, K8M800,
        PM800/PM880/CN400, VM800
(II) Primary Device is: PCI 01:00:0
(EE) No devices detected.

En concreto, en el estado actual del driver, parece que hay algún problema con la sincronización horizontal (de hecho, el parche lo que cambia son definiciones de algunos modos), como se aprecia en esta fotos que he tomado:

Driver openChrome:

TV Out driver openChrome

Driver VIA:

TV Out driver VIA

Al menos, el driver de VIA funciona bien para conectar la placa a una TV. Para activar la salida de TV, tanto en el driver de VIA como en el openChrome, sería suficiente con poner en la sección Device del /etc/X11/xorg.conf algo como esto:

Section "Device"
        Identifier  "VIA CX700M2"
        Driver      "via"
        Option      "ActiveDevice" "TV"
        Option      "TVType" "PAL"
        Option      "TVOutput" "S-Video"
EndSection

Si usamos el driver de VIA, también podemos dejar sin tocar la configuración actual del servidor X y activar la salida de TV usando la S3 Utility, que nos da mucha flexibilidad para configurarla, permitiéndonos modificar, entre otras cosas, el tamaño y la posición de la imagen en la TV:

S3 Utility TV S3 Utility TV Properties

Desde la S3 Utility no podemos cambiar la resolución, así que, a menos que usemos alguna utilidad gráfica para ello, tendremos que hacerlo editando directamente el xorg.conf. La EX (VT1625) tiene una resolución ideal para la salida de TV PAL, la 720×576. Sin embargo, no tiene la que tan bien me funciona con la SP (VT1623) para la TV 16:9, la 848×480, una auténtica lástima. Eso sí, el VT1625 tiene disponibles resoluciones de alta definición, cosa que otros codificadores de TV no tienen. Nos lo confirma el Instructions.txt del driver:

      2.6.5 Supported TV Encoder & Mode
 
         a. TV Encoder - VT1621
 
            mode:
                 640x480, 800x600 -
                           support 
 
         b. TV Encoder - VT1622(A)/VT1623
 
            mode:
                 640x480, 800x600, 848x480, 1024x768 ,720x480(NTSC Only),
                 720x576(PAL Only)-
                           support 
 
         c. TV Encoder - VT1625
 
                 640x480, 800x600, 1024x768 ,720x480(NTSC Only),
                 720x576(PAL Only), 1280x720(720P), 1920x1080(1080I) -
                           support

Pruebas: Gráficas de rendimiento de la aceleración MPEG2/4 por hardware

Para probar la efectividad real de la aceleración hardware de MPEG2/4 en la EX10000EG con el driver de VIA, he estado probando diferentes combinaciones de driver y reproductor. También he hecho algunas pruebas en mi SP8000E (una placa con procesador C3-2 de 800MHz -contra el C7 de 1GHz de la EX- y chipset CN400 -frente al CX700M2 de la EX-) para tener como referencia. En la SP está el driver normal de openChrome; ni el experimental, ni el de VIA. Este driver lleva muchos meses funcionando de forma muy estable en esta placa y sólo soporta aceleración de MPEG2.

Para las pruebas, he usado un DVD original de la película Minority Report copiado a disco como representante de MPEG2 y dos episodios de series distintas como representantes MPEG4. La primera tiene estas características:

VIDEO:  [XVID]  640x480  24bpp  25.000 fps  1118.0 kbps (136.5 kbyte/s)

y la segunda estas:

VIDEO:  [XVID]  608x336  24bpp  23.976 fps  1085.3 kbps (132.5 kbyte/s)

Aunque tienen características muy parecidas, la verdad es que la primera resulta algo más difícil de decodificar que la segunda. Ahora ya están las pruebas hechas, pero para el futuro me anoto el comprimirme yo mismo las películas de pruebas para tener control sobre los parámetros del codificador. En cualquier caso, nos sirven perfectamente para poder ver las diferencias.

Los valores de uso de CPU están tomados con el comando “sar -x PID 5 0“. Es decir, tomamos un valor cada 5 segundos. La película MPEG2 dura 130 min, la película MPEG4-1 46 min y la MPEG4-2 20 min. Para otra vez, también, me anoto medir el uso de CPU del proceso Xorg que, aunque no es excesivamente importante en ningún caso, hay aplicaciones/drivers que hacen consumir a este proceso más que otras.

Y pasamos ya a la primera gráfica:

Uso de CPU MPEG2

En ella vemos pruebas hechas con el MPlayer, el Xine, el VeMP y el Totem. En los tres primeros casos, siempre se usan las opciones para habilitar la aceleración hardware, aunque no esté disponible. El Totem es el reproductor multimedia del proyecto GNOME, que usa las librerías del Xine, pero al que yo no le he encontrado opciones para habilitar la aceleración, por lo que sirve de referencia como si fuera “Xine sin aceleración”. Además, todas las pruebas en la EX están hechas con el driver openChrome experimental excepto las del VeMP (no he podido hacer pruebas con el VeXP por el Segmentation fault).

En la gráfica vemos que:

  • En la EX, el Xine y el Totem tienen exactamente el mismo rendimiento, comportamiento esperado ya que el Xine no tiene aceleración en esta placa.
  • En la SP el Totem necesita más CPU que en la EX, ya que sólo usa la potencia del procesador inferior, pero, sin embargo, en la SP el Xine con aceleración nos da un resultado impresionante.
  • El MPlayer necesita mucha más CPU para reproducir MPEG2 que el Xine, usando aceleración o sin usarla. Podemos ver que MPlayer en la SP va mejor que en la EX porque saca provecho de la aceleración MPEG2, pero que en cualquier caso, va mucho peor que el Xine.
  • Los resultados del VeMP con el driver de VIA son absolutamente impresionantes. El proceso apenas se ve en la salida del top, pero no debemos de perder de vista que el driver openChrome con el Xine hace un trabajo sólo un poco peor en la SP.
  • Todas la líneas asociadas a aceleración MPEG (mplayer/xine en SP, VeMP en EX) son mucho más lisas que las otras. El uso de CPU apenas sufre alteraciones.

Pasemos ahora a la primera película MPEG4. En esta no hay prueba de Xine en la SP porque la placa no era capaz de reproducir esta película sin perder tramas (CPU >90% de uso):

Uso de CPU MPEG4-1

En la gráfica vemos que:

  • El Xine va bastante peor que el MPlayer para reproducir MPEG4
  • Aunque va ligeramente mejor, apenas se nota la aceleración de MPEG4 en la EX

Y la segunda película MPEG4:

Uso de CPU MPEG4-2

Las conclusiones, las mismas: Xine peor que MPlayer y la aceleración MPEG4 que no aparece claramente.

Sobre la aceleración MPEG4, hay una curiosidad… Vemos que el MPlayer normal con el driver openChrome funciona muy bien. Sin embargo, si usamos el VeMP y no especificamos el “-vo vmix11” sí que se nota muchísimo la mejora y que la aceleración MPEG4 hace algo.

La versión de MPlayer que uso normalmente es la última:

# mplayer -version
MPlayer 1.0rc1-4.1.2 (C) 2000-2006 MPlayer Team

Mientras que el VeMP está basado en una versión muy antigua:

# mplayer -version
MPlayer 1.0pre5-4.1.2 (C) 2000-2004 MPlayer Team

Y creo que eso puede tener muchísimo que ver en el mal rendimiento del VeMP (un MPlayer antiguo) con MPEG4 sin acelerar. En clave de VIA-ficción, es posible que si VIA sacara un nuevo VeMP basado en la última versión del MPlayer y activando la aceleración MPEG4, aunque sea a su manera, el resultado fuera increíble.

Conclusiones sobre la reproducción de vídeo en EPIA-Linux a la vista de los resultados
  • En general, es mejor usar MPlayer para MPEG4 y Xine para MPEG2
  • La aceleración por HW de MPEG2 funciona, y muy bien, en la SP con el driver openChrome normal y en la EX con el driver de VIA (y el VeMP, no tenemos otra forma de usarla)
  • El driver de VIA es un desastre… úsalo sólo si la aceleración de MPEG en una EX (y sólo por medio del VeMP) es importantísima para ti o el driver openChrome experimental es muy inestable en tu entorno y/o se cuelga mucho.
¿Es posible reproducir contenido en HD con esta placa en Linux?

¡Buena pregunta! Lo difícil es encotrar contenido HD para probar… Las muestras de vídeo en HD de Microsoft están en formato WMV, y hasta donde yo sé, los vídeos HD de Apple no se pueden descargar.

Los vídeos H264/MP4 de h264info.com funcionan en el MPlayer actual pero no con el VeMP este tan antiguo, por lo que no hay forma de probarlos con aceleración MPEG4 (sin ella, no son reproducibles).

Con los tres espectaculares vídeos HD 720p de Martin Microscope Company parece que el VeMP sí que puede, usando sobre el 70% de la CPU. Los vídeos son reconocidos así:

Playing FernWebVideo.mp4.
ISO: File Type Major Brand: ISO/IEC 14496-1 (MPEG-4 system) v2
QuickTime/MOV file format detected.
--------------
MOV track #0: 33 chunks, 1275 samples
MOV: Found MPEG4 movie Elementary Stream Descriptor atom (66)!
Image size: 1280 x 720 (24 bpp)
Display size: 1280 x 720
Fourcc: mp4v  Codec: 'mpegable'
--------------
MOV track #1: 20 chunks, 1993 samples
Audio bits: 16  chans: 2  rate: 48000
MOV: Found MPEG4 audio Elementary Stream Descriptor atom (39)!
Fourcc: mp4a
--------------
[...]
 
 HardWare Accelerate Supported: MPEG4 Yes, MPEG2 Yes
==========================================================================

¡Es importante asegurarse en la salida de que la aceleración funciona! A veces no lo hace y es mejor que reiniciemos las X, lo que debería de resetear el driver. Los vídeos anteriores, por ejemplo, sin aceleración hardware no se pueden reproducir.

En Digigami MegaPEG.X – Samples también hay algunos vídeos HD. Los vídeos MPEG2 Mako_Shark_Club_Jacket_720p_25fps_MPEG-2.mpg (720p) y Least_Likely_PSA_1080i.mpg (1080i), la aceleración del VeMP se los come, con usos de CPU por debajo del 20% en el primer vídeo y del 15% en el segundo vídeo. Sin embargo, con el mismo vídeo en MPEG1, Mako_Shark_Club_Jacket_720p_25fps_MPEG-1.mpg, no puede.

Por tanto, yo diría que en MPEG4, probablemente esta placa no pueda hacer 1080p, pero yo creo que un vídeo MPEG2 en 1080p sí que estaría a su alcance.

Sin embargo, el driver openChrome, cuando la aceleración por XvMC está soportada, no puede con vídeos de más de 1024×1024 en la mayoría de los casos (openChrome: Hardware Caveheats), lo que no sería suficiente para 1080p. ¿Tendrá el driver de VIA la misma limitación? Según [Openchrome-users] CN700, XvMC and HDTV, es una limitación hardware, así que posiblemente, sí. El enlace lo he encontrado en la entrada de Ringmaster: Tutorial: Proyecto reproductor multimedia Reloaded que trata, entre otras interesantes temas, de la alta definición en un chipset CN700.

:wq

Entradas relacionadas

47 Comentarios a “Sobre las VIA EPIA (VI): Gráficos y vídeo acelerado por HW en Linux con la EX10000EG”

  • Sagman dice:

    Menudo curro para hacer todo esto joder :o . Felicidades por el artículo, es excelente y me aclara muchas dudas que tenía acerca de estas placas jejeje.

    Por cierto me he reido con esto:
    Y ahí es donde nacen el VeXP (VIA Enhanced Xine Player) y el VeMP (VIA Enhanced Mplayer), que podrían haber llamado también “MPlayer Chapuza Edition” o Xine damaged by VIA“. Ambos proyectos están hospedados en sourceforge.net, VeMP y VeXP.

    xD

    A ver si el driver Openchrome mejora o los de Via se lo curran algo más :P

    De nuevo, mis más sinceras felicitaciones.

  • Sagman La verdad es que sí que ha costado un poquillo, sí ;-)

    ¡Me alegro mucho de que te haya gustado! ¡Y gracias por la visita! :P

  • Ringmaster dice:

    ¡Gracias por este informe tan detallado!! Como ves está muy bien que la arquitectura gráfica esté más o menos abierta, pero como vemos con el controlador 3D, si no hay programadores que desarrollen el tema (al ser estas placas minoritarias), no tenemos tampoco controladores apropiados para 3D, ni abiertos ni cerrados. Sí, ya se que la potencia 3D es pobre, pero para acelerar los efectos de AIGLX estaría bien. Un saludo!

  • MarioDebian dice:

    La de años pegándome con este driver, ¡qué recuerdos!

    Felicidades y gracias por el pedazo de curro en este artículo.


    Ex usuario de VIA KM400

  • Ringmaster ¡Muchas gracias! Pues sí, tienes toda la razón del mundo en que aunque el 3D de estas placas no sirva para juegos, al menos poder usar el AIGLX sería genial.

    MarioDebian Ya veo que eres un ex del club de sufridores de VIA, así que cuentas con toda mi simpatía ;-) ¡Muchas gracias a ti por la visita!

  • Iván dice:

    ¡Pedazo de artículo!. Menudo curro!. Muchas gracias por compartir todo esto con nosotros. Si alguna vez me decido por una placa como esta tengo en tu blog una gran guía de referencia.

    Saludos, Iván.

  • Iván ¡Muchas gracias a ti por la visita!

  • Packo dice:

    Muy bueno, muchas gracias. Es muy completo y exacto y me resuelve un buen problema.
    Un saludo!.

  • Packo ¡Me alegro de que te haya ayudado!

  • Un artículo de campeonato. Me ha gustado mucho, y me ha despejado algunas dudas sobre estas placas. Me gustaría echarle el guante a alguna y repetir tus pruebas con Windows… me sigo preguntando si con software propietario llegan a soportar vídeo HD.

  • tendero-digital ¡Muchas gracias! Hace tiempo en la SP yo tuve Windows con Media Center algunas semanas y cuando conseguí que me funcionara bien la aceleración de vídeo dentro del WMC, cosa que no fue fácil, iba muy bien para reproducir vídeo de definición normal.

    Con la EX, ya he puesto links de gente de los foros que no está contenta del todo con las capacidades de reproducir HD en esta placa. Como ya he dicho anteriormente, aunque su hardware sea bueno, los ingenieros que hacen el software (drivers, BIOS) son un desastre que a veces echan por tierra el esfuerzo de los ingenieros de hardware.

  • Ringmaster dice:

    Gracias por el enlace, Super Coco. Por cierto, ¿probaste la aceleración 3D con los controladores de via? ¿es estable? Con el driver Mesa (openchrome) mi CN700 se cuelga aleatoriamente con 3D. El kernel no se bloquea, sino sólo el servidor X (con lo que no responden ni ratón ni teclado, pero la red y el disco duro siguen haciendo las tareas que estuvieran haciendo), y sólo pasa cuando usas algo que utilice OpenGL. Hay multitud de bugs abiertos en p.e. Launchpad (ubuntu) sobre los problemas con la serie de gráficas Unichrome PRO IGP (no sé cómo habilitan el 3D si los controladores tienen bugs graves).
    Por otro lado si VIA da el código fuente completo de sus controladores es un problema que la comunidad no tenga los recursos para desarrollar uno “bien hecho”, cosa que no pasaría con ATI o nvidia ya que son más utilizadas :( .
    Voy a ver si ofreciendo 60 euros al desarrollador que arregle los cuelgues actuales (he llegado a estar usando 3D durante media hora, pero siempre se cuelga por lo que los errores no son generalizados) a ver si alguien se anima y me evita cambiar de hardware… Si aportamos algo entre todos seguro que se arregla, como la llamada que hizo el proyecto nouveau cuyo objetivo es crear controladores abiertos para nvidia (sus tarjetas utilizan controladores unificados, esto es, los registros hardware no difieren en la misma serie, sino que se amplían).

  • Ringmaster Tienes toda la razón del mundo. Es una auténtica lástima que siendo el driver de VIA de código abiero (o al menos todo menos el libddmpeg.so) no haya suficientes recursos en la comunidad para tener un driver mejor basándose en él. Al menos existe y eso mantiene la esperanza de que el soporte a estos chipsets mejore. Tu iniciativa de contribuir económicamente al desarrollo del driver es altamente loable.

    Respecto al 3D, yo probé el TuxRacer (planetpenguin-racer en Debian) un ratillo con FPS aceptables. Coméntame qué aplicación 3D sueles usar tú y puedo hacer la prueba.

  • Ringmaster dice:

    He creado un hilo para esto (es un problema tan extendido como las luces rojas de la XBOX 360 ;-) ) ofreciendo 60 eurillos por la causa. Por ejemplo Crossover office utiliza este método para canalizar los esfuerzos de compatibilidad en aplicaciones, Ubuntu podría usarla y así también se podría financiar (siempre que los objetivos sean posibles y loables; animaría a desarrolladores “del lado oscuro” a ganarse un extra, aprender el sistema del futuro, etc).

    La aplicación que he estado probando (aunque con todo me pasa lo mismo, el 3D me funciona felizmente hasta que hace no sé qué cosa y el servidor X se congela) ha sido el pSX emulator, que utiliza opengl para mover todo, no necesita plugins, funcionan bastantes juegos de la play y la emula a la perfección, sin mejoras ni gaitas. Por otro lado, ¿por qué puñetas tiene que estár el teclado controlado por el servidor X? ¿No sería mejor que lo controlara el kernel, como otros sistemas de entrada/salida como los puertos com o al menos que fuera un servicio independiente? (no me hagas caso, ya estoy empezando a pensar como un ingeniero de Miclosof).

    El link del hilo es el siguiente:

    http://ubuntuforums.org/showthread.php?p=3542162#post3542162

    Y del pSX emulator:

    http://psxemulator.gazaxian.com/

    No sé, si te funciona el 3D durante una hora seguramente no se bloquee (nunca me ha durado tanto), yo probaría con un salvapantallas 3D.
    Es una pena, con la Sis300 de mi anterior placa VIA todo funcionaba (lo mantenía otro héroe del código abierto; Thomas Winischhofer http://www.winischhofer.net/) menos a pantalla completa que tenía un bug y la pantalla desplazaba la mitad hacia arriba, dejando la parte de abajo negra…

    Ah! Y bonito avatar. (Así se distingue mejor al moderador de los demás).

  • Ringmaster ¡Gracias por el link a esta entrada en ese hilo del foro! He de decir que me ha gustado mucho como lo has explicado todo y lo bien documentado que lo has presentado. ¡Impresionante!

    Probaré a ver si a mí también me ocurre el problema. Como yo no tengo juegos de PSX, intentaré ver si el TuxRacer se puede dejar en algún modo que funcione solo o si encuentro algún salvapantallas 3D y lo dejaré un buen rato.

    Gracias por lo del avatar. Estoy intentando vectorizarlo con el InkScape, como tú contaste en tu blog :-)

  • Ringmaster dice:

    Gracias! La verdad es que es lo menos que podía hacer después de pelearme toda la tarde de ayer con el servidor X y las opciones intentando que funcionara el emulador para un viejo juego que tenía por ahí y que tanto a mi mujer como a mi nos encanta, el Super Puzzle Fighter II, y al final me dió tanta rabia haber perdido el tiempo (el pSX necesita una supercomputadora si no tienes Opengl) y no haberlo pasado con ella jugando a otra cosa (al scrabble, no seais mal pensados ;-) )…

    Y por otro lado, ¿te servirá para la web el vectorizado? (es decir, ¿podremos verlo o necesitamos el Firefox 3?)

    Y debajo podría poner: SuperCoco, defensor de causas perdidas… o Supercoco al rescate! jejeje

  • Ringmaster dice:

    Finalmente he dado con un “hack” estable aunque temporal (al menos para pSX emulator), como comentabas en este exhaustivo análisis, el estado de la aceleración deja que desear en estas tarjetas y hay regresiones ‘For now you should use the Mesa-6.4 branch; the last version known to work sort of reliably is Mesa-6.4.1′, por lo que seguí las indicaciones de Khowe en los forums de Ubuntu (traducido):

    [Tuve el mayor éxito con Ubuntu 6.10 edgy. Feisty y Gutsy causan bloqueos, cuelgues siempre que arranco una aplicación 3D. Tengo un portátil averatec 3715.

    Encontré este error en la lista de Bugs Ubuntu @ https://bugs.launchpad.net/linux/+bug/43154

    No sé si tengo el mismo problema,:
    Todo me funcionaba bien hasta Feisty.
    Mi tarjeta es una KM400 y desde Feisty tengo bloqueos completos (pero el ratón todavía se podia mover) cuando corría CUALQUIER aplicación 3D. Incluso un simple glxinfo congelaba el sistema.
    No encuentro mensajes de error en los logs y puedo iniciar el servidor X con “via” especificado en xorg.conf pero tan pronto como se requiere 3D la diversión se acaba.

    Resolví este problema bajando la versión de libgl1-mesa-glx y libgl1-mesa-dri desde 6.5.2-3ubuntu7 (Feisty) a 6.5.1~20060817-0ubuntu3 (Edgy).

    Mi tarjeta nunca ha funcionado por defecto, incluso aunque Ubuntu la reconoce en el proceso de instalación (que lo hace desde Edgy, supongo).
    Opciones adicionales que siempre he necesitado para que funcione son:
    Option “VBEModes” “true”
    Option “DisableIRQ”
    Option “EnableAGPDMA”]

    (colocar en la sección “Device” de tu tarjeta gráfica en xorg.conf)

    Estas versiones se pueden descargar de: http://packages.ubuntu.com/edgy/allpackages
    Después instalarlos (desde la carpeta donde los tengas descargados)
    sudo dpkg -i ./libgl1-mesa-glx ./libgl1-mesa-dri

    Claro que esto se deshará en cuanto actualices el sistema… Al menos sabemos que las librerías de rutinas de operaciones gráficas se han actualizado al contrario que el controlador OpenGl, que sigue llamando a las rutinas con parámetros incorrectos? pero con mis pequeños conocimientos no creo que lo solucione… aaaaahhhh

    Bueno, al menos puede servir a los desesperados.

  • Ringmaster ¡Muchas gracias por tus aportaciones!

    Ayer estuve un rato jugando al TuxRacer con el driver de VIA y sin problemas. Luego instalé los paquetes xscreensaver y xscreensaver-gl y dejé funcionando un salvapantallas 3D (estuve probando varios y al final dejé el “Queens”) durante más de una hora. Sin problemas tampoco. Luego cambié el driver de VIA por el openChrome y dejé el “Queens” otra hora y sin problemas tampoco.

    ¿Tú puedes tener el salvapantallas “Queens” funcionando una hora seguida?

    Mi versión de Mesa es la estándar de Debian Etch, la 6.5.1 (la que según comentas funciona bien):

    # dpkg -l | grep mesa                                                                                           
    ii  libgl1-mesa-dev      6.5.1-0.6      A free implementation of the OpenGL API -- G
    ii  libgl1-mesa-dri      6.5.1-0.6      A free implementation of the OpenGL API -- D
    ii  libgl1-mesa-glx      6.5.1-0.6      A free implementation of the OpenGL API -- G
    ii  libglu1-mesa         6.5.1-0.6      The OpenGL utility library (GLU)
    ii  libglu1-mesa-dev     6.5.1-0.6      The OpenGL utility library -- development su
    ii  mesa-common-dev      6.5.1-0.6      Developer documentation for Mesa
    ii  mesa-utils           6.3.2-2.1      Miscellaneous Mesa GL utilities

    Sí que es cierto que, como cuento en la entrada, si instalabas el drm de desarrollo:

    git clone git://anongit.freedesktop.org/git/mesa/drm

    el driver se colgaba muchísimo. Pero incluso sin usar el 3D ni nada…

    De las opciones que muestras, la VBEModes suele se muy importante, como podemos leer en el “man via“:

    Option "VBEModes"  "boolean"
    
    Uses the VBE BIOS calls to set the display mode.  This mimics the behaviour of the vesa video
    driver  but still  provides acceleration and other features.  This option may be used if your
    hardware works with the vesa driver but not with the Openchrome driver.  It may not work on
    64-bit systems.  Using "VBEModes" may speed  up  driver  acceleration  significantly due to a
    more aggressive hardware setting, particularly on systems with low memory bandwidth.  Your
    refresh rate may be limited to 60 Hz on some systems.

    La DisableIRQ curiosamente puede causar problemas en el DRI:

    Option "DisableIRQ"  "boolean"
    
    Disables  the Vblank IRQ.  This is a workaround for some mainboards that have problems with
    IRQs from the Unichrome engine.  With IRQs disabled, DRI clients have no way to synchronize
    drawing to  Vblank. (This option is enabled by default on the KM400 and K8M800 chipsets.)

    Y la EnableAGPDMA es totalmente necesaria:

    Option "EnableAGPDMA"  "boolean"
    
    Enables  the  AGP  DMA  functionality in DRM.  This requires that DRI is enabled and will force
    2D and 3D acceleration to use AGP DMA.  The XvMC DRI client will also make use of this on
    the  CLE266  to consume much less CPU. (This option is enabled by default on all chipsets
    except the K8M890 and P4M900.)

    Bueno, ya ves en la entrada que yo tengo la primera y la tercera puestas.

    Por cierto, para cambiar fácilmente de driver, yo lo que hago es tener en /usr/lib/xorg/modules/drivers/ un via_drv.so.oc y un via_drv.so.via y en /etc/X11/ un xorg.conf.oc y un xorg.conf.via (e incluso un xorg.conf.via_tv) y, con el servidor X parado (si no, lo tiraremos), pongo lo que me interese fácil y rápidamente con scripts a tal efecto.

    Por cierto, me encanta el Super Puzzle Fighter :-) ¿Has probado a jugarlo en MAME?

  • Ringmaster dice:

    Sí, creo que era conveniente resumir todos nuestros comentarios en una entrada ;-), y ayudar a más gente. Gracias por el enlace, de nuevo.
    Por otro lado comentas que esas opciones se activan por defecto, pero a mí nunca se me han activado (debe ser tarea del xserver y no lo hace)… no sé.

    Por cierto, sí que se aceleran bastante los gráficos, con la primera y tercera opción; de ir un poco a saltos pasó a ir totalmente fluido el Puzzle Fighter. Jeje, no sabía que tú también le dieras a los videojuegos de vez en cuando…

    Lo del MAME, supongo que lo dices por la versión recreativa, ¿no? Lo probaré. Gracias por todo. Eres un crack.

  • Ringmaster No sólo de Linux vive el hombre, a veces también hay que echar alguna canita lúdica al aire ;-) ¡Gracias a ti por tu colaboración!

  • Batalla dice:

    Hola a todos,
    En primer lugar queria darte la enhorabuena por el Blog. He buscado mucha información acerca de las VIA EPIA, y esta web es de las mejores que he encontrado.

    Estoy interesado en hacerme con una de estas placas, en concreto la EX10000EG, para fabricarme un reproductor multimedia (ver DVD, TV por satelite, grabar programas de TV, etc). La primera duda que tengo es dónde comprar la placa. Me he puesto en contacto con Ibertronica que son los distribuidores en España, pero les veo un precio excesivo, así que he pensado que aprovechando la situación del euro respecto al dólar podría comprarlo en EEUU a un precio más bajo. El problema es que no conozco ninguna tienda online de Estados Unidos en la que se pueda confiar y que tenga buenos precios. ¿Sabeis donde puedo comprar la placa a un buen precio?

    Otra duda que tengo es acerca de la tarjeta de TV por satelite. He visto que algunas incorporan aceleración por hardware de MPEG y no sé si sería conveniente comprar una de estas, ya que la VIA EPIA también incorpora este tipo de aceleración ¿creeis que merece la pena, o con la aceleracion de la EPIA sería suficiente?¿permitirá ver HDTV con el chipset incorporado en la placa?

    Gracias por todo y enhorabuena de nuevo.

  • Batalla ¡Muchas gracias!

    En Ibertrónica parece que la EX1000EG vale 228€ (IVA inc.) ahora mismo. Cuando yo compré mi SP lo hice en Alternate, que tenía un precio mucho más bueno (como 60€ menos, si no recuerdo mal) que Ibertrónica. Fíjate que pedí la caja en Ibertrónica y me compensó comprar la caja en un sitio y la placa en otra y pagar gastos de envío en los dos sitios. Sin embargo, Alternate parece que ya no vende placas EPIA.

    Por lo que he leído en foros por ahí, me da la sensación de que la mejor tienda de placas EPIA en Internet es LogicSupply, pero parece que sólo mandan a EEUU y Canadá. La EX10000EG la tienen a 267$ que, aplicando un cambio de 1.4, sale a 191€. También está Mini-ITX.com (tienda del Reino Unido), que tiene la EX1000EG a 191€ y envían a España. Con el IVA de allí (que es una pasada, 17.5%) y gastos de envío sale por 257.20€, aún más barata que en Ibertrónica a la que le tienes que aplicar sus gastos de envío. En agalisa.es también tienen algunas placas EPIA, pero son todo modelos muy antiguos.

    Respecto a la aceleración hardware, si has leído detenidamente la entrada, podrás ver que en el driver openChrome aún no funciona y en el driver de VIA, sólo el VeMP puede usarla (el MythTV, por ejemplo, no puede). Por ello, igual te interesaría pensar en una EPIA con chipset CN700.

    Sobre una capturadora con aceleración MPEG2, puede ayudar, pero te tienes que asegurar de que esté bien soportada. Mira lo que dice la documentación del MythTV al respecto:

    If you have a Via M10000 series or a Hauppauge PVR-350, MythTV can use the hardware-based video decoder for playback, which further reduces CPU requirements.

  • maxy dice:

    se puede correr el escritorio 3d con esto…

  • @maxy Puedes leer en la entrada que hasta donde yo he probado, no, ya que el driver 3D no proporciona las extensiones necesarias.

  • Tostadilla dice:

    Buenas Supercoco, geniales post. Una gran aportación, sobre todo por la poca documentación que hay de las prestaciones de las mini-itx.

    Yo le he hechado un ojo a esta tienda, que parece ser también bastante barata: mini-box

    Además, he encontrado tres cacharros que me llaman bastante la atención:

    El Elite C7VCM con un VIA C7 1.5Ghz y lo curioso, DC-DC power on board, osea que no hace falta ni ponerle un picoPsu, por solo 69.50$ (47€ al cambio). Aunque me da miedo, si los componenetes del Jetway según Ringmaster ya eran cutres, los de este tienen que ser tremendos.

    También me he fijado en los Intel D201GLY por otros 69.50€. Nada de particular, salvo que toda la placa y el micro son de intel, integrados. Calidad asegurada, y segun parece con bastantes buenas prestaciones. Me hecha un poco para tras que el consumo es algo mayor, 28 Kw en idle (aunque ya me he asustado con los 50Kw del jetway O_OU).

    Por otro lado, totalmente distinto, son curiosas las ALIX de PC Engine. Con todo incluido, Los 256 MB de ram, conversor DC-DC y un micro muche menor, AMD Geode LX800 de 500 MHz, con la coña de que… consume solo 5W!! ¿Con esas prestaciones podrá correr decentemente los programas P2P (sobre todo aMule, que tira bastante)? Por que si es así, me parece el producto definitivo para estas cosas, ya que total, como media center, los VIA ya veo que no sirven :-/

    Bueno, decidme que os parecen, uno de los 3 cacharros me compraré, seguramente. Cuando lo haga posteare mis impresiones.

    Un saludo y tal :)

  • @Tostadilla No habiendo yo personalmente probado ninguna de las tres, no me siento en condiciones de aconsejarte con argumentos en la mano. Mis sensación es:

    - La Intel → Calidad asegurada y soporte seguro de todos los componentes en Linux.

    - La ALIX → Consumo muy muy pequeño pero bastante cara dadas las prestaciones aunque ya lleve algo de memoria (256MB es bastante poco, en mi opinión), pero puede ser suficiente para P2P.

    - La Elite con VIA C7 → Bien en tanto que te ahorras pagar por la fuente (aunque muchas cajas Mini-ITX ya la llevan) y bien también porque el consumo es algo menor.

    Yo creo que de entre las tres, me decantaría seguramente por la Intel a menos que el consumo fuera un factor muy decisivo. En tal caso, la VIA podría ser muy buena opción, porque probablemente la ALIX se te pudiera quedar pequeña según el uso.

    Si te interesa la ALIX como sistema de bajas prestaciones pero muy bajo consumo, ¿no te has planteado un NSLU2 que se puede comprar muy fácilmente en España y hay una buena comunidad a su alrededor?

  • Tostadilla dice:

    Hey, gracias por contestarme. Yo lo que de verdad estoy intentando es separar la reproduccion de peliculas y la descarga de p2p del ordenador. Las peliculas por que me interesan que se reproduzca en el televisor como debe ser y el p2p, por que es absurdo tener un ordenador que consume 140W toda la noche encendido. Soy un recien independizado y ya me he asustado con la factura.

    Al NSlug ya le heché un vistazo en su momento. El problema que le veo es que por 75€ que cuesta, por lo que he leido va muy ajustado para el p2p sobretodo con aMule. El ARM de 266MHz y 32Mb de SDRAM se puede overclockear pero pfff, No me gusta meterme en esas cosas. Además, que no tenga procesador gráfico y tengas que depender de otro ordenador…

    Encontré una tienda española con precios realmente ajustados que vendian el ALIX por 99€. Junto con la fuente de alimentación, por 107€ tengo todo lo necesario (la caja me la haré yo de madera para que haga juego con los muebles ;)). La reproducción de videos se puede hacer cargo esta pequeña maravilla con nucleo linux: el Popcourn Hour.

    La verdad es que el Intel me ha tentado sobremanera. Pero al final sale practicamente por 300$ (Placa+memoria RAM+alimentación+gastos de envio). Ni su consumo es tan bajo ni sus prestaciones con video son tán buenas. Para eso por poco más puedo tener un ALIX y un Popcorn Hour en lo que mejor saben hacer cada uno.

    Por cierto, ¿has visto el iMedia linux?

  • @Tostadilla Pues no conocía la distribución iMedia Linux pero me parece interesante. Si puedo la probaré. Gracias por mencionarla. ¡El Popcorn Hour ese también tiene una pinta extraordinaria!

    Otra alternativa que te puede interesar es un eTC de los que distribuye la empresa española EPATec del fabricante eBox.

    Si finalmente te compras la ALIX ya nos contarás si quedas contento…

  • Tostadilla dice:

    Pues es atrayente también ese eTC, pero finalmente creo que si me pillaré un combo ALIX+Popcorn Hour. Justo cuando has escrito, me llego mi turno en la kilometrica lista de espera de este aparato (llevaba mes y medio esperando y no me lo mandarán hasta mediados del proximo :P). Al final no he podido aguantarme y lo he pedido. Así que de primeras me pillaré este y con mi próximo sueldo el ALIX con dos puertos ethernet para poder conectar directamente los dos cacharros y reproducir en streaming sin el cuello de botella del router.

    Por cierto, finalmente el Popcorn Hour sale por unos 150€ (cacharro + gastos de envio)
    Ya os contaré que tal sí ;)

    Un saludo.

  • cHemarY dice:

    El driver openChrome:

    Una vez todo me iba de maravilla, hasta que decidí poner el google-earth. Entonces vi que se quedaba colgado al iniciarse, busqué información del por qué y vi que era problema de los driver.

    Abrí el synaptic y como tenía el openchrome, que hasta ese momento para las nacesidades que tenía me iba de maravilla creyendo erróneamente como mas adelante he comprobado que era el adecuado, y decidí poner el repositorio xserver-xorg-video-via que al no ser compatible con el xserver-xorg-video-openChrome me quitó las libreriás de las que dependía.

    Me he bajado el paquete de la pagina oficial http://www.openchrome.org/, pero está en deb. En live cd no me deja instalarlo y en modo consola sin el live cd no se como hacerlo.

    Ahora me encuentro en que no abre en modo gráfico solo en modo consola, no se como instalar el xserver-xorg-video-openChrome ni donde buscarlo, pues cuando introduzco mi login y password y hago sudo aptitude xserver-xorg-video-openChrome, no me instala porque no sé como hacer la conexión inalámbrica en modo consola. Si no fuese posible conectar a internet, ¿de donde me bajo el xserver-xorg-video-openChrome y como lo instalo?

    Estoy usando el live cd 7.10.

    Muchas gracias.

    Mi email es: el.chemary@gmail.com

  • @Tostadilla Después de comentarme tú aquí lo del Popcorn Hour lo he visto mencionado en varios sitios. ¡La verdad es que es un aparato impresionante! Me gustaría mucho saber cómo te va tanto con él como con el ALIX.

    @cHemarY Lo puedes encontrar en:

    http://packages.ubuntu.com/source/gutsy/xserver-xorg-video-openchrome

    y para instalarlo tienes que hacer: “dpkg -i fichero.deb

  • anonimous dice:

    Buen articulo…

  • Fernando Ruza dice:

    Hola, lo primero decir que buenisimo articulo … mi enhorabuena, tiene mucho curro.

    Queria preguntarte una cosa. Estoy en proceso de hacerme un cliente de MythTV y había pensado hacerlo con una placa VIA EPIA EX10000EG pero despues de leer el articulo estoy valorando otras opciones. Lo mas importante para mí es que funcione bien en cuanto a velocidad en la gráfica, que funcione la aceleración mpeg2/4 pero como he leido veo que esto esta aún verde. ¿que opción me aconsejas mejor entonces para lo que quiero? una VIA EPIA EN12000EG por ejemplo que lleva chipset CN700 y parece que esta mejor soportado aunque prefería algunas de las caracteristicas de la placa EX10000EG como la salida DVI, y SPDIF opticas.

    Estoy empezando a mirar las placas de las que hablais de Intel, las jetway y las ALIX pero lo que mas me interesa es la aceleración gráfica y decodificación por hardware de mpeg2/4 y de estas otras placas no se por cual decantarme ahora.

    Saludos.

  • Tostadilla dice:

    Muy buenas. Ya tengo en mi poder tanto el Popcorn Hour como el ALIX. Os hago una breve review, tengo pensado montarme un blog y hacer una buena revisión por que los cacharros lo merecen y sobre todo del ALIX apenas hay información en la red:

    De primeras, el Popcorn Hour. Me sorprendio por que viene ya de serie con cable de alimentación adaptado a la normativa española, no hace falta adaptador :) y bueno, tiene cosas buenas y malas.

    En reproducción de videos es brutal. Reproduce perfectamente videos desde Pendrive, discos duros externos o tirando de red, sean divx normales o peliculas HD, y con subtitulos. La reproducción de música es un tanto chusca. Tarda un buen rato en ponerse a reproducir mientras te enseña fotos de peces ¿? y sin ningun tipo de información (ni siquiera el numero de canción ni el tiempo, solo fotos de peces :P) Los servicios web son un tanto regulares, el mejor sin duda el de youtube, permite incluso poner tu cuenta para reproducir los videos que tienes guardados, pero un 0 patatero en el resto. De las radios online tiene el 360 que no funciona y una serie de radios preestablecidas, que funcionan pero no puedes añadir las tuyas propias (y no estan las de SomaFM!)

    Osea, que por ahora… y hasta que liberen en firmware (si acaso lo hacen, es un tanto ambiguo la información al respecto)el Popcorn sirve para videos, cualquier video y de puta madre, pero casi solo para eso. Por cierto, al instalarle discos duros dentro (necesario para usar el bittorrent) me dio problemas, segun leí, por que tienen que estar perfectos, es muy quisquilloso para eso, y yo le meti los discos duros viejos que ya no usaba :P). Aún así, para lo que necesitaba, fue una buena compra.

    Sobre el ALIX (120 euros con el iva), es curioso, viene sin manual ni cables ni nada, solo la placa, me he tirado una buena semana santa (en vez de hacer trabajos :P) probando cosas y por ahora la unica distro que me funcionó a la perfeccion es el Puppy. Y practicamente a la primera, tiene una instalación idonea (“instalar el sistema en un CF por USB que luego se usara como CF IDE” y el sistema en si esta desarrollado para no quemar demasiado este tipo de unidades flash) Por lo que he probado, puedo cargar el navegador (viene con SeaMonkey, un tanto pesado, pero bueno), el transmission(torrents) y el lastfm perfectamente, pero solo dos de las tres opciones si quiero que vaya fluido. Ni pensar en reproducir youtube. Eso si, el Puppy es feisimo XD, viene con el jwm y el ROX que deben ser el Windows manager y el file manager más feos de la scene linux. al cambiar a XFCE se ve de lujo pero va más lento, con el solo puedo hacer fluidamente una de las tres opciones que antes he dicho. Y el sonido es bueno, si no subes el volumen a tope, entonces petardea. Es mejor dejarlo a un 75% como mucho y subir el volumen de los altavoces.

    La distro que me ha parecido más idonea es el Tinyflux: Fluxbox como windows manager, Thunar como gestor de archivos con automontaje, synaptic para los paquetes y un nucleo basado en PClinuxOS perfecto para detectar hardware. La pena es que su instalador es una patata y solo funciona bien con la tipica de instalar en disco duro.

    Damm Small Linux ni si quiera funcionaba en mi ordenador como para montar la distro en el CF.

    iMedia es de pago y con una licencia que no me gustaba nada (cada 6 meses o pagas la nueva versión o te quedas sin actualizaciones, cara me iba a salir la cosa) ademas de que lei que no tenia sistema de paquetes para añadir cosas.

    Voyage Linux es un debian pensado para estos cacharros pero para usar como servidor, sin entorno grafico, se instalo bien pero en el login me dio un fallo que me impedia poner acceder como ningun usuario ni como root :P.

    Y Debian a palo seco tiene una opcion muy curiosa para poner el instalador en un pendrive, falla la mitad de las veces a la hora de instalar y falla otras tantas a la hora de añadir paquetes. Nu se. Ahora utilizaré el sistema de debian para probar otras distros desde el pendrive, pero a saber. Jor, que frustración, me veo que acabo con el Puppy. XD

    Y si, mis conocimientos de Linux son un tanto tristes, si no seguro que no tendria tantos problemas :P.

    Enga, un saludo.

  • @Fernando Ruza ¡Gracias!

    Se supone que en las placas con chipset CN700 la aceleración MPEG2 funciona bien con el driver openChrome, pero no te lo puedo decir seguro porque no tengo una. En el chipset CN400 sí que funciona bien. La aceleración MPEG4 sólo funciona bien con el driver de VIA y su mplayer propietario. Sobre el resto de placas, me temo que no te puedo decir nada de primera mano…

    En la entrada se explica lo que hay con las VIA EPIA… puede ser que te sirva y es posible que cambie en el futuro, pero ¡también es posible que no!

    @Tostadilla ¡Muchas gracias por tu detallada explicación! La verdad es que viendo cómo te explicas y lo interesantes que son tus cacharrillos, no deberías dejar de abrir un blog y contárnoslo detalladamente. Si finalmente te animas, no dejes de publicar la dirección aquí mismo y la añadiré a la sección de enlaces.

    Sobre arrancar Linux desde USB, no sé si te puede ser útil la entrada de: Arrancar Knoppix desde una memoria USB usando SYSLINUX. Aunque sólo tengas 256MB de RAM, a partir de 96MB ya puedes usar el entorno gráfico: KNOPPIX FAQ: What are the minimum system requirements?

  • Tostadilla dice:

    Muchas gracias por el link, Super Coco. Cuando me dedique a experimentar de nuevo probaré ese Knoppix. Por ahora estoy disfrutando lo que tengo. Gracias a la magia de Linux ;) he podido convertir ese feo Puppy en algo más decente y con la particularidad de que ya puedo descargar por bittorrent, escuchar last.fm y navegar por internet de forma fluida.

    Para ello uso Shell-FM,un reproductor de Last.FM mediante consola. Con un link en el escritorio rapidamente se pone a reproducir tu estacion favorita sin apenas consumir recursos. Con Conky puedes mostrar la canción actual, ademas de recursos del sistema, espacio disponible y mil cosas más en el fondo de escritorio también de forma ligera. Eso si, si metes muchas cosas en seguida enpieza a parpadear, lo que es bastante molesto. PcMan es un gestor de archivos muy ligero y con la particularidad de que usa pestañas y favoritos como Firefox. Una vez te acostumbras a ellos, los hechas en falta en otros gestores :P. Para los torrents Transmission funciona bien y tiene todo lo necesario, pero funciona mucho mejor Enhanced Ctorrent, un torrent por consola. En puppy hay una GUI para tontos para usarlo.

    En cuestion de navegadores he probado Dillo, rapidisimo pero inmanejable. Me la suda que no haya flash, casi mejor. puedo pasar sin javascript. Incluso puedo aguantar que solo acepte las CSS1… pero que no tenga un copiar/pegar! XD. En cuanto me ha salido un enlace sin hipervinculo de esos kilometricos que pueblan los foros de Puppy he desinstalado el programa.

    Firefox 3b5 será rapido y de consumos pequeños en windows, pero no en Linux. He leido incluso que funciona mejor correr la versión de windows bajo Wine, inaceptable. He aguantado un tiempo por que soy chico Firefox desde hace tiempo pero al final he pasado de el.

    He probado un par más y al final he vuelto a Seamonkey que viene por defecto en Puppy. Tiene la mejor proporcion de rapidez y prestaciones.

    Y eso, que al final, ALIX si es capaz de hacer todo lo que quiero, al mismo tiempo y de forma fluida. A sido una buena compra. :)

    Solo queda una pequeña espina que me pica jeje. Las Xorg tal cual no aceptan la grafica de la ALIX de serie, osea el AMD Geode. XVesa si y es lo que uso pero solo de una forma estandar sin aceleración ni nada. Para las Xorg existe este driver muy majo el pero leches, soy incapaz de instalarlo lo poco que he probado, alguno lo ha conseguido en los foros de Puppy pero se callan la forma, los muy jodios. Anda Super Coco, comprate un ALIX, si lo estás deseando, que casi que los regalan. Y así nos enseñas como se hace XD.

  • @Tostadilla Hombre, pues no te creas que no me tienta pillarme una ALIX y cacharrear con ella, aunque no sé si sería capaz de hacer funcionar ese driver con el que tú no puedes ;-) . Por cierto, ¿la pones en alguna caja específica para ella o la tienes así como vino al mundo?

    Sobre el navegador, no sé si en Puppy podrás probar el Epiphany con Webkit que tal vez te funcione más ligero. Sobre Firefox, la verdad es que ya son muchos los comentarios que he leído de que Firefox está despreciando a la comunidad Linux cuando es donde encontró su soporte incial cuando todo el mundo usaba Internet Explorer.

    ¡Muchas gracias por tus interesantes comentarios!

  • Tostadilla dice:

    Bueno, la caja para el Alix 1C aún no ha salido y es que el propio Alix 1c se encuentra según parece bajo desarrollo (pese a que ya lo vendan, igual que el PopCorn Hour ¬_¬).Aún así, yo lo que tenía planteado era hacerle una cajita de madera para que haga juego con los muebles. Finalmente ni hizo falta, utilizé uno de los multiples cajones del mueble de la tele, lo taladré para hacerle el botón, meterle los leds y al final pese a los desastre habituales por no ser carpintero, no ha quedado mal la cosa. Resulta curioso que uno de los cajones de un mueble antiguo de madera maziza sea en realidad un ordenador embedido, con un led que al presionarlo enciende u apaga el Alix.

    Puedes meter un ordenador en cualquier tipo de material siempre que este rodeado de metal por obra y gracia de la fabulosa Jaula de Faraday. Yo forré el cajón con papel de aluminio de las embolturas del chocolate y lo peque con barra de pegamento escolar. para que la placa no toque el aluminio, utilizé unos pequeños embellezedores que compré en el alcampo por 0,90e. Seguramente Faraday uso otros materiales para sus experimentos XD

    Como la cosa ha quedado tan chik, sin cables ni nada por ningun sitio, quiza haga lo mismo con el router y/o con el popcorn hour. Tener los distintos cacharros del salón insertados en cajones contiguos enaltece mi vena geek.

    Un saludo SuperCoco y ¡por supuesto que tu podrias con los drivers del xorg!, tus conocimientos de linux le dan sopas con ondas a los mios. Seguramente, pasar por tu experiencia con los del VIA habría acabado con mi cordura.

  • @Tostadilla ¡Ufff! Eso se merecería un buen reportaje fotográfico. A ver si te animas a hacerte un blog como decías y nos lo enseñas ;-)

  • plati dice:

    Hola :) ,
    Antes que nada felicitarte por tu magnifico blog y los estupendos articulos que has publicado sobre las Via epia, que van ha hacer que le quite el polvo a la EX15000 que compre antes de navidades :D . Que por cierto fue en una tienda alemana (www.hpm-computer.de) que pa aquel entonces habia mucha mas diferencia con los precios de españa.

    Queria preguntarte que si has probado con exito (o algun lector del blog :P ) el ultimo driver de via (40072d) con mejores resultados que el que usas en el articulo, ya que quiero ponerme a cacharrear con ella haber si obtengo mejores resultados que en windows (pegaba saltos el TDT, aunque no llegué a probar las configuraciones que comentas en los otros articulos para el wmc y el wmp), o si me recomiendas mejor el de Unichrome project (que no me quedó bien claro jeje)…

    Un saludo y de nuevo mil gracias por estos interesantes articulos!! :)

  • @plati ¡Gracias! Sobre el driver de VIA, tras escribir este artículo, no lo he vuelto a usar nunca dado lo lamentable que es. Dudo mucho que en la nueva versión haya mejorado mínimamente, especialmente en lo que respecta a la aceleración de vídeo que seguro que necesita los obsoletos VeMP y VeXP.

    Sobre el TDT, ten en cuenta que es imposible obtener aceleración de vídeo con el driver de VIA si no es con aplicaciones parcheadas a propósito para este driver, que a día de hoy sólo son el VeMP y el VeXP, y no el Kaffeine ni el MythTV, por decir algo. En definitiva, una basurilla de driver.

  • Xadawa dice:

    Holà, este wiki me parece ser una fantastica ayuda por utilisadores de via technologies. Pero desde la escritura de eso, una novela version està salida y voy a ver si tù wiki functionna tambien con ella. Pero yo tengo una pregunta : con el CX700M2, que driver es el mejor ? openchrome o via ?? Pérdon por mi mal acento pero soy Francès…

  • @Xadawa El driver openchrome es muchísmo mejor que el driver de VIA, pero me temo que aún no soporta XvMC y que puede tener problemas con algunas pantallas LCD y con la salida de TV. A ver si VIA definitivamente libera sus drivers para que la comunidad aprenda de ellos y pueda mejorar mucho los existentes.

  • Simon dice:

    hola soy un nuevo usuario de linux, pase de xp a ubuntu y estoy aprendiendo muy de a poco el cambio de paradigma…hasta el momento hice andar todo q lo q fui necesitando, pero el tema de la placa de video sigue siendo un dolor de cabeza, tengo una “VIA Technologies, Inc. Chrome9 HC IGP (rev 01)” y estoy corriendola con el driver vesa, y si que es una porqueria, la verdad q no entiendo nada de lo posteado, alguien puede compartir su Xorg.conf conmigo, o necesito tocar algo mas???…..me la he pasado de foro en foro pero no he encontrado nada “amigable” para resolver el problema.
    ( simonbour@gmail.com )

  • @Simon No tengo ese chipset y no te puedo ayudar con experiencia de primera mano, pero el driver openchrome te debería de funcionar. Viene por defecto en la Ubuntu 8.04.

    También es posible que el driver binario de VIA que puedes encontrar en http://linux.via.com.tw te funcione bien.

  • Simon dice:

    wow, jejeje, q rapidez, te agradezco, el chipset es el P4M900…..el driver q vino con linux anda, la relacion de aspecto es la correcta y se ve bonito, pero no puedo utilizar ninguna herramienta de transparencia ni de animacion.
    saludos
    simon

Tema LHYLE09, creado por Vicente Navarro