[RFC] Adding screen dimensions to machine configs

[RFC] Adding screen dimensions to machine configs

[Paul Sokolovsky]

Hello openembedded-devel,

  We already discussed issue of providing more exact device screen
properties info than currently available screen classes "smallscreen"
and "bigscreen". I for one was proponent of staying with those classes
instead of hasting with introducing too many screen parameters without
proper way of handling them in OE. However, it's just the matter of
fact that at least the most basic of them, like screen dimensions are
already in use by more than one package (I can point to opie and
fbreader out of top of mind), and so far in adhoc manner, so
standardizing them would be beneficial.

  When discussing this on IRC, Marcin Juszkiewicz pointed me to Poky's
formfactor package, designed to query various device properties at
runtime (including current screen resolution).
http://svn.o-hand.com/view/poky/trunk/meta/packages/formfactor/

  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
that does not supersedes need for build-time data. It is useful for
the cases where we need to preinstall some resources based on the
standard device resolution. For example, if we build image for device
with QVGA resolution, we want to install only QVGA backgrounds by
default, as shipping them all (and for example decide which one to use
at runtime) can be a waste of space.

   Now with formfactor around, I guess it would be nice to use
consistent variable names for the same info. Marcin still suggested to
use MACHINE_ prefix for build-time (i.e. machine config) variables.
So, the exact topic of this RFC is adding

MACHINE_DISPLAY_WIDTH_PIXELS=
MACHINE_DISPLAY_HEIGHT_PIXELS=

to machine configs.

   It's a bit verbose, hence this RFC to discuss exact naming
conventions. Otherwise, I'd like to keep in on pragmatic side -
there's use for these properties right now, so here they are. More
properties for the other aspects of device configuration can wait till
they have similarly clear usecases (and we really should use runtime
configuration as much as possible, just not leave out built-time
optimizations where it is useful).


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

Re: [RFC] Adding screen dimensions to machine configs

[Koen Kooi]

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

Paul Sokolovsky schreef:
> Hello openembedded-devel,
> 
>   We already discussed issue of providing more exact device screen
> properties info than currently available screen classes "smallscreen"
> and "bigscreen". I for one was proponent of staying with those classes
> instead of hasting with introducing too many screen parameters without
> proper way of handling them in OE. However, it's just the matter of
> fact that at least the most basic of them, like screen dimensions are
> already in use by more than one package (I can point to opie and
> fbreader out of top of mind), and so far in adhoc manner, so
> standardizing them would be beneficial.
> 
>   When discussing this on IRC, Marcin Juszkiewicz pointed me to Poky's
> formfactor package, designed to query various device properties at
> runtime (including current screen resolution).
> http://svn.o-hand.com/view/poky/trunk/meta/packages/formfactor/

Formfactor is a hack that does nothing what our Xserver scripts and HAL+OHM can't do. And
we were explicitly asked *not* to merge it into OE by someone from o-hand.

>   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. And if you take a closer look at formfactor, you'll notice it's internally
inconsistent (e.g. dpi = resolution/size, but you need to specify all 3 in formfactor)


>    Now with formfactor around, I guess it would be nice to use
> consistent variable names for the same info. Marcin still suggested to
> use MACHINE_ prefix for build-time (i.e. machine config) variables.
> So, the exact topic of this RFC is adding
> 
> MACHINE_DISPLAY_WIDTH_PIXELS=
> MACHINE_DISPLAY_HEIGHT_PIXELS=
> 
> to machine configs.

We can add those without adding formfactor. But what will those setting be for e.g. an
nslu2 or efika board?

regards,

Koen





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGkI9eMkyGM64RGpERAlDQAJ0WTX9BbRKn7/3/X054Vl2iYUeVZgCbBLkn
ado8odEDSAko1n1+LyCj9+E=
=00Rv
-----END PGP SIGNATURE-----

Re: [RFC] Adding screen dimensions to machine configs

[Dr. Michael Lauer]

>>    Now with formfactor around, I guess it would be nice to use
>> consistent variable names for the same info. Marcin still suggested to
>> use MACHINE_ prefix for build-time (i.e. machine config) variables.
>> So, the exact topic of this RFC is adding
>> 
>> MACHINE_DISPLAY_WIDTH_PIXELS=
>> MACHINE_DISPLAY_HEIGHT_PIXELS=
>> 
>> to machine configs.

+1 from me for that.

> We can add those without adding formfactor. But what will those setting be for e.g. an
> nslu2 or efika board?

0 -- what else? :D

Regards,

:M:
-- 
Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de

Re: [RFC] Adding screen dimensions to machine configs

[Richard Purdie]

