lkml.org 
[lkml]   [2006]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: OpenGL-based framebuffer concepts
    Date
    > One solution to this split is to build the system management console
    > in-kernel using the existing fbdev code. A hot key can be used to
    > access it or it will appear automatically on a panic. The system
    > management console does not need acceleration, but it always has to
    > work and work in any context (like interrupt context). Working in any
    > context forces an implementation that is entirely contained in the
    > kernel.

    And what happens if that console data has been damaged by a wild pointer write
    in kernel?

    This does have a practicle use, and the console data for the "System Console"
    is unlikely to get screwed with. I am just pointing out that there are
    problems even with your suggestions. I had already planned on something
    similar to this when I began working on a method to have the video drivers
    able to be added and removed at runtime. What I was planning on was using
    vgacon (for those systems that support it) as the system console and having
    tthe system default back to that should *anything* go wrong in the kernel.
    For the systems that don't support vgacon there is going to be a very minimal
    fbcon that will serve the same purpose.

    Userspace helpers for modesetting and other simple tasks is no problem. When
    it comes to handling the acceleration, the DRI part of the DRM
    infrastructure (the Userspace side of it, in other words) needs to be running
    and available. This is why X has to load the module. Providing that to
    userspace then become a concern, and the easiest way to do this is to have
    the DRI portion loaded and running inside a userspace daemon, either pinned
    into memory so that the OOM killer can't touch it, or running as a special
    process under init that will *always* get restarted if it dies.

    Using a mass of userspace helpers, or requiring the applications to provide
    and load their own userspace drivers for the DRM/DRI system is, IMHO, not an
    option.

    DRH
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-06-02 04:25    [W:3.161 / U:0.164 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site