RE: Why is Device3Dfx driver (voodoo1/2) not in the kernel?

RE: Why is Device3Dfx driver (voodoo1/2) not in the kernel?

[Grover, Andrew]

> From: James Simmons [mailto:jsimmons@transvirtual.com]
> > > different VCs. The current system allows it too but it is 
> more of a later
> > > add on hack. I have a much cleaner implementation which 
> does what you ask 
> > > of the above.         
> > 
> > The requirements of ACPI may yet see you get your wish ...
> 
> Let me guess. Insane like the rest of it.

Aww why'd you have to go and say that? Alan for once didn't bash ACPI
(;-)))) and you have to step up and do so?

Knowing ACPI intimately, I can say it deserves several unflattering
adjectives (insane isn't one of them) but also many good qualities that will
be obvious once implementation is complete.

Regards -- Andy
(Insane ACPI maintainer)

Why is Device3Dfx driver (voodoo1/2) not in the kernel?

[Steven Griffiths]

Does anyone know why the Device3Dfx kernel driver is not in the standard 
kernel?

Would anyone be willing to accept a patch?

Re: Why is Device3Dfx driver (voodoo1/2) not in the kernel?

[Alan Cox]

> Does anyone know why the Device3Dfx kernel driver is not in the standard 
> kernel?

Because it lets anyone crash the machine by feeding a Voodoo1 garbage. To
get something like that into the kernel I suspect would involve

-	Making sure glide is using the fifo
-	Writing a parser for packet1-packet5 commands to verify they 
	are valid

then voodoo would be safe for user direct access.

Alan

Re: Why is Device3Dfx driver (voodoo1/2) not in the kernel?

[Jason McMullan]

Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> Because it lets anyone crash the machine by feeding a Voodoo1 garbage. To
> get something like that into the kernel I suspect would involve
>
> -	Making sure glide is using the fifo
> -	Writing a parser for packet1-packet5 commands to verify they 
> 	are valid
>
> then voodoo would be safe for user direct access.

	Better stop that this minute Alan! You're starting
to sound like those old KGI people, with their 'safe kernel
drivers for video' spiel... ;^)


-- 
Jason McMullan, Senior Linux Consultant
Linuxcare, Inc. 412.432.6457 tel, 412.656.3519 cell
jmcmullan@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Putting open source to work.

Re: Why is Device3Dfx driver (voodoo1/2) not in the kernel?

[Alan Cox]

> > then voodoo would be safe for user direct access.
> 
> 	Better stop that this minute Alan! You're starting
> to sound like those old KGI people, with their 'safe kernel
> drivers for video' spiel... ;^)

There are actually distinct similarities between some DRI drivers and what
Linus suggested the KGI people needed to be doing. Certain hardware isnt 
totally user safe (not on the extremes of the voodoo1 here) and the drivers
do small amounts of work to stop abuse. All mode changes, rendering
primitives and the like are however in userspace.

I firmly believe you can do X11 with 3D in windows, including partial 
occlusion of 3d windows on a 3dfx voodoo1 or voodoo2 card. 

Alan

Re: Why is Device3Dfx driver (voodoo1/2) not in the kernel?

[Jason McMullan]

On Thu, Sep 27, 2001 at 01:00:50PM +0100, Alan Cox wrote:
> There are actually distinct similarities between some DRI drivers and what
> Linus suggested the KGI people needed to be doing. Certain hardware isnt 
> totally user safe (not on the extremes of the voodoo1 here) and the drivers
> do small amounts of work to stop abuse. All mode changes, rendering
> primitives and the like are however in userspace.

	Rendering - definitely agree. Userspace.

	Mode changing - Now there I can get into an argument. I
still (after all these years) feel that the Kernel is the best
place to put video mode control. That way 'killall -9 X' isn't
nearly as nasty... The kernel could at least get you back to
a text console.

	And now that XFree86 4 has a vm86 system to 'run the
Video BIOS' for certain cards, it shouldn't be to hard to 
emulate the old OS/2 system - in a vm86 session, use the BIOS
to switch to all the supported modes, and record (via vm86
io traps) everything the BIOS does. Then, in the driver,
just 'play back' the scripts... Worked beatifully for OS/2
back in the day for 2D framebuffers...

	Anyway, I'll just let sleeping dogs lie and leave it
at that.

> I firmly believe you can do X11 with 3D in windows, including partial 
> occlusion of 3d windows on a 3dfx voodoo1 or voodoo2 card. 

	As do I, but I lack three things: The time, The Specs, and
The Hardware. :(

-- 
Jason McMullan, Senior Linux Consultant
Linuxcare, Inc. 412.432.6457 tel, 412.656.3519 cell
jmcmullan@linuxcare.com, http://www.linuxcare.com/
Linuxcare. Putting open source to work.

Re: Why is Device3Dfx driver (voodoo1/2) not in the kernel?

[James Simmons]

> 	Mode changing - Now there I can get into an argument. I
> still (after all these years) feel that the Kernel is the best
> place to put video mode control. That way 'killall -9 X' isn't
> nearly as nasty... The kernel could at least get you back to
> a text console.

Can we say framebuffer devices. As graphics cards are placed into more 
and more different types of systems we need to have a way to make these
cards workable on different platforms. This requires us to write
drivers that can initialize a mode without firmware. I have reworked the
console layer to deal with this and with allowing different modes on
different VCs. The current system allows it too but it is more of a later
add on hack. I have a much cleaner implementation which does what you ask 
of the above.         
 
> 	And now that XFree86 4 has a vm86 system to 'run the
> Video BIOS' for certain cards, it shouldn't be to hard to 
> emulate the old OS/2 system - in a vm86 session, use the BIOS
> to switch to all the supported modes, and record (via vm86
> io traps) everything the BIOS does. Then, in the driver,
> just 'play back' the scripts... Worked beatifully for OS/2
> back in the day for 2D framebuffers...

Really. I have my own personal compain to make all the graphics drivers
firmware independent. I even like to see the VGA console driver also
firmware independent.

Re: Why is Device3Dfx driver (voodoo1/2) not in the kernel?

[Alan Cox]

> different VCs. The current system allows it too but it is more of a later
> add on hack. I have a much cleaner implementation which does what you ask 
> of the above.         

The requirements of ACPI may yet see you get your wish ...

Re: Why is Device3Dfx driver (voodoo1/2) not in the kernel?

[James Simmons]

> > different VCs. The current system allows it too but it is more of a later
> > add on hack. I have a much cleaner implementation which does what you ask 
> > of the above.         
> 
> The requirements of ACPI may yet see you get your wish ...

Let me guess. Insane like the rest of it.

Re: Why is Device3Dfx driver (voodoo1/2) not in the kernel?

[James Simmons]

> Certain hardware isnt 
> totally user safe (not on the extremes of the voodoo1 here) and the drivers
> do small amounts of work to stop abuse. 

The voodoo1 is really dangerous. I have locked my system many times.

> I firmly believe you can do X11 with 3D in windows, including partial 
> occlusion of 3d windows on a 3dfx voodoo1 or voodoo2 card. 

SGI has been doing it for a long long time.