The definition of portrait-primary on orientation between panel on portrait & landscape mode.

[Marco Chen]

Hi all,

Requisition:
We are developing a device with panel on landscape mode (ex: 1280x800 resolution & scan line is from 0 ~ 1279 then go to next line).
According to panel on landscape mode, the splash screen or OS boot animation are all on landscape mode too.

Issue:
But we will see lockscreen and home screen are on portrait mode after booting up. This is strange because we expected they run on landscape according to panel's characteristic.

Question:
1. What is the definition of portrait-primary in app's manifest.xml?

Ex: a. It is defined as there is no rotation angle applied to screen. So if panel is landscape mode then app will run on this resolution too. (it seems to be not the case now)
b. It is always expected to "width is small then height". So even the panel is landscape mode (1280x800) but app will still run on (800x1280) as default.

2. Currently we changed the matrix of sOrientationMappings in orientationObserver.cpp, is this the correct way?

Thanks,
Sincerely yours.

-------------------------------------
Marco Chen
Engineering Manager
System Team, Device Engineering
Mozilla Taiwan

Tel: +886-2-87861100 # 352
mail: mc...@mozilla.com

[Thinker K.F. Li]

Marco Chen <mc...@mozilla.com> writes:

> Hi all,
>
> Requisition:
> We are developing a device with panel on landscape mode (ex: 1280x800 resolution & scan line is from 0 ~ 1279 then go to next line).
> According to panel on landscape mode, the splash screen or OS boot animation are all on landscape mode too.
>
> Issue:
> But we will see lockscreen and home screen are on portrait mode after booting up. This is strange because we expected they run on landscape according to panel's characteristic.
>
> Question:
> 1. What is the definition of portrait-primary in app's manifest.xml?
>
> Ex: a. It is defined as there is no rotation angle applied to screen. So if panel is landscape mode then app will run on this resolution too. (it seems to be not the case now)
> b. It is always expected to "width is small then
> height". So even the panel is landscape mode (1280x800) but
> app will still run on (800x1280) as default.

I think this can be handled by apps them-self with different CSS rules.
We don't need to do any thing at API or the platform.

Not every device can be rotated by the user; ex. desktop or TV. I don't
think force to rotate the screen in manifest is nonsense.

--
Sinker
--
天教懶漫帶疏狂

[Jeremie Patonnier]

Hi Marco,

Maybe reading this could help:

-
https://developer.mozilla.org/en-US/docs/WebAPI/Managing_screen_orientation
-
https://developer.mozilla.org/en-US/docs/Web/API/window.screen.lockOrientation
- https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html

Cheers,
Jérémie


2013/7/4 Marco Chen <mc...@mozilla.com>

> Hi all,
>
> Requisition:
> We are developing a device with panel on landscape mode (ex: 1280x800
> resolution & scan line is from 0 ~ 1279 then go to next line).
> According to panel on landscape mode, the splash screen or OS boot
> animation are all on landscape mode too.
>
> Issue:
> But we will see lockscreen and home screen are on portrait mode after
> booting up. This is strange because we expected they run on landscape
> according to panel's characteristic.
>
> Question:
> 1. What is the definition of portrait-primary in app's manifest.xml?
>
> Ex: a. It is defined as there is no rotation angle applied to screen.
> So if panel is landscape mode then app will run on this resolution too. (it
> seems to be not the case now)
> b. It is always expected to "width is small then height". So
> even the panel is landscape mode (1280x800) but app will still run on
> (800x1280) as default.
>

> 2. Currently we changed the matrix of sOrientationMappings in
> orientationObserver.cpp, is this the correct way?
>
> Thanks,
> Sincerely yours.
>
> -------------------------------------
> Marco Chen
> Engineering Manager
> System Team, Device Engineering
> Mozilla Taiwan
>
> Tel: +886-2-87861100 # 352
> mail: mc...@mozilla.com
>

> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi
>



--
Jeremie
.............................
Web : http://jeremie.patonnier.net
Twitter : @JeremiePat <http://twitter.com/JeremiePat>

[Jonas Sicking]

On Thu, Jul 4, 2013 at 12:07 AM, Marco Chen <mc...@mozilla.com> wrote:
> Hi all,
>
> Requisition:
> We are developing a device with panel on landscape mode (ex: 1280x800 resolution & scan line is from 0 ~ 1279 then go to next line).
> According to panel on landscape mode, the splash screen or OS boot animation are all on landscape mode too.
>
> Issue:
> But we will see lockscreen and home screen are on portrait mode after booting up. This is strange because we expected they run on landscape according to panel's characteristic.
>
> Question:
> 1. What is the definition of portrait-primary in app's manifest.xml?
>
> Ex: a. It is defined as there is no rotation angle applied to screen. So if panel is landscape mode then app will run on this resolution too. (it seems to be not the case now)
> b. It is always expected to "width is small then height". So even the panel is landscape mode (1280x800) but app will still run on (800x1280) as default.

"portrait-primary" is always a portrait orientation. If the device has
landscape as its primary orientation, and neither of the portrait
modes is more obvious as "primary", then "portrait-primary" should be
90 degress clockwise from the primary landscape mode. See

http://www.w3.org/TR/screen-orientation/#current-orientation

So "portrait-primary" is always a portrait mode. It's not always the
device's default orientation.

/ Jonas

[Lars Knudsen]

How are the DeviceMotion/Orientation axis mapped on a "landscape device"
set to portrait-primary vs portrait-primary set on a "portrait device"? I
have brought up the issue many times (and got ignored...*sigh*) for some
years now - but maybe you can take my worries away by giving some good
solid examples of how all this (Media Query [orientation],
DeviceMotion/DeviceOrientation and orientation lock) plays together so the
average Joe developer don't have to have a Ph.D in mapping coordinate
systems between devices and/or have a big bucket of money to buy and test
on all combinations available.

IMO: Keep it simple:

"all devices are "portrait" in all coordinate systems"

YES, there are tablets designed for landscape - but if you make a game for
landscape or portrait - you then *always* know how the mapping should be,
e.g. if landscape game and device orientation is -90 degrees ["RIGHT SIDE
UP"], then gravity = -X. I know there was pressure to get out the Firefox
device - but we need a holistic solution going beyond that, removing the
worst street bumps in the area for developers.

br
Lars

[Jonas Sicking]

The DeviceMotion/Orientation axis should probably always be mapped
such that whatever orientation the screen is rendered in is considered
"up".

That way what's rendered as up on the screen is always up according to
the DeviceMotion/Orientation events. I.e. code that lets you tilt the
screen in order to control an in-game item (like steering a car or
rolling a marble) won't have to care about if the device is in
portrait or landscape mode. Or if that mode is not the default mode
for the device.

/ Jonas

[Lars Knudsen]

Hi Jonas,

Thanks for the quick reply :)

On Thu, Aug 1, 2013 at 10:28 AM, Jonas Sicking <jo...@sicking.cc> wrote:

> The DeviceMotion/Orientation axis should probably always be mapped
>

Thanks - but see... it's this "probably always" that bothers me a lot as we
will have MANY problems between
different browser (and handset) vendors. I know the orientation lock spec
has been done with good intentions,
but in my experience from a previous job with a larger handset manufacturer
- even between departments in
the same company there can be confusion on how the mapping should be when
you open the can of worms
of allowing "portrait devices" and "landscape devices". Without going into
specifics - we did actually have a case, where
I uncovered that because of a simple "this is a landscape device"-mapping
someone did on a particular device
- even if the device had "auto rotate" on orientation - the XY-values were
still rotated 90 degrees compared to
all other devices. Everyone followed the specs they were given - but the
result was still a wrong mapping.

IF we go with the solution you propose, then the accelerometer data from
the deviceorientation/motion specs should be
revised to make it VERY simple for everyone (device and browser
manufacturers, framework developers and
application developers) to understand what's going on when you e.g. turn
the device and *then* call orientation lock to
some other orientation - or start with a lock in a certain orientation that
is then released, etc....

OR we could just make everything VERY simple by saying:

there are only portrait orientation devices - all others are mappings of
+/- 90 degrees - AND all coordinate systems stay stable
regardless of how you turn your device or how you call current or future
APIs. At least this would be easier for me to explain
to an entry level developer.

br
Lars

[Jonas Sicking]

Rather than assuming buggy implementations because device vendors
would be buggy, I think it would be more fruitful to write tests and
make sure that those tests get included in the test suites that
devices go through before shipping.

Generally speaking, I find that tests do a lot more for quality than
detailed spec writing.

/ Jonas

[Lars Knudsen]

Still - is there any reason why we can't just make it simple for
everyone - and define that "portrait up" is the default - and all
other orientations are relative to that. Including accelerometer
readings, media queries, etc.?

The orientation lock spec (and probably implementation - if it's now
in the Firefox device) feels a bit like it's done in it's own "silo"
without a holistic view on related specs (e.g. DeviceOrientation/Motion)
and to some extent - without first trying to do some reference games
and apps as average WebApps developers would have done them
(mixing API's for a full game, etc.).
Is there a chance there could be a version 2 taking the others into
account - or even better: using a different method for locking
the orientation related to the viewport definition (meta tag and/or css).

br
- Lars

[Jonas Sicking]

On Thu, Aug 1, 2013 at 5:25 AM, Lars Knudsen <lar...@gmail.com> wrote:
> Still - is there any reason why we can't just make it simple for
> everyone - and define that "portrait up" is the default - and all
> other orientations are relative to that. Including accelerometer
> readings, media queries, etc.?

The makes it easier for browser implementors, and harder for
developers, and will likely lead to more bugs for users. So I'm not
sure that I agree with your definition of "everyone".

> The orientation lock spec (and probably implementation - if it's now
> in the Firefox device) feels a bit like it's done in it's own "silo"
> without a holistic view on related specs (e.g. DeviceOrientation/Motion)
> and to some extent - without first trying to do some reference games
> and apps as average WebApps developers would have done them
> (mixing API's for a full game, etc.).
> Is there a chance there could be a version 2 taking the others into
> account - or even better: using a different method for locking
> the orientation related to the viewport definition (meta tag and/or css).

I agree the orientation spec should define the interaction with
DeviceOrientation/Motion.

[Marcos Caceres]

On Thursday, 1 August 2013 at 17:47, Jonas Sicking wrote:

> I agree the orientation spec should define the interaction with
> DeviceOrientation/Motion.

So this doesn't get lost, I've filed a bug on the w3c spec:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23072

--
Marcos Caceres

[Lars Knudsen]

Fun fact/side note:

It seems that the current chrome beta (android) has somehow flipped the
XY-axis (accelerometer) readings from iPhone (at least on my Nexus 4) -
http://www.dothisathome.com/MagicBox/

br
Lars

PS to everyone .. please consider not ignoring outsiders
(non-webkit/blink/mozilla developers/reviewers) *too* much when they
participate with some findings or thoughts on these lists ...

On Mon, Aug 26, 2013 at 10:55 PM, Marcos Caceres <mcac...@mozilla.com>wrote:

>
>
> On Thursday, 1 August 2013 at 17:47, Jonas Sicking wrote:
>

> > I agree the orientation spec should define the interaction with
> > DeviceOrientation/Motion.
>
>