Re: [RFC] Adding screen dimensions to machine configs

[Koen Kooi <koen@dominion.kabel.utwente.nl>]

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