All of lore.kernel.org
 help / color / mirror / Atom feed
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




             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.