I’m trying to compile libSDL 1.2.6 under a Kernel 2.6.0 box, but the
file “src/video/XFree86/Xxf86dga/XF86DGA2.c” needs kernel headers, and
2.6 kernel headers fails to compile on user space. It’s not a real
problem, since I solved it copying this to the file (before the, now
commented, “#include <linux/fb.h>”):
struct fb_fix_screeninfo {
char id[16]; /* identification string eg “TT Builtin” /
unsigned long smem_start; / Start of frame buffer mem /
/ (physical address) /
Uint32 smem_len; / Length of frame buffer mem /
Uint32 type; / see FB_TYPE_* /
Uint32 type_aux; / Interleave for interleaved Planes /
Uint32 visual; / see FB_VISUAL_* /
Uint16 xpanstep; / zero if no hardware panning /
Uint16 ypanstep; / zero if no hardware panning /
Uint16 ywrapstep; / zero if no hardware ywrap /
Uint32 line_length; / length of a line in bytes /
unsigned long mmio_start; / Start of Memory Mapped I/O /
/ (physical address) /
Uint32 mmio_len; / Length of Memory Mapped I/O /
Uint32 accel; / Type of acceleration available /
Uint16 reserved[3]; / Reserved for future compatibility */
};
I haven’t tested it with another kernel versions (maybe diferent fields
?), and I don’t have enought time to fine tune the code, make a “crash
test” for it and create a macro to check the kernel version in compile
time. Sorry about that…
IMHO that’s not the way to make this crap code evolve… I’d suggest
that we mail XFree86 dev team to know the proper way to get X
framebuffer address. We must rely on X API and not play with kernel in a
file that’s reserved to X access… We can’t allow us to use kernel API
there. I don’t want this file not to compile when I’ve chosen X support
but disabled Linux FB support ;-)…On the other hand, in the SDL code supporting Linux FB we can assure a proper SDL API call to get such information provided that Linux FB is enable at compile time. Any comment ? Couannette Eduardo Costa wrote:
I’m trying to compile libSDL 1.2.6 under a Kernel 2.6.0 box, but the
file “src/video/XFree86/Xxf86dga/XF86DGA2.c” needs kernel headers, and
2.6 kernel headers fails to compile on user space. It’s not a real
problem, since I solved it copying this to the file (before the, now
commented, “#include <linux/fb.h>”):
struct fb_fix_screeninfo {
char id[16]; /* identification string eg “TT Builtin” /
unsigned long smem_start; / Start of frame buffer mem /
/ (physical address) /
Uint32 smem_len; / Length of frame buffer mem /
Uint32 type; / see FB_TYPE_* /
Uint32 type_aux; / Interleave for interleaved Planes /
Uint32 visual; / see FB_VISUAL_* /
Uint16 xpanstep; / zero if no hardware panning /
Uint16 ypanstep; / zero if no hardware panning /
Uint16 ywrapstep; / zero if no hardware ywrap /
Uint32 line_length; / length of a line in bytes /
unsigned long mmio_start; / Start of Memory Mapped I/O /
/ (physical address) /
Uint32 mmio_len; / Length of Memory Mapped I/O /
Uint32 accel; / Type of acceleration available /
Uint16 reserved[3]; / Reserved for future compatibility */
};
I haven’t tested it with another kernel versions (maybe diferent fields
?), and I don’t have enought time to fine tune the code, make a “crash
test” for it and create a macro to check the kernel version in compile
time. Sorry about that…
IMHO that’s not the way to make this crap code evolve… I’d suggest
that we mail XFree86 dev team to know the proper way to get X
framebuffer address. We must rely on X API and not play with kernel in a
file that’s reserved to X access… We can’t allow us to use kernel API
there. I don’t want this file not to compile when I’ve chosen X support
but disabled Linux FB support ;-)…
On the other hand, in the SDL code supporting Linux FB we can assure a
proper SDL API call to get such information provided that Linux FB is
enable at compile time.
Any comment ?
This file (src/video/XFree86/Xxf86dga/XF86DGA2.c) is taken from the
XFree86 sources. Maybe it’s simply time to update it ?
Actually, that modification is just an "OMG-I-must-put-SDL-working-now"
version. It only does the same job the precompiler will do with an 2.4
kernel.
Anyway, I guess you are right… If this file was borrowed from X, then
it’s their responsability to not use the kernel headers…
Couannette wrote:>Hi,
IMHO that’s not the way to make this crap code evolve… I’d suggest
that we mail XFree86 dev team to know the proper way to get X
framebuffer address. We must rely on X API and not play with kernel in a
file that’s reserved to X access… We can’t allow us to use kernel API
there. I don’t want this file not to compile when I’ve chosen X support
but disabled Linux FB support ;-)…
On the other hand, in the SDL code supporting Linux FB we can assure a
proper SDL API call to get such information provided that Linux FB is
enable at compile time.
Actually, that modification is just an "OMG-I-must-put-SDL-working-now"
version. It only does the same job the precompiler will do with an 2.4
kernel.
Anyway, I guess you are right… If this file was borrowed from X, then
it’s their responsability to not use the kernel headers…
Actually, it was I who added the kernel headers - it allows DGA to work
without root access when the framebuffer is properly configured. Does
the normal fbcon support work with Linux 2.6?
Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Sam Lantinga wrote:>>Actually, that modification is just an “OMG-I-must-put-SDL-working-now”
version. It only does the same job the precompiler will do with an 2.4
kernel.
Anyway, I guess you are right… If this file was borrowed from X, then
it’s their responsability to not use the kernel headers…
Actually, it was I who added the kernel headers - it allows DGA to work
without root access when the framebuffer is properly configured. Does
the normal fbcon support work with Linux 2.6?
Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment
I have an OpenGL program, an dwhen I pass SDL_Fullscreen to the hardware
screen surface, it switches to the apropriate resolution, but sets my hz
wrong, to 60hz. Making my screen flicker.
I think this is 3D speciffic, since I have a 2D program that uses the
exact same code, yet does not affect the hertz. Anyone have an Idea what
causes this?
Sam Lantinga wrote:>>Actually, that modification is just an “OMG-I-must-put-SDL-working-now”
version. It only does the same job the precompiler will do with an 2.4
kernel.
Anyway, I guess you are right… If this file was borrowed from X, then
it’s their responsability to not use the kernel headers…
Actually, it was I who added the kernel headers - it allows DGA to work
without root access when the framebuffer is properly configured. Does
the normal fbcon support work with Linux 2.6?
Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Um, no. The reason is the same in X, if you tried to change refresh
rates: you can’t tell what the highest working refresh is, since many
pre-PnP monitors will simply be configured (by the user) incorrectly;
on old monitors, there’s no way for the system to tell.
Sorry, can’t quite lay this one on Windows. :)On Thu, Jan 15, 2004 at 11:31:00PM +0100, Christian Biere wrote:
It looks like fb.h is just broken in the 2.6 kernels. There are people
who have submitted kernel patches to fix this, but they haven’t been
integrated yet. I’ll provide some sort of fix so that DGA compiles,
and then when the 2.6 kernels fix the headers, you’ll be able to build
framebuffer console support again.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
