Messages in this thread | | | Date | Tue, 10 Oct 2006 09:57:11 +0000 | From | "Miguel Ojeda" <> | Subject | Re: 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/
| |