nanogui: Thread: Re: [ot] [nanogui] More...Porting to a custom video device

> 	You only quoted two ;-)

Two *is* several.  You gotta give me a break, I write C 8 hours a day.    I 
could have said "reasons++".... :)

> 	Yes, but at a cost of size and performance. Compare a
> 	framebuffer verses a serial console kernel (heck who needs
> 	a console at all??).

There is virtually no cost in terms of size or performance.   A framebuffer 
driver and a serial driver are the same beast -- they are both console 
drivers that interact with hardware.  The only additional cost that you have 
is the actual framebuffer hardware driver, and thats only recognizable 
because it is uniquely added.   The serial hardware driver has a huge chunk 
of code too, but because it is included virtually every time, people don't 
notice it.
 
> 	If you are embedding Microwindows into an appliance things
> 	like screen dimensions and colour depth are decided at the
> 	design stage, long before the programmers get to touch the
> 	device.

Thats true of any embedded project.  But as long as Linux can run on the 
device, my point still stands.  I am not saying that we shouldn't develop 
custom drivers for unique RTOS situations.  But if you are going to the 
effort of sticking Linux on a chip, it is in everybody's best interest to put 
your work into developing a kernel driver instead if littering Microwindows 
with 3 dozen custom drivers.  The Microwindows project is not in the business 
of running out and supporting every single driver that comes along.   We stay 
generic, and we stay portable.  

 > 	Please don't think I'm having a go at you, but a lot of people
> 	don't seem to appreciate that an appliance is NOT a P.C.
>
> 	So, for example, a 'Fancy Git' phone may use microwindows as
> 	it's user interface but it won't contain any P.C. like
> 	functionality, will probably run from flash and be very simple
> 	in comparison to normal P.C. It probably won't have any 'BIOS'.
>
> 	Wrt to initilsation, this could be handled by the Microwindows
> 	driver (scr_???.c function ???_open() ).

But is it running linux?  Thats the acid test you need to apply here.  As  I 
said above, it is perfectly OK to develop a custom driver for RTOS or non 
Linux operating systems.  I have no problem with that.   

But if it is running Linux, I still fail to see any reason why you wouldn't 
want to use a kernel framebuffer driver.  Take the Ipaq for example.  It runs 
from flash.  It has almost nothing in common with a normal PC.  Yet, it has a 
kernel framebuffer driver.   Even the X11 folks chose to use the framebuffer 
driver, and they are in the business of writing very good custom video 
drivers for their servers.  

How about the Agenda, the assabet, the Helio?  All lack any sort of 
similarity to the thing sitting on your desk, yet they all use a framebuffer 
driver.

>  One of the major advantages of the way Microwindows is designed
>  is the amount of choice in how you adopt it, suiting it to
>  your hardware (and software) platform. It also gives the
>  portability that you can design your application on one platform
>  (say P.C.) and shift to the real target when the hardware comes
>  back from manufacture.

I agree. Thats part of the reason why I am so up in arms about it.  The 
portability is what we strive for, thats our thing that differentiates us 
from all other GUI projects.  But one of the main ways we accomplish that is 
through maintaining a consistant standard.   I can build Microwindows with a 
framebuffer device and put it on *any* device (that is running the same 
processor) and have it work.  Without modification, without recompiling, 
without doing anything overly special.    

Yes, Microwindows provides you with the ability to directly write a video 
driver.  Thats beautiful...  we can run on any platform on the planet, and I 
cherish that.  But if you choose to run linux on your platform, we have a 
very simple, standard and optimized way to draw on the screen with relatively 
little effort.    My question is, why would you want to do anything else?

This thread is moving dangerous off topic, and directly into the bandwith 
wasting category, so thats the last I have to say on the subject.  

Jordan