lkml.org 
[lkml]   [2006]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: OpenGL-based framebuffer concepts
    On 5/30/06, Antonino A. Daplas <adaplas@gmail.com> wrote:
    > I was thinking of reviving this patch, because of problems with suspend/
    > resume and mode setting. But if there is a plan to put an emulator as part
    > of the kernel library, I'll hold off.

    There's a plan but nobody is working on it right now. The first step
    is to get klibc in and that seems to be taking forever. klibc is
    making progress, there is a merged kernel/klibc git tree available,
    I'm just not sure when it will get merged for real.

    > I'm also thinking of using a different user-kernel interface. The old
    > patch creates a misc device which the daemon opens, but can the kernel
    > connector do the job? I don't know anything about this.

    My app wrote its results and signaled it was finished by writing to a
    sysfs attribute. I'm sure one of the experts on the list will tell us
    the right way to do this.

    The flow is like this:
    normal user ioctls device
    kernel driver calls usermodehelper
    what's the right way for the kernel driver to sleep here?
    user space run the helper app as root
    app writes to sysfs attribute
    kernel driver wakes
    returns out to normal user

    If you look at the code for /sys/class/firmware it does most of what is needed.
    Check out drivers/base/firmware_class.c

    This code can be generalized to support calling out to arbitrary user
    mode helpers instead of the specific firmware helper. I think I posted
    a patch to do this, I don't have it locally but it may be in the
    archives.

    > PS: This user helper need not just do x86 calls, it might use OF or even
    > X. (I believe the Xen people have something similar). A userspace
    > framebuffer driver usable by the kernel console is definitely possible.

    I have never been against having the driver call out into user mode,
    in fact it is required for some hardware. The model I would like to
    see is for everything to be controlled via a device node. Having the
    device node lets you control it as a normal user and then use the
    device driver to gain root when you have to have it.


    --
    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: 2006-05-31 04:40    [W:2.491 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site