Openembedded Devel Discussions
 help / color / mirror / Atom feed
From: Paul Sokolovsky <pmiscml@gmail.com>
To: Graeme Gregory <dp@xora.org.uk>
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: [RFC] Adding screen dimensions to machine configs
Date: Mon, 9 Jul 2007 17:25:37 +0300	[thread overview]
Message-ID: <15110327374.20070709172537@gmail.com> (raw)
In-Reply-To: <20070709140338.GE2336@p3n3tr4t0r.internal>

Hello Graeme,

Monday, July 9, 2007, 5:03:38 PM, you wrote:

> On Mon, Jul 09, 2007 at 03:52:45PM +0200, Dr. Michael Lauer wrote:
>> Heh, it's not just Opie. Eventually we may want to ship prerendered png's for
>> UI elements. We better know about the size and dpi of the displays to
>> get sane defaults. There's a whole lot of packages which could use the
>> MACHINE namespace to improve targetting the platforms specifics at
>> build time.
>> 
> I just worry what happens to machines without screens but that can have
> gfx cards added. By the current level of thought behind these variables
> a divide by zero is inevitable.

  Where is division here at all?

> It also triggers my gut feeling of "this is the wrong way to crack the nut"

  Oh, let me say it *again*. *All* software should be made to adapt to
different screen sizes (including small) and other params dynamically,
at runtime. What will we patch today?

>> What makes you worry so much about adding more (imho necessary)
>> information to the MACHINE_ capability namespace?
>> 
> Nothing, but these variables seem little thought out and seem to be being
> rushed into use for one use case (opie backgrounds).

  Background in general to start with. I don't know exactly how
theming is handled for X, but we don't want to ship backgrounds of
800x600 sizes for QVGA devices there too, even if X would scale them.
Or at least, we may want to optimize. Second, I gave 2 usecases, not
1. And other participants gave more (though I can't say if those
usecases would better be handled in runtime right away).

  Otherwise, I indeed use otherwise pretty static (and needing cleanup
anyway) OPIE as a testbed for ideas on how we can minimize device
dependency and improve support and maintainability. I'm sure results
will be worthy more general application.

> And if it is neccessary then it should be the "correct" information,

  Please add correct, sure. There're guidelines for semantics, but
eventually details are up to device maintainer and users.
  
>  like
> for spitz the screen is 480x640 by default. Deal with it in packages that
> wish to use rotation correctly. Not just this value makes it easy for my
> magic background generator.

  Maybe your generator can use fbset right away?

> Maybe a MACHINE_DEFAULT_ROTATION is also needed.

  And many more others! But again, ultimate usefulness of resolution
is too allow to optimize install size (a random background is say 40k,
there's a difference if we install 40k or 5*40k, right). What would we
gain with specifying a default rotation? Only ability to preconfigure
device to be in user-expectable orientation instead of what its LCD
hardware has (which is good aim, btw ;-) ).

> Graeme




-- 
Best regards,
 Paul                            mailto:pmiscml@gmail.com




  parent reply	other threads:[~2007-07-09 14:31 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 [this message]
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=15110327374.20070709172537@gmail.com \
    --to=pmiscml@gmail.com \
    --cc=dp@xora.org.uk \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox