SDL on Linux without X

Im developing an embedded product with OpenGL, and Im
trying to avoid the use of X on my product.

I though SDL might to the job. I downloaded it,
compiled and read the documentation and it looks like
it requires the X11 server.

Is there a way to configure SDL so it and OpenGL use a
framebuffer without X.

Thanks

Jim Shelton__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger

SDL itself doesnt require X, it can use SVGAlib, or write to a framebuffer
device, or even do ascii art output :slight_smile:
The problem is that all the GL libraries I have seen for linux need an X
server, at least thats what I think, you may be able to compile Mesa to
output to framebuffer?On Sat, Sep 08, 2001 at 12:31:15PM -0700, Jim Shelton wrote:

Im developing an embedded product with OpenGL, and Im
trying to avoid the use of X on my product.

I though SDL might to the job. I downloaded it,
compiled and read the documentation and it looks like
it requires the X11 server.


Adam
@Adam_Feakin
j: superpeach at jabber.org
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20010908/f7f26117/attachment.pgp

Software Mesa can output to any number of things, but no 3D cards have
non-X support. You might be able to compile a stripped down X server for
NVidia’s chipset driver, but that limits you to NVidia. You might also be
able to, with a small ammount of effort, convert Mesa/Glide2 to use the
input core instead of SVGALib for input, but that limits you to 3Dfx
Voodoo2 and less. Voodoo3 Glide2 requires X in order to provide the glue
between the card’s 2 and 3D functions, but this could be seperated.
Voodoo4/5 support is dependant on making DRI work without X.

Either way, you’re going to come back to this essential need to get a
stripped down X server. Now this is POSSIBLE, the XFree86 4.x servers are
very modular nowadays so it’s probably possible to remove the components
you do not need, but it won’t be a trivial hack to be sure.

Sorry I can’t offer more advice. NVidia’s stuff will probably be the
easiest to get working because it doesn’t rely on the DRI infrastructure
which is very much tied to X. Unfortunately, NVidia isn’t really willing
to give us low-level specs. They tried to offer midlevel specs (the kind
used by all of their win32 drivers, which may or may not be sufficient for
writing open drivers for Linux, I don’t know) but the DRI people wanted
much lower level stuff and NVidia isn’t willing to provide it.

I think your most effective solution is going to wind up being to try and
strip out unneded cruft from the X server. It’s the hardest solution, but
the one that affords the most hardware compatibility and allows for better
testing of your applications since you can just use them on a real X
server on your PC…On Sat, Sep 08, 2001 at 10:10:13PM +0100, Adam Feakin wrote:

SDL itself doesnt require X, it can use SVGAlib, or write to a framebuffer
device, or even do ascii art output :slight_smile:
The problem is that all the GL libraries I have seen for linux need an X
server, at least thats what I think, you may be able to compile Mesa to
output to framebuffer?


Joseph Carter Free software developer

LWE?
Linux W?? E??
will eatyou
World Expo?
i see

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20010908/ba3e70fd/attachment.pgp

  • Joseph Carter on Sat, Sep 08, 2001:

Software Mesa can output to any number of things, but no 3D cards have
non-X support. You might be able to compile a stripped down X server for
NVidia’s chipset driver, but that limits you to NVidia. You might also be
able to, with a small ammount of effort, convert Mesa/Glide2 to use the
input core instead of SVGALib for input, but that limits you to 3Dfx
Voodoo2 and less. Voodoo3 Glide2 requires X in order to provide the glue
between the card’s 2 and 3D functions, but this could be seperated.
Voodoo4/5 support is dependant on making DRI work without X.

Uh the input core has nothing to do with the card in your box or the Linux
framebuffer.

M. R.

The SVGALib Mesa/Glide target no longer works on many systems, AT ALL.
Oh Glide works fine, but not SVGALib. Hence input core, which is already
available to USB input users and has been declared a good thing that will
go in to mainline kernels when the various arch’s input drivers are able
to use it.

Given that SVGALib is working fewer and fewer places, was never all that
stable, and is primarily used for what input core does better anyway, the
solution seems obvious and totally non-controversial. FWIW, Glide2 has
never to my knowledge been able to be used outside of ia32, the Voodoo3
was the first card that you could ever pop into a Mac or whatever, so even
the lack of multi-arch support in the input core patch is not an issue.On Sat, Sep 08, 2001 at 08:06:18PM -0500, M. R. Brown wrote:

Software Mesa can output to any number of things, but no 3D cards have
non-X support. You might be able to compile a stripped down X server for
NVidia’s chipset driver, but that limits you to NVidia. You might also be
able to, with a small ammount of effort, convert Mesa/Glide2 to use the
input core instead of SVGALib for input, but that limits you to 3Dfx
Voodoo2 and less. Voodoo3 Glide2 requires X in order to provide the glue
between the card’s 2 and 3D functions, but this could be seperated.
Voodoo4/5 support is dependant on making DRI work without X.

Uh the input core has nothing to do with the card in your box or the Linux
framebuffer.


Joseph Carter Free software developer

Hmm… Which would do a better job at driving physicists crazy? Travel
faster than light, or a floating-point boolean value?
– Michael Mol

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20010908/9e321e23/attachment.pgp

  • Joseph Carter on Sat, Sep 08, 2001:

Software Mesa can output to any number of things, but no 3D cards have
non-X support. You might be able to compile a stripped down X server for
NVidia’s chipset driver, but that limits you to NVidia. You might also be
able to, with a small ammount of effort, convert Mesa/Glide2 to use the
input core instead of SVGALib for input, but that limits you to 3Dfx
Voodoo2 and less. Voodoo3 Glide2 requires X in order to provide the glue
between the card’s 2 and 3D functions, but this could be seperated.
Voodoo4/5 support is dependant on making DRI work without X.

Uh the input core has nothing to do with the card in your box or the Linux
framebuffer.

The SVGALib Mesa/Glide target no longer works on many systems, AT ALL.
Oh Glide works fine, but not SVGALib. Hence input core, which is already
available to USB input users and has been declared a good thing that will
go in to mainline kernels when the various arch’s input drivers are able
to use it.

The only input cores I’m aware of are the one in 2.4.x, and the one
currently being developed for 2.5.x (codenamed Ruby). The input core
(which is fully supported in SDL) consists of a generic evdev layer that
can report input events from all devices, a keyboard event handler and
mouse event handler (for USB HIDs), and a joystick driver that supports the
older 2.2 interface and the newer input core one. It’s available to anyone
who wants to use it, it’s been in mainline kernels all of 2.4.x, and
various archs do support it. Even the Linux/Dreamcast port reports events
through the input core, that happens to be the SH architecture.

Given that SVGALib is working fewer and fewer places, was never all that
stable, and is primarily used for what input core does better anyway, the
solution seems obvious and totally non-controversial. FWIW, Glide2 has
never to my knowledge been able to be used outside of ia32, the Voodoo3
was the first card that you could ever pop into a Mac or whatever, so even
the lack of multi-arch support in the input core patch is not an issue.

Again, the input core isn’t related to the graphics card you are using.
That’s all I’m trying to clarify as you would lead folks to believe
otherwise. Perhaps becasue Mesa uses SVGAlib (why?) for input it’ll only
run on those specific cards from the console, but SDL doesn’t have that
restriction. You mean to say that when SDL exposes OpenGL, it relies on
Mesa for input? That’s what you implied.

Also, one would think that you would use the kernel DRI interface for
framebuffer/non-X 3D rendering, but I guess no one’s interested in doing
that as the X behemoth keeps chugging along :).

M. R.> On Sat, Sep 08, 2001 at 08:06:18PM -0500, M. R. Brown wrote:

The SVGALib Mesa/Glide target no longer works on many systems, AT ALL.
Oh Glide works fine, but not SVGALib. Hence input core, which is already
available to USB input users and has been declared a good thing that will
go in to mainline kernels when the various arch’s input drivers are able
to use it.

The only input cores I’m aware of are the one in 2.4.x, and the one
currently being developed for 2.5.x (codenamed Ruby).

Yes, which is there for USB and other drivers are being ported to it as
fast as possible.

The input core (which is fully supported in SDL) consists of a generic
evdev layer that can report input events from all devices, a keyboard
event handler and mouse event handler (for USB HIDs), and a joystick
driver that supports the older 2.2 interface and the newer input core
one. It’s available to anyone who wants to use it, it’s been in
mainline kernels all of 2.4.x, and various archs do support it. Even
the Linux/Dreamcast port reports events through the input core, that
happens to be the SH architecture.

