linuxdc-dev

[linuxdc-dev] LCD driver

[Adrian M. <ad...@mc...>]

Can I have a definitive statement on where people think this code should live? 
This seems like a reasonable Saturday afternoon project as most of the code 
is extant anyway in the vmu flash driver.

But is it a framebuffer device or an mtd device?

Answers please.....

Adrian

Re: [linuxdc-dev] LCD driver

[Karl T. K. <ka...@pr...>]

On Sat, 16 Nov 2002 12:23:32 +0000
Adrian McMenamin <ad...@mc...> wrote:

> But is it a framebuffer device or an mtd device?

Physically, it's obviously a framebuffer device, and I guess we should try
to make it appear as one logically as well.

However, if that doesn't work, can we address its buffer using mmap after
doing an open("/dev/lcd0") or whatever node name we choose ?

Kind regards,

Karl T

Re: [linuxdc-dev] LCD driver

[M. R. B. <mr...@0x...>]

* Adrian McMenamin <ad...@mc...> on Sat, Nov 16, 2002:

> Can I have a definitive statement on where people think this code should =
live?=20
> This seems like a reasonable Saturday afternoon project as most of the co=
de=20
> is extant anyway in the vmu flash driver.
>=20
> But is it a framebuffer device or an mtd device?
>=20
> Answers please.....
>=20

Note that in both stable and devel trees, Maple will be gutted and redone
within the next few weeks.  I don't know if you want to continue with the
driver, but just know *all* maple drivers will be ripped to shreds fairly
quickly...

M. R.

Re: [linuxdc-dev] LCD driver

[Adrian M. <ad...@mc...>]

On Saturday 16 Nov 2002 4:00 pm, M. R. Brown wrote:
> * Adrian McMenamin <ad...@mc...> on Sat, Nov 16, 2002:
> > Can I have a definitive statement on where people think this code should
> > live? This seems like a reasonable Saturday afternoon project as most of
> > the code is extant anyway in the vmu flash driver.
> >
> > But is it a framebuffer device or an mtd device?
> >
> > Answers please.....
>
> Note that in both stable and devel trees, Maple will be gutted and redone
> within the next few weeks.  I don't know if you want to continue with the
> driver, but just know *all* maple drivers will be ripped to shreds fairly
> quickly...
>
> M. R.

I haven't got very far in any case - as doing this as an fb device is not as 
simple as simply ripping out bits of code I don't want.

I will stick to vmufs then...

Adrian