All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Sokolovsky <pmiscml@gmail.com>
To: Koen Kooi <openembedded-devel@lists.openembedded.org>
Subject: Re: [RFC] Adding screen dimensions to machine configs
Date: Tue, 10 Jul 2007 00:36:22 +0300	[thread overview]
Message-ID: <1404299021.20070710003622@gmail.com> (raw)
In-Reply-To: <f6u5bq$ht5$1@sea.gmane.org>

Hello Koen,

Monday, July 9, 2007, 11:21:14 PM, you wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

> Dr. Michael Lauer schreef:
>> To summarize:
>> 
>> It looks like we can agree to adding information to the
>> MACHINE_DISPLAY_ namespace.
>> 
>> However, we're undecided regarding the semantics. Some of think the
>> physical hardware information need to be there, some of us want the
>> logical (including kernel-level gfx hardware rotation), some of us
>> want a high-level meaning.

> and how about linux kernel 2.4 and 2.6 (or even 2.6.ancient and 2.6.recent) having
> different opinions on rotation, or maybe worse, having rotation specified via CMDLINE?

> I think OE should specify the hardware (since it's in the MACHINE namespace anyway) and
> have userspace deal with rotation and stuff.

> The main question remains: what are people going to (ab)use this for? If it's just for
> opie backgrounds I don't see why adding 3 or more lines to each and every machine is less
> work than adding one machine override to the background .

  Hopefully not just for OPIE. And it is still paradigmatic question -
where is the proper place for such information. With this change, we
move towards having machine-specific information in ... well, machine
config itself, not spread around the codebase, and that's apparently the
right direction of changes.

>> This is Poky version of that part XServer script - no machine related code
>> at all. Of course it support only machines with formfactor defines.
> 
> So you have the exact same problem, but in a different place. And as a side-effect, the
> image can't be shared between machines anymore, since only one config is present in
> formfactor.

  As if we had too good multi-machine shareability before... And it's
still about doing the right abstraction in the right place. It's only
one step from current formfactor implementation which uses build-time
file override to one which keeps DB of machine configs and dispatches
on them. And both these implementations can be used as needed,
transparently to the rest of system. And in general, it removes adhoc
case dispatches from different places, putting them in one clean
place.

> regards,

> Koen


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




  reply	other threads:[~2007-07-09 21:42 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
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 [this message]
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=1404299021.20070710003622@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.