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