I think I was able to made some progress by myself, but I am not there yet.
I decided to install a full GUI OS (also X11 based) to do some more testing - based on this tututial.
With the OS configured in landscape mode (default) everything worked as expected, however when I configure the display settings to portrait mode the behavior was the same as the experienced on my setup using Browser Block.
Looking around for a while I was able to fix this:
This is because (by default) when you SSH into a machine, you won’t have the DISPLAY variable set, so xinput commands don’t know which display you are trying to talk to. All you need to do after you SSH in, is run export DISPLAY=:0 (assuming you only have one display), and then all commands will run fine until you exit that SSH session. You will need to run that again the next time you connect.
On that note, if you reboot the device or the containers, you will have to run the xinput commands again, because xinput wont be persistent over reboots.
A good way to make it a permanent change in your full GUI app is to write a file to /etc/X11/xorg.conf.d/49-touch-rotate.conf with an InputClass xorg conf section: (you can change the file name if you need/want to)
I was able to run the export DISPLAY=:0 command but the I keep getting the same output on xinput commands.
However, you mention a very relevant issue with persistence. As so, I move on and try the method you advice:
I was created the .conf file under the /etc/X11/xorg.conf.d directory: It simply worked. I just had to get the right transformation. so again: thank you so much for the guidance.
Meanwhile, there is something in this approach I cannot fully understand. If I hard reset the device, the config file is persisted on the next boot. On the other hand, if I just soft reset the browser service, the file is deleted.
At this stage and for test proposes only I am SSH into the container and create the file manually.
I’m not sure about the inconsistency with hard vs. soft resetting the device. One thing I can say is that you will want to make sure you have a persistent data volume for your container, otherwise it’s expected that the file would definitely be gone when you stop/start the container. In the docker-compose.yml you can do this by setting a volume and a volume binding in the service: