[lkml]   [2003]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectHelp with patch for vesafbd support again?
    Hi Guys,

    Well I managed to finally dig up the old code that Aki Laukkanen deveoped
    sometime in early 2000. Unfortunately Aki died sometime in January 2001,
    so his work on the vesafbd daemon and patches to the vesafb device driver
    were lost - until now.

    I would like to revive this project, and the code I received from Matan
    Ziv-Av still configures and compiles correctly on Red Hat 8.0. I need to
    patch the latest kernel vesafb driver, but I think his patch is very old
    (probably around 2.2.14 timeframe). I am grabbing the 2.2.14 code to see
    if the patch will apply to that code, and then try to port the patch to
    the latest kernel release. Which brings up the first question. What
    kernel version should I patch against? 2.4.x or 2.5.x?

    However since I am not that familiar with the patching mechanism for the
    Linux kernel, would someone more familiar with this be willing to help
    out? I would like to modify the vesafb module in the kernel to optionally
    support the vesafbd daemon if it is present on the system, if not it will
    function as it does today. If vesafbd is present, it will be used to
    provide extended features to the default VESA framebuffer console driver.

    I would also like to generalise the daemon module a bit such that it does
    not need to be a VESA specific daemon, but could in fact contain it's own
    hardware interfacing module. For instance the daemon could use XFree86
    loadable driver modules to implement the functions rather than the VESA
    interface code, which would also open up the option of doing accelerated
    screen blits using the existing XFree86 driver modules. Hence I was
    thinking that the name 'vesafbd' for the daemon is a misnomer and should
    probably be changed to something else like 'fbcond' or something. Any
    suggestions? Or should we just leave it as 'vesafbd' even though it could
    be updated to support more than just the VESA BIOS interface?

    Also the code I have right now for the daemon relies on the /dev/vesafb
    special file to have been created, which is used as the communication
    mechanism between the modified vesafb kernel driver and the daemon code.
    The daemon simply constantly reads from /dev/vesafb for command packets
    to process and writes the results to /dev/vesafb. Some people suggested
    in the past that a better approach might be to either use extended
    ioctl()'s to the existing /dev/fb special file, and have the kernel
    module sleep until it needs to do something, or use other polling methods
    (of which I am not familiar). I would like some guidance here as to the
    best way to implement this daemon if people think it should be changed.

    Finally, before I embark on this project, will this patch will be
    accepted into the kernel source code tree? I would hate to spend my time
    on it only to find out that the kernel developers don't like it and won't
    accept it.


    Kendall Bennett
    Chief Executive Officer
    SciTech Software, Inc.
    Phone: (530) 894 8400

    ~ SciTech SNAP - The future of device driver technology! ~

    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: 2005-03-22 13:34    [W:0.022 / U:0.884 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site