On Sun, 2007-07-08 at 08:16 +0100, Koen Kooi wrote:
> Paul Sokolovsky schreef:
> >   We already discussed issue of providing more exact device screen
> > properties info than currently available screen classes "smallscreen"
> > and "bigscreen". I for one was proponent of staying with those classes
> > instead of hasting with introducing too many screen parameters without
> > proper way of handling them in OE. However, it's just the matter of
> > fact that at least the most basic of them, like screen dimensions are
> > already in use by more than one package (I can point to opie and
> > fbreader out of top of mind), and so far in adhoc manner, so
> > standardizing them would be beneficial.
> > 
> >   When discussing this on IRC, Marcin Juszkiewicz pointed me to Poky's
> > formfactor package, designed to query various device properties at
> > runtime (including current screen resolution).
> > http://svn.o-hand.com/view/poky/trunk/meta/packages/formfactor/
> 
> Formfactor is a hack that does nothing what our Xserver scripts and HAL+OHM can't do. And
> we were explicitly asked *not* to merge it into OE by someone from o-hand.

The ideas in formfactor are directly lifted from zaurusd. I still wish
zaurusd could become a more generic kind of glue program like the fabled
devmand should have been but I can't be the person to do that.

> >   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. And if you take a closer look at formfactor, you'll notice it's internally
> inconsistent (e.g. dpi = resolution/size, but you need to specify all 3 in formfactor)

That was mainly because you get some weird DPI values out and often want
control of the rounding.

Formfactor does solve some problems that currently exist. Its a pain
having to patch xtscal for every machine with a rotated screen for
example (duplicating the code in the Xserver script). In the end I've
extended the Xcalibrate extension in Poky to solve that problem properly
though (xtscal no longer needs a rotate option). formfactor also gives
information about the relationship of the keyboard with the screen which
you can't get from anywhere else.

> >    Now with formfactor around, I guess it would be nice to use
> > consistent variable names for the same info. Marcin still suggested to
> > use MACHINE_ prefix for build-time (i.e. machine config) variables.
> > So, the exact topic of this RFC is adding
> > 
> > MACHINE_DISPLAY_WIDTH_PIXELS=
> > MACHINE_DISPLAY_HEIGHT_PIXELS=
> > 
> > to machine configs.
> 
> We can add those without adding formfactor.

I'd be in favour of moving the variables defined in formfactor to the
machine.conf file. Poky could then autogenerate the machine specific
formfactor config file and its also becomes available at build time.

Cheers,

Richard

Re: [RFC] Adding screen dimensions to machine configs

[Michael Krelin]

>    Now with formfactor around, I guess it would be nice to use
> consistent variable names for the same info. Marcin still suggested to
> use MACHINE_ prefix for build-time (i.e. machine config) variables.
> So, the exact topic of this RFC is adding
> 
> MACHINE_DISPLAY_WIDTH_PIXELS=
> MACHINE_DISPLAY_HEIGHT_PIXELS=
> 
> to machine configs.
> 
>    It's a bit verbose, hence this RFC to discuss exact naming
> conventions. Otherwise, I'd like to keep in on pragmatic side -

I type fast, so I'm all for these names. Also, what comes into my head 
is xtscal (or what was the name?) and psplash scripts which may also 
benefit from some information regarding orientation.

Love,
H

Re: [RFC] Adding screen dimensions to machine configs

[Stanislav Brabec]

Richard Purdie wrote:

> The ideas in formfactor are directly lifted from zaurusd. I still wish
> zaurusd could become a more generic kind of glue program like the fabled
> devmand should have been but I can't be the person to do that.

On my opinion shell script handled events are very ineffective solution.
It's easy to program it, but it is ugly and slow. For example, look what
happens at headphones removal event: Loading shell interpreter, parsing
script, calling alsactl, writing state to /etc, modifying this text
config by sed, writing it back, calling alsactl again. Think about
millions of obsolete machine instructions and also obsolete /etc write
(one flash cycle or one obsolete start of HDD).

Desktop systems (and devmand proposal) use HAL -> D-BUS -> D-BUS enabled
app. I guess it's the right way, which prevents calling a bunch of
scripts for each single event, and instead of it introduces "listen what
you need, get event, do what you should". Single purpose monitoring
daemons can turn into D-BUS event providers, applications or action
daemons can listen and react on whatever they need.

In upper mentioned example one daemon can listen to keyboard+jack events
and send it to D-BUS, another daemon linked with alsa will list these
events and modify mixer directly.


________________________________________________________________________
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

Re: [RFC] Adding screen dimensions to machine configs

[Richard Purdie]

On Sun, 2007-07-08 at 14:00 +0200, Stanislav Brabec wrote:
> Richard Purdie wrote:
> > The ideas in formfactor are directly lifted from zaurusd. I still wish
> > zaurusd could become a more generic kind of glue program like the fabled
> > devmand should have been but I can't be the person to do that.
> 
> On my opinion shell script handled events are very ineffective solution.
> It's easy to program it, but it is ugly and slow. For example, look what
> happens at headphones removal event: Loading shell interpreter, parsing
> script, calling alsactl, writing state to /etc, modifying this text
> config by sed, writing it back, calling alsactl again. Think about
> millions of obsolete machine instructions and also obsolete /etc write
> (one flash cycle or one obsolete start of HDD).

This is a tangent to the original point but yes, shell isn't the most
efficient way to do this. FWIW, none of the events handled in zaurusd
needs massive amounts of efficiency and it did need something easy to
program/hack as when it was written, it was meant as a prototype and
hence was subject to change.

> Desktop systems (and devmand proposal) use HAL -> D-BUS -> D-BUS enabled
> app. I guess it's the right way, which prevents calling a bunch of
> scripts for each single event, and instead of it introduces "listen what
> you need, get event, do what you should". Single purpose monitoring
> daemons can turn into D-BUS event providers, applications or action
> daemons can listen and react on whatever they need.
> 
> In upper mentioned example one daemon can listen to keyboard+jack events
> and send it to D-BUS, another daemon linked with alsa will list these
> events and modify mixer directly.

It you look through the archives I've always hinted it would evolve to
use dbus. With the current playing field, it would make sense to work
with OHM for that. Where I disagree with OHM is about the need for a
source for device specific data like dpi. keyboard location etc :-(.

Regards,

Richard

Re: [RFC] Adding screen dimensions to machine configs

[Rod Whitby]

>>> MACHINE_DISPLAY_WIDTH_PIXELS=
>>> MACHINE_DISPLAY_HEIGHT_PIXELS=
>>>
>>> to machine configs.
> 
> We can add those without adding formfactor. But what will those setting be for e.g. an
> nslu2 or efika board?

Since those MACHINES will not have the 'screen' machine_feature enabled,
it doesn't really matter, does it?

-- Rod

Re: [RFC] Adding screen dimensions to machine configs

[Stelios Koroneos]

> > We can add those without adding formfactor. But what will those
> setting be for e.g. an
> > nslu2 or efika board?
>
> Since those MACHINES will not have the 'screen' machine_feature enabled,
> it doesn't really matter, does it?
>

As i see it there are 3 types of "machines"
1) Those without a screen (i.e nslu)
2) Those that can be with or without a screen (efika, a pc) depending on
configuration
3) Those with screen (all the rest) :)

The "problem" might be with those on category 2 as you can't know in advance
if they have screen or what the size of that will be.
But one could always specify these parameters later (local.conf or distro
settings)

Other than that i am also in favour of the proposued naming

Stelios S. Koroneos

Digital OPSiS - Embedded Intelligence
http://www.digital-opsis.com


> -----Original Message-----
> From: openembedded-devel-bounces@openembedded.org
> [mailto:openembedded-devel-bounces@openembedded.org]On Behalf Of
> Rod Whitby
> Sent: Monday, July 09, 2007 3:54 AM
> To: openembedded-devel@openembedded.org
> Subject: Re: [oe] [RFC] Adding screen dimensions to machine configs
>
>
> >>> MACHINE_DISPLAY_WIDTH_PIXELS=
> >>> MACHINE_DISPLAY_HEIGHT_PIXELS=
> >>>
> >>> to machine configs.
> >
> -- Rod
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: [RFC] Adding screen dimensions to machine configs

[Paul Sokolovsky]

Hello openembedded-devel,


      To sum app current discussion:

Sunday, July 8, 2007, 10:16:46 AM, you wrote:


> Paul Sokolovsky schreef:
>> Hello openembedded-devel,
>> 
>>   We already discussed issue of providing more exact device screen
>> properties info than currently available screen classes "smallscreen"
>> and "bigscreen". I for one was proponent of staying with those classes
>> instead of hasting with introducing too many screen parameters without
>> proper way of handling them in OE. However, it's just the matter of
>> fact that at least the most basic of them, like screen dimensions are
>> already in use by more than one package (I can point to opie and
>> fbreader out of top of mind), and so far in adhoc manner, so
>> standardizing them would be beneficial.
>> 
>>   When discussing this on IRC, Marcin Juszkiewicz pointed me to Poky's
>> formfactor package, designed to query various device properties at
>> runtime (including current screen resolution).
>> http://svn.o-hand.com/view/poky/trunk/meta/packages/formfactor/

> Formfactor is a hack that does nothing what our Xserver scripts and HAL+OHM can't do.

  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.

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

   Pity.

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

> And if you take a closer look at formfactor, you'll notice it's internally
> inconsistent (e.g. dpi = resolution/size, but you need to specify all 3 in formfactor)

  If division is banned from kernel, why not ban it from shell
scripts? ;-)

