Embedded LCD orientation ignored: set the screen mode

Why does my panel ignore the orientation I set in the project?

The orientation field in a module project sets what the design environment shows you on screen; the panel itself runs the compiled program, so the mode it draws with is whatever the program sets, and a program that never sets it keeps the default.

Two images are in play. The preview is rendered by the design environment straight from the project file, so the orientation field shows there the moment you change it. The panel image is rendered by the compiled program after you load it. The compiled image carries only the calls the code makes; the project file with its orientation field stays on the PC. That split, stored design data on one side and running instructions on the other, is the subject of Where compiled code resides in embedded systems.

A setting that the running system ignores is a pattern worth recognizing across tools. The same diagnosis, applied to control software, is in Why a control application config setting is ignored.

Which symptom tells you it is the runtime mode and not the panel?

Preview rotated and panel unrotated points at the missing screen mode call; preview and panel both rotated but upside down for the mount points at the wrong constant; nothing drawn at all points at the build never loading, which is a transfer problem instead.

Match your case to one of these before you change anything:

• Preview rotated, panel unrotated. The program never sets a screen mode. This is the case the one-line fix below solves.
• Panel rotated but 90° off the mount. The constant matches a different quarter turn. The screen mode list gives one constant per 90° step; pick the one equal to the panel's angle from portrait.
• Nothing on the panel after a reload. The transfer failed before orientation mattered. Check the load tool's completion message and the power wiring first.
• Text flipped on a display driven over serial from a controller. That text path has its own diagnosis, in Diagnosing serial display text orientation.

Where does the screen mode call go, and what does it look like?

Call gfx_Set(SCREEN_MODE, PORTRAIT_R) once, before the repeat-forever loop; placed there it runs before the first frame is drawn, so every form, text object and graphic the loop draws afterwards uses the rotated coordinate system.

PORTRAIT_R is portrait turned 180°, the case for a panel mounted upside down relative to the forms as drawn. The mount decides the constant: the screen mode list documented for gfx_Set carries one entry per 90° step, and the panel's mechanical mounting, connector exit and bezel decide which one applies. Before the loop, the call runs once at startup and every frame after it draws rotated.

Recommendation: on any programmed module whose panel mounts rotated, set the screen mode in code with gfx_Set(SCREEN_MODE, PORTRAIT_R) before the repeat-forever loop, match the project orientation field to the same mode, and rebuild and reload after every change to the call. The panel never picks the mode up from the project file.

Does the same fix work in an editor that generates the program for you?

Yes, the same rule decides it: the panel obeys the mode the running program sets, so in an editor that builds the program from forms you get the rotation by regenerating the code so the screen mode call lands in the init section before the main loop.

The trap appears in forms-based environments exactly as in coded ones: orientation changed in the project's display settings, the preview agrees, and the panel keeps the old mode, because the generated program never carried a screen mode call. The rule is unchanged: the running program decides. Change the orientation, regenerate so the startup code carries the call, and reload. If your version of the environment offers no way to insert that call, the module vendor's support channel can point to the supported insertion point; the requirement the program must satisfy does not move.

How do you check that the rotation took effect?

Reload the build, power cycle the panel, and judge the first form that draws: with the call placed before the loop the change shows on the first frame, and a panel that still draws the old way is running an image that never called it.

1. Reload the build, then power cycle. A mode change left only in the editor changes nothing on the panel.
2. Read the first form. The title strip should sit at the mounted top; after a 180° flip, text drawn at the top sits at the physical bottom.
3. Press test on a touch panel: press the control at the physical top left. If the control at the physical bottom right reacts, the drawing is rotated and the touch map is not; the next section covers it.
4. If the panel shows machine status or alarms, confirm the alarm line still lands where operators look first. A flip moves that line, and a status board that hides its alarm state fails at its one job.
5. Still nothing after reload and power cycle? The panel is running an image without the call; check the build output timestamp and the transfer tool's completion message.

On a Linux panel the near-identical symptom, rotation set but not applied, often has a compositor or container cause, covered in Fix Weston screen rotation not applying in a container.

What happens to touch input after you rotate the screen?

The touch sensor keeps reporting in its own fixed coordinate frame, so once the drawing rotates 180° a press at the top left of the bezel reports coordinates for the drawn top left, which now sits at the physical bottom right; the touch map needs the same rotation.

Libraries that keep input and drawing separate expose a matching call that rotates pointer coordinates with the display; set it to the same mode as the screen. Where the environment generates drawing and touch map together, regenerate after the mode change so the pair leaves the generator matched. The corner press test settles it in seconds: four presses, one per corner, and each should land on the control drawn there.

What does a worked example look like for a 4.3 inch cabinet door panel?

A 4.3 inch module on a cabinet door mounts with its ribbon exit at the top edge, 180° from the portrait the program draws, so you set the project to Portrait Reversed for the preview and add gfx_Set(SCREEN_MODE, PORTRAIT_R) before the repeat-forever loop to make the panel match.

Situation: a 4.3 inch module drives a cabinet door, with the ribbon exiting the top of the bezel, so the panel mounts 180° from the portrait the forms were drawn in. The same steps hold for a 3.2 inch module; only the bezel size changes.

1. Set the project orientation to Portrait Reversed. The Object Inspector now shows the forms flipped, which confirms the design intent and nothing more.
2. Add the call: gfx_Set(SCREEN_MODE, PORTRAIT_R), first line of the program, before the repeat-forever loop.
3. Rebuild, reload, power cycle.
4. Read the result: the title strip now sits at the mounted top. The 180° flip swaps the two ends of the panel, so a control drawn at the drawn top left appears at the physical bottom right, and drawn bottom right appears at physical top left.
5. Press the physical top left. Before the touch fix, that press reports drawn top left coordinates, which after the flip drive the control at the physical bottom right; after the matching touch rotation, it drives the control you meant.

Result: one call plus one matched touch rotation, and the door panel reads upright with every press landing on its own control.

Which fix path applies to your screen?

Match the screen to its stack before you change anything: a programmed module takes the code call, a Linux panel takes the compositor file, an embedded Windows panel takes the driver setting, and a finished Android sign takes its product's own configuration, not a code edit.

If the screen also serves as a shop-floor status board, shop-floor screens and andon-style boards collects the mounting, power and brightness questions that come next.

Questions