Project

General

Profile

Actions

Feature #1169

closed

Add display rotation hidden option

Added by Hammel about 1 month ago. Updated 4 days ago.

Status:
Closed
Priority:
Immediate
Assignee:
Category:
UI
Target version:
Start date:
17 Jan 2025
Due date:
% Done:

100%

Estimated time:
Severity:
01 - Critical

Description

PiStore and PiSentry are upside down on my desk and it's not easy to flip them around.

I need a way to easily flip the display, either via xrandr or by setting a firmware config and rebooting.


Related issues

Related to launcher - Bug #1180: Launcher uses hard coded messaging instead of pmsg to appmgrNewHammel16 Feb 2025

Actions
Is duplicate of launcher - Action Item #441: Add display rotatation/flipClosedHammel20 Jul 2020

Actions
Has duplicate lcdshow - Feature #964: Should pistore/pisentry be rotated 180 degrees?ClosedHammel02 May 2023

Actions
Actions #1

Updated by Hammel 24 days ago

This requires updating /media/boot/tft-config.txt from this

dtoverlay=tft35a:rotate=90,speed=80000000,fps=60

to this

dtoverlay=tft35a:rotate=270,speed=80000000,fps=60

For HDMI display, change config.txt from this

display_rotate=0x00000

to this

display_rotate=0x20000
Actions #2

Updated by Hammel 24 days ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 30
  • Severity changed from 02 - High to 01 - Critical
Actions #3

Updated by Hammel 24 days ago

To enable this the launcher needs a Ctrl-R key-press added. This key-press can be enabled with the cross.sh using a new -r option.

The code that handles this would need to also support HDMI rotation too. piboxDisplayType() should determine if we're in HDMI or TFT.

Actions #4

Updated by Hammel 10 days ago

  • % Done changed from 30 to 50

Launcher is updated to call an external script for this. The script, pirotate.sh, can be tested manually.
Both are ready for testing.

Actions #5

Updated by Hammel 7 days ago

This doesn't really work as written. The script will cycle through rotations, but that requires multiple reboots to get 180 degree rotation. I either need to default to 180 (which makes some sense - when do we need only 90 degree rotation?) or allow a UI that can select the rotation.

Additionally, the rotation doesn't affect the launcher. It still thinks it's in the opposite rotation. That means the launcher needs to query the orientation to compute touchscreen or even keypad positions.

So if the launcher needs to query for it, that means it needs to read the config files and parse them. That's what I was trying to avoid with the shell script. And querying the config file is something that other apps may need as well. So I need to add that to libpibox.

Simple problem now made complex. Again.

Note: there may be some additional methods available using xinput to set display rotation.

Actions #6

Updated by Hammel 7 days ago

Actually, I can just install a new /etc/pointercal after rotation. The following pointercal works with rotate=270 on the pistore.

-185 8210 -1058924 -5323 -68 21115394 65536 480 320 0

I got this by running pibox-touchtest -c, which runs ts_calibrate which will automatically update /etc/pointercal.

The questions are:
  1. where do I store this alternative pointercal
  2. which package should own it

lcdshow appears to own the current pointercal (see configs/lcdshow.*). But that has a generic LCD35 model. I'm wondering if the touchlib, which knows specific models, care?

Actions #7

Updated by Hammel 7 days ago

