Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
Rueda de ratón en kernel 2.6

dodger's Diary
Por dodger
departamento Ya era hora de migrar , Sección Diarios
Puesto a las Wed May 4th, 2005 at 11:20:30 AM CET
El kernel 2.4 me funcionaba tan bien, que me daba muchísima pereza migrar al 2.6. Pero claro, cuando estuve viendolo funcionar en una kubuntu, y vi por ejemplo las mejoras en los discos usb, decidí que ya era el momento.

 


A si que empecé a buscar como hacer una migración "sin problemas" del 2.4 al 2.6. Empezando por bajarse las fuentes del kernel, ya que hace tiempo me inculcaron la costumbre de compilarme mis propios núcleos. Leyendo algo de documentación, descubrí que se podía reutilizar parte de la configuración antigua haciendo un:
#make oldconfig
(previamente copié el fichero antiguo de configuración, claro). Lo malo es que te pregunta una a una por todas las opciones que han cambiado, y se tarda un buen rato...
En fin, partiendo de ahí, y luego jugando un poco con el menuconfig, conseguí que arrancasen las 2.6 al primer intento :) (luego tueve que recompilar un par de veces más, porque me había dejado cosas, claro).
Total, que todo parece ir bastante bien, excepto el ratón, que no funciona, y por tanto las X no arrancan. Como google es sabio, no tardó en darme la solución: tenía que cambiar el dispositivo
Option "Device" "/dev/input/mice"
(antes, no sé por qué, lo tenía en ttyS0. ¡Y con el 2.4 funcionaba!)

Una vez hecho esto, ya arrancaban las X, aparecía el puntero de ratón... pero no respondía. Algo de investigación más tarde, nueva solución:
#modprobe psmouse

Y, ¡voila!, ya funciona el ratón. ¿Del todo? ¡No! No funciona la rueda. Y sólo cuando no funciona, uno se da cuenta de lo importantísima que es la rueda para el trabajo diario. De verdad.
Y aquí empezó la odisea. Miré muchísima documentación, cambié unas 20 veces parámetros del fichero de configuración de las X, pero no había nada que hacer.

El resto, funcionaba todo... excepto el mp3 por usb, que no lo reconocía Extrañamente, el disco grande sí que lo cogía. Si hubiese estado más atento, me hubiese dado cuenta de que todo lo que actuaba "raro" era usb 1... pero no darme cuenta me costó varias noches de frustración.

Hasta que por fin, anoche, encontré que un sabio anónimo de kerneltrap había publicado la solución:
Resulta que la configuración por defecto de los kernel 2.6 es con el controlador USB-UHCI. Sin embargo, para ciertos dispositivos hace falta el controlador OHCI. A si que make menuconfig, device drivers, usb support, seleccionar OHCI HCD support. Recompilar, etc... ¡Y todo funciona! Ya tengo rueda de ratón, y reconoce el mp3. Por fin.

¿Y a qué viene el rollo que os he soltado? Primero a que con lo que me ha costado encontrar la solución, prefiero dejarla escrita en elgún sitio por si me vuelve a pasar. Y segundo, porque he visto que había más gente que "sufría" el problema de la rueda, y pocas soluciones... a si que espero que esto le sirva a alguien.
< Movilización contra las patentes de software en Europa el 27-A (3 comments) | Debian en mac mini (I) (32 comments) >
Enlaces Relacionados
· fuentes del kernel
· solución
· More on dodger's Diary
· Also by dodger

Encuesta
¿Es la rueda del ratón indispensable?
· Claro. Es básico para hacer scroll. 83%
· Claro. Es básico para jugar al Quake. 8%
· Pues no la uso mucho, la verdad. 8%
· ¿Ratón? ¿X? Eso es para nenas. 0%
· Yo uso un ratón de mac, con un botón, y sin rueda. 0%

Votos: 12
Resultados | Otras Encuestas

Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

