A quoi sert encore une couche supplémentaire comme X, alors qu'on peut faire du graphisme tout ce qu'il y a de plus époustouflant directement sur le frame buffer, en utilisant DirectFB ? Allez voir les screenshot sur le site.
Et puis d'abord, pourquoi est-ce que à l'origine X a été développé ? Pourquoi n'as-t-on pas développé tout ce qui a trait au graphisme sur le FB depuis le début ?
Merci, parce que ça me parrait sacrêment illogique et une perte de temps.
Forum général.général Quelle utilité a Xorg quand on a DirectFB
28
fév.
2009
# Plein de raisons
Posté par Nerdiland de Fesseps . Évalué à 10.
# Tu t'es pas trop foulé...
Posté par lolop (site web personnel) . Évalué à 10.
* c'était quoi le driver frame-buffer dans les années 80 (début de X), quelles étaient les architectures et l'utilisation qui en était faite, quel coût?
* ton driver DirectFB, il gère toutes les capacités de ta carte graphique (3D & Co compris)?
* tu fais comment niveau développement pour faire une appli qui puisse *aussi* s'afficher sur un poste distant, éventuellement d'un autre OS, de façon transparente (si si, c'est utilisé)?
* est ce-qu'il n'y aurais pas dans X11 des choses qui le rendent plus costaud/sympa que le frame buffer - surtout dans les technos récentes de direct rendering, de librairies asynchrones, etc...
* combien de temps ça prendrais de recoder les nombreuses applications qui fonctionnent via X11, avec combien de nouveaux bugs?
Parce qu'un jugement ça me parrait sacrêment illogique et une perte de temps sans s'être plus renseigné, ça me parait un peu faire le jeunot qui débarque et qui va expliquer à tout le monde quelles sont les meilleurs solutions...
Quelques pistes - là j'ai fait ton boulot de recherche sur google avant d'écrire des âneries:
En français:
http://forum.hardware.fr/hfr/OSAlternatifs/graphique-dominan(...)
http://mjules.littleboboy.net/carnet/index.php?post/2006/11/(...)
En anglais:
http://en.wikipedia.org/wiki/X_Window_System
http://jonsmirl.googlepages.com/graphics.html
http://xcb.freedesktop.org/
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Tu t'es pas trop foulé...
Posté par Ph Husson (site web personnel) . Évalué à 5.
Heureusement qu'on se base pas sur l'age d'une solution pour juger de son utilité, sinon on serait encore sur MS-DOS à coder en basic ... (ou autre pour les plus vieux)
* ton driver DirectFB, il gère toutes les capacités de ta carte graphique (3D & Co compris)?
Il sait le faire, faut "juste" coder les drivers avec.
* tu fais comment niveau développement pour faire une appli qui puisse *aussi* s'afficher sur un poste distant, éventuellement d'un autre OS, de façon transparente (si si, c'est utilisé)?
Il le gère déjà, l'option s'appelle voodoo de mémoire. (Et porte mal son nom ;)
* est ce-qu'il n'y aurais pas dans X11 des choses qui le rendent plus costaud/sympa que le frame buffer - surtout dans les technos récentes de direct rendering, de librairies asynchrones, etc...
Je veux pas dire, mais ces technos ca compte, amha, pas, c'est des technos très récentes qui ont été surajoutées, donc quitte à prendre du temps pour refaire quelque chose, autant le refaire proprement.
* combien de temps ça prendrais de recoder les nombreuses applications qui fonctionnent via X11, avec combien de nouveaux bugs?
Pour la plupart des applis, ils utilisent des toolkits graphiques qui sont indépendants de la couche supérieur, et qui peuvent tourner derrière sur DirectFB sans trop de probleme si ledit toolkit est porté dessus, en l'occurence Gtk est déjà porté, mais certaines applis Gtk sont bizarres et ont quand même un bout de X11 dans leur code j'ai pas trop compris pourquoi. De même SDL a été porté dessus, donc y a pas mal de choses qui peuvent tourner dessus.
Bon après, ca n'empèche que X11R7 est franchement pas mal. Ce que font les mecs de DirectFB est bien, mais rien n'empeche de faire exactement la même chose sur un X11 normal. Je pense que DirectFB a sa place dans le semi-embarqué (type HTPC), plutot que dans le desktop, mais bon il fait partie de la diversité qui fait la force du libre (amha.)
[^] # Re: Tu t'es pas trop foulé...
Posté par Amand Tihon (site web personnel) . Évalué à 5.
- la transparence réseau,
- les drivers accélérés,
- le multi-écrans entre une carte Intel, une Nvidia et une Ati,
- la gestion des différents périphériques d'entrée (souris, écran tactile, tablette graphique avancée, ...),
- le côté asynchrone...
Enfin, lorsque les toolkits (puis les applications) auront été portés vers cette nouvelle solution, qu'y aura-t-on gagné au final ? Une nouvelle couche supplémentaire (parce qu'il faut bien un niveau d'abstraction pour que ça fonctionne sous les différents OS), qui s'appellera autrement que X11.
La vraie question n'est pas de savoir si c'est faisable, mais si ça apporte le moindre avantage. Tu y apportes une réponse à la fin de ton commentaire : pas grand chose, sauf peut-être pour des petites configs, à une époque où le public commence à demander de pouvoir jouer des films en 720p sur des machines de la taille d'une carte de crédit...
[^] # Re: Tu t'es pas trop foulé...
Posté par Ph Husson (site web personnel) . Évalué à 6.
- la transparence réseau,
- les drivers accélérés,
- le multi-écrans entre une carte Intel, une Nvidia et une Ati,
- la gestion des différents périphériques d'entrée (souris, écran tactile, tablette graphique avancée, ...),
- le côté asynchrone...
Pourquoi parler au futur ? Tout ca est déjà supporté, sauf peut être le multiécran multicarte (qui soit dit en passant, marche assez mal sous Xorg....) et le côté asynchrone dont je sais pas du tout vu que ca rentre pas dans ce que j'utilisais.
Enfin, lorsque les toolkits (puis les applications) auront été portés vers cette nouvelle solution, qu'y aura-t-on gagné au final ? Une nouvelle couche supplémentaire (parce qu'il faut bien un niveau d'abstraction pour que ça fonctionne sous les différents OS), qui s'appellera autrement que X11.
Parce que un standard existe déjà, il ne faut pas chercher à le remplacer, alors qu'il est considéré comme mal foutu pour l'utilisation actuelle ?
pas grand chose, sauf peut-être pour des petites configs
Petites config ?
Tu peux me dire où j'ai dit ca ? Peut êtrre que tu fais réference au terme de "semi-embarqué" ? Si c'est ca faut que tu révise ta définition d'embarqué, parce qu'une freebox HD c'est de l'embarqué pur et dur, ca l'empeche pas de lire les mains dans les poches un flux H264 qui dépasse la norme la plus dure.
Il n'en reste pas moins que je penses pas que DirectFB ait un avenir glorieux, mais c'est pas une raison pour les descendre sur des raisons complétement fausses et infondées.
[^] # Re: Tu t'es pas trop foulé...
Posté par Amand Tihon (site web personnel) . Évalué à 2.
Pourquoi parler au futur ? Tout ca est déjà supporté
Alors j'ai une guerre de retard. La 3D en était à ses balbutiements que je m'y étais intéressé. Ça ne semble d'ailleurs être qu'un problème de drivers, parce que je vois qu'ils supportent maintenant DRI.
le multiécran multicarte (qui soit dit en passant, marche assez mal sous Xorg....)
Peut-être a-t-il été cassé entre-temps (c'est bien possible), mais je l'utilisais il y a un bon paquet d'années, et ça fonctionnait.
Parce que un standard existe déjà, il ne faut pas chercher à le remplacer, alors qu'il est considéré comme mal foutu pour l'utilisation actuelle ?
Loin de moi cette idée ! Je suis avec beaucoup d'intérêt les évolutions autour de X.org, dont le Kernel Mode Setting, justement une fonctionnalité qui tend un peu à rapprocher le modèle X.org de celui directFB.
Il me semble que depuis que Keith Packard a présenté son Xserver, avec l'extension Composite, puis le fork de Xfree86, il y a plein de changements dans X : xcb, KMS, (TTM)/GEM, DRI2, RandR, composition, et j'en passe.
De là à dire que X est un standard mal foutu, il y a un pas que je ne franchirai pas :)
faut que tu révise ta définition d'embarqué
Mea culpa. Effectivement, ces derniers temps, je joue beaucoup avec de l'embarqué sur lequel justement X.org serait un peu à l'étroit et où un framebuffer semble la solution idéale (32Mo de RAM sur un bus 16 bits, 2x8 Mo de flash, 180MHz).
Au final, ma question reste : qu'est-ce qui est foireux avec X, et de quelle manière directFB adresse-t-il ces problèmes ? Autrement dit, que m'apporte directFB techniquement ?
Sinon, rassure-toi, je verrais un gigantesque avantage à ce qu'une solution directFB se développe réellement, avec son propre protocole réseau et son architecture complètement différente : la diversité des solutions.
[^] # Re: Tu t'es pas trop foulé...
Posté par Aefron . Évalué à 2.
C'est même sûr... complètement cassé : depuis RandR 1.2... le chargement d'un pilote RandR plus d'une fois plante à tous les coups, et le chargement d'un pilote RandR avec un non-RandR n'est pas supposé marcher (j'avais lu un gars chez qui ça marchouillait entre une Intel et une carte à blob de je ne sais plus qui - mais bon, c'est le genre de fonctionnement sur un malentendu)...
Ça devait être résolu avec RandR 1.3, mais finalement, les GPU objects, qui permettront l'abstraction des GPU, sont maintenant annoncés comme la "feature" qui initiera RandR 2.x...
Donc, c'est cassé depuis un bail (~1,5 ans, je crois), et pour encore au moins un autre... reste DMX : pour avoir plus d'écrans, ayons plus de machines (faute de grives...) - je ne sais pas si le framebuffer permet des choses comme ça, tiens...
[^] # Re: Tu t'es pas trop foulé...
Posté par Ph Husson (site web personnel) . Évalué à 2.
Tu peux lancer plusieurs serveurs en parallèle, avec un par carte graphique, et y mettre DMX derrière je penses.
(En ce qui concerne le framebuffer, j'en sais trop rien mais ca m'étonnerait qu'ils gérent ca)
[^] # Re: Tu t'es pas trop foulé...
Posté par Aefron . Évalué à 2.
Par contre, rien n'empêche d'utiliser deux serveurs, chacun sur leur carte, chacun(e) sur leur machine, et d'y coller DMX... m'enfin...
[^] # Re: Tu t'es pas trop foulé...
Posté par Ph Husson (site web personnel) . Évalué à 2.
[^] # Re: Tu t'es pas trop foulé...
Posté par Aefron . Évalué à 2.
... le truc, c'est que j'ai plus l'impression que l'ampleur de la tâche a été surestimée... ça devait venir dès RandR 1.2, puis 1.3, puis le 1.3 a été retardé de 8-10 mois, pour finalement se retrouver sans GPU Object... qui n'arriveront qu'avec X.org 7.6, voire 7.7, via RandR 2.0...
... et en attendant, c'est plus moche que pas de pot. Dès RandR 1.2, il a été décidé que cette feature serait cassée, mais réparée au pire en 6 mois/1 an... Un an et demi après, on est au même point : c'est cassé, mais ça devrait revenir d'ici 6 mois/1 an :'|
[^] # Re: Tu t'es pas trop foulé...
Posté par briaeros007 . Évalué à 4.
ça c'est un faux point. Elle utilise un dsp dédié pour effectuer ce traitement.
# trop simple
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
Le but c'est d'être simple et de marcher partout, si tu veux du plus haut niveau attaque en openGL.
"La première sécurité est la liberté"
[^] # Re: trop simple
Posté par Ph Husson (site web personnel) . Évalué à 3.
[^] # Re: trop simple
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.