[lkml]   [1998]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Calm on the GGI waters..

    Btw, one last word to clarify my position a bit, and maybe explain why I
    have gotten so upset by the GGI discussion.

    For example, I've already pointed out that the current kernel already
    _has_ a rather limited support for graphics: it can already write text on
    various graphics cards (the TGA chip I mention is only one of them, and I
    brought it up really only because that's the one I've used personally).

    So what is the difference between that kind of graphics support and the
    GGI kind?

    The difference is really a matter of interface, and tying my hands.

    The TGA kind of "make the graphics card work as a text-mode thing" kernel
    code does not imply a new interface. The code to do the text rendering may
    be simple or complex, buggy or bug-free, but whatever the case is it does
    not limit me or the kernel in any way because it really implies only a
    very limited interface to user space, and it is also an interface that I'm
    more thn happy to provide and that is _obviously_ required, ie a basic
    tty-like interface.

    Think of it as a very basic kind of driver, but a driver that makes no
    policy. The kernel only really guarantees that it can write characters on
    the screen.

    In contrast, the GGI kind of interface implies a lot _more_ in the way of
    support. And by implying that, it ties my hands: I am no longer free to do
    what I think is right, because I have to abide by the interface. This is
    what makes UNIX so good: the basic interfaces are _really_ well thought
    out (whether by chance or good design the basic "fork()" + "execve()" +
    "everything is a file" mentality is a very simple but powerful one). That
    is why I like UNIX, and why I wanted to write my own.

    So while I'm more than happy to have my hands tied in the sense that I, as
    the maintainer of Linux, export that kind of fork() + execve() type of
    interface to user mode, I am not at all certain what kind of interface I
    would feel happy about exporting wrt graphics. I feel confident in
    exporting the text-mode things - that one is a no-brainer. But graphics?

    As a result, I kick back _very_ strongly because I don't see any
    "obviously correct" interface. I'd be happy either with something very
    generic (basic DMA and interrupt interfaces to XFree86, for example), or
    something very specific (some very limited subset of XAA for example: only
    the bare necessities to make XAA easier to do). But anything else is not
    "obvious" any more.

    And when it is not obvious, I feel that "nothing" is much better than
    "something that might not be the right thing". Because it is much easier
    to fix up "nothing" than it is to fix something that people depend on.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to

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