|
From: Andrew M. <ak...@li...> - 2008-07-25 23:36:10
|
On Sun, 13 Jul 2008 22:19:28 +0300 Yauhen Kharuzhy <je...@gm...> wrote: > On Mon, Jul 14, 2008 at 03:03:05AM +0800, Jaya Kumar wrote: > > On Sun, Jul 13, 2008 at 8:20 PM, Mikhail Gusarov > > <dot...@do...> wrote: > > > Twas brillig at 11:02:29 13.07.2008 UTC+08 when jay...@gm... did gyre and gimble: > > > > > > JK> However, I should point out that hecubafb is a driver for this same > > > JK> apollo controller. > > > > > > AFAICT from the diff, eink_apollofb already includes all the features of > > > hecubafb, so that would be just renaming. Is it worth it? > > > > > > -- > > > > > > > Hi Mikhail, > > > > Looking at the posted code, it is the same code as hecubafb, renamed, > > and with the 2-bit, partial update, and flash features added. > Hardware abstraction layer (with platform_device framework) and rotation also :) > > > The new > > features are good but basically, its a fork of hecubafb. I'm > > suggesting that rather than doing that, it would make more sense to > > add those features to the existing hecubafb code. If any help is > > needed in making that happen, please let me know, I'm happy to help. > > I am agreed. I saw 'Apollo' name more frequently than any other, but > it is not a matter of principe. > I agree that having a separate-but-similar driver for the same hardware is most undesirable. I presently have eink_apollofb-new-driver-for-apollo-eink-controller.patch on "hold" status, waiting for some resolution here. |