[ BIENVENIDO | ENCUENTRA O COMPARTE SOLUCIONES ]
I M P O R T A N T E
REGLAS DEL FORO | PROBLEMAS DE INGRESO O CONTRASEÑA | DEEPINES CHANGE LOG | ÚLTIMOS MENSAJES
Hola comunidad,
Estoy teniendo un problema bastante extraño con la tecla AltGr en Deepin 25.1 y quisiera saber si alguien más lo ha experimentado o si existe una solución definitiva.
Problema
La tecla AltGr deja de funcionar correctamente de forma aleatoria.
Por ejemplo:
-
AltGr + Qno genera@ -
el sistema no reconoce AltGr correctamente
-
en
xev, la tecla aparece como:
keycode 108 (keysym 0xff20, Multi_key)
cuando debería aparecer como:
ISO_Level3_Shift
Además, al presionar la tecla derecha de Alt, aparece un símbolo extraño (tipo Compose/Multi_key) en lugar de comportarse como AltGr.
Comportamiento extraño detectado
Descubrí que el problema parece estar relacionado con:
-
cambios de tema/apariencia en Deepin
-
el sistema de métodos de entrada (Input Method / Fcitx)
Cada vez que:
-
cambio de tema
-
modifico apariencia
-
o a veces después de reiniciar
Deepin vuelve a romper el mapping del AltGr.
También noté que aparece un indicador “ES” en el centro de la pantalla al iniciar sesión, como si el entorno estuviera recargando el layout del teclado automáticamente.
Lo que YA intenté
Reconfiguración de teclado
Ejecuté:
sudo dpkg-reconfigure keyboard-configuration
Configurando:
-
PC genérico 105 teclas
-
Español Latinoamericano
-
Alt derecho como AltGr
Pero el problema vuelve después de algunos reinicios o cambios visuales.
Verificación con xev
Ejecuté:
xev
Y la tecla Alt derecha devuelve:
keycode 108 (keysym 0xff20, Multi_key)
Corrección temporal manual
Esto sí corrige el problema temporalmente:
setxkbmap -layout latam -option lv3:ralt_switch
xmodmap -e "keycode 108 = ISO_Level3_Shift"
Después de eso:
-
AltGr + Qvuelve a funcionar -
@aparece correctamente
Persistencia
Intenté también:
-
.Xmodmap -
setxkbmap -
autostart scripts
-
.profile -
/etc/default/keyboard -
configuración XKB
-
remapeos persistentes
Pero Deepin eventualmente vuelve a sobrescribir la configuración.
Sospecha
Creo que el problema puede estar relacionado con:
-
Fcitx / Input Method
-
recarga del entorno DDE
-
cambio dinámico de layout al modificar temas
Porque el problema suele reaparecer exactamente después de cambiar apariencia o tema del sistema.
Preguntas
-
¿Alguien más ha tenido este problema en Deepin 25.1?
-
¿Existe una forma definitiva de impedir que DDE/Fcitx sobrescriba el AltGr?
-
¿Es recomendable desactivar o eliminar Fcitx si no se usan idiomas asiáticos?
-
¿Hay algún bug conocido relacionado con layouts LATAM y Multi_key?
Gracias.
El problema está resuelto. Para resumir lo que se hizo:
- Diagnóstico:
gsettingsya teníalv3:ralt_switchcorrecto, pero Fcitx5 estaba sobreescribiendo el XKB mapping al tener dos grupos (keyboard-latamcon layout baseusykeyboard-es) y sin override de XKB option propio. - Solución aplicada:
OverrideXkbOption=True+CustomXkbOption=lv3:ralt_switchen~/.config/fcitx5/config— Fcitx5 ahora aplica activamente la opción correcta de AltGr.~/.config/fcitx5/profilelimpiado a un solo grupo conDefault Layout=latam— elimina el conflicto con el grupokeyboard-esy el layout baseus.
Ambos cambios persisten reinicios y cambios de tema porque viven dentro de la propia configuración de Fcitx5, que es el proceso que tenía la última palabra sobre el XKB.
Lo anterior no fue suficiente así quese agregó esto:
1. Fcitx5 profile — Se limpió de dos grupos (keyboard-latam con base us + keyboard-es) a un solo grupo con Default Layout=latam. Esto eliminó un conflicto secundario pero no resolvió el problema raíz.
2. Fcitx5 config — Se activó OverrideXkbOption=True y CustomXkbOption=lv3:ralt_switch. Correcto, pero insuficiente porque Fcitx5 se aplicaba después de que X11 ya había cargado la base incorrecta.
3. /etc/default/keyboard — Se cambió XKBOPTIONS de compose:ralt a lv3:ralt_switch. Esta fue la corrección definitiva porque atacó la capa que X11 lee al arrancar, antes de que cualquier otro proceso tenga oportunidad de intervenir.
La señal que lo delató
El comando xprop -root _XKB_RULES_NAMES mostró compose:ralt como el valor real que X11 tenía en memoria, mientras que gsettings y Fcitx5 decían lv3:ralt_switch. Esa inconsistencia entre lo que los configs decían y lo que X11 realmente tenía apuntó directamente a que la fuente original estaba en una capa más baja que ambos.
@nolourq Excelente, qué bueno que haya logrado solucionarlo. También gracias por mostrar la solución para otros usuarios que encuentren este hilo en el futuro.
He marcado el hilo como "Resuelto".
Saludos.
[ Por favor, ayúdanos a mantener un sitio organizado, lee las reglas de discusión del foro.]
