* Re: In-kernel graphics subsystem @ 2005-09-22 5:51 rep stsb 2005-09-22 6:06 ` Valdis.Kletnieks 2005-09-22 6:55 ` Ian Romanick 0 siblings, 2 replies; 11+ messages in thread From: rep stsb @ 2005-09-22 5:51 UTC (permalink / raw) To: linux-kernel; +Cc: 06020051 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: In-kernel graphics subsystem 2005-09-22 5:51 In-kernel graphics subsystem rep stsb @ 2005-09-22 6:06 ` Valdis.Kletnieks 2005-09-22 6:51 ` Helge Hafting 2005-09-22 8:35 ` rep stsb 2005-09-22 6:55 ` Ian Romanick 1 sibling, 2 replies; 11+ messages in thread From: Valdis.Kletnieks @ 2005-09-22 6:06 UTC (permalink / raw) To: rep stsb; +Cc: linux-kernel, 06020051 [-- 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 --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: In-kernel graphics subsystem 2005-09-22 6:06 ` Valdis.Kletnieks @ 2005-09-22 6:51 ` Helge Hafting 2005-09-22 8:35 ` rep stsb 1 sibling, 0 replies; 11+ messages in thread From: Helge Hafting @ 2005-09-22 6:51 UTC (permalink / raw) To: Valdis.Kletnieks; +Cc: rep stsb, linux-kernel, 06020051 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: In-kernel graphics subsystem 2005-09-22 6:06 ` Valdis.Kletnieks 2005-09-22 6:51 ` Helge Hafting @ 2005-09-22 8:35 ` rep stsb 1 sibling, 0 replies; 11+ messages in thread From: rep stsb @ 2005-09-22 8:35 UTC (permalink / raw) To: linux-kernel; +Cc: Valdis.Kletnieks, 06020051 --- 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: In-kernel graphics subsystem 2005-09-22 5:51 In-kernel graphics subsystem rep stsb 2005-09-22 6:06 ` Valdis.Kletnieks @ 2005-09-22 6:55 ` Ian Romanick 1 sibling, 0 replies; 11+ messages in thread From: Ian Romanick @ 2005-09-22 6:55 UTC (permalink / raw) To: rep stsb; +Cc: linux-kernel, 06020051 -----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----- ^ permalink raw reply [flat|nested] 11+ messages in thread
[parent not found: <AcW+QBo8uJ+XV7vHTZWR1mo7M5VcNg==>]
* In-kernel graphics subsystem @ 2005-09-21 0:05 ` Athar Hameed 2005-09-21 0:30 ` Kyle Moffett ` (3 more replies) 0 siblings, 4 replies; 11+ messages in thread From: Athar Hameed @ 2005-09-21 0:05 UTC (permalink / raw) To: linux-kernel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: In-kernel graphics subsystem 2005-09-21 0:05 ` Athar Hameed @ 2005-09-21 0:30 ` Kyle Moffett 2005-09-22 10:12 ` Marek W 2005-09-21 0:42 ` Matheus Izvekov ` (2 subsequent siblings) 3 siblings, 1 reply; 11+ messages in thread From: Kyle Moffett @ 2005-09-21 0:30 UTC (permalink / raw) To: Athar Hameed; +Cc: LKML Kernel, Dave Airlie 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: In-kernel graphics subsystem 2005-09-21 0:30 ` Kyle Moffett @ 2005-09-22 10:12 ` Marek W 0 siblings, 0 replies; 11+ messages in thread From: Marek W @ 2005-09-22 10:12 UTC (permalink / raw) To: linux-kernel 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: In-kernel graphics subsystem 2005-09-21 0:05 ` Athar Hameed 2005-09-21 0:30 ` Kyle Moffett @ 2005-09-21 0:42 ` Matheus Izvekov 2005-09-21 2:55 ` Christopher Prest 2005-09-21 10:32 ` Dave Airlie 3 siblings, 0 replies; 11+ messages in thread From: Matheus Izvekov @ 2005-09-21 0:42 UTC (permalink / raw) To: Athar Hameed; +Cc: linux-kernel 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/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: In-kernel graphics subsystem 2005-09-21 0:05 ` Athar Hameed 2005-09-21 0:30 ` Kyle Moffett 2005-09-21 0:42 ` Matheus Izvekov @ 2005-09-21 2:55 ` Christopher Prest 2005-09-21 10:32 ` Dave Airlie 3 siblings, 0 replies; 11+ messages in thread From: Christopher Prest @ 2005-09-21 2:55 UTC (permalink / raw) To: Athar Hameed; +Cc: linux-kernel 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/ > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: In-kernel graphics subsystem 2005-09-21 0:05 ` Athar Hameed ` (2 preceding siblings ...) 2005-09-21 2:55 ` Christopher Prest @ 2005-09-21 10:32 ` Dave Airlie 3 siblings, 0 replies; 11+ messages in thread From: Dave Airlie @ 2005-09-21 10:32 UTC (permalink / raw) To: Athar Hameed; +Cc: linux-kernel > > 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2005-09-22 10:39 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-09-22 5:51 In-kernel graphics subsystem rep stsb
2005-09-22 6:06 ` Valdis.Kletnieks
2005-09-22 6:51 ` Helge Hafting
2005-09-22 8:35 ` rep stsb
2005-09-22 6:55 ` Ian Romanick
[not found] <AcW+QBo8uJ+XV7vHTZWR1mo7M5VcNg==>
2005-09-21 0:05 ` Athar Hameed
2005-09-21 0:30 ` Kyle Moffett
2005-09-22 10:12 ` Marek W
2005-09-21 0:42 ` Matheus Izvekov
2005-09-21 2:55 ` Christopher Prest
2005-09-21 10:32 ` Dave Airlie
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).