lkml.org 
[lkml]   [2006]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 2.6.19-rc1 V9] drivers: add LCD support
    On 10/9/06, Pavel Machek <pavel@ucw.cz> wrote:
    > Hi!
    >
    >
    > I do not understand, both /dev/fbcfag12864b and /dev/cfag12864bX are
    > in /dev/...
    >

    I mean: I think it is better to have the cfag12864b device than doesn't.

    >
    > What is advantage of /dev/cfag12864bX over /dev/fbcfag12864b ?
    >
    > (And I guess you should invent better name... /dev/fbaux0?)
    >
    >
    > I do not think we need a Kconfig option, and I do not think we need
    > /dev/cfag12864bX . Just use /dev/fbaux0, always.
    >

    One is the pure device, the other one is the framebuffer device. I
    think having both is better than just one. There is no advantage, they
    are different.

    Maybe someone doesn't need any of the framebuffer advantages and just
    wants to write to it directly, for better performance, for example:
    The LCD needs to change 8 pixels (1 byte) every write, if you modify a
    single pixel at the framebuffer device you will write more times than
    you need for the same result (right? I'm not sure of this); the LCD is
    not capable of high refreshing rates.

    And well, I think it is better that way. About the Kconfig activating
    both modules (cfag12864b and fbcfag12864b) I really don't care. One
    option = easy of use. Both options = more control. Maybe someone just
    needs the pure device :-/ We can really know how the requeriments will
    be, but I think having more options in the future is better than
    shrinking them now.

    >
    > I do not think it is suitable for -rc at this point, and it does not
    > have chance before 2.6.20-rc1, anyway.
    >

    No? Why not? Time is not a problem, I would want to know why are you
    saying that.

    If you are talking about the code's quality, well, the modules are
    working fine, they have been reviewed by many people, and I and some
    friend have tested them enought times to be sure they work. They
    doesn't remove or change any other's code, they doesn't get compiled
    by default either...

    If you are talking about the framebuffer device, it is something that
    can be added later, without any withdraws; and without having to stop
    or modify the other device drivers; as is an additional feature that
    should be added as other module "fbcfag12864b", like:

    lcd -> parport -> ks0108 -> cfag12864b -> fbcfag12864b -> fbcon -> console

    This way, adding future forks/modifications is easier and doesn't
    affect other modules. Right now, we are providing cfag12864b support
    to Linux, then, we will be able to provide a framebuffer device for
    the cfag12864b; then, ...; then, ...
    -
    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-10-09 00:49    [W:0.042 / U:124.224 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site