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
next prev 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