>>    Now with formfactor around, I guess it would be nice to use
>> consistent variable names for the same info. Marcin still suggested to
>> use MACHINE_ prefix for build-time (i.e. machine config) variables.
>> So, the exact topic of this RFC is adding
>> 
>> MACHINE_DISPLAY_WIDTH_PIXELS=
>> MACHINE_DISPLAY_HEIGHT_PIXELS=
>> 
>> to machine configs.

> We can add those without adding formfactor.

  Sure, and only that is in immediate topic, of course.

> But what will those setting be for e.g. an nslu2 or efika board?

  As was pointed out, interpretation of those vars should depend on
presence of "screen" in machine features. And yes, then we need to set
their bitbake.conf default to 0, so only screen'ed machines specify
them.

  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

  Otherwise, I assume the names are OK.

> regards,

> Koen



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

Re: [RFC] Adding screen dimensions to machine configs

[Graeme Gregory]

On Mon, Jul 09, 2007 at 03:43:03PM +0300, Paul Sokolovsky wrote:
>   As was pointed out, interpretation of those vars should depend on
> presence of "screen" in machine features. And yes, then we need to set
> their bitbake.conf default to 0, so only screen'ed machines specify
> them.
> 
>   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 problem with this interpretation is that although spitz boots and looks
like it is 640x480 it is in fact 480x640 with rotation. So it may just
be a mistake in your example that spitz happens to show up. Or it may be
something that has not been considered.

Graeme

Re: [RFC] Adding screen dimensions to machine configs

[Dr. Michael Lauer]

Graeme Gregory wrote:
> On Mon, Jul 09, 2007 at 03:43:03PM +0300, Paul Sokolovsky wrote:
>>   As was pointed out, interpretation of those vars should depend on
>> presence of "screen" in machine features. And yes, then we need to set
>> their bitbake.conf default to 0, so only screen'ed machines specify
>> them.
>> 
>>   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 problem with this interpretation is that although spitz boots and looks
> like it is 640x480 it is in fact 480x640 with rotation. So it may just
> be a mistake in your example that spitz happens to show up. Or it may be
> something that has not been considered.

I agree with Paul's "they provide *some default* screen resolution and
orientation.". Almost all our screen devices can be rotated on-the-fly
anyway. The MACHINE_DISPLAY_ namespace is mainly UI frameworks and
applications, as much as native framebuffer rotations and stuff are
important to know, they're less relevant here.

Regards,

:M:
-- 
Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de

Re: [RFC] Adding screen dimensions to machine configs

[Paul Sokolovsky]

Hello Graeme,

Monday, July 9, 2007, 4:17:44 PM, you wrote:

> On Mon, Jul 09, 2007 at 03:43:03PM +0300, Paul Sokolovsky wrote:
>>   As was pointed out, interpretation of those vars should depend on
>> presence of "screen" in machine features. And yes, then we need to set
>> their bitbake.conf default to 0, so only screen'ed machines specify
>> them.
>> 
>>   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 problem with this interpretation is that although spitz boots and looks
> like it is 640x480 it is in fact 480x640 with rotation. So it may just
> be a mistake in your example that spitz happens to show up. Or it may be
> something that has not been considered.

That's just low-level details, which would be handled on another
level. I have specific usecase for this on which I model this initial
usage: background images for OPIE. So, what would you prefer for
spitz: having a landscape or portrait background by default? That's
what should go into those vars. Of course, for other uses we may need
another interpretation, for example, add function which will
"normalize" resolution (w >= h for example), or just return largest of
them, etc.

And rotation may need special support, and then DPI too. Just let's
start with specific itches first and elaborate on that. Actual pixel
dimension is the objective parameter, so we're not on the wrong track.

> Graeme


> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel


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

Re: [RFC] Adding screen dimensions to machine configs

[Graeme Gregory]

On Mon, Jul 09, 2007 at 03:35:13PM +0200, Dr. Michael Lauer wrote:
> I agree with Paul's "they provide *some default* screen resolution and
> orientation.". Almost all our screen devices can be rotated on-the-fly
> anyway. The MACHINE_DISPLAY_ namespace is mainly UI frameworks and
> applications, as much as native framebuffer rotations and stuff are
> important to know, they're less relevant here.
> 
But this argument makes the variables useless as if you support on the fly
rotate then the UI framework must support dynamic resize.

So are we adding these global variables solely in order to tell opie what
size backgrounds to ship?

Graeme

Re: [RFC] Adding screen dimensions to machine configs

[Dr. Michael Lauer]

Graeme Gregory wrote:
> On Mon, Jul 09, 2007 at 03:35:13PM +0200, Dr. Michael Lauer wrote:
>> I agree with Paul's "they provide *some default* screen resolution and
>> orientation.". Almost all our screen devices can be rotated on-the-fly
>> anyway. The MACHINE_DISPLAY_ namespace is mainly UI frameworks and
>> applications, as much as native framebuffer rotations and stuff are
>> important to know, they're less relevant here.
>> 
> But this argument makes the variables useless as if you support on the fly
> rotate then the UI framework must support dynamic resize.

> So are we adding these global variables solely in order to tell opie what
> size backgrounds to ship?

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.

What makes you worry so much about adding more (imho necessary)
information to the MACHINE_ capability namespace?

Regards,

:M:
-- 
Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de

Re: [RFC] Adding screen dimensions to machine configs

[Paul Sokolovsky]

Hello Dr.,

Monday, July 9, 2007, 4:35:13 PM, you wrote:

[]

> I agree with Paul's "they provide *some default* screen resolution and
> orientation.". Almost all our screen devices can be rotated on-the-fly
> anyway. The MACHINE_DISPLAY_ namespace is mainly UI frameworks and
> applications, as much as native framebuffer rotations and stuff are
> important to know, they're less relevant here.

  Yes, that's why I responded to Koen's discussion of formfactor
package. We won't get around runtime support for multiple resolutions,
rotations, etc. What it will be, is another question for further
consideration.


  As for the machine settings in question, they serve very specific
purpose, and not hardcode that device is bound to be in that
resolution and rotation all the time. To sum up, their purpose is:

1. Provide consistent way to configure packages which require screen
resolution parameter (usecase: fbreader)
2. To not install large-size graphic resources which won't be
needed/used on a specific device "by default", and at the same time,
to install the resource which will fit a device best (again just in
its default config). (usecase: opie-taskbar's background images).

> Regards,

> :M:



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

Re: [RFC] Adding screen dimensions to machine configs

[Graeme Gregory]

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.

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

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

And if it is neccessary then it should be the "correct" information, 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 a MACHINE_DEFAULT_ROTATION is also needed.

Graeme

Re: [RFC] Adding screen dimensions to machine configs

[Dr. Michael Lauer]

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

Which is almost all equipment with USB host.

>  By the current level of thought behind these variables
> a divide by zero is inevitable.

Ok, how about VGA being the default?

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

The idea of additional settings like this to the build time machine
database has been around for long, its just that the Opie
backgrounds are IMO a good enough trigger to (finally) add these
attributes.

> And if it is neccessary then it should be the "correct" information, like
> for spitz the screen is 480x640 by default. Deal with it in packages that
> wish to use rotation correctly.

So, what's the correct information? The physical rotation? The
hardware rotation? How about different kernels configuring the gfx
hardware in different ways?

Tell you what... applications don't care! They care about sane
defaults for common use cases.

> Not just this value makes it easy for my
> magic background generator.

Stop hammering on this particular use case, I already pointed out
there's a lot more potential.

> Maybe a MACHINE_DEFAULT_ROTATION is also needed.

I don't think so. What applications care about is if portrait or
landscape is the common default and this is already encoded in HEIGHT
and WIDTH.

Regards,

:M:
-- 
Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de

Re: [RFC] Adding screen dimensions to machine configs

[Marcin Juszkiewicz]

Dnia poniedziałek, 9 lipca 2007, Graeme Gregory napisał:

> And if it is neccessary then it should be the "correct" information,
> 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 a MACHINE_DEFAULT_ROTATION is also needed.

poky/formfactor/files/akita,spitz/machconfig:
DISPLAY_ORIENTATION=270

so MACHINE_DISPLAY_ROTATION = "270" for them.

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

               Life's not fair. But the root password helps.

Re: [RFC] Adding screen dimensions to machine configs

[Paul Sokolovsky]

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

Re: [RFC] Adding screen dimensions to machine configs

[Graeme Gregory]

On Mon, Jul 09, 2007 at 04:19:25PM +0200, Dr. Michael Lauer wrote:
> > Maybe a MACHINE_DEFAULT_ROTATION is also needed.
> 
> I don't think so. What applications care about is if portrait or
> landscape is the common default and this is already encoded in HEIGHT
> and WIDTH.
> 
Applications do care, a short snippet of /etc/X11/Xserver

        "SHARP Shepherd" | "SHARP Husky" | "SHARP Corgi")
                ARGS="$ARGS -dpi 200 -rgba rgb" ;;
        "SHARP Spitz" | "SHARP Akita" | "SHARP Borzoi")
                ARGS="$ARGS -dpi 200 -rgba rgb -screen 480x640@270" ;;

Why restrict yourself to the simple usecase of opie backgrounds when
the information could be used in far better ways.

If this information was taken from MACHINE_ variables then a large chunk
of this case statement could be removed. But the way you want to do it
the information is in machine.conf, xserver-common somwhere, and a variety
of other places. And all because you refuse to use real information but
some pre-parsed info that is narrowly defined for one application.

Graeme

Re: [RFC] Adding screen dimensions to machine configs

[Paul Sokolovsky]

Hello Graeme,

Monday, July 9, 2007, 5:25:44 PM, you wrote:

> On Mon, Jul 09, 2007 at 04:19:25PM +0200, Dr. Michael Lauer wrote:
>> > Maybe a MACHINE_DEFAULT_ROTATION is also needed.
>> 
>> I don't think so. What applications care about is if portrait or
>> landscape is the common default and this is already encoded in HEIGHT
>> and WIDTH.
>> 
> Applications do care, a short snippet of /etc/X11/Xserver

>         "SHARP Shepherd" | "SHARP Husky" | "SHARP Corgi")
>                 ARGS="$ARGS -dpi 200 -rgba rgb" ;;
>         "SHARP Spitz" | "SHARP Akita" | "SHARP Borzoi")
>                 ARGS="$ARGS -dpi 200 -rgba rgb -screen 480x640@270" ;;

> Why restrict yourself to the simple usecase of opie backgrounds when
> the information could be used in far better ways.

  So you see, why I was so enthusiastic about that formfactor thingy,
right? ;-)


> If this information was taken from MACHINE_ variables then a large chunk
> of this case statement could be removed. But the way you want to do it
> the information is in machine.conf, xserver-common somwhere, and a variety
> of other places. And all because you refuse to use real information but
> some pre-parsed info that is narrowly defined for one application.

  That's common problem of community discussions - they become
ontological arguments. And we discussed matter of screen size in
particular and other machine feature in general many times already.
Time to start with something, that's idea here ;-). I strongly believe
that we won't stop there, but go on.

  As for xserver-common, it's pretty simple, not we (OE) maintain it,
but GPE project, and they should be consulted if there're ready to
give away hardware param detection to standalone hardware
detection script. So again, not all can happen immediately, but I
really glad people care about this (because it was pain in the neck
for me all the time).


> Graeme


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

Re: [RFC] Adding screen dimensions to machine configs

[Marcin Juszkiewicz]

Dnia poniedziałek, 9 lipca 2007, Paul Sokolovsky napisał:
> > 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?

fbset was broken in busybox 1.6.0 so it not always can be used ;(

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

   Fear leads to anger, anger leads to hate, hate... leads to suffering.
   		-- Yoda

Re: [RFC] Adding screen dimensions to machine configs

[Marcin Juszkiewicz]

Dnia poniedziałek, 9 lipca 2007, Graeme Gregory napisał:
> On Mon, Jul 09, 2007 at 04:19:25PM +0200, Dr. Michael Lauer wrote:
> > > Maybe a MACHINE_DEFAULT_ROTATION is also needed.
> >
> > I don't think so. What applications care about is if portrait or
> > landscape is the common default and this is already encoded in HEIGHT
> > and WIDTH.
>
> Applications do care, a short snippet of /etc/X11/Xserver
>
>         "SHARP Shepherd" | "SHARP Husky" | "SHARP Corgi")
>                 ARGS="$ARGS -dpi 200 -rgba rgb" ;;
>         "SHARP Spitz" | "SHARP Akita" | "SHARP Borzoi")
>                 ARGS="$ARGS -dpi 200 -rgba rgb -screen 480x640@270" ;;

===========================================================================
ARGS="$ARGS -screen ${DISPLAY_WIDTH_PIXELS}x${DISPLAY_HEIGHT_PIXELS}@${DISPLAY_ORIENTATION}x${DISPLAY_BPP}"

if [ ! -z "$DISPLAY_DPI" ]; then
        ARGS="$ARGS -dpi $DISPLAY_DPI"
fi
===========================================================================

This is Poky version of that part XServer script - no machine related code 
at all. Of course it support only machines with formfactor defines.

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

       Nazwałem swojego psa Internet, bo robi wuf... wuf... wuf...

Re: [RFC] Adding screen dimensions to machine configs

[Florian Boor]

Hi,

Dr. Michael Lauer schrieb:
>> I just worry what happens to machines without screens but that can have
>> gfx cards added.
> 
> Which is almost all equipment with USB host.

I think it is fine to assume that these devices that do not have a built-in
screen but support one by adding a graphics device can have a more or less
arbitrary resolution. That means that you assume a common resolution like
1024x768 and if you really have a special need you would override these values
anyway. For most devices which usually have no screen or a built-in one you
would be quite safe with one setting. For the others just choose a big default
which should bee correct in most cases and for things like background images it
is usually better to ship a big one and scale it down instead of shipping a too
small one.

>>  By the current level of thought behind these variables
>> a divide by zero is inevitable.
> 
> Ok, how about VGA being the default?

That's fine as long you do not have this set if you do not have the screen
feature enabled, otherwise you might pull in big backgrounds and similar stuff
for no reason.

> I don't think so. What applications care about is if portrait or
> landscape is the common default and this is already encoded in HEIGHT
> and WIDTH.

Exactly... and on rotatable displays you need some support from the applications
anyway.

Greetings

Florian

-- 
The dream of yesterday                  Florian Boor
is the hope of today                    Tel: +49 271-771091-15
and the reality of tomorrow.            Fax: +49 271-771091-19
[Robert Hutchings Goddard, 1904]        florian.boor@kernelconcepts.de

1D78 2D4D 6C53 1CA4 5588  D07B A8E7 940C 25B7 9A76

Re: [RFC] Adding screen dimensions to machine configs

[Richard Purdie]

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

Re: [RFC] Adding screen dimensions to machine configs

[Dr. Michael Lauer]

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.

How do we proceed now? Collect more arguments in favour or against or
shall we vote? Who is having a voice?

Regards,

:M:
-- 
Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de

Re: [RFC] Adding screen dimensions to machine configs

[Graeme Gregory]

On Monday 09 July 2007 21:01:36 Dr. Michael Lauer wrote:
> 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.
>
> How do we proceed now? Collect more arguments in favour or against or
> shall we vote? Who is having a voice?
>
I would vote for using the version that gives the most information and 
therefore the other information can be derived.

WIDTH=480
HEIGHT=640
ROTATION=270

You can infer that inside your opie/x11/other system you have a 640x480 
landscape.

But from

WIDTH=640
HEIGHT=480

You cannot infer the rotation.

So I think having the physical parameters including rotation is essential.

Graeme

Re: [RFC] Adding screen dimensions to machine configs

[Koen Kooi]

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

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD4DBQFGkpi6MkyGM64RGpERAq/AAJi6NzXwnUoFlVytANkXA8voyPaTAJ4mWblB
DuMuNnxqg1h/cn7GBORPkw==
=Pq/i
-----END PGP SIGNATURE-----

Re: [RFC] Adding screen dimensions to machine configs

[Koen Kooi]

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

Marcin Juszkiewicz schreef:
> Dnia poniedziałek, 9 lipca 2007, Graeme Gregory napisał:
>> On Mon, Jul 09, 2007 at 04:19:25PM +0200, Dr. Michael Lauer wrote:
>>>> Maybe a MACHINE_DEFAULT_ROTATION is also needed.
>>> I don't think so. What applications care about is if portrait or
>>> landscape is the common default and this is already encoded in HEIGHT
>>> and WIDTH.
>> Applications do care, a short snippet of /etc/X11/Xserver
>>
>>         "SHARP Shepherd" | "SHARP Husky" | "SHARP Corgi")
>>                 ARGS="$ARGS -dpi 200 -rgba rgb" ;;
>>         "SHARP Spitz" | "SHARP Akita" | "SHARP Borzoi")
>>                 ARGS="$ARGS -dpi 200 -rgba rgb -screen 480x640@270" ;;
> 
> ===========================================================================
> ARGS="$ARGS -screen ${DISPLAY_WIDTH_PIXELS}x${DISPLAY_HEIGHT_PIXELS}@${DISPLAY_ORIENTATION}x${DISPLAY_BPP}"
> 
> if [ ! -z "$DISPLAY_DPI" ]; then
>         ARGS="$ARGS -dpi $DISPLAY_DPI"
> fi
> ===========================================================================
> 
> 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.

regards,

Koen


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGkprSMkyGM64RGpERAhosAJ9SzPUj8HvHNf1jt5sojJJoBFf82gCeMwaV
lMA44jJhi2NkkXTqeH5bPlA=
=yw5b
-----END PGP SIGNATURE-----

Re: [RFC] Adding screen dimensions to machine configs

[Richard Purdie]

On Mon, 2007-07-09 at 21:19 +0100, Graeme Gregory wrote:
> On Monday 09 July 2007 21:01:36 Dr. Michael Lauer wrote:
> > 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.
> >
> > How do we proceed now? Collect more arguments in favour or against or
> > shall we vote? Who is having a voice?
> >
> I would vote for using the version that gives the most information and 
> therefore the other information can be derived.
> 
> WIDTH=480
> HEIGHT=640
> ROTATION=270
> 
> You can infer that inside your opie/x11/other system you have a 640x480 
> landscape.
> 
> But from
> 
> WIDTH=640
> HEIGHT=480
> 
> You cannot infer the rotation.
> 
> So I think having the physical parameters including rotation is essential.

Well said :). If you give the physical information you can derive the
rest. If you give "logical" information you can't get back to the
physical which is why formfactor gives physical parameters.

Cheers,

Richard

Re: [RFC] Adding screen dimensions to machine configs

[Paul Sokolovsky]

Hello Dr.,

Monday, July 9, 2007, 11:01:36 PM, you wrote:

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

