Un nouvelle release de DirectFB vient de sortir (24/2/2005)
ainsi que la video du FOSDEM 2004 sur DirectFB
http://www.directfb.org/docs/FOSDEM/FOSDEM_2004_remuxed.avi(...) (380Mo)
En gros cela présente l'avancement du projet, ainsi que de belles demos en 3D (avec alpha) sur la fin!
Les RPMS sont facilement générable pour FC3 :
http://thomas.apestaart.org/download/pkg/fedora-3-i386-fedora-stabl(...)
Par contre, pour XDirectFB (serveur X s'appuyant sur DirectFB)
je n'arrive pas à le recompiler pour FC3!
(Xorg 6.8.2 + XDirectFB-1.0-rc5 + fix) si quelqu'un à déjà fait cela, qu'il le post!
Journal DirectFB 0.9.22
25
fév.
2005
# Mais euh!
Posté par Ph Husson (site web personnel) . Évalué à 2.
Pfff
bon bref
Sinon pour XDirectFB essaye plutot xfree86 4.3 (oula ca fait bizarre de taper ca :)
Enfin sinon l'avancée majeur de cette version (amha) c'est l'amélioration significatif de l'accélération nVidia (bon faut que je teste qd meme :p)
Parait il qu'on peut l'utiliser sans que ca bouffe tout le cpu! :D
(bon par contre leurs infos sur le site web serait donc faux.... enfin bref)
bon sinon la démo avec gnome ca me désole :/
Ils auraient pas pu montrer le début de portage de qt4 par exemple? :)
Et pis aussi ils auraient pu virer le rétroprojecteur de la "ligne de mire" parce que bon il manque un ch'ti bout
et pis le son il est aussi pas mal du tout:D deja que je comprends pas grand chose à l'anglais
Par contre présenter XDirectFB comme partie 'majeure' de DirectFB ca me désole aussi du fait que directfb est aussi utilisable avec que sans (c'est à dire quasiement pas tant qu'il n'y a pas de bureaux virtuels :/)
# ...
Posté par M . Évalué à 3.
- actuellemnt chaque server doit developper ses propres drivers
- pas d'utilisation d'api du noyeau : on fait des io -> le serveur doir avoir les droits root + pb d'incompatibilite avec le frame buffer, pb pour la mise en veille, ...
Ce qui serait pas mal serait de pouvoir reutiliser un maximun le framebuffer pour la 2d, et d'avoir une biblioteque "minimaliste" pour supporter le reste (extension video telque dga, xv,...)
Je sais pas trop ou ce place directfb dans tout ca.
D'ailleur au lieu d'avoir XDirectFB, ne serait t'il pas possible d'avoir un driver pour xorg qui utilise l'api directfb pour faire des operations video, un peu comme le fait le diver fbdev avec le framebuffer ?
[^] # Re: ...
Posté par Ph Husson (site web personnel) . Évalué à 3.
C'est deja le cas plus ou moins :p
En fait c'est comme le driver vesa qui permet de se passer de fichiers externes
Mais t'as raison que ca pourait être plus mieux
de toutes facons c'est pas la meme chose:
xdirectfb est 'root-less' en fait il n'occupe que la place que les applis demande, mais pas tout l'écran(de ce que j'ai compris quoi :D)
Ce qui permet de garder une cohabitation
Ce qui serait pas mal serait de pouvoir reutiliser un maximun le framebuffer pour la 2d, et d'avoir une biblioteque "minimaliste" pour supporter le reste (extension video telque dga, xv,...)
dga il me semble que c'est un accès directe au périphérique qui est donc dépend du matériel, ca n'a donc aucun sens
et xv ben c'est pour X :p
Je supposes que c'est en rapport avec ce que je vais dire après
Ce que je trouve domage c'est que l'api video ne soit pas mieux developper sous linux :
- actuellemnt chaque server doit developper ses propres drivers
- pas d'utilisation d'api du noyeau : on fait des io -> le serveur doir avoir les droits root + pb d'incompatibilite avec le frame buffer, pb pour la mise en veille, ...
T'as tout à fait raison
En fait le nom exacte pour ca c'est donc dri mais il est possible qu'il ne fasse en fait que la 3D, l'interet étant donc nul
par contre pour ce que tu dis des droits root c'est pas le cas avec directfb (en fait doit falloir les perms qui vont bien sur les perifs dans /dev donc ca revient au meme en fait)
bon donc ca c'etait le résumé
Par contre la raison de tout ca amha c'est l'arrivée très tardive premièrement
et deuxiemement que les principaux drivers (bon nvidia et fglrx pour ne pas les nommer) ne l'utilises pas (en fait c'est faux nvidia peut utiliser agpgart mais bon ca fait pas du dri quand meme)
En fait il faudrait que je m'informe plus sur tout ca.....
[^] # Re: ...
Posté par Bruno Ethvignot (site web personnel) . Évalué à 2.
Linux utilise donc généralement le serveur X-Window, à savoir XFree86 remplacé depuis peu par le X Server de X.org, car à la base Linux est un clone d'Unix, et X-Window est la couche graphique utilisée par ces derniers. XFree86/X.org ont leurs pilotes graphiques propres. Ces deniers sont ceux sans aucun doute ceux qui supportent le mieux les cartes graphiques sous Linux. Ces pilotes sont indépendants du noyau Linux, mis à part le DRI qui permet aux pilotes d'accéder au matériel.
Bien que X-Window ne fonctionne pas trop mal, il est loin de donner toute satisfaction. (lacune des polices de caractères, gestion de la 2D non satisfaisante, pas de gestion des transparences et des ombres, ...) Ces lacunes ont provoquées l'émergence de projets parallèles comme Fresco, DirectFB, Y-Window, PicoGUI.
Mis à part DirectFB ces projets battent de l'aile. DirectFB utilise la boîte à outils GTK et se veut une alternative à X-Window. Il possède ses propres pilotes graphiques, mais seules les cartes Matrox sont bien supportées. Pourquoi les autres projets ne réutilisent-ils pas les pilotes X.org ? Peut-être que les pilotes X.org ne sont-ils pas adaptés ?
Le plus difficile reste à faire les pilotes des cartes graphiques qui sont de plus en plus complexes, et les constructeurs donnent rarement les spécifications. Ce qui est regrettable.
Même si ATI et NVidia fournissent des pilotes binaires pour le projet X.org, c'est insuffisant. Rien ne prouve que les pilotes des anciennes cartes seront supportés très longtemps, ces pilotes restent limitées à l'architecture 80x86. ATI et Nvidia pourrait au moins donner les spécifications des cartes sorties voilà un an ou deux. NVidia s'est même permis de snober le DRI en proposant sa technologie soit disant plus performante...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.