lkml.org 
[lkml]   [2007]   [May]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] enhancing the kernel's graphics subsystem
    On 5/21/07, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
    > Jon, that's why I'm posting this stuff in the first place! :) Again, if
    > you have specific problems with the proposed interfaces (problems that
    > would preclude your wishlist from being fully implementable), please let
    > me know (preferably with specifics).

    A simple place to start is OOPS display while in graphics mode. If we
    going to tear up the kernel graphics system this is something that
    needs to be fixed.

    I don't think it is safe for the OOPS code to attempt a mode change to
    text mode when the OOPS happens. The OOPS could have happened in a 3D
    driver and left the GPU messed up. The safest thing to do is to
    display the OOPS using the mode that is already set.

    This implies that the kernel driver needs to track the dimensions and
    location of the framebuffer and whether it is in text/graphics mode
    (this hasn't been possible before because X never tells the kernel
    what mode it is setting). You also need to bring in the bitmap copy
    code and fonts over from fbdev. When the OOPS happens you use this
    info to paint the OOPS onto the screen. The code from fbdev will let
    you display text in graphics mode entirely in kernel context. The
    driver should also attempt to stop the GPU to try and make sure it
    doesn't erase the OOPS display.

    Another simple thing that needs to be built is a mechanism to run the
    VBIOS in x86 mode when the driver is first loaded. This can be
    achieved by using call_usermode helper to trigger an external app. You
    also need to get the x86 emulator working so that this will work on
    non-x86 platforms (benh has already done this). I've aput the hooks
    into place to give you access to the VBIOS from sysfs. This app is a
    prime candidate for klibc. This app is strongly coupled to the problem
    of VGA arbitration.

    Could we try and work out a solution to these two problems? If we can
    solve these they will provide a foundation for fixing the harder ones.

    --
    Jon Smirl
    jonsmirl@gmail.com
    -
    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: 2007-05-22 16:31    [W:3.481 / U:0.448 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site