Openembedded Devel Discussions
 help / color / mirror / Atom feed
From: Richard Purdie <rpurdie@rpsys.net>
To: openembedded-devel@openembedded.org
Subject: Re: [RFC] Adding screen dimensions to machine configs
Date: Mon, 09 Jul 2007 16:55:38 +0100	[thread overview]
Message-ID: <1183996538.5757.55.camel@localhost.localdomain> (raw)
In-Reply-To: <128309124.20070709154303@gmail.com>

On Mon, 2007-07-09 at 15:43 +0300, Paul Sokolovsky wrote:
>   Oh, I guess it's the other way around - it's a simple config and
> shell script which can do things for which whole big daemons with
> gross dependencies are required ;-).
> 
>   More seriously, it makes no sense to ignore the fact that X with
> freedesktop.org's novelties is not the only and won't become the only
> choice for embedded GUI. Many adhoc toolkits pop up, and some of them
> will be leveraged by vendors and it makes no sense to say that OE is
> not place for them (though community distros are of course much less
> interested in them). It would be nice to anticipate the need for a
> lightweight, flexible, and consistent way to query device params for
> them.

Agreed.

> > And
> > we were explicitly asked *not* to merge it into OE by someone from o-hand.
> 
>    Pity.

I'm not going to stop anyone, it just at least needed discussion which
is now happening.

> >>   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 we already have sufficient tools inplace to handle that, formfactor just muddies the
> > waters.
> 
>   Hopefully cleans up, though yes, it opens question that GPE scripts
> would be needed converted to it, etc.

I guess GPE would need to decide this and the OE needs to decide whether
to follow its own approach or patch GPE to use some internal OE method.

>   Also a note of exact semantics of those vars - they provide *some
> default* screen resolution and orientation. Actually not some, but the
> most appropriate after-install default. So, in particular,
> notebook-style keyboarded devices would have:
> 
> MACHINE_DISPLAY_WIDTH_PIXELS=640
> MACHINE_DISPLAY_HEIGHT_PIXELS=480
> 
> A device with vertical PDA layout would have
> 
> MACHINE_DISPLAY_WIDTH_PIXELS=480
> MACHINE_DISPLAY_HEIGHT_PIXELS=640

The intent was to provide the hardware resolution the device should
default to along with any rotation parameter.

For spitz, this is 480x640 with 270 degree rotation.

Since the c7x0 can rotate in hardware, that defaults to 640x480 with no
rotation.

My point is that the above is the default hardware resolution which has
to be combined with a rotation parameter to be fully meaningful.

Cheers,

Richard





  parent reply	other threads:[~2007-07-09 16:01 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-08  1:11 [RFC] Adding screen dimensions to machine configs Paul Sokolovsky
2007-07-08  7:16 ` 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 [this message]
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=1183996538.5757.55.camel@localhost.localdomain \
    --to=rpurdie@rpsys.net \
    --cc=openembedded-devel@lists.openembedded.org \
    --cc=openembedded-devel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox