Remaining portrait mode issues

[MerlijnWajer]

From IRC:

11:37 < Wizzup> freemangordon: I've observed the following in portait mode. When a device boots to portrait mode (droid4, pinephone, and I think vm
                too, but do not yet have vbox set up), all is well - desktop is shown and can swipe to go to a different one.
11:38 < Wizzup> But the application launcher menu doesn't render / is completely dark, and I also can't get out of it. Unless I rotate to 'right'
                (depending on hw display orientation ofc)
11:38 < Wizzup> The same is true for launching any application - say osso-xterm
11:38 < Wizzup> But here's the thing: if I then press power button twice, and unlock the screen, it's still black. If I do that again, suddenly
                it's all visible and usable.
11:39 < Wizzup> But what goes wrong then is that the entire scene is not drawn at the corners, but slightly more centered. Something I've on
                occasion seen on the N900 but always considered to be a race or a pvr bug.
11:40 < Wizzup> To be clear, when I wrote n900 above here, I mean fremantle.

[javiplx]

I've testing with portrait mode on pinephone, and behaves in a very similar manner.

If i run xrandr --output DSI-1 --rotate normal screen goes to portrait, and going through the application launcher produces the result described and waiting for some time (instead of pressing power button) gives back the usual desktop but reduced with a black frame around. Going again with xrandr (right then normal) renders it again at full screen.

When the screen goes black I see this warning on the serial console

** (hildon-desktop:3424): WARNING **: Couldn't find CRTC to rotate

and it only seems to go black when it must be completelly redraw. The top menu by pressing the power button or the one from the battery applet are displayed without any problem.

[javiplx]

I've made an image with changes from #337, and although everything is configured on portrait mode, the display starts in landscape mode, but pointer/touchscreen responds in portrait mode as expected.

In this situation, I restore the display into the expected state with xrandr --output 'DSI-1' --rotate normal, and it behaves as previously. The top menu is shown properly, but as soon as I try to get the application list the screen goes to black, although I got time to see that it draws the expected screen in landscape mode (the CRTC message mentioned before does not appear).

hildon-desktop is 1:2.2.167+1m, although I'm not sure whether that's the relevant package for this issue

[freemangordon]

yes, h-d will always start in landscape mode.
If you want to rotate to portrait, please try:
run-standalone.sh dbus-send --system --type=signal /com/nokia/mce/signal com.nokia.mce.signal.sig_device_orientation_ind string:'portrait'

see https://wiki.maemo.org/Using_Fremantle_widgets#Testing_Screen_Orientation_Changes_In_Scratchbox

[javiplx]

Great. I've tested it on the recent beowulf image and that avoids black screen, but that signal does not rotates pointer/touchscreen.
In any case, is it possible to change that setting permanently?

[MerlijnWajer]

I think if you do that on boot, after mce has started, you can probably have it that way on start.

Not sure if there is a gconf key for it.

[MerlijnWajer]

This might help: https://github.com/maemo-leste/status-area-orientationlock-applet

I haven't yet built it for beowulf I think.

[MerlijnWajer]

Hm, I think it might only lock for landscape...

[freemangordon]

No, it locks in both orientations.

[freemangordon]

Great. I've tested it on the recent beowulf image and that avoids black screen, but that signal does not rotates pointer/touchscreen.

Yes, this is something we still not decided how to deal with.

In any case, is it possible to change that setting permanently?

use orientation lock applet :)

[clort81]

I don't know what heppened but booting now gives me rotated (portrait) screen, and no Hildon desktop.

I can run xrandr --output 'DSI-1' --rotate right to get to landscape mode.

I can run /etc/X11/Xsession.post/20hildon-desktop and osso-xterm gets window decorations but don't get the little applets and clock.

I also lost the 'enter' key and need to use ctrl-enter again.

very confusing.

[MerlijnWajer]

So to be clear, on the Pinephone I did the following:

• dbus-send --system --type=signal /com/nokia/mce/signal com.nokia.mce.signal.sig_device_orientation_ind string:'portrait'
• xinput set-prop 8 261 0 0
• xinput set-prop 8 263 0

And then installed the orientation lock applet (which actually installs into the wrong lib path, will fix), and then it mostly just works for me, on the pinephone, in portrait mode.

[MerlijnWajer]

But it looks like most 'desktop' applications (firefox, VLC, anki) still force h-d to rotate back to 'landscape' mode.

[IMbackK]

"But it looks like most 'desktop' applications (firefox, VLC, anki) still force h-d to rotate back to 'landscape' mode."
this is by design and can be configured in transition.ini

also the remaining bugs regarding rotation where solved, we can close this

[clort81]

"But it looks like most 'desktop' applications (firefox, VLC, anki) still force h-d to rotate back to 'landscape' mode."
this is by design and can be configured in transition.ini

For anyone reading: This is transitions.ini in
/usr/share/hildon-desktop/transitions.ini

There is both a blacklist and a whitelist. Normally, a blacklist is used when default is to enable and a whitelist is used when default is to disable.

What is the intended default rotation policy for apps not on either list?

On my current device, Clock application is neither blacklisted nor whitelisted. Opening Clock application and turning device to portrait orientation rotates Clock.

Rotation / portrait can be disabled globally without adding every app to the blacklist with:
https://github.com/maemo-leste/status-area-orientationlock-applet
This builds and runs fine for me (tm).

[IMbackK]

default policy is to not rotate apps that are not in the lists and do not use the h-d custom "portraitable" x11 atom unless forcerotation is set in transitions.ini.

in reality this policy is silly as standard x apps already have a "portraitable" flag in the "supported aspect ratios" wm hint.