lkml.org 
[lkml]   [1998]   [Feb]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: GGI, EGCS/PGCC, Kernel source
    From
    Date
    >>>>> "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

    \
     
     \ /
      Last update: 2005-03-22 13:41    [W:0.051 / U:0.616 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site