Can someone give me one good reason why hardware dependent OpenGL drivers also depend on the X server? What is the reason DRI chose to be XFree86 specific? An obvious solution would be making a hardware dependent driver part of the kernel and simply write a Mesa binding that would run on the framebuffer. The next reasonable step would be making the X server compatible with that system. Who on earth got the idea of making DRI specific to XFree? [edited by - CoffeeMug on September 1, 2003 12:09:55 AM]

Why are hardware dependent OpenGL windows drivers also dependant on MSWindows?

quote:Original post by owl
Why are hardware dependent OpenGL windows drivers also dependant on MSWindows?

Same reason hardware dependent OpenGL linux drivers are dependent on linux. But why would they be dependent on a third party software package (XFree)?

quote:Original post by CoffeeMug
Same reason hardware dependent OpenGL linux drivers are dependent on linux. But why would they be dependent on a third party software package (XFree)?

Maybe they are drivers for the XFree windows system which happens to be a package in the linux distributions..

quote:Can someone give me one good reason why hardware dependent OpenGL drivers also depend on the X server?

Yes. OpenGL is simply a graphics API standard and can be implemented over the X protocol, as well as simply the graphics card. This basically means OpenGL programs are also network transparent. This is a boon for universities like mine where a tinderbox is supplied and CS students need to verify their programs compile and run on the tinderbox (so that the teacher can verify that they work correctly in a way that the student can predict the results of the teacher''s verification).

quote:What is the reason DRI chose to be XFree86 specific?

AFAIK, it''s not. DRI drivers in the linux kernel provide features that XFree86 uses. It''s currently XFree86 specific, but that''s in large part because no stable kernel currently has the drivers provided by XFree86 in it.

quote:An obvious solution would be making a hardware dependent driver part of the kernel and simply write a Mesa binding that would run on the framebuffer.

It''s just a matter of doing it; there''s nothing really stopping anyone from using the provided drivers (and C&P''ing part of the X drivers, if necessary) into a framebuffer library.

quote:Original post by Flarelocke
Yes. OpenGL is simply a graphics API standard and can be implemented over the X protocol, as well as simply the graphics card.

Well, ok. I won''t argue about superiority of RPC and the stupidity of adopting "computer is a network" approach for stuff like graphics because it''s a whole different discussion. What I meant to say was "Can someone give me one good reason why hardware dependent OpenGL drivers also depend on the XFree86 server?" Which brings us to the next point...

quote:Original post by Flarelocke
AFAIK, it''s not [...] It''s just a matter of doing it; there''s nothing really stopping anyone from using the provided drivers (and C&P''ing part of the X drivers, if necessary) into a framebuffer library.

I just love those projects that have "platform independent design." Of course there''s implementation for only one platform but "there''s potential to port to anything". DRI claims it''s not specific to XFree86, but right now there is only one XFree specific implementation. I understand they''re reluctant to spend time on doing something they don''t consider useful (DRI on the framebuffer) but at least they could provide sufficient documentation for doing so. For instance, I was interested in getting OpenGL to run on the framebuffer. Try visiting DRI''s website and get some information on how to do that. I''ll give you a hint: there is none. And I''m fairly confident that contacting the developers will get me a typical linuxoid response. "Use the source, Luke." This is the main reason we''re locked into XFree monopoly and DirectFBGL is moving so slow. Oh well, I guess we won''t see X free (pun intended) accellerated desktop in a long time.

quote:
Can someone give me one good reason why hardware dependent OpenGL drivers also depend on the X server? What is the reason DRI chose to be XFree86 specific?

Probably because at the time the DRI was started, X Free had the best initial hardware support and the 2D drivers were (mostly) already written.
The GL-code itself probably isn''t very XFree86 specific, but the GLX setup code obviously is. If DirectFB is so important to you, you might look into ways you can combine DirectFB GLContext initialization and XFree86 GLContext initialization into a single libGL.so. I don''t think anybody in the DRI project will try to make this any harder for you, it''s just that except for embedded developers, almost nobody has a reason to help you, either.

quote:
Oh well, I guess we won''t see X free (pun intended) accellerated desktop in a long time.

This leaves the obvious question: Why would you want a Linux desktop without X?
Whenever there''s a discussion about "the Linux desktop", people are always bitching about lack of standards and so on. And sure enough, the very same people then demand that XFree be replaced by something else.

Hello? Newsflash: XFree is _the_ standard as far as the Linux desktop is concerned. Abandoning XFree would throw development back by at least 10 years. It would immediatly _kill_ the Linux desktop.

Obviously, this doesn''t mean that the current state of affairs is perfect. But if you think something has to improve, there are better ways to go about it. If, for example, you have issues with the X itself, you should check out XOuvert.
If there are issues with desktop functionality (which is more likely; most people who are complaining about X are simply complaining because they have no clue), you could go to Freedesktop and convince yourself that things are looking up.

cu,
Prefect

quote:This is the main reason we''re locked into XFree monopoly and DirectFBGL is moving so slow.

XFree monopoly? Yeah, how dare they release a project for free with such technical perfection that it''s only significant competition is a fork of itself, and two or three radically different substitutes. DirectFBGL is moving slow because a) it''s based on something few people use, and b) it''s something that''s not essential even to those people who already use DirectFB.

quote:And I''m fairly confident that contacting the developers will get me a typical linuxoid response. "Use the source, Luke."

Considering you''ll end up reading the source anyway, for such a project, and that the project isn''t absolutely massive, like Mozilla, this isn''t too unreasonable anyway. Perhaps if you did this, you could then provide the documentation you feel is missing. Unless, of course, you just wanted to work on your little project, in which case (what a coincidence!), you''ve done the same thing the developers did.

quote:Abandoning XFree would throw development back by at least 10 years. It would immediatly _kill_ the Linux desktop.

Nope, there''s already a usable version of gnome for DirectFB. It might be necessary to fix some applications that don''t use gdk, but it''s hardly 10 years of work.

The real question is, Does it really matter? Everyone has/uses XFree anyway.