In-kernel graphics subsystem

In-kernel graphics subsystem

[Athar Hameed]

Hi,

We are a group of three undergrad CS students, almost ready to start our senior project. We have this idea of integrating a graphics subsystem with the kernel and doing away with the X server. We are not really sure if this is a wise thing to do. It hasn't been done before. Your comments on this idea will be very helpful.


Thanks,

Athar
Shery
Kazi

P.S. We are not subscribed to the lklm. Kindly CC your replies to 06020051@lums.edu.pk

Re: In-kernel graphics subsystem

[Kyle Moffett]

On Sep 20, 2005, at 20:05:15, Athar Hameed wrote:
> We have this idea of integrating a graphics subsystem with the  
> kernel and doing away with the X server.

Don't, please!  Graphics cards are way too complex to consider  
putting a whole OpenGL or windowing layer into the kernel.

> We are not really sure if this is a wise thing to do.

It's not.

> It hasn't been done before.

It has.  See http://fbui.org/  Please note that most kernel  
developers do not think it's a good idea.  We have several interfaces  
(framebuffer, DRM, etc) provided to userspace to make it really easy  
to do such things there.

If you want to do something useful for graphics in the Linux kernel,  
you might ask Dave Arlie what he needs help with (I've CCed him).  I  
think that the current list (not in any kind of order), includes a  
generic platform-independent VGA arbiter and a safe kernel/userspace  
API for submitting commands to graphics cards so that the X server  
doesn't need to mmap /dev/mem and manually bang on the PCI busses.   
Also, a reliable system to freeze GPU activity, reset the GPU, and  
display a panic message would be helpful.  Dave can probably give you  
more information about this stuff.

You might also think about a console program that uses the  
framebuffer and input subsystem, so that it is possible to put  
multiple graphics cards in a single box and have multiple independent  
consoles (One on each GPU).

If you feel like doing something X.org related, you could go ask on  
the x.org mailing lists, I'm sure they'd welcome the extra help.

Cheers,
Kyle Moffett

--
There are two ways of constructing a software design. One way is to  
make it so simple that there are obviously no deficiencies. And the  
other way is to make it so complicated that there are no obvious  
deficiencies.  The first method is far more difficult.
   -- C.A.R. Hoare

Re: In-kernel graphics subsystem

[Matheus Izvekov]

On Ter, Setembro 20, 2005 9:05 pm, Athar Hameed disse:
> Hi,
>
> We are a group of three undergrad CS students, almost ready to start our
> senior project. We have this idea of integrating a graphics subsystem with
> the kernel and doing away with the X server. We are not really sure if
> this is a wise thing to do. It hasn't been done before. Your comments on
> this idea will be very helpful.
>
>

http://fbui.org/

> Thanks,
>
> Athar
> Shery
> Kazi
>
> P.S. We are not subscribed to the lklm. Kindly CC your replies to
> 06020051@lums.edu.pk
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: In-kernel graphics subsystem

[Christopher Prest]

I would say no.  Maybe a better idea would be to
extend the current OpenGL lib and provide an API layer
for creating a set of rich graphics functionality in
"regular" applications.  I.e. 3d charts, buttons, 3d
form space ?

Just a suggestion.


--- Athar Hameed <06020051@lums.edu.pk> wrote:

> Hi,
> 
> We are a group of three undergrad CS students,
> almost ready to start our senior project. We have
> this idea of integrating a graphics subsystem with
> the kernel and doing away with the X server. We are
> not really sure if this is a wise thing to do. It
> hasn't been done before. Your comments on this idea
> will be very helpful.
> 
> 
> Thanks,
> 
> Athar
> Shery
> Kazi
> 
> P.S. We are not subscribed to the lklm. Kindly CC
> your replies to 06020051@lums.edu.pk
> 
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at 
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: In-kernel graphics subsystem

[Dave Airlie]

>
> We are a group of three undergrad CS students, almost ready to start our senior project. We have this idea of integrating a graphics subsystem with the kernel and doing away with the X server. We are not really sure if this is a wise thing to do. It hasn't been done before. Your comments on this idea will be very helpful.
>
>

This isn't a good idea, the whole idea of dumping the X server has
been done to death, you might notice we still have an X server... as
mentioned fbui and also DirectFB does a lot of things (not all
in-kernel....)

What might be an interesting side project that is fairly self
contained would be a userspace console with full support for
international languages and Unicode/UTF-8 rendering, using
freetype/xft code. Jon Smirl suggests this in his
http://www.freedesktop.org/~jonsmirl/graphics.html paper and I've
thought it would be an interesting idea to implement at some point,

You could sit it on top of OpenGL or directly on the drm/fbdev layers
(probably a bit harder) an OpenGL rendered console would be a good
enough start I suppose...

Dave.

Re: In-kernel graphics subsystem

[Marek W]

On Wed, 21 Sep 2005 10:30, Kyle Moffett wrote:
> On Sep 20, 2005, at 20:05:15, Athar Hameed wrote:

> If you feel like doing something X.org related, you could go ask on
> the x.org mailing lists, I'm sure they'd welcome the extra help.
>
> Cheers,
> Kyle Moffett

In fact they are in desperate need of programmers as far as I can tell...

-- 
-
Marek W

--
2b | !2b
Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: In-kernel graphics subsystem

[rep stsb]

--- Valdis.Kletnieks@vt.edu wrote:


> Wouldn't it make more sense to extend the current
> framebuffer driver
> support to support v-sync? (framebuffers are already
> in the kernel, and
> there were so many security holes with svgalib-based
> programs that it left
> a bad taste in a lot of people's mouths)

I am presently wounded and cannot do either until I
heal.

> And having gotten a v-sync interrupt, what would you
> *do* with it?
> You'll need an API here....

svgalib has a vga_waitrefresh() function. It can be
implemented as a block on, either a ioctl or a read,
on a kernel-space driver, or by polling.

mihai cartoaje


	

	
		
__________________________________________________________ 
Find your next car at http://autos.yahoo.ca

Re: In-kernel graphics subsystem

[Ian Romanick]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

rep stsb wrote:
> Athar Hameed wrote: 
> 
>>We are a group of three undergrad CS students, 
>>almost ready to start our senior project. We have
>>this idea of integrating a graphics subsystem with
>>the kernel
> 
> A thread about getting vertical synchronization
> interrupts from a video card is available at, 

This functionality is already exposed by the DRM for several cards.
Since work is happening on the X side of things (i.e., EXA) that will
make having a DRM for even non-3D cards desireable, this is probably a
better route to go.

Either that or extend the existing fb drivers.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFDMlVoX1gOwKyEAw8RAgvzAJ41K9u5LQ7GTNe7qfBrWY61+bI32wCeMHIH
z4f5g5uzAIgYixVRpQAqZJI=
=CYVB
-----END PGP SIGNATURE-----

Re: In-kernel graphics subsystem

[Helge Hafting]

Valdis.Kletnieks@vt.edu wrote:

>On Thu, 22 Sep 2005 01:51:20 EDT, rep stsb said:
>
>  
>
>>1. Convert svgalib drivers into kernel modules to get
>>v-sync interrupts. 
>>
>>2. Write a windowing program on svgalib. 
>>    
>>
>
>Wouldn't it make more sense to extend the current framebuffer driver
>support to support v-sync? (framebuffers are already in the kernel, and
>there were so many security holes with svgalib-based programs that it left
>a bad taste in a lot of people's mouths)
>
>And having gotten a v-sync interrupt, what would you *do* with it?
>You'll need an API here....
>  
>
Simple.  What we want from such interrupts, is to wait for them, no?
So lets use one of the existing structures made for waiting.  One example
is a file descriptor.  Do a blocking read, which the kernel unblocks when
the interrupt comes in. A file descriptor also supports things like
select() if need be.

Helge Hafting

Re: In-kernel graphics subsystem

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 531 bytes --]

On Thu, 22 Sep 2005 01:51:20 EDT, rep stsb said:

> 1. Convert svgalib drivers into kernel modules to get
> v-sync interrupts. 
> 
> 2. Write a windowing program on svgalib. 

Wouldn't it make more sense to extend the current framebuffer driver
support to support v-sync? (framebuffers are already in the kernel, and
there were so many security holes with svgalib-based programs that it left
a bad taste in a lot of people's mouths)

And having gotten a v-sync interrupt, what would you *do* with it?
You'll need an API here....



[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: In-kernel graphics subsystem

[rep stsb]

Athar Hameed wrote: 

> We are a group of three undergrad CS students, 
> almost ready to start our senior project. We have
> this idea of integrating a graphics subsystem with
> the kernel


A thread about getting vertical synchronization
interrupts from a video card is available at, 

http://groups.google.ca/group/alt.lang.asm/browse_frm/thread/d1057c825a7933f0/f7239ffb484587d9

I have started a project to write a windowing program
on svgalib at, 

http://sourceforge.net/projects/svgalib-windows 

My idea is, 

1. Convert svgalib drivers into kernel modules to get
v-sync interrupts. 

2. Write a windowing program on svgalib. 

Everyone can join. 

> P.S. We are not subscribed to the lklm. Kindly CC
> your replies to 06020051@lums.edu.pk 

http://groups.google.ca/group/fa.linux.kernel


	

	
		
__________________________________________________________ 
Find your next car at http://autos.yahoo.ca