From: Paul Sokolovsky <pmiscml@gmail.com>
To: openembedded-devel@lists.openembedded.org
Subject: [RFC] Adding screen dimensions to machine configs
Date: Sun, 8 Jul 2007 04:11:51 +0300 [thread overview]
Message-ID: <513012886.20070708041151@gmail.com> (raw)
Hello openembedded-devel,
We already discussed issue of providing more exact device screen
properties info than currently available screen classes "smallscreen"
and "bigscreen". I for one was proponent of staying with those classes
instead of hasting with introducing too many screen parameters without
proper way of handling them in OE. However, it's just the matter of
fact that at least the most basic of them, like screen dimensions are
already in use by more than one package (I can point to opie and
fbreader out of top of mind), and so far in adhoc manner, so
standardizing them would be beneficial.
When discussing this on IRC, Marcin Juszkiewicz pointed me to Poky's
formfactor package, designed to query various device properties at
runtime (including current screen resolution).
http://svn.o-hand.com/view/poky/trunk/meta/packages/formfactor/
I think that it is great tool, and we should merge and leverage it
in OE by all means. But it handles only runtime configuration, and
that does not supersedes need for build-time data. It is useful for
the cases where we need to preinstall some resources based on the
standard device resolution. For example, if we build image for device
with QVGA resolution, we want to install only QVGA backgrounds by
default, as shipping them all (and for example decide which one to use
at runtime) can be a waste of space.
Now with formfactor around, I guess it would be nice to use
consistent variable names for the same info. Marcin still suggested to
use MACHINE_ prefix for build-time (i.e. machine config) variables.
So, the exact topic of this RFC is adding
MACHINE_DISPLAY_WIDTH_PIXELS=
MACHINE_DISPLAY_HEIGHT_PIXELS=
to machine configs.
It's a bit verbose, hence this RFC to discuss exact naming
conventions. Otherwise, I'd like to keep in on pragmatic side -
there's use for these properties right now, so here they are. More
properties for the other aspects of device configuration can wait till
they have similarly clear usecases (and we really should use runtime
configuration as much as possible, just not leave out built-time
optimizations where it is useful).
--
Best regards,
Paul mailto:pmiscml@gmail.com
next reply other threads:[~2007-07-08 1:17 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-08 1:11 Paul Sokolovsky [this message]
2007-07-08 7:16 ` [RFC] Adding screen dimensions to machine configs Koen Kooi
2007-07-08 8:39 ` Dr. Michael Lauer
2007-07-08 9:26 ` Richard Purdie
2007-07-08 12:00 ` Stanislav Brabec
2007-07-08 14:27 ` Richard Purdie
2007-07-09 0:53 ` Rod Whitby
2007-07-09 5:31 ` Stelios Koroneos
2007-07-09 12:43 ` Paul Sokolovsky
2007-07-09 13:17 ` Graeme Gregory
2007-07-09 13:35 ` Dr. Michael Lauer
2007-07-09 13:42 ` Graeme Gregory
2007-07-09 13:52 ` Dr. Michael Lauer
2007-07-09 14:03 ` Graeme Gregory
2007-07-09 14:19 ` Dr. Michael Lauer
2007-07-09 14:25 ` Graeme Gregory
2007-07-09 14:40 ` Paul Sokolovsky
2007-07-09 15:15 ` Marcin Juszkiewicz
2007-07-09 20:30 ` Koen Kooi
2007-07-09 22:03 ` Richard Purdie
2007-07-09 15:44 ` Florian Boor
2007-07-09 14:23 ` Marcin Juszkiewicz
2007-07-09 14:25 ` Paul Sokolovsky
2007-07-09 15:11 ` Marcin Juszkiewicz
2007-07-09 13:57 ` Paul Sokolovsky
2007-07-09 13:41 ` Paul Sokolovsky
2007-07-09 15:55 ` Richard Purdie
2007-07-09 20:01 ` Dr. Michael Lauer
2007-07-09 20:19 ` Graeme Gregory
2007-07-09 20:44 ` Richard Purdie
2007-07-09 20:21 ` Koen Kooi
2007-07-09 21:36 ` Paul Sokolovsky
2007-07-09 21:21 ` Paul Sokolovsky
2007-07-10 10:33 ` Dr. Michael Lauer
2007-07-12 12:36 ` Paul Sokolovsky
2007-07-08 11:36 ` Michael Krelin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=513012886.20070708041151@gmail.com \
--to=pmiscml@gmail.com \
--cc=openembedded-devel@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.