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