> How do we proceed now? Collect more arguments in favour or against or
> shall we vote? Who is having a voice?

  I proposed to model variables in those namespace on the formfactor
package, and with Richard's and Marcin's explaining that there intention
was to have "physical" parameters, and with Graeme's vote, that's
apparently the way to go.

  From my side, proposal to use logical meaning was an RFC, and
choosing other semantics won't change situation much.

> Regards,

> :M:



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

Re: [RFC] Adding screen dimensions to machine configs

[Paul Sokolovsky]

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

Re: [RFC] Adding screen dimensions to machine configs

[Richard Purdie]

On Mon, 2007-07-09 at 21:30 +0100, Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Marcin Juszkiewicz schreef:
> > ===========================================================================
> > ARGS="$ARGS -screen ${DISPLAY_WIDTH_PIXELS}x${DISPLAY_HEIGHT_PIXELS}@${DISPLAY_ORIENTATION}x${DISPLAY_BPP}"
> > 
> > if [ ! -z "$DISPLAY_DPI" ]; then
> >         ARGS="$ARGS -dpi $DISPLAY_DPI"
> > fi
> > ===========================================================================
> > 
> > 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.

With formfactor as is, no. Pull the code from zaurusd for machine
detection and you can (it sets up a symlink to the correct machine
config upon first boot).

Cheers,

Richard

Re: [RFC] Adding screen dimensions to machine configs

[Dr. Michael Lauer]

Hi Paul.

> Monday, July 9, 2007, 11:01:36 PM, you wrote:
>   I proposed to model variables in those namespace on the formfactor
> package, and with Richard's and Marcin's explaining that there intention
> was to have "physical" parameters, and with Graeme's vote, that's
> apparently the way to go.

So be it then, but while we're going the physical route, lets include
the DEPTH as well.

Regards,

:M:
-- 
Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de

Re: [RFC] Adding screen dimensions to machine configs

[Paul Sokolovsky]

Hello Michael,

Tuesday, July 10, 2007, 1:33:12 PM, you wrote:

> Hi Paul.

>> Monday, July 9, 2007, 11:01:36 PM, you wrote:
>>   I proposed to model variables in those namespace on the formfactor
>> package, and with Richard's and Marcin's explaining that there intention
>> was to have "physical" parameters, and with Graeme's vote, that's
>> apparently the way to go.

> So be it then, but while we're going the physical route, lets include
> the DEPTH as well.

  Ok, as we have issues with commit mails, here's what I'm committing for
bitbake.conf. As discussed, we want "non-zero" defaults just in case,
and I used QVGA defaults, which is consistent with our "smallscreen"
default for GUI_MACHINE_CLASS. This variable in turn is named
inconsistently with the rest of machine vars, so I proposed to rename
it to GUI_MACHINE_CLASS. Finally, I tried to be consistent with
formfactor's var names, so here's BPP, not DEPTH. Feel free to tweak
if needed. I'll proceed with adding these options to machine configs
within couple of days. (And of course I would need help with that.)

#
# old_revision [8654baa6db1769cd516400afebdc63c9b19ee633]
#
# patch "conf/bitbake.conf"
#  from [28be7aa3c03959211fa8fff38d1903e1ec2dd8de]
#    to [1a40a8a4b4660be43379de36b41dceabe1bebd19]
#
============================================================
--- conf/bitbake.conf   28be7aa3c03959211fa8fff38d1903e1ec2dd8de
+++ conf/bitbake.conf   1a40a8a4b4660be43379de36b41dceabe1bebd19
@@ -468,7 +468,7 @@ OES_BITBAKE_CONF = "1"
 OES_BITBAKE_CONF = "1"
 
 ##################################################################
-# Task-base stuff
+# Machine properties and task-base stuff
 ##################################################################
 
 MACHINE_FEATURES ?= "kernel26"
@@ -477,7 +477,13 @@ ROOT_FLASH_SIZE ?= "256"
 # This is used to limit what packages goes into images built, so set big by default
 ROOT_FLASH_SIZE ?= "256"
 
-GUI_MACHINE_CLASS ?= "smallscreen"
+MACHINE_GUI_CLASS ?= "smallscreen"
+# GUI_MACHINE_CLASS is deprecated, please use MACHINE_GUI_CLASS instead
+GUI_MACHINE_CLASS ?= "${MACHINE_GUI_CLASS}"
+MACHINE_DISPLAY_WIDTH_PIXELS ?= "240"
+MACHINE_DISPLAY_HEIGHT_PIXELS ?= "320"
+MACHINE_DISPLAY_ORIENTATION ?= "0"
+MACHINE_DISPLAY_BPP ?= "16"
 
 DISTRO_EXTRA_RDEPENDS ?= ""
 DISTRO_EXTRA_RRECOMMENDS ?= ""

> Regards,

> :M:



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