lkml.org 
[lkml]   [2006]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 2.6.19-rc1-mm1
    On 10/10/06, Andrew Morton <akpm@osdl.org> wrote:
    > On Tue, 10 Oct 2006 07:31:23 +0000
    > "Miguel Ojeda" <maxextreme@gmail.com> wrote:
    >
    > > On 10/10/06, Andrew Morton <akpm@osdl.org> wrote:
    > > >
    > > > +# drivers-add-lcd-support.patch: Pavel says use fbcon
    > > > +drivers-add-lcd-support.patch
    > > > +drivers-add-lcd-support-update.patch
    > > >
    > >
    > > Has the # a special meaning?
    >
    > It's a comment separator ;)
    >

    Ouch. Right.

    >
    > > I'm going to work on offering the fbcon feature as Pavel requested.
    >
    > Thanks. It does sound like making the thing an fbdev is the right way to go.
    >

    Yep, such way will let us to run a xgl server through some ascii video
    lib and display it on the 128x64 LCD fb device ;)

    > > suggested 2 ways.
    > >
    > > Pavel's idea: Change the driver so the cfag12864b module will be just
    > > a framebuffer device, removing access through /dev/cfag12864b.
    > >
    > > My idea: Code a new module called "fbcfag12864b", which will depend on
    > > cfag12864b and will be the framebuffer device. This way we have both
    > > devices, and they doesn't affect each other as they are different
    > > things. So the ks0108 and cfag12864b can stay without any changes.
    > > Also, if we finally decide we don't want the raw cfag12864b module, it
    > > is easy to remove it from the cfag12864b and the fbcafg12864b will
    > > continue working.
    > >
    > > Is there anyone who can decide which idea is better? If not, I will
    > > code it my way. Also, if the Pavel's idea will be the chosen one, it
    > > will be easier to put the fbcfag12864b code into the cfag12864b rather
    > > than the opposite.
    >
    > I'd have thought that once the device is accessible as an fbdev, there's so
    > much other software and kernel infrastructure to support that, there's
    > little point in offering an alternative way of presenting the device to
    > userspace.
    >

    Allright, I will code it as the fbcfag12864b module, and when it will
    be working fine, I will remove the raw device of the cfag12864b and if
    the code of fbcfag12864b results really small/trivial, I will put it
    in the cfag12864b module. Then I will send you the "update patch 2".

    Give me a couple of days or so :)

    Thanks you,
    Miguel Ojeda
    -
    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-10 11:59    [W:0.023 / U:124.708 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site