[Regression] Screen output is shifted in v0.56.14

[Olf0]

modRana's screen output is strangely shifted (¼ of the screen content is off-screen) in v0.56.14 from OpenRepos the Jolla Store. This affects landscape and portrait orientation, and it affects all GUI output of modRana. Previous modRana versions, up to and including v0.55.20, are working fine. Tested on a Jolla 1 phone with SailfishOS 2.2.1.18.

Exemplary screenshots:

1. 
2. 
3. 
4. 
5. 

[Olf0]

Oh, it is a little different but even worse on an Xperia X with SailfishOS 3.0.1.11: The shift is consistent between landscape and portrait orientation, so that the black area to the right (in landscape) respectively to the bottom (in portrait) stays constant. But the black area is even larger than on a Jolla 1!

[Olf0]

And I missed to mention, that the "starting modRana..." start-up screen is centered correctly for a few seconds, before it becomes shifted as depicted in screenshots 3 and 4 above.

[Olf0]

This issue actively evades debugging: 😉

• I rebooted the devices (Jolla 1, SFOS 2.2.1.18 / Xperia X, SFOS 3.0.1.11) with modRana 0.56.14 installed meanwhile, while my "production phone" (Jolla 1, SFOS 2.2.1.18) with modRana 0.55.20 is used as a reference.
• When starting modRana 0.56.14 at the command line on the J1 (2.2.1.18), the screen output is in order! Still I captured a log file (as suggested), just starting modRana, waiting a few seconds (while doing nothing) and closing modRana: modrana056-jolla1-sfos2.2.1.txt and (a second time on the same device) modrana056-jolla1-sfos2.2.1-2.txt The captured output to stdErr shows a few warnings and errors, but modRana 0.56.14 is ultimately working fine.
• I first suspected the reboot as a reason for the different behaviour (i.e., non-reproducibility), so I tried the Xperia X to confirm this. But this time I started modRana at the GUI, and the issue occurred again!
• So back to the Jolla 1, also using modRana's GUI icon to start it: issue is present!
• Tested starting modRana per CLI and GUI a couple of times on both devices: This is absolutely reproducible for me. When started per GUI modRana always exhibits this issue, while it never does so, when started at the command line per harbour-modrana 2>&1 | tee log.txt
• Edit: I can't see anything significantly different (including the same, few warning and error messages) in two logs taken on the Xperia X (but modRana was working fine then, as it was started per CLI): modrana056-xperiax-sfos3.0.1.11.txt, modrana056-xperiax-sfos3.0.1.11-2.txt

Any ideas for further debugging?

P.S.: The debugging output to stdErr is really nice and informative. Maybe it makes sense to prepend every line with an absolute (wall / system clock) or relative (i.e., modRana's runtime since start-up) time stamp to capture the timing behaviour (function's runtime, phases of user inactivity etc.), instead of appending relative timing information (apparently in multiple formats) to a few, specific lines of debug output.

[Cmdr-Zod]

I have the same problem on a Jolla C flashed Intex Aquafish with Sailfish OS 3.0.1.11. I can't reproduce it when starting Modrana on the shell. On my other devices (Jolla 1, Intex with original Firmware and Sony Xperia X dual sim) it works fine. Tell me if there is something I can do to help tracking this down.

[Olf0]

Tried two things on the Xperia X, both did not make a difference (this issue is always present on that device):

1. Upgraded from SailfishOS 3.0.1.11 to 3.0.2.8
2. Tested with all Patchmanager Patches unapplied

[M4rtinK]

So I think I found the root cause & it should be fixed in 0.56.17 - please grab it from OpenRepos or Harbour (once past its QA) and check if it fixes the issue for you. :)

As to what was actually happening - as I was suspecting, it was related to the new native launcher:

• modRana need to know if it was started from native launcher or something else (qmlscene, etc.) due to some argument processing expectations
• the native launcher detection was previously based on binary name & thus broken when launched via icon (harbour-modrana != /usr/bin/harbour-modrana
• this resulted in no device module id being passed to the modRana backend
• this might not be a problem as modRana can autodetect on which device it is running
• but this is most likely not working on your affected device for some reason :D
• as a result, modRana defaults to the default device module (PC) and incorrect default screen resolution for desktops, yay! :P

With the fix the correct device id should always be passed regardless of how the native launcher is started (icon or CLI) and no platform/device detection should take place. :)

[M4rtinK]

@Olf0 BTW, one more note about logging & timestamps. :)

The full modRana stdout also ends up in the system journal & can be easily watched by running journalctl -f as root. That's how I found out the platform detection is being run when you click the modRana icon. :)

But that's actually not all - modRana can also log int a file, this can be enabled viaOptions->Debug->Log file Once this is enabled, modRana will create a new log file one every startup in /home/nemo/Documents/modrana_debug_logs/. This is pretty useful if you spot an issues, as you can just check the respective log file and see what happened.

And the lines in the log file have a rather precise timestamp:

2019-03-27 02:10:48,869 INFO :  == modRana Starting ==
2019-03-27 02:10:48,871 INFO :   0.56.14
2019-03-27 02:10:48,871 INFO :   Python 3.7.2
2019-03-27 02:10:48,873 INFO :   Sailfish OS 3.0.2.8 (Oulanka)

So considering that, having the timestamp also in the stdout is most likely not necessary. :)

[Olf0]

[...] the root cause [...] should be fixed in 0.56.17 - please [...] check if it fixes the issue for you. :)

I am abroad currently and my testing devices are at home. Will check next Monday, earliest.

As to what was actually happening - [...]

Thank you for the explanation.

BTW, one more note about logging & timestamps.

That is extremely helpful to know and will be useful when I ever run into an issue with modRana again (if I still remember that, then).

[Cmdr-Zod]

@M4rtinK Problem is solved on my affected device, thank you for the fix.

[Olf0]

Ack. Fixed in 0.56.17