OpenGL without X11
Author
Hi everyone!
I'm wondering what would be the best approach to code, say a trivial game, on Linux/BSD without relying on the X11 Windowing System?
Suppose I don't want an X11 window, I will have my application take over the screen.
From what I've understood, the way things work now, is as such:
1. I write code that uses some OpenGL functions.
2. Thus, I need to include opengl headers
3. I include the headers and now I want to compile my program.
4. So then there must be a library that provides GL.h. I believe a popular choice would be Mesa 3D.
5. I compile my program and link against Mesa3D.
6. I run the program.
And point 6 is where I am a bit stuck. Will Mesa allow access to the graphics hardware? Does Mesa know about the hardware at all, or is it relying on some other library to deal with that, like for example DRI?
So far I'm thinking DRI takes care of the hardware and Mesa takes care of OpenGL. But how do they work together?
And is DRI usable without an X11 server?
What about SDL? Is it a replacement for Mesa 3D or DRI? Or is SDL using/can use Mesa to do its drawing?
I guess I need a brief explanation about what libraries to use in order to be able to draw graphics without X11.
This whole Mesa/DRI/SDL(?) seems complicated and overwhelming, because all I want is to run an application that will draw something on the screen, on a computer that does/should not use X11.
I still remember the good old Pascal/C days where I would specify #include <graphics.h> or 'uses graph;' and then call initgraph() to initialize the graphics. And then I could draw on that screen to my heart's content.
I am of course looking to use 3D acceleration and OpenGL, and if I could get (roughly) the same simplicity and low-level access, I'll be more than happy.
If you have any suggestions or corrections to the way I'm looking at things, please do reply. Any links and explanations will be appreciated!
Thanks!
P.S.: Where does the NVidia / ATI driver fit? Are they dependant on the X Server? Does NVidia supply any header files for us to use their driver?
SDL can draw to the Linux framebuffer, but I'm unsure if OpenGL can be patched in.
I don't know a lot about the subject, but try Googling for things like 'opengl linux framebuffer' and see what you get. A few pages mention it, but no solid howto's or anything.
I don't know a lot about the subject, but try Googling for things like 'opengl linux framebuffer' and see what you get. A few pages mention it, but no solid howto's or anything.
There's a project called DirectFB whose goal is to provide accelerated framebuffer access on linux. This project also provides DirectFBGL which provides an OpenGL API. There seems to be a requirement for a Matrox card for the latter though.
I have no idea how well these projects work in practice or how stable they are, so YMMV.
I have no idea how well these projects work in practice or how stable they are, so YMMV.
Author
Thank you for your replies!
It seems that DirectFB is indeed the only feasible alternative so far and I think it's good enough for my purposes.
Thanks again for your answers.
It seems that DirectFB is indeed the only feasible alternative so far and I think it's good enough for my purposes.
Thanks again for your answers.
The thing you should ask yourself first and foremost is: Why do you want to disregard X?
Since the Linux/BSD desktop is fundamentally based on X and all advanced graphics drivers are written for X, writing a (graphics-based) game without relying on X makes about as much sense as writing a game for DOS.
If you don't want to deal with the X libraries directly, you can always use some intermediary like SDL, glut, or GLFW. In fact, SDL will just give you a simple frame buffer that you can work with, just like in the "good old days" that you seem to be missing.
cu,
Prefect
Since the Linux/BSD desktop is fundamentally based on X and all advanced graphics drivers are written for X, writing a (graphics-based) game without relying on X makes about as much sense as writing a game for DOS.
If you don't want to deal with the X libraries directly, you can always use some intermediary like SDL, glut, or GLFW. In fact, SDL will just give you a simple frame buffer that you can work with, just like in the "good old days" that you seem to be missing.
cu,
Prefect
Hi
You can use Mesa with linux framebuffer. There is glut support. Compile mesa from source with
make linux-fbdev
There is a fbdev api, but then your program will only work on this api. If you make your program use glut, then it will run on X or framebuffer.
mesa on framebuffer is not hardware accelerated.
For hardware accelerated, there is miniglx, but it is not complete. I have run it on a radeon 7500 card and got hardware acceleration without X.
You can use Mesa with linux framebuffer. There is glut support. Compile mesa from source with
make linux-fbdev
There is a fbdev api, but then your program will only work on this api. If you make your program use glut, then it will run on X or framebuffer.
mesa on framebuffer is not hardware accelerated.
For hardware accelerated, there is miniglx, but it is not complete. I have run it on a radeon 7500 card and got hardware acceleration without X.
While I'm no expert, as I understand it nVidia and ATI drivers are X Server drivers only. What you are asking would essentially be the equivalent of trying to do hardware accelerated graphics under DOS rather than Windows. The point to remember is that X--just like windows--exists in large part to provide a unified framework for things like graphics drivers to be built on, and as such is really the only environment where you can reliably access them in a consistent way.
Is there a specific reason you can't use X? That might help in figuring out an answer that would be more useful.
Is there a specific reason you can't use X? That might help in figuring out an answer that would be more useful.
Author
Fair enough.
I do not want to use X because I believe it's a suboptimal solution to what your users really need. It's not modular - it's dissected. I ranted for about 3 pages and then I realized it's not going to help. I'll just write several weaknesses of X and I can say that it's because of these weaknesses that I think Xorg has served it's time and needs to be replaced. This is the main reason why I am looking for an alternative.
And now, the weaknesses, from the point of view of a person who has spent less time changing and recompiling the BSD kernel from scratch (along with GNU tools) then modifying X. I got it to work eventually, but the process did not impress me at all.
1. Almost no documentation. Compare the website X.org with doc.trolltech.com. A documentation should provide a thorough description of all the project's components, an API documentation with description for each function, tutorials to help new users and various examples with screenshots to illustrate the working of the example.
What does X.org have? A wiki. Thanks god they created links for developers, otherwise we would be bound to the search function, which, by the way, is as helpful as a google search for X.org.
Maybe all you X fans can read the developers mind and automagically know what comes from where, how to put it in the right place and how to use it, but we, mortals, like to have a consistent and helpful documentation. Computer Science 101 should teach you about the importance of good documentation.
2. Modular? Huh? Well, splitting something up into 1000 little archives is NOT modularization. Out of these 1000 libraries, 999 are required for the server to work.
Check the Xorg site for what is required to build the X server and then try to do it from scratch. One has to first decipher the cryptic error messages in the makefiles, then go through the dependency hell and then recompile, only to find another annoying error message.
At this point, I would rather prefer to have a monolithic tool with plugins.
I don't want the process to necessarily be easy, but I do want it to be intuitive and documented. It's too much to ask, apparently. If you really need 1000 little archives, provide a tool to manage them, don't throw them at me and expect me to be happy to spend more time on managing the dependency hell than to do actual work.
3. Network transparency is inappropriate for users. Grandpa and his 15 year-old grandson want to check their e-mail, they don't need to login via ssh and start a KDE session.
John the Hacker and his colleague at work, the Great Sysadmin, do need to login remotely and do find X forwarding useful. See a difference in the intended audience? Well then why don't you build something that gets rid of multiple network screens (servers/clients, etc), sockets and ridiculous configuration files and performs one basic thing: draws on the god damn screen. Isn't specialization the fundamental concept of UNIX? Let's follow it, shall we?
4. Xlib. Awful. Junk. Guys, I am no Linus Torvalds, but I can tell you that is some ridiculously stinking stuff. Thanks God there's Qt (or GTK, if you were about to feel offended).
And yet again: NO DOCS! Oh, oh, wait.. There's a book printed in 1997 about Xlib.. and another about plugins and extensions. Have you checked the price? 200$. Xlib is making it's way into 'Collector's Edition'. "Look, grandson, I've got a book about Xlib. The only one left in the Universe."
Hold on.. there's a tutorial on the web, on some Chinese server: the only resource for such a huge and widely used tool. Good job!
Of course, they're OK with it, they've developed the API so they know it. We, the people, can only admire the lack of documentation.
I guess this is it. I can't really complain about anything else. It works fine so far. Now if only nVidia or AMD would make some quality drivers.
By the way, my favorite quote about X is from Wikipedia:
"Mike Paquette, one of the authors of Quartz, explained why Apple did not move from Display PostScript to X, and chose instead to develop its own window server, by saying that once Apple added support for all the features it wanted to include in to X11, it would not bear much resemblance to X11 nor be compatible with other servers anyway".
First, this means Apple did not want to work on improving X, and thus making Linux a better place. They chose to develop their own servers.
Second, this means that, in Apple's eyes and at that time, X was lacking the necessary features to be used in an operating system that focuses on quality.
In other words, "it's crap and we're not going to use it".
Right now, Quartz is doing advanced stuff, and we're still waiting for Xgl.
Yeah, yeah, I know the usual excuse: "It's free, so don't complain". OpenGL is free. Did you hear anyone complaining about how bad it works? That's because it works well! In fact, it works so well, that it's as good as (if not better than) the proprietary DirectX.
There's a need for another graphics display system on *nix, and if DirectFB is not going to become one, somebody will write another one. I just hope they do it right this time. Trust me, if I had the knowledge, I would have been the first person to join the developers team.
[Edited by - Encryptor on July 27, 2008 4:01:48 PM]
I do not want to use X because I believe it's a suboptimal solution to what your users really need. It's not modular - it's dissected. I ranted for about 3 pages and then I realized it's not going to help. I'll just write several weaknesses of X and I can say that it's because of these weaknesses that I think Xorg has served it's time and needs to be replaced. This is the main reason why I am looking for an alternative.
And now, the weaknesses, from the point of view of a person who has spent less time changing and recompiling the BSD kernel from scratch (along with GNU tools) then modifying X. I got it to work eventually, but the process did not impress me at all.
1. Almost no documentation. Compare the website X.org with doc.trolltech.com. A documentation should provide a thorough description of all the project's components, an API documentation with description for each function, tutorials to help new users and various examples with screenshots to illustrate the working of the example.
What does X.org have? A wiki. Thanks god they created links for developers, otherwise we would be bound to the search function, which, by the way, is as helpful as a google search for X.org.
Maybe all you X fans can read the developers mind and automagically know what comes from where, how to put it in the right place and how to use it, but we, mortals, like to have a consistent and helpful documentation. Computer Science 101 should teach you about the importance of good documentation.
2. Modular? Huh? Well, splitting something up into 1000 little archives is NOT modularization. Out of these 1000 libraries, 999 are required for the server to work.
Check the Xorg site for what is required to build the X server and then try to do it from scratch. One has to first decipher the cryptic error messages in the makefiles, then go through the dependency hell and then recompile, only to find another annoying error message.
At this point, I would rather prefer to have a monolithic tool with plugins.
I don't want the process to necessarily be easy, but I do want it to be intuitive and documented. It's too much to ask, apparently. If you really need 1000 little archives, provide a tool to manage them, don't throw them at me and expect me to be happy to spend more time on managing the dependency hell than to do actual work.
3. Network transparency is inappropriate for users. Grandpa and his 15 year-old grandson want to check their e-mail, they don't need to login via ssh and start a KDE session.
John the Hacker and his colleague at work, the Great Sysadmin, do need to login remotely and do find X forwarding useful. See a difference in the intended audience? Well then why don't you build something that gets rid of multiple network screens (servers/clients, etc), sockets and ridiculous configuration files and performs one basic thing: draws on the god damn screen. Isn't specialization the fundamental concept of UNIX? Let's follow it, shall we?
4. Xlib. Awful. Junk. Guys, I am no Linus Torvalds, but I can tell you that is some ridiculously stinking stuff. Thanks God there's Qt (or GTK, if you were about to feel offended).
And yet again: NO DOCS! Oh, oh, wait.. There's a book printed in 1997 about Xlib.. and another about plugins and extensions. Have you checked the price? 200$. Xlib is making it's way into 'Collector's Edition'. "Look, grandson, I've got a book about Xlib. The only one left in the Universe."
Hold on.. there's a tutorial on the web, on some Chinese server: the only resource for such a huge and widely used tool. Good job!
Of course, they're OK with it, they've developed the API so they know it. We, the people, can only admire the lack of documentation.
I guess this is it. I can't really complain about anything else. It works fine so far. Now if only nVidia or AMD would make some quality drivers.
By the way, my favorite quote about X is from Wikipedia:
"Mike Paquette, one of the authors of Quartz, explained why Apple did not move from Display PostScript to X, and chose instead to develop its own window server, by saying that once Apple added support for all the features it wanted to include in to X11, it would not bear much resemblance to X11 nor be compatible with other servers anyway".
First, this means Apple did not want to work on improving X, and thus making Linux a better place. They chose to develop their own servers.
Second, this means that, in Apple's eyes and at that time, X was lacking the necessary features to be used in an operating system that focuses on quality.
In other words, "it's crap and we're not going to use it".
Right now, Quartz is doing advanced stuff, and we're still waiting for Xgl.
Yeah, yeah, I know the usual excuse: "It's free, so don't complain". OpenGL is free. Did you hear anyone complaining about how bad it works? That's because it works well! In fact, it works so well, that it's as good as (if not better than) the proprietary DirectX.
There's a need for another graphics display system on *nix, and if DirectFB is not going to become one, somebody will write another one. I just hope they do it right this time. Trust me, if I had the knowledge, I would have been the first person to join the developers team.
[Edited by - Encryptor on July 27, 2008 4:01:48 PM]
Quote:Original post by Encryptor
Right now, Quartz is doing advanced stuff, and we're still waiting for Xgl.
Xgl was released for over 2 years ago. And is now deprecated and all the functionality is in mainline Xorg. Google compiz.
Do what everyone else does and use a window manager built on top of X11. You linked to the Qt site, why don't you use that? Or GTK+? Or any number of the vast numbers of window managers out there that are designed to simplify the process.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement