This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Re: MicroWindows, network stack, framebuffer API
- From: Alexander Neundorf <neundorf at kde dot org>
- To: ecos-discuss at ecos dot sourceware dot org
- Cc: tgabor84 at gmail dot com
- Date: Tue, 4 Nov 2008 23:18:02 +0100
- Subject: Re: [ECOS] Re: MicroWindows, network stack, framebuffer API
- References: <30c102240810250643w4688bfdbrf5c9970442b0c1c2@mail.gmail.com> <pnhc6xkky1.fsf@delenn.bartv.net> <30c102240810280508l946a0ecj85e7c97180ec6a4c@mail.gmail.com>
- Reply-to: neundorf at kde dot org
On Tuesday 28 October 2008, Gábor Török wrote:
> Is it OK if I add an option to use the generic fb driver and write the
> required code to do this?
> What about updating to a newer MicroWindows and removing the
> requirement for the network? Maybe I can do this also.
Two years ago or so I was working on this already, you can find the results
here:
http://www.ecosforge.net/pmwiki/index.php/Projects/EcosMicrowindows
It is a back then up-to-date copy of Microwindows. It supports the Qt virtual
frame buffer, and it shouldn't be hard to port it to the new framebuffer
support in eCos.
It can be configured fine-grained, e.g. you can enable only the drawing
functions, then you get a library for drawing, which doesn't require any
networking.
mwin, the Windows compatible API works, it also doesn't need networking
(tested with Qvfb and on an ARM board).
I didn't manage to rip the network requirements out of the X API yet, so this
still needs to be done.
A socket is used for communication with the X server thread, it should be
possible to replace this with eCos thread synchronization primitives.
Most of my changes are also in the main Microwindows cvs.
Alex
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss