Framebuffer driver question

[Pavel Pisa]

Hello Alex and Joel,

On Monday 13 August 2012 16:29:30 Joel Sherrill wrote:
> On 08/13/2012 09:16 AM, Alexandru-Sever Horin wrote:
> > While I was working on Cirrus fb driver, useful for QEMU simulations for
> > nano-X, I found in the nano-X deprecated files for the VGA planar
> > subdriver. I missed it before because it was not compiled anymore and
> > included as a deprecated driver.
> >
> > With a few modifications, I think it would work.

any problem fixup is welcomed. But this is special
case. I would add list of my pros and cons

 - use of the planar hardware is pain
 - performance is horrible
 - x86 real mode limits do not apply now, there is no
   640 kB/1 MB barrier (at least for RTEMS)
 + these modes are only ones which are emulated on hardware
   level by (allmost) all PC video hardware

If the correction done such way that it does not need changes
and mainly introduction of the slow paths in preferred/current
driver paths then it worth to be changed. But MWin has heavily
moved to use bit blitting and similar.

It would worth to check with upstream (Greg) if introduced
changes would be problem or no.

> > Would it be useful, or is it deprecated, by a cirrus driver ?

The Cirrus driver is good for testing in QEMU. We need other
solution for real PC hardware. 

> What resolutions is this for? Is this VESA or simply 640x480x16
> VGA?

At the moment you go for VESA, it has no worth to depend
on VGA hardware hardware emulation in today GPUs.
So it is good for 640x480x16. We should define
plan to develop VBE based driver for x86 targets and list it
on open projects page. I thing that it has much more value
and would result in use native display resolution for LCDs,
which is only reasonable mode selection today.

> I am not a graphics expert so you will have to educate me
> why they have deprecated it.

This complicate code implementation a mess etc. But on the
other hand too strict dependence on linear frame buffer
can have some disadvantages for providing driver
for some special (SPI, I2C, etc) small displays used in some
embedded environments.

> As a code basis for building it up to the Cirrus driver, it is
> a good thing to use if the license is OK.

I have build Alex RTEMS version and driver it works in QEMU.
The driver is allmost full rewrite of the HW dependant
code when compared to my attempt. It is rewrite according
to MIT licensed x86 driver but used mostly as documentation
than source pool. So it should be Ok. May it be a line with
reference to x86 code should be restated by some native
speaker to be more clean. License in header should extended
and reworded as well. May it be MIT and RTEMS GNU with exception
could be combined there. But there should be some variant/text
used usually in RTEMS sources.

Best wishes,

              Pavel