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 [email protected]
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
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
> [email protected]
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
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 <[email protected]> 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 [email protected]
>
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
> 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.
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 [email protected]
http://groups.google.ca/group/fa.linux.kernel
__________________________________________________________
Find your next car at http://autos.yahoo.ca
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....
[email protected] 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
-----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-----
--- [email protected] 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
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