Re: [proposal] Decrease X.org XFree86 server footprint


Jason Clarke <jason@...>
 

Agreed. I just felt like X seemed like a big solution for some process
synchronization and layer management.

Usually all I want is a nice API to access a layers, move a viewport,
etc...and since it's a custom system I'll manage the rest. Directfb gives us
most of what we want.

Jason Clarke
Crank Software Inc.
Office: 613-595-1999
Mobile: 613-853-9088
Online: www.cranksoftware.com

-----Original Message-----
From: Gustavo Sverzut Barbieri [mailto:barbieri@...]
Sent: December-02-09 5:40 AM
To: Jason Clarke
Cc: Mikhail Gusarov; Tim Bird; celinux-dev@...; Ruud
Derwig
Subject: Re: [Celinux-dev] [proposal] Decrease X.org XFree86 server
footprint

On Wed, Dec 2, 2009 at 1:27 AM, Jason Clarke <jason@...>
wrote:
I think the question that might need to be asked is why are they using an
X
server on a full screen embedded consumer device? If your UI fills and
owns
the entire screen you can easily just use directfb or even fbdev. I'd
guess
they are looking more for a way to have multiple applications share the
screen (the main UI, webkit, mplayer,...) then actually a desire to have a
full window manager environment on a small arm device.

Maybe X isn't exactly what they want, but happens to be the closest thing
available?
The major problem with X is how to expose the various layers some
hardware have (some have 5 layers, some are ARGB, some are just
YUV/video, some use color-key, etc). It is possible, but just more
work Companies don't usually want/can pay.

But even for initially fullscreen only applications, X proves to be
useful... and very often requirements change and we're faced with
other screens that need more complexities.

Some times multiple applications are not just 2 different
applications, but two process that compose the same applications but
are separated to avoid full-crashes or even to keep latency away. For
example, one could do widgets/gadgets that query Network (with badly
written parses that often crash) or access user USB drives that often
have corrupted VFAT that can lead to crashes or blocks, in such cases
you really don't want your main app to crash or halt.

However, DirectFB provides multi-app access since a while... so it has
a solution for that.

Last but not least, someone in this thread said the main reason: it
makes embedded software development closer to desktop. You can use the
same libraries, it's easier to test (Xephyr and that's it!), without
much overhead... and the remaining overhead is what Mikhail is willing
to remove!

I know Mikhail and its OpenInkpot project. The hardware is very "low
end", but still he runs X (Kdrive) with success. What he is proposing
is to merge improvements from Kdrive into regular X as well, and this
is worth.

BR,

--
Gustavo Sverzut Barbieri
--------------------------------------
Mobile: +55 (19) 9225-2202
Contact: http://www.gustavobarbieri.com.br/contact

Join Celinux-dev@lists.celinuxforum.org to automatically receive all group messages.