Messages in this thread |  | | | Subject | Re: GGI, EGCS/PGCC, Kernel source | | From | Jes Degn Soerensen <> | | Date | 25 Feb 1998 12:28:39 +0100 |
| |
>>>>> "Stefan" == Stefan Mars <mars@lysator.liu.se> writes:
Stefan> On 24 Feb 1998, Jes Degn Soerensen wrote: >> Then show us what needs to go into the kernel .... OpenGL does >> not.
Stefan> *heartattack* Geez, whatever gave you the impression that we Stefan> are trying to put OpenGL into the kernel?? trust me, we are Stefan> not.
One of the previous posters said that kernel support was needed. I have been looking at some of the web pages and it is not exacly clear to me what will go into the kernel and what will not.
Will you use user space access to video registers when these can be memory mapped and kernel access for boards that do only support the old brain-damaged port IO? Or will you do all access to the video boards' registers using ioctls in kernel space? (for me it doesn't make a difference whether kernel space is something compiled into the kernel statically or if it is a loadable module - it is all kernel context).
Stefan> Living in kernel space is also our drivers, and just like any Stefan> other system they can be compiled in or loaded as a Stefan> module. The drivers knows about their hardware, and exports Stefan> some ioctl calls, some general, some specific to the Stefan> hardwarde, in order to let userland change modes, use Stefan> acceleration etc.
Acceleration in kernel space using ioctls, sorry but no thank you. If you want performance you still need to let the user-space applications such as X and svgalib type things (is that what ggilib is?) access the hardware directly. If it requires apps to be suid root in order to access IO-ports then it is just the price you have to pay IMHO.
Stefan> Hmm.. I am not going to spam the mailing list with a large gif Stefan> (or was it jpeg?), but if you go to our www pages at Stefan> http://www.ggi-project.org, and then look under Stefan> documentation/"overheads from linux kongress" (the link isn't Stefan> called that, you will have to read a little), then you will Stefan> find a speed comparision between Xggi and the S3 Xserver.
Well I didn't look closely at the X server performance comparisons, and frankly I need a usable console before I will even consider X performance.
As to those slides, I still don't see a clear explanation as to what actually goes into the kernel and what does not. I asume a lot of it is hidden in this `graphics special file' ? The closest thing I can find is a reference to some `accelleration ring buffer' which I asume is to communicate with acceleration inside the kernel?
Stefan> As for Geert I haven't seen or heard anything about him tryin Stefan> out GGI for quite some time though, so I would think Stefan> (admittingly without knowing his results) that if you want to Stefan> reference that, then it should be redone.
I wont make any comments on Geert's behalf, he's on holiday at the moment.
Stefan> So, please, come and have a look for yourself. If you feel Stefan> that we are doing something good, then please tell us and Stefan> linux-kernel so. If you feel something should be done Stefan> otherwise we will listen to that too.
I've been there now, any well maybe I didn't look close enough, but I didn't find a lot of information that convinced me that GGI is the ultimate solution in the end. All the things about input devices etc., I do not see why they have to be part of a graphics library, but still it looks like nice things to implement for the kernel.
>> I do agree entirely with Alan when he says that bits from both >> camps will be the right solution in the end.
Stefan> Ok, what specific bits?
I belive that having video-mode switching in the kernel is a good thing, and it is mandatory for some architectures. Your driver architecture which splits the handling of the seperate chips is quite similar to what I would like to do and you have a lot more low-level driver code than we have for obvious reasons.
Having some sort of standard user space library to handle video acces is also a nice idea, and I don't mind having the X server built on top of this. However, I still belive that all the acceleration details has to go into the user space library and not the kernel.
However, how are you going to deal with architectures that do not have VGA-style text-modes for the console and how will you deal with weido devices such as TIGA boards?
Jes
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
|  |