The non-HID keyboard/mouse support is what is still in development. SDL
does support it (and indeed it makes linuxfb useful since it gives you a
uniform way to access a mouse if your mouse happens to be USB…) However,
fxMesa does not. fxMesa uses SVGALib. It’s kinda frustrating actually,
but I am certain someone could fix fxMesa to also use the input core and
when the non-HID keyboard/mouse support goes in later on, we will
hopefully find suddenly that SVGALib can truly die at long last since it
will no longer be needed for graphics output or uniform mouse input. =)

Given that SVGALib is working fewer and fewer places, was never all that
stable, and is primarily used for what input core does better anyway, the
solution seems obvious and totally non-controversial. FWIW, Glide2 has
never to my knowledge been able to be used outside of ia32, the Voodoo3
was the first card that you could ever pop into a Mac or whatever, so even
the lack of multi-arch support in the input core patch is not an issue.

Again, the input core isn’t related to the graphics card you are using.
That’s all I’m trying to clarify as you would lead folks to believe
otherwise. Perhaps becasue Mesa uses SVGAlib (why?) for input it’ll only
run on those specific cards from the console, but SDL doesn’t have that
restriction. You mean to say that when SDL exposes OpenGL, it relies on
Mesa for input? That’s what you implied.

I’m saying that fxMesa requires SVGALib. This is correctable, but only if
you wanna take a large mallet to fxMesa and pound the SVGALib code into
linuxfb/input core code. This is a worthwhile endeavor, but the cards
that support it are very old, very slow (by modern standards), and haven’t
been produced for a couple years now. The company who made them is dead,
gone, history, kaput. There’s not a huge driving force to fix fxMesa.

Also, one would think that you would use the kernel DRI interface for
framebuffer/non-X 3D rendering, but I guess no one’s interested in doing
that as the X behemoth keeps chugging along :).

Half the kernel DRI interface code is not in the kernel. That and they
keep changing the interface, and most people are satisfied with X. Hence
the suggestion that stripping down X as much as possible is probably
better in the long run. More hardware will work with OpenGL that way.On Sun, Sep 09, 2001 at 07:48:52AM -0500, M. R. Brown wrote:


Joseph Carter Free software developer

It’s as BAD as you think, and they ARE out to get you.

-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: application/pgp-signature
Size: 273 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20010909/cfbabbbb/attachment.pgp

SDL itself doesnt require X, it can use SVGAlib, or write to a framebuffer
device, or even do ascii art output :slight_smile:
The problem is that all the GL libraries I have seen for linux need an X
server, at least thats what I think, you may be able to compile Mesa to
output to framebuffer?

Software Mesa can output to any number of things, but no 3D cards have
non-X support. You might be able to compile a stripped down X server for
NVidia’s chipset driver, but that limits you to NVidia. You might also be
able to, with a small ammount of effort, convert Mesa/Glide2 to use the
input core instead of SVGALib for input, but that limits you to 3Dfx
Voodoo2 and less. Voodoo3 Glide2 requires X in order to provide the glue
between the card’s 2 and 3D functions, but this could be seperated.
Voodoo4/5 support is dependant on making DRI work without X.

I at one point distributed a patch that made Voodoo3 Glide3 work under
framebuffer. Doesn’t really matter though - as the glide3 drivers aren’t
supported under framebuffer in Mesa. Mesa doesn’t seem to support
framebuffer at all, under any condition. deep sigh
(last looked at about 6 months ago though) - and patch is on the
glide-patches mailing list archive I guess… not sure that anyone ever
tried it though other than myself… and as I no longer have a -working-
Voodoo3-type card, I can’t work on it anymore.

I’d be happy with X if it supported text-fullscreen and multiple
fullscreen text consoles, all accelerated just like my FB driver :slight_smile:
Oh and multiple depths, although an accelerated 32bpp is fine.
g. I’ve -never- been happy in X…

G’day, eh? :slight_smile:
- Teunis PetersOn Sat, 8 Sep 2001, Joseph Carter wrote:

On Sat, Sep 08, 2001 at 10:10:13PM +0100, Adam Feakin wrote: