Out of the box screen orientation

simpzsimpz
in Supported peripherals

I'm using the official RPi 7 inch touchscreen with Emteria. Out of the box the display seems to be upside down, I say this as when you put it into what looks like an official case (with the case's feet at the bottom) the display is upside down. The case I have:

https://thepihut.com/products/raspberry-pi-official-7-touchscreen-case?variant=15155531396

Also I always flip the screen orientation using

cd /boot
echo "lcd_rotate=2" >>config.txt

, as this seems to be the documented way to rotate the screen with no performance degradation (and using the GUI rotation controls in Emteria leaves the boot messages and logo upside down). Is this an okay/supported method with Emteria?

The only downside of this method (I can see), and it's a minor complaint, is I have to redo this every time Emteria updates. Can the updater be told not to kill this option in config.txt (if an okay rotate method)?

Comments

  • kalkovkalkov

    Yes, using this method is okay (I'm not aware of any other drawbacks).

    All files on the boot partition are replaced during an update, so its quite difficult to keep manual changes. And we don't have a mechanism for device-specific configuration yet. If you have an idea how this can be integrated, please let us know - we will be glad to adopt it.

  • simpzsimpz

    Thanks for the information.

    No real method I know beyond keeping a copy of the file and diffing after an update. And restore diffs in first boot, then forcing another boot if there are any.

    I'm sure the clunkiness of the above has put you off this already.

  • kalkovkalkov

    We were thinking of a similar process before, but there are a couple of problems with keeping file copies:
    1) Requirement for a writeable partition of a sufficient size (may be doable if the file set is fixed), which is not affected by the update
    2) Distinguishing between global configuration changes (diff between the original config file and post-update file), which can be ignored, and changes introduced by the user (diff between the original config file and the pre-update file)
    3) Decision about the compatibility of the manually introduced changes and the new platform version (hypothetical example: enabling the uart may interfere with the default GPS HAL and break the boot process)

    Sorry, it sounds very much like an excuse, but we are still looking for a good solution to overcome such (hypothetical) problems.

Sign In or Register to comment.