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


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/