CameraControl.sensorAngle on Unagi returns 270 degree. Meanwhile, CameraControl.sensorAngle on Buri returns 90 degree with exactly the same direction of preview. I guess they report degree based on different direction of rotation (e.g. one on clockwise and another on counter-clockwise). We may need to fix this before applying it into Camera app, or one of them will show preview upside-down.

Hello Mike, do you have any idea on this issue?

Hi KM, does hamachi otherwise take photos and record videos with the correct orientation? I just checked and there is not ro.moz.camera offset in https://github.com/mozilla-b2g/android-device-hamachi/blob/master/full_hamachi.mk, so the value you're getting from .sensorOffset is exactly the value returned by the camera driver.

Yes, both photos and video recording works as they should be. The same problem is reported on Keon (see Bug 947956 comment 11) after applying CameraControl.sensorAngle... We didn't print the angle out, but maybe they are having the same problem.

KM, try adding a line like this one to the file in comment 2: https://github.com/mozilla-b2g/android-device-unagi/blob/master/full_unagi.mk#L16

Nominating 1.3? since it blocks a 1.3+ bug.

I'm not having the build environment of Buri.. I can try on it for now but I feels like it would be better if there are someone working on Gecko/Gonk can help on supporting this bug.

(In reply to KM Lee [:rexboy] (Away: 12/25-1/5) from comment #6) > I'm not having the build environment of Buri.. I can try on it for now but I > feels like it would be better if there are someone working on Gecko/Gonk can > help on supporting this bug. Hi, You can find Vincent Liu or I can help.

marking this a blocker based on initial description of previews showing upside down

I just pushed the setting mentioned in Comment 4. to buri. It works. I can apply patch of bug 947956 after pushing the setting. As far as I know, we have at least Keon and Buri having this problem. So, maybe what we need to do in this bug is to confirm if this pref is set correct for each devices?

(In reply to KM Lee [:rexboy] (Away: 12/25-1/5) from comment #9) > > I just pushed the setting mentioned in Comment 4. to buri. > It works. I can apply patch of bug 947956 after pushing the setting. \o/ > As far as I know, we have at least Keon and Buri having this problem. > So, maybe what we need to do in this bug is to confirm if this pref is set > correct for each devices? Exactly.

Since I haven't send Gecko patch before, I think I'm not the appropriate one who can help on this issue. Marco may you help find someone help on it?

(In reply to KM Lee [:rexboy] (Away: 12/25-1/5) from comment #11) > > Since I haven't send Gecko patch before, I think I'm not the appropriate one > who can help on this issue. Marco may you help find someone help on it? It's not actually a Gecko change--just a chance to one of the configuration files used to build the Gonk image. Since the repo is on github, patching it is the same as patching Gaia.

Yes, This change will be added into device-XXX folder in github not in Gecko. If you still feel not suitable to update it, please let me know what value should be added into ro.moz.cam.0.sensor_offset. Then I can do it. Ex: https://github.com/mozilla-b2g/android-device-unagi/blob/master/full_unagi.mk#L16

Update: I just did more tests per comment from Vliu. If we just add sensor_offset for Hamachi, the preview rotates correctly; however pictures taken are upside-down instead. So it seems that adding sensor_offset doesn't solve the problem. we need to trace it with more detail. Just discussed with Vliu and Ben. We are clarifying some details both inside takePicture and preview frame.

KM Lee, From the latest updates from you, assuming you are actively working on this. Assigning it to you. Thanks! Hema

We are still investigating the root cause. I can assign to appropriate assignee after we find how to solve it. Changing catalog since this doesn't seem to be a Gaia bug.

Tested on several devices. Seems that devices without ro.moz.cam.0.sensor_offset works well. Otherwise it fails. Devices works: Helix_back :sensor_offset=0 .sensorAngle returns= 90. Expected sensorAngle= 90. Helix_front :sensor_offset=0 .sensorAngle returns=270. Expected sensorAngle=270. Fugu_back :sensor_offset=0 .sensorAngle returns= 90. Expected sensorAngle= 90. Fugu_front :sensor_offset=0 .sensorAngle returns=270. Expected sensorAngle=270. Flatfish_back :sensor_offset=0 .sensorAngle returns= 0. Expected sensorAngle= 0. Flatfish_front :sensor_offset=0 .sensorAngle returns= 0. Expected sensorAngle= 0. Hamachi :sensor_offset=0 .sensorAngle returns= 90. Expected sensorAngle= 90. Devices doesn't works: Keon :sensor_offset=270.sensorAngle returns= 0. Expected sensorAngle= 90. Inari :sensor_offset=270.sensorAngle returns= 0. Expected sensorAngle= 90. Unagi :sensor_offset=180.sensorAngle returns=270. Expected sensorAngle= 90. Not very sure what's going wrong, but I guess we should do something on sensorAngle against sensor_offset.

Gecko should return raw orientation [1] instead of sensor orientation in [2], since preview is only affected by raw orientation. [1] http://developer.android.com/reference/android/hardware/Camera.CameraInfo.html#orientation [2] http://dxr.mozilla.org/mozilla-central/source/dom/camera/GonkCameraControl.cpp#445 Only picture orientation should consider ro.moz.cam.0.sensor_offset as the sensor_offset is to correct picture orientation done by non-v4l2 qcom camera driver. Non-v4l2 driver appends 1) raw orientation [3] and 2) 7x25A offset [4] onto picture orientation set by gecko, whereas v4l2-based one doesn't. Therefore, Hamachi requires no sensor_offset as it uses v4l2-based driver. > Hamachi :sensor_offset=0 .sensorAngle returns= 90. Expected > sensorAngle= 90. Keon and Inari require sensor_offset=270 to correct 1). > Keon :sensor_offset=270.sensorAngle returns= 0. Expected sensorAngle= > 90. > Inari :sensor_offset=270.sensorAngle returns= 0. Expected sensorAngle= > 90. Unagi requires sensor_offset=180 to correct 1)+2). > Unagi :sensor_offset=180.sensorAngle returns=270. Expected sensorAngle= > 90. [3] https://www.codeaurora.org/cgit/quic/la/platform/hardware/qcom/camera/tree/QualcommCameraHardware.cpp?h=ics_chocolate_rb4.2#n8840 [4] https://www.codeaurora.org/cgit/quic/la/platform/hardware/qcom/camera/tree/QualcommCameraHardware.cpp?h=ics_chocolate_rb4.2#n2601 Note one way to tell whether it's v4l2-based camera driver is from logs. V4l2-based driver shows "QCamera_..." logs, whereas non-v4l2 driver shows "QualcommCameraHardware..." logs.

Return raw orientation for preview and video; only picture uses offset adjusted orientation.

Comment on attachment 8358265 [details] [diff] [review] Patch 1 (v1): Return raw orientation to gaia for preview Review of attachment 8358265 [details] [diff] [review]: ----------------------------------------------------------------- This looks good to me--does it fix the issue Rex is running into?

(In reply to Mike Habicher [:mikeh] from comment #20) > Comment on attachment 8358265 [details] [diff] [review] > Patch 1 (v1): Return raw orientation to gaia for preview > > Review of attachment 8358265 [details] [diff] [review]: > ----------------------------------------------------------------- > > This looks good to me--does it fix the issue Rex is running into? Yes, this patch makes [1] return raw orientation for preview instead of offset adjusted orientation. I've verified this patch on unagi with Rex's gaia change. [1] http://dxr.mozilla.org/mozilla-central/source/dom/camera/GonkCameraControl.cpp#445

try server: https://tbpl.mozilla.org/?tree=Try&rev=edbe794e772a