This is how I think it should work. LCDShow is built for specific TFTs. Currently it only supports TFT35 (3.5" TFTs). That means the build can specify the normal and rotated pointercal settings.

  1. lcdshow has MODEL and MODEL.rotate installed as pointercal.normal and pointercal.rotate.
  2. lcdshow postinst creates a symlink to pointercal.normal.
  3. Launcher checks the rotation value (tft-config.tft or config.txt) and chooses normal or rotate.
  4. Launcher updates the symlink appropriately.

So launcher, not pirotate.sh, will handle rotation in the config files and update the pointercal symlink to match.

I'll need to write a file parser function to read and update the rotate fields in both files.

Actions #8

Updated by Hammel 6 days ago

Side note: I actually implemented something like this 8 years ago . Same basic solution but not as complete as this current solution. It does skip the external script, however. But that solution was not merged. Note that the diff on GitLab shows mostly code clean up changes - the actual rotation (and, in that case, flip) code is rather small.

Actions #9

Updated by Hammel 6 days ago

Actions #10

Updated by Hammel 6 days ago

So it works, sort of, but only if launcher has appmgr.priv. But we don't want the launcher to have that.

The correct way to do this is with a new pmsg to piboxd, which will have root privs. The new msg is MT_SYS/MA_ROTATE.
See
  • libpibox/src/pmgs.h
  • piboxd/src/queueProcessor.c:handleSys()
    Then add a pmsg call to have piboxd call rotate. Note that pirotate.sh will need to move to piboxd from launcher.
This will require
  1. a new libpibox build in dev system with new message defintions
  2. a new piboxd build/pkg to handle the new message
    1. migrate pirotate.sh to piboxd packaging
  3. a new launcher that calls piboxMsg
    1. See example in picam/src/src/picam.c
    2. I need a return value to know if the request worked.
    3. See example in libpibox/src/ptests/pmsg.c
    4. See piboxMsg() in libpibox/src/src/pmsg.c

I could also update piboxMsg() in libpibox to support a port value so messages can go to either piboxd or appmgr, as shown in the Message Flow diagram. To check where this breaks things I can run through all the metabuilds. I don't think piboxMsg() is called in that many places other than in the unit tests for libpibox. See RM# 1180.

Actions #11

Updated by Hammel 6 days ago

  • Related to Bug #1180: Launcher uses hard coded messaging instead of pmsg to appmgr added
Actions #12

Updated by Hammel 5 days ago

  • % Done changed from 50 to 90

This is 90% there now. I even have launcher showing a status message briefly about the ensuing reboot.

However, there are two things I need to do.
  1. Fix the return code handling from piboxd. It's not properly sending the return code, possibly because the insd has been closed already.
  2. Make msg() in launcher support a timeout. It's defaulting to 3 seconds, but we can make that longer if we know we're going to reboot anyway.
None of this code is committed although I did have to rebuild a custom libpibox for the dev platform. I need to do the following after these two items are addressed.
  1. Commit and push libpibox changes.
  2. Rebuild rpi2 libpibox - remove the archive first.
  3. Commit and push piboxd changes.
  4. Commit and push launcher changes.
  5. Commit and push lcdshow changes.

Then rebuild pistore with metabuild and install to target and retest again.

One more thing: I need to test this on both Ironman and Media System. Both use the LCD/HDMI code for rotation without touching the pointercal files. The rotation is pointless on Media System (as far as I can see) but would be useful if Ironman is run in an official touchscreen without a stand, like in a wall mount.

Actions #13

Updated by Hammel 4 days ago

Ironman doesn't work right. First, the display_rotate value should be 2, not 0x20000. The former is rotation. The latter is flip.

Second, the pointercal is messed up. Except there isn't any pointercal. It was working without one. Now I need to set one up. I need to create pointercal files for both orientations and install them via ironmancfg.

Actions #14

Updated by Hammel 4 days ago

Media System shows the reboot message in the status bar but doesn't reboot. This is because pirotate doesn't identify the TYPE correctly. The pibox-config line needs to be stripped to it's first field. This will work on all three display types (TFT, LCD and HDMI).

I also realized that some HDMI are touchscreens, like the SMALL 5" display. Those will need pointercal's too. But there is no pointercal for HDMI in general since most HDMI are not touchscreen. So we need an app (probably started by launcher keystroke) to generate the pointercals. The app will need to generate default pointercal's and symlink, if they don't exist, then generate the current pointercal - specified by user selection.

I should note that pbtouchstate does a decent job of identifying touchscreens we support. If it doesn't find a touchscreen then we don't need to worry about setting up pointercal files. See RM #1181.

Actions #15

Updated by Hammel 4 days ago

  • Status changed from In Progress to Closed
  • % Done changed from 90 to 100

This is all working now, sans the new app for HDMI displays (see RM #1181).

All code is committed and pushed, across all repositories involved (pibox, lcdshow, piboxd, piboxlib, launcher, and ironmancfg).

Closing issue.

Actions #16

Updated by Hammel 4 days ago

  • Has duplicate Feature #964: Should pistore/pisentry be rotated 180 degrees? added
Actions

Also available in: Atom PDF