J'avoue que je me faisais l'avocat du diable. Je n'avais pas l'impression de « descendre directFB » en flammes, mais si ça a été compris comme ça, j'ai dû mal m'exprimer.
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 Amand Tihon (site web personnel) . En réponse au message Quelle utilité a Xorg quand on a DirectFB. É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.