Skip to content

android: fix getRotationMode() to return canonical DEVICE_ROTATED_* values - #2393

Open
chofuhoyu wants to merge 5 commits into
koreader:masterfrom
chofuhoyu:feat/android-auto-rotation
Open

android: fix getRotationMode() to return canonical DEVICE_ROTATED_* values#2393
chofuhoyu wants to merge 5 commits into
koreader:masterfrom
chofuhoyu:feat/android-auto-rotation

Conversation

@chofuhoyu

@chofuhoyu chofuhoyu commented Jun 8, 2026

Copy link
Copy Markdown

Add a mapping from Android's SCREEN_ORIENTATION_* constants to KOReader's canonical DEVICE_ROTATED_* values. Required by koreader/koreader#15507.

Changes:

  • Add ANDROID_ORIENTATION_TO_ROTATION mapping table
  • Fix getRotationMode() to return canonical DEVICE_ROTATED_* values
  • Fix setRotationMode() to sync cur_rotation_mode

This change is Reviewable

…alues

Add a mapping from Android's SCREEN_ORIENTATION_* constants to KOReader's
canonical DEVICE_ROTATED_* values. Previously, getRotationMode() returned
raw Android orientation values (e.g., PORTRAIT=1, LANDSCAPE=0) which don't
match the DEVICE_ROTATED_* encoding (0=UPRIGHT, 1=CLOCKWISE, etc.) used
throughout the rest of the codebase.

Also ensure setRotationMode() updates cur_rotation_mode to keep the
internal state in sync.
Comment thread ffi/framebuffer_android.lua Outdated
As suggested by Frenzie in PR review.
android.orientation.get() already returns LinuxFB constants (which are
identical to DEVICE_ROTATED_* encoding) via getOrientationCompat(), which
has used Display.getRotation() since 2021. The mapping table was designed
for Android SCREEN_ORIENTATION_* constants but received LinuxFB values,
inverting the mapping for orientations 0 and 1.

Restore the pre-PR koreader#2393 behavior of returning android.orientation.get()
directly, now with the understanding that it already provides the correct
4-way orientation value.
@chofuhoyu

chofuhoyu commented Jun 12, 2026

Copy link
Copy Markdown
Author

However, I seem to have come across a bug related to this ANDROID_ORIENTATION_TO_ROTATION mapping. I found a critical bug that will cause mismapping of the touching layer and the screen content layer in certain circumstances. In a word, my clicking will be shifted somehow, and I can't interact with what I'm clicking.

I'm trying to fix that.

Android's SurfaceFlinger handles display rotation and delivers touch
events in display coordinates. The BB is never rotated by the Android
setRotationMode override (it only calls android.orientation.set),
so touch coordinates must not be transformed. Return 0 (UR) to skip
the coordinate translation in the gesture detector and input handler.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants