• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 97 subscribers
  • Views 4746 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Setting orientation through configuration rather than through sensors

Ron Olson
Intellectual 680 points
Other Parts Discussed in Thread: AM3517

I'm looking for approaches for setting display orientation through configuration, rather than through sensors.  I've seen other postings on this subject in various forums, but the responses vary greatly, and often warn about unforeseen consequences for following the advice.  Some of this may be due to Android's evolving orientation implementation over time. But, some of it may be also due to Android not originally anticipating this need for immobile, sensorless, devices.

Here's our need:

  • We're building a new Android Gingerbread 2.3.4 tablet, with hardware similar to the AM3517 EVM.
  • The tablet will be permanently mounted in various orientations.
  • The tablet has no orientation sensors.  Instead, the customer configures the orientation, resulting in a stored orientation property retrievable by firmware.
  • The firmware reads the orientation property only during system initialization, so its value will not change while Android is running.
  • The orientation must apply to the whole system, not individual apps.  All apps adhere to the configured orientation, and an individual app should be oblivious to our implementation.  The app should adjust to the orientation exactly as it would if the orientation was set by sensors, which in our case will not change further once system initialization has completed.

The question is, what do we do software-wise to make this happen?.  We want a solution that is robust, with no (or at least minimal) chances of unforeseen side effects.  If that means we should emulate a sensor at the lowest level, then that's what we'll do.  But, we would hope to work above that layer, perhaps at the HAL layer, and preferably in Java rather than C.

Thanks,
Ron

  • 0
    TI__Guru**** 170661 points

    I believe the feature you are looking for is already there in Rowboat.

    Just set ro.sf.hwrotation=90, 180 or 270 in build.prop, default.prop, or init.rc, wherever you prefer, you will get the display orientation changed during system boots up.

  • 0 in reply to Bin Liu
    Intellectual 680 points

    Thank you Bin Liu for that information.  Your suggestion led to partial success.

    But, I saw these issues:

    • For 90 and 270, the display rotated as expected.  But, the touch input did not rotate properly.  It's not clear how the touch input was behaving, but it clearly was not lined up with the display.
    • For 180, neither the display nor the touch input rotated.  They behaved as if I never applied the ro.sf.hwrotation property.

    I've seen references in the forums to problems such as these, when using property ro.sf.hwrotation.  But, those reports went back in time, and I hoped the issues were resolved for the 2.3.4/2.1 release that I'm using.  Apparently not.

    So, I'm looking for further advice on resolving these problems.  The touch issue is by far the more serious for me.

    Thank you,

    Ron

  • 0 in reply to Ron Olson
    TI__Guru**** 170661 points

    re 180 rotation, honestly, I am not really sure if it is supported in Android AOSP. The last time (months ago) when I was looking that part of the code, I only focused on 90 & 270 rotation. But your observation tells most likely 180 rotation is not supported.

    re touch screen rotation, it is not supported in Android AOSP (at least up to gingerbread 2.3.4), but Rowboat has patched (on 07/14) to enable it. So if you use the source code from Rowboat newer than 07/14, the touch screen should be rotated once 'ro.sf.hwrotation' is set to 90 or 270. but again, 180 is not supported.

  • 0 in reply to Bin Liu
    Intellectual 680 points

    Bin,

    Thank you for the additional information.  I applied a patch dated 6/30, titled 'rotate touch screen according to property ro.sf.hwrotation', and which updates InputReader.cpp and InputReader.h.  Based on the patch contents, I believe it's the patch you referred to, although it differs from the 7/14 date you gave.  I tested with that patch, and for further assurance, I did a full update of all rowboat changes through this morning (Oct 7), and tested with that.  The results were identical.

    I experimented with a rotation of 90.  The update appears to flip the axis as needed.  But, the positioning of a touch is not correct.  For example, on the lock screen, the lock icon is about 25% up from the display bottom, but I need to touch about 50% up from the bottom to move it.

    So, it appears more work is needed.  My guess, and it's only a guess, is that some rescaling logic is needed, to account for the different lengths of the two display axis.

    For reference, for my experiment I used an AM3517 EVM board, with a clean 2.3.4/2.1 distribution plus the patch.

    Ron

  • 0 in reply to Ron Olson
    TI__Guru**** 170661 points

    yes, we are talking about the same patch. :) it was created on 06/30, and pushed to Rowboat on 07/14.

    The touch screen rotation patch was validated on AM/DM37x EVM only (not sure if anyone else has tested it on other platforms). I know AM3517 EVM uses QVGA LCD (landscape), while AM/DM37x EVM has a VGA LCD in portrait. So I am wondering if the touch screen on AM3517EVM needs more work once rotated. Hope someone who has an AM3517 EVM can give some inputs.