test
Codito, ergo sum - "I code, therefore I am"
James Simmons (o_
fbdev/gfx developer (o_ (o_ //\
http://www.linux-fbdev.org (/)_ (/)_ V_/_
http://linuxgfx.sourceforge.net
It only works for PowerPCs :(
Codito, ergo sum - "I code, therefore I am"
James Simmons (o_
fbdev/gfx developer (o_ (o_ //\
http://www.linux-fbdev.org (/)_ (/)_ V_/_
http://lin
tian Groessler wrote:
>
>
> On 01/05/2000 02:37:24 PM GMT James A Simmons wrote:
> >
> >It only works for PowerPCs :(
>
> But it should not much to be changed to make it work on PCs.
> I once (linux 2.1.131) tried it and already had it loading (it was more or
&
I will update. Also the drivers are in 2.3.37+ becoming less dependent on
Open Firmware so it needs updating anyways. Anyone have the docs for this
card? I can port it over to the standard kernel.
Codito, ergo sum - "I code, therefore I am"
James Simmons
> This is one of the reasons why the 3D hardware support must be into
> the kernel (of course, the main one is that "it's hardware, you shouldn't
> talk directly to the hw on a unix machine!!").
>
> > Isn't hurt by input or other processing/signals/...
>
> My opinion is that it
On Tue, 25 Jan 2000, Justin Cormack wrote:
> >
> > Andreas Beck wrote:
>
> > > So IMHO one should rather _avoid_ multithreading, except for _large_
> > > independent tasks. The natural way to do this is in the user program, like
> > > separating input, scene calculation and rendering.
>
> Thi
http://oss.sgi.com/projects/ogl-sample/
Codito, ergo sum - "I code, therefore I am"
James Simmons (o_
fbdev/gfx developer (o_ (o_ //\
http://www.linux-fbdev.org (/)_ (/)_ V_/_
> UNIX has some ancient thing called "job control". Programs started as
> _background_ processes (e.g. from a main program) are denied access to
> the TTY (i.e. the VT), they can't write to it or get input. I suppose
> the idea was, programs could be spawned and they shouldn't mess up the
> mai
> >Jason and Steffen since you have attempted multiheaded support before
> > your input will be greatly welcomed :> If we all work together we can come
> > up with one heck of a solution. This is going to be my project at 3Dfx.
> > It's going to kick butt to have quake run on multiple heads o
> >What needs to be done? Well both me and Vojtech have early work for
> >multihead support in 2.3.X. Vojtech already has /dev/event in the usb
> >directory of the developement branch.
>
> yes, i noticed this recently and got /dev/input0 working this morning with
> my USB keyboard (yea!).
On 16 Feb 2000 [EMAIL PROTECTED] wrote:
> James Simmons <[EMAIL PROTECTED]> wrote:
> >[snip snip]
> >What needs to be done? Well both me and Vojtech have early work for
> > multihead support in 2.3.X. Vojtech already has /dev/event in the usb
> > directory of the developement branch. I have
On 17 Feb 2000 [EMAIL PROTECTED] wrote:
> James A Simmons <[EMAIL PROTECTED]> wrote:
> > All of the ones in linux/drivers/video. I have the API in but know one
> > seems to understand the new API. I have written a FB-Driver-HOWTO. You can
> > read it from http://
On Fri, 18 Feb 2000, Cesar Crusius wrote:
> This is just in case someone is really desperated for a GGI web browser: I
> just bumped into ZEN, a web browser that works in fbdev, but it does not use
> GGI. If someone has time to spare maybe a little hack on zen could result in
> a GGI browser.
I
> Sure, and you could simply draw two or three screens that way instead of
> drawing six. In fact, if you ever get GL hardware support in GGI, it
> might be possible to have 3 screens rendered in HARDWARE.. That would
> just seriously kick ass!
Howdy!!!
I back from my trip from San Jose. W
> Yep, the more interfaces, the better. :)
> My main purpose was to get a web browser for the framebuffer, and
> that's why I started doing my current oFBis interface.
>
> Recently, I've mailed with a guy who had an interest in making an
> interface using the Allegro library, which apparently ha
> > Howdy!!!
> >
> > I back from my trip from San Jose. What you described below was one of
> > this I discussed with 3Dfx about doing. It is quite possible to get GL
> > support in GGI going. One of the topics I discussed with 3Dfx was GGI. I
> > discovered they have someone that works for th
> I've had many email pass between Joseph Kain and myself... I usually send
> anyone with a Glide problem I can't answer his way (poor guy!)
I can imagine. He seems like a really nice guy. I answer question about
fbdev all the time.
> There is a GGI Glide target, but it's 2D. What's wanted is
On Tue, 22 Feb 2000, Justin Cormack wrote:
>
> > > There is a GGI Glide target, but it's 2D. What's wanted is accellerated
> > > hardware 3D.. Something that CAN render 3 screens of Quake at a decent
> > > FPS. =>
> >
> > I agree. So where do we start? First voodoo cards like many cards are
> Okay, I'm not sure but I'm also on the 3dfx/DRI list :)
> [still looking at possibly making a DRI loader for GGI but haven't built
> up the energy *sigh*]
You fully understand the X authentic scheme they use?
> Oh, and 3dfx/opengl is being made -very- X/DRI specific.
The attitude is that X/
On Sun, 27 Feb 2000, teunis wrote:
> Heya.
> Is it possible to do an accelerated 2D driver under OpenGL?
>
> Should be, I can't see why not.
Yes you can. The 3D stuff would have to be software rendered ontop of the
2D code.
> Any driver to look for ideas?
Don't think so.
> It'd be cool to
Due to demand. I have started the linux console project. The goal is to
design a new multihead console system for linux. I hope to have it ready
to be ported right into the 2.5.X kernels. I see alot of people have
worked on new and different ideas for a console system. I would like to
see this pr
> True if you want to run fullscreen, and you can live with the other
> limitations ie 16 bit colour and Z buffer, and 256x256 textures maximum.
> The Voodoo 4 and 5 overcome these limitations however, and I am just waiting
> for them to come out...
Also the voodoo 4 and 5 have a geometric proce
On Tue, 22 Feb 2000, Firstname Lastname wrote:
>
>
> Sometimes when i'm running X and run fbset (using the fbdev matrox driver),
Thats a bad idea. A patch will be going in to 2.3.X to not allow this.
> my screen hoses... if i switch VC's my screen is still hosed. however, if
> i type, s
> One thing I have always dreamed about is a GGIMesa extension of
> the "multi" target which would accept multiple eye coordinate sets and
> render each frame to a different sub-target using the different eye
> coordinates. That should do it, right?
Me too :)
> > Cute possibility -> Mesa
> I've been looking at making a Mesa/3Dfx/fbdev varient [or DRI without
> requiring X]. I'm annoyed at X again...
Okay. I fbdev 3Dfx target could easily be developed. The ATI 128 would be
a little hard since its DMA based. Both have fbdev drivers. A DMA libggi
howto ?
Codito, ergo sum - "I co
On Sat, 19 Feb 2000, Jaime Dias wrote:
> what is need to port ggi to the aros (an amiga os clone) to run the 3D cube
> demo?
If you want the ability to run ggi programs on this target you need to
create a target for the libggi library. Their are several docs on this.
Unfortunely I have to run t
On 1 Mar 2000, Thomas Mittelstaedt wrote:
> Hallo,
>
> I am not a GGI-newbie anymore but fairly 'young' in it.
> I recently was trying to use the above functions without any success.
> I am running a late January snapshot of all ggi including ggi2d.
>
> According to the ChangeLog in libggi2d/d
On Tue, 28 Mar 2000, Andrew Apted wrote:
> I think that the LibGGI fbdev target should check whether KDGETMODE
> returns KD_TEXT or KD_GRAPHICS, and if the VT is already in graphics
> mode then refuse to perform a ggiSetMode. Currently it is possible to
> run a libggi program when the framebuff
> 1. Mesa: AFAIK Mesa has some native S3 driver, but I don't know, if it works
> under Unix - it might be for DOS/Win only - anyone ?
Windows only :(
> 2. SVGAlib: I don't know, if Mesa has an SVGAlib target, but I don't
> recommend using it, if you want to go through LibGGI. Mesa has native
>
29 matches
Mail list logo