Ver: Modo: Orden:
Rueda de ratón en kernel 2.6 | 8 comentarios (8 temáticos, editoriales, 0 ocultos)
En estos casos ... (none / 0) (#1)
por shamkao a las Wed May 4th, 2005 at 02:10:58 PM CET
(Información Usuario)

Creo que es mejor dejar la configuración de los kernels a "profesionales" (personas o grupos de personas que se conocen todas las opciones del kernel), es decir, por ejemplo a la gente que mantiene el kernel en tu distribución. Yo uso debian, y he llegado a la conclusión de que no me merece la pena andar compilando para tener un kernel a medida (a lo mejor a otras personas si). En debian, cuando te bajas un kernel image, todo aparece compilado como módulo, así que lo único que tienes que hacer es decirle que cargue los módulos que te interesan en el arranque y ni uno más.

Aunque este mundo es libre, y cada uno puede hacer con su kernel lo que le de la gana.



Estoy contigo (none / 0) (#2)
por man ls a las Thu May 5th, 2005 at 12:48:48 AM CET
(Información Usuario)

Compilar un kélmer es una experiencia interesante que vale la pena pasar, sobre todo para perderle miedo. Pero una vez que lo tienes y no te funciona algo, deja de tener gracia; mejor usar un kernel de una distribución, y así si te falla algo y lo reportas estarás mejorando la existencia de otras personas también.

Es normal que las distribuciones cambien algunas cosas de los paquetes que incluyen. El proceso de desarrollo del núcleo es un pelín sui generis, lo que hace que las distros tengan versiones tan parcheadas.

[ Padre ]


Por cierto (none / 0) (#4)
por man ls a las Fri May 6th, 2005 at 01:27:40 AM CET
(Información Usuario)

En este artículo sobre Andrew Morton en linux.conf.au, el propio Morton se queja de que los núcleos de kernel.org son cada vez menos accesibles para el público en general. Esto es debido, explica, a que el proceso de la rama 2.6 se ha hecho más amigable para las distros -> hace falta dedicarles más tiempo para configurar un kernel.

Luego dice que va a intentar que se mejore la experiencia de los usuarios finales, que compilan sus propios kelmers. Esperemos que sea cierto.

[ Padre ]


Cambio de política de desarrollo de la rama 2.6 (none / 0) (#6)
por jorginius ("jorginius" en Google Mail) a las Sat May 7th, 2005 at 11:49:25 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

No es que haya que dedicarles más tiempo para configurar el kernel.

Ahora la estabilidad del kernel ha quedado definitivamente en manos de los distribuidores. Los desarrolladores dedican menos tiempo a hacer estable el "vanilla kernel". Saltándose pruebas de regresión, por ejemplo.

Esto se debatió ya en su momento en KernelTrap (Linux: New Kernel Development Model) y trajo bastante cola (continúa en "Linux: Discussing the New Development Model").

La idea detrás del nuevo modelo es que los distribuidores tienen que hacer de todos modos sus pruebas de integración y regresión y prácticamente nadie usa las fuentes prístinas del kernel, así que no merece la pena que los desarrolladores pierdan tiempo en eso.

Lo único que cambia para el usuario final es que, si quiere compilar el kernel, debe bajarse las fuentes y los parches de su distribución en vez de la versión en kernel.org. Algo que la mayoría de la gente hacía ya con la versión 2.4.

apt-get source kernel
rpmbuild -bp kernel-2.6.spec
make menuconfig
etc.


[ Padre ]


Un poco exagerado (none / 0) (#7)
por man ls a las Mon May 9th, 2005 at 12:18:32 AM CET
(Información Usuario)

Ahora la estabilidad del kernel ha quedado definitivamente en manos de los distribuidores.
No te falta razón, pero creo que exageras un poco con lo de "definitivamente". Si fuera así, no habría habido versión 2.6.11.1, paradójicamente. Vale, el hecho de que la 2.6.11 no funcionara con ciertos teclados Dell apunta a que no se hicieron suficientes pruebas de regresión; pero el hecho de que rápidamente se sacara una revisión 2.6.11.1 indica que el proceso sí incluye a los usuarios finales, que se bajan un núcleo de kernel.org y se lo compilan. O la misma rama ultraestable 2.6.X.Y.

Y también me parece exagerado lo de
prácticamente nadie usa las fuentes prístinas del kernel
Puedes ver cómo en esta historia H Peter Anvin cuenta que habitualmente kernel.org se come de 150 a 200 Mbits por segundo. ¡Dudo que sean solamente distribuidores bajándose el kelmer una y otra vez! ;)

[ Padre ]


A mí no me lo parece (none / 0) (#8)
por jorginius ("jorginius" en Google Mail) a las Mon May 9th, 2005 at 08:13:17 AM CET
(Información Usuario) http://www.rodriguezmoreno.com

Ahora la estabilidad del kernel ha quedado definitivamente en manos de los distribuidores.
No te falta razón, pero creo que exageras un poco con lo de "definitivamente".

No, para nada.

No me refiero a la estabilidad en el sentido de que falle mucho o poco sino a tener la certeza absoluta de que todo lo que funciona ahora en un 2.6.x lo seguirá haciendo en un 2.6.x+1 sin cambios.

Hablo de tener una plataforma estable y el "vanilla kernel" de la rama 2.6 no lo es o no tiene por qué serlo. Ahora se aceptan cambios "drásticos" en la rama estable (la retirada de devfs o el cambio a NPTL, por ejemplo).

Son los distribuidores los que tienen que coger el kernel de kernel.org, probar si la actualización rompe algo en su distribución (por un cambio en el API, porque un sistema que usaban ya no existe, etc.) y, en caso afirmativo, parchear el kernel para que el usuario no lo note.

El compromiso de estabilidad para con el usuario final recae en el distribuidor. Es él el que asegura al usuario que sus aplicaciones seguirán funcionando como se espera cuando actualice su kernel, sólo que ahora tendrá más soporte hardware y los parches de seguridad aplicados.

Esto mismo ya era su responsabilidad antes. ¿A qué se dedica un "distribuidor" si no? :-). No podían dejar de hacerlo aunque los desarrolladores oficiales se obligasen a mantener la estabilidad entre revisiones. Ahora "definitivamente" queda en sus manos asegurar una plataforma estable para el usuario.

Y también me parece exagerado lo de
prácticamente nadie usa las fuentes prístinas del kernel
Veamos, ¿cuantos usuarios de Linux están corriendo un kernel compilado directamente las fuentes de originales?.

Ahora mismo sólo se me ocurre Slack como distribución que use (¿usaba?) un "vanilla kernel" y no es precisamente de las más populares. Todas las demás que conozco aplican sus parches y empaquetan sus kernels modificados.

Luego, de entre los usuarios que se lo descargan de kernel.org, hay un porcentaje alto que lo hace para aplicar después un saco de parches no oficiales (bootsplash, swsuspend2, grsecurity, etc.), así que tampoco corren el kernel según sale.

¿Al final qué queda?, ¿lo están usando un 5% o un 10% como mucho, de entre todos los usuarios de Linux?.

[ Padre ]


 
OHCI vs UHCI (none / 0) (#3)
por ridiculum a las Thu May 5th, 2005 at 12:51:38 AM CET
(Información Usuario)

El asunto no es que unos dispositivos usen UHCI y otros OHCI, ya que esos terminos se refieren al "host controller" que reside en tu placa base y no tiene nada que ver con el dispositivo que se conecta. Normalmente, o se tiene uno o se tiene otro y a lo sumo se tiene UHCI/OHCI mas EHCI para USB 2.0 (UHCI y OHCI son para USB 1.1).

Por ejemplo, en mi caso sale:
0000:00:07.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 1a)
0000:00:07.3 USB ContController: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 1a)






gracias :) (none / 0) (#5)
por dodger (dodgerNOSPAM@NOSPAMseastorm.org) a las Fri May 6th, 2005 at 11:14:19 AM CET
(Información Usuario) http://www.seastorm.org

Guay, no lo sabía.
Por eso me gusta hacer las cosas por mi mismo (como compilar el kernel): se eprenden cosas nuevas :)

--
dodger
http://www.seastorm.org
"Hacer software basado en requisitos es igual que caminar sobre el agua: Es fácil, si están congelados"
[ Padre ]


 
Rueda de ratón en kernel 2.6 | 8 comentarios (8 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:

ecol Logo Powered by Scoop
Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda