nanogui: More...Porting to a custom video device
Subject:
RE: [nanogui] More...Porting to a custom video device
From:
"Gray, Tim" ####@####.####
Date:
24 May 2001 15:50:56 -0000
Message-Id: <AB6EA0602143D51192DD00508BCF8B8F3311B1@entcoexch03.tci.com>
Ok I think I have an Idea of what he means.
Example: I grab a standard parallel input LCD that is
240X64 pixels 1bpp only. This device sits on either the parallel port or a
General purpose I/O bus.
would it be feasible to write a framebuffer driver for the linux kernel for
such a device, or would it be easier to just write a driver for microwindows
that just dumps the display to a block of ram and then have a daemon running
that snags that block of ram and shovel it to the device....
I have never tried to write a linux device driver, let alone a display
driver. But I have used Parallel LCD's in many embedded projects coupled
with linux. The easy way is to make your application talk to the device
directly.
On a side note, this is very interesting to me, as a project I am currently
working on follows these same lines...
Sorry if I am way off base, or just added to the noise.
-----Original Message-----
From: Simon Wood ####@####.####
Sent: Thursday, May 24, 2001 11:36 AM
To: ####@####.####
Cc: ####@####.####
Subject: RE: [nanogui] More...Porting to a custom video device
> -----Original Message-----
> From: Jordan Crouse ####@####.####
> Sent: Thursday, May 24, 2001 3:59 PM
> To: Simon Wood; ####@####.####
> Subject: Re: [nanogui] More...Porting to a custom video device
>
> There are several reasons why I wouldn't do this:
[Simon Wood]
You only quoted two ;-)
> 1. Without the kernel interface, you have to resort to somewhat ticky
tack
> methods of determine screen size, depth, colormap, etc, etc.. The kernel
> gives you a universal method to determine everything you need to know
about
> the display.
[Simon Wood]
Yes, but at a cost of size and performance. Compare a
framebuffer verses a serial console kernel (heck who needs
a console at all??).
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.
In this case the 'scr_???.c' file would be written for that
specific device.
> 2. Any way you slice it, you will still need some sort of kernel driver
to
> initalize and communicate with the hardware. (Unless of course your
hardware
> can be initalized by the BIOS and access through the standard VGA memory
> window - but then if it could, why not use VESA?)
[Simon Wood]
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() ).
Please also note that I don't know exactly what Gordon has in
mind, I was just trying to point out that he may be putting a
lot more in the chain than he has too. It is obviously up to
him which technique to choose.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: ####@####.####
For additional commands, e-mail: ####@####.####
