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 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.