[lkml]   [2006]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: OpenGL-based framebuffer concepts
    > Where do you get 'tons'? There will probably be one for initial reset,
    > one for VESA based mode setting and a few more if there is device
    > specific code needed for a specific card.
    > Making console rely on a permanent daemon that is subject to getting
    > killed by the OOM mechanism is not a workable solution.

    Jon stop trying to hammer everyone by repeating ad-nauseum statements
    of little importance...

    We can stop the OOM killer from killing the daemon if necessary.
    running device drivers in userspace would sort of require this, we can
    run the daemon from init and if it dies, have it respawn, it could put
    persistent info in a shared memory segment provided by the DRM, just
    because you can't think of any way around things, doesn't mean the
    rest of us can't..

    The same things apples to a lot of your other "issues" a /dev/ with
    permissions is no more or less useful than a /tmp/.grphs_socket1 and 2
    with permissions, you insistence that everything be controlled via the
    kernel is another thing you've just failed to think about rather than
    hammer on about it *must* do this.

    I'm spending more time rebutting points you repeatedly make, please
    accept that there are other solutions, and everytime you post a list
    of things *YOU* believe *MUST* be done, remove the things we've shown
    are possible to be done other ways...

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-06-02 01:17    [W:0.020 / U:6.880 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site