Reprise du message précédent :

http://linuxfr.org/2009/03/10/25136.html
un lien intéressant

c'est très surfait je trouve

on en est où du débat sur l'integration de xorg dans le kernel ?

il fait probablement référence au déplacement d'un certains nombres de fonctions vers le noyau comme la gestion des modes ou l'initialisation de la carte.

Oui mais on est encore loin d'une integration totale de Xorg dans Linux.
 
Sinon, question que je me posais, quid de la portabilite de Xorg sur d'autres plateformes que GNU/Linux maintenant que Xorg depend encore plus sur du code integre a Linux?

Les seules choses qui dépendent de code linux, c'est le DRM et evdev. Soit quelques pilotes de sortie graphique si on veut utiliser une accélération via le moteur 3D de la carte et un pilote d'entrée.
Le DRM est en cours de portage vers les BSD et Opensolaris.

KMS et GEM dans le futur aussi.

 
Par rapport à ça, j'ai quelques problèmes "mystères" :
 
1) J'ai enlevé tout ce qui concerne le clavier de xorg.conf et si je me balade dans /etc/hal/fdi/policy/ il n'y a rien.  
Dans /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi j'ai un layout défini en US. Il n'y a pas de .fdi spécifique à mon matériel non plus. J'aimerai comprendre comment xorg trouve ça (c'est correct, mais ça sort d'où ?)
 

 
2) Depuis Xorg 1.5.x et jusqu'à maintenant (1.6), même si les touches multimédia de mon clavier sont détectées et mapées sur les bons keysim, il faut que l'application ait le focus pour qu'elles fonctionnent. Par exemple, si mon lecteur audio est minimisé, appuyer sur Play, stop, next... n'a aucun effet. Si je l'ouvre au premier plan, les touches fonctionnent normalement. Pourtant ce sont des raccourcis globaux. Je ne sais même pas si c'est un bug ou une mauvaise configuration.
 
J'aimerai assez comprendre.

  MJULES JE T4AIMEUH §§§

je vais pouvoir remettre le gdm du pc du cybercafé en azerty

 
peut-être que ton clavier renvoie lui même le bon keymap ?  
 
pour le 2, je sais pas.

 
KMS et GEM sont des parties du DRM. KMS implémentant plus ou moins RandR en espace noyau et GEM est spécifiques aux pilotes, il n'a pas beaucoup de rapport avec Xorg.

Les pilotes etant des pilotes pour Xorg, pour moi ca reste du Xorg.

mouais, si tu veux.

Sinon, pour répondre à ta question concernant la portabilité. à part evdev et certaines fonctions non obligatoire (KMS, gestionnaire de mémoire vidéo et comme je l'ai dit, ces derniers sont en cours de portage) du DRM. tout est portable sur au moins 4 ou 5 OS.

drapal

petit ajout concernant le serveur X et EXA/XAA

KMS sous OpenSolaris (ils mentionnent également les BSD) :
http://www.phoronix.com/scan.php?p [...] &px=NzIwMA

Mise à jour de xserver-xorg-input-kbd ce matin, et je perd les touches super, multimédias et ctrl-alt-del (et sûrement d'autres). Comment faire pour dire à hal que mon clavier comporte bien ces touches/raccourcis ? Est-il prévu dans un futur proche de configurer automatiquement cette reconnaissance (puisque le principal intérêt c'est le hotplug, donc on a pas à mettre son nez dans les fichiers de conf) ?

ça dépend de comment ta distribution gère tout ça pour le coup.

C'est HAL qui donne des keycodes à tes touches si elles n'en ont pas. Pour cela il se base sur le modèle, le constructeur, etc. Si ton clavier n'est pas encore dans la base de données ce serait bien de contribuer. C'est comme tout le reste avec HAL c'est du XML.

Édit: mais la gestion du clavier ce n'est pas que des keycodes, le problème peut éventuellement venir d'ailleurs.

 
Zut, cramé de 24h
 
Sujet très louable au fait, c'est rare de trouver des infos sur le serveur X sans que la personne ne se prenne les pieds dans le tapis

J'ai downgrader xfce de 4.6.0.2/3 en 4.6.0, pas de changement, certaines touches/combinaisons sont toujours absentes.
Upgrade avec les derniers paquets xfce, idem.
Downgrade xserver 1.6 > 1.4 ok, les touches refonctionnement.
En 1.6, j'ai remarqué que la touche win gauche donnait le code "Multi_Key", alors que la touche win de droite donne "Super". Comment spécifier à xorg qu'il peut considérer ces touches comme une seule touche ?
Consernant le "bug report", où le faire ? sur le site de hal ? debian ? xorg ? Je suis un peu perdu sur ce point là.

A l'origine, tu es passé de xorg 1.4 à 1.6 ?
Si oui, tu as adapté ton xorg.conf ?
 
A l'origine, tu passais sans doute par le driver kbd qui vogue droit vers l'obsolescence. Si t'as gardé les sections inputdevice dans xorg.conf sans ajouter  Option  "AutoAddDevices" "False" (pour dire à HAL de ne pas s'occuper des périphs d'entrées) dans serverflags, tu te retrouves avec kbd + evdev et c'est le souk.

Ce qu'il faudrait que tu fasses c'est regarder exactement quel est le problème, les touches en question n'ont simplement plus de "symbol" ou elles n'ont carrément plus de "keycode" ?

Édit: +1 BloodyCarnage

J'ai vérifié mais l'AutoAddDevices était en commentaire (et l'est toujours).
Normalement les paragraphes du clavier et souris sont ignorés, qu'ils soit donc présent ou non ne change pas le problème.
 
xev me retourne bien des code pour les touches multimédias et super/multi_key, mais différentes de la version 1.4 (pour super c'est 133/134 en 1.6, 115/116 en 1.4)

Bah il te reste à t'amuser avec xmodmap pour redéfinir correctement ton layout. C'est ce que j'ai fait quand je me suis trouvé face au même problème.
Idéalement, faudrait créer un .fdi pour que HAL reconnaissent directement ton clavier mais, personnellement, j'ai trouvé xmodmap bien moins pénible

 
Pour ceux qui veulent expérimenter HAL, il y a de la doc sympa sur thinkwiki (wiki pour IBM Thinkpad)
http://en.thinkwiki.org/wiki/How_t [...] ys_to_work
http://www.thinkwiki.org/wiki/How_ [...] TrackPoint

Waow, je comprends maintenant pourquoi on compare HAL à une usine à gaz soviétique.

HAL c'est super simple. Quand tu veux faire quelque chose tu crées/édites un .fdi ...

Parce que ca peut exploser à tout moment ?

A propos d'exploser, je viens d'exploser mon Xorg.
J'ai installer le 1.5, mais j'ai du louper une étape dans l'installation.
Donc clavier+souris ne répondent plus.
 
Y'a un moyen pour forcer le démarrage en mode console avant de lancer Xorg ? (je suis sous Gentoo)

démarre en mode single, généralement les distribs ne lancent pas X dans ce mode.

J'avais pas vu la spec XML, mais uniquement le code en C (lors du portage du bouzin sous NetBSD). Je constate qu'il n'y a pas que l'implémentation qui est dégueux, le design aussi. En particulier la gestion dynamique des volumes.

En fait, c'est tout simplement grandiose, je comprends pourquoi les auteurs d'origine le recommence presque de zéro.

 
merci
 
 
J'ai rajouté une bibliographie en dernier post. à étoffer.

un lien intéressant sur ce qui arrive pour les pilotes Intel et qui explique pas mal les limitations d'EXA/XAA, DRI et ce qui va arriver dans le futur :
http://keithp.com/blogs/Sharpening [...] ver_Focus/

Petite question : on peut choisir son pilote video via ces fichiers *.fdi ? Sans Xorg.conf, Xorg démarre avec le pilote NV, mais j'aimerais qu'il démarre avec le pilote Nouveau ... il y a moyen?
 
Merci.

je ne crois pas, il me semble que c'est Xorg qui choisi quel pilote charger en fonction du modèle de matériel (carte graphique mais aussi clavier/souris)  qui lui est présenté par hal ou qu'il détecte lui même. Il faudrait patcher xorg amha.

EDIT : le patch en question chez fedora
http://svn.pardus.org.tr/pardus/20 [...] veau.patch

Merci pour ta réponse.    
 
Bon je ne vais pas patcher Xorg   , alors je garde mon Xorg.conf pour préciser le driver à utiliser. Dommage qu'on ne puisse pas faire ca via Hal comme pour les claviers/souris.   Tampis ...

Drapeau Topic intéressant

c'est cool merci pour m'avoir un peu plus eclairci le fonctionnement de linux, mais parmis tous ces noms (ddx, dri, exa, uxa, mesa, ...) il y en a pas qui sont obselete ou doublon par rapport au driver proprio nvidia ?
quel changement auront ils dans l'avenir ? vu qu'ils sont entrain de revoir les cpu et gpu
petite derniere, j'ai mon xorg.conf de vide, et mon ordi marche sans probleme apparant, est ce que jdois le remplir ou jpeux faire sans ?