I have the stock kernel, no apps from extra-devel
- portrait mode set on phone app. Do not have launch by turning set
- turned off auto-rotate on browser

*** This bug has been confirmed by popular vote. ***

I also have similar issues. One difference - sometimes Reject and Answer
buttons appear for a moment side by side in portrait mode. Then after a second
their normal one above he other.

For more information take a look at
http://talk.maemo.org/showthread.php?t=54556
Same problem for me btw

Comment 5 Andre Klapper 2010-06-09 21:43:33 UTC

Can you define "glitch" a bit better, please?
Screenshots also welcome (Control+Shift+P, please remove any confidential data
displayed)

[b]@Andre Klapper[/b]
It will be hard to produce a screen shot because this lasts only a second or
two and during that time phone is unresponsive. I will try anyway.
There are two main variants of the issue:
1. It looks like screen is not responding to touch - you touch green button,
but nothing happens. Sometimes the screen goes black for a moment. Then turns
back On. And then you can press answer.
2. Sometimes the "incoming call" screen only is shrunk on half of the
screen(portrait halves) and the remaining half is the desktop beneath.And after
a moment it goes on all screen. As far as I can recall answer and reject
buttons are one next to another, like phone is trying to squeeze landscape into
portrait.

And there are combination of the two. May be these are separate and non related
issues, but they both occur on incoming call.

You can see it in a video on http://www.youtube.com/watch?v=CFgM5ZsCM6I thanks
to "simpu".

Comment 8 Andre Klapper 2010-06-11 00:22:51 UTC

Thanks a lot for the video - makes it way easier to understand the problem!

What EXTRA SOFTWARE do all the other people that have this problem have
installed?

As you can see in the mentioned thread in TMO some people say it is related to
installed widgets like Foreca and recaller but I am not sure.
I have too many applications installed to list them here manually. Is there any
way to create a simple text list?

Created an attachment (id=2869) [details]
Screenshot of issue(thanks simpu)

This sreenshot by simpu(thanks!) shows side by side answer/reject buttons in
portrait mode.

Andre - bug 10657(https://bugs.maemo.org/show_bug.cgi?id=10567)looks very
similar to this one?

(In reply to comment #9)
> As you can see in the mentioned thread in TMO some people say it is related to
> installed widgets like Foreca and recaller but I am not sure.
> I have too many applications installed to list them here manually. Is there any
> way to create a simple text list?
> 

It is now safe to state that this glitch is NOT related to any of the third
party software. I reflashed the device clean - does not make any difference. It
is a intrinsic problem of Nokia PR 1.2.
I'm writing to Nokia care now. If any of you could do the same it would be
helpfull.

Same happens here. I have noticed that the incoming call in this case is not
marked as Rejected or Answered, but similar to Silenced. When I end up to
Conversations app in answering call it is yet possible to answer to an incoming
call - I close Conversations app, open a Phone app and can answer the same call
which I missed due to screen glitch.
Apps installed only from maemo-extras

Comment 14 Andre Klapper 2010-06-17 15:29:35 UTC

*** Bug 10567 has been marked as a duplicate of this bug. ***

(In reply to comment #11)
> Andre - bug 10657(https://bugs.maemo.org/show_bug.cgi?id=10567)looks very
> similar to this one?
> 

Bug 10567 is similar but not same. 
In 10613, the call screen resizes and buttons locations change for a short
interval.
In 10567, the call screen shows, then it switches to blurred view of desktop
for a short interval, and then the call screen shows again.

(In reply to comment #15)
> (In reply to comment #11)
> > Andre - bug 10657(https://bugs.maemo.org/show_bug.cgi?id=10567)looks very
> > similar to this one?
> > 
> 
> Bug 10567 is similar but not same. 
> In 10613, the call screen resizes and buttons locations change for a short
> interval.
> In 10567, the call screen shows, then it switches to blurred view of desktop
> for a short interval, and then the call screen shows again.
> 
I've got both of it...guess I'm the lucky one

Comment 17 Andre Klapper 2010-06-18 12:06:25 UTC

(Please do not fullquote the complete previous comment but strip unneeded lines
instead.)

http://www.youtube.com/watch?v=c9JCRM2FxDM

here are two issues in my opinion when receiving call using PR 1.2:
- The screen orientation changes (and this is what causes it to flash)
- The Accept/Refuse button change location (side by side at first then on top
of each other).

This makes it very difficult to pick up the call (because the buttons change
place and are unresponsive). It makes me miss a lot of calls (right now, I have
to wait for the buttons and the screen to settle because attempting to pick
up... which takes about two rings).

I did not notice this issue in PR 1.1 and it appeared in PR 1.2 as far as I
know.

The following workaround exist:
Go to Phone application > Turning Control > 
* Make sure "Launch by Turning is unchecked"
* Define display orientation to "Landscape".

Indeed, it seems the issue only happens when using "Portrait mode" or
"Automatic".

It also seems the issue only happens if the screen is locked and the proximity
sensor is covered when you receive an incoming call. It is actually often the
case if you keep your phone in a pocket.

My Maemo version:
10.2010.19-1 (global version)

Talk.maemo.org thread (many people are affected by this glitch):
http://talk.maemo.org/showthread.php?t=54556

Youtube video of the glitch (it can actually be worse if you turn the phone
upside down upon receiving the call):
http://www.youtube.com/watch?v=CFgM5ZsCM6I

Comment 20 Andre Klapper 2010-06-21 13:18:33 UTC

This has been fixed in package hildon-desktop.

The next public update will include the fix.

To answer popular followup questions:
 * Nokia does not announce release dates of public updates in advance.
 * There is currently no access to these internal, non-public build versions.
   A Brainstorm proposal to change this exists at
http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/

(In reply to comment #20)
> This has been fixed in package hildon-desktop.
Has been fixed?? Actually I did try to play with different hildon-desktops...no
luck still.

@Andy > Be patient. We need to wait for the next public release. This may take
some time.

In any case, thank you Andre Klapper for fixing this bug.

Comment 23 Andre Klapper 2010-06-21 14:40:11 UTC

(In reply to comment #21)
> Has been fixed??

Please read the complete comment 20 again.

(In reply to comment #22)
> In any case, thank you Andre Klapper for fixing this bug.

I didn't fix it. I just forwarded the fact that it has been fixed internally.
:)

*** Bug 10851 has been marked as a duplicate of this bug. ***

Comment 25 Andrew Flegg 2010-07-07 15:50:02 UTC

(In reply to comment #20)
> This has been fixed in package hildon-desktop.

Andre, have you got a commit which can be linked to, so we can investigate a
backport for PR1.2?

Comment 26 Andre Klapper 2010-07-07 17:36:04 UTC

(In reply to comment #25)
> Andre, have you got a commit which can be linked to

The internal comment was "i can't tell you the exact commit (perhaps it was
22d24ca3c9108dad057a08e51cb9fe72bc1d8d87) but it looks like fixed and will be
released in a future public update of hildon-desktop"
which would be
http://maemo.gitorious.org/fremantle-hildon-desktop/hildon-desktop/commit/22d24ca3c9108dad057a08e51cb9fe72bc1d8d87

Comment 27 Andre Klapper 2010-07-09 14:09:06 UTC

*** Bug 10902 has been marked as a duplicate of this bug. ***

Backport of hildon-desktop, shouldn't conflict with PR1.2 and should include
the fix, can't make sure since I've never encountered it, however it might be
updated by apt-get so be sure to pin it.
http://mohammadag.xceleo.org/public/maemo/debfiles/hildon-desktop_2.2.138-1+0m5_armel.deb

Please don't spam the bugtracker with questions on how to install this/if the
deb causes you problems (it shouldn't anyways), feel free to email on the
address linked in my name above.

P.S, custom transitions and all that stuff might be replaced.

Comment 29 Andre Klapper 2010-08-09 11:41:45 UTC

*** Bug 11095 has been marked as a duplicate of this bug. ***

Comment 30 Andre Klapper 2010-08-25 00:17:24 UTC

*** Bug 10975 has been marked as a duplicate of this bug. ***

Mohammad Abu-Garbeyyeh: I installed your package but the bug is still
happening. Should we re-open this bugreport?

Comment 32 Andre Klapper 2010-08-26 22:04:21 UTC

Mohammad's (unofficial, but welcome) package has nothing to do with the status
of this ticket that refers to Nokia's official codebase. Please do not reopen.

And FYI, Mohammad's package fixes the issue on my N900.

Comment 34 Andre Klapper 2010-10-25 17:13:08 UTC

The problem reported here should be fixed in the update that was released today
for public: The Maemo5 update version 20.2010.36-2 (also called "PR1.3"
sometimes). Please leave a comment if the problem is not fixed for you in this
update version.

Bad news. After flashing to PR1.3 and installing nothing else than Melody
theme, the glitch appeared once today. It's mostly gone, though. I'm not
reopening this just yet, let's wait and see for other opinions.

I have also encountered this bug once, I'm a bit disappointed that the latest
hildon-desktop from gitorious didn't get into the image.

Noticed also glitch while phone app's display orientation was set to automatc.
Setting now to portrait and let's see will it help.

still experiencing screen glitch on incoming call after flashing with global PR
1.3

probably the same step still apply to reproduce this bug
out of several calls, the screen glitch usually occurs if the phone was in my
pocket before i took it out and answer the call

still observing for some more information regarding this bug

Yes, the problem still on firmware 1.3.
It's a shame that the NOKIA does not pay attention to it, or finds the issue is
not critical.

Comment 40 Andre Klapper 2010-10-27 17:55:53 UTC

So "Incoming call dialog rotates when orientation is locked" is still happening
for you in 20.2010.36-2, as in comment 7?


(In reply to comment #39)
> It's a shame that the NOKIA does not pay attention to it

People that are in a position to judge if Nokia pays attention or not please go
to http://talk.maemo.org where such comments are welcome, or contact Nokia
Customer Care to express your opinion. In this bugtracker it's not welcome.

Comment 41 Andre Klapper 2010-10-27 17:56:48 UTC

*** Bug 10778 has been marked as a duplicate of this bug. ***

Sorry. It is very disappointing that for half a year, not eliminated. Yes, is
still happening in 20.2010.36-2.

Happened to me yesterday with latest PR1.3 firmware. I do have Titans' OC
kernel installed but I do not think this hurts, quite the opposite I believe...

I had web browser open and was running flash based speed test
(www.speedtest.net) over T-mobile HSDPA connection when I had a call coming in.
The N900 web browser first became unresponsive, then the phone started ringing
about 2 seconds later. The Phone application showed up about 2 seconds after
that in landscape mode. (Phone is set up in portrait mode only, but because I
had keyboard slider open the phone will be then in landscape mode.) I was not
able to press the answer button. Next the screen went blank and phone kept
ringing. Trying to press power button etc. didn't have any effect. Finally the
call timed out (transfer to voicemail). After that I got missed call
notification and phone become responsive again.

This is the first time I encountered this situation, and it happened in a
public place with lots of people around me staring what kind of fool I am
letting phone ring and not to silence it or pick up... Embarrasing!

Have the same problem. The behavior of the phone on receiving a call is
basically not predictable. But basically what happens is that: 1) phone rings;
2) I take it out of the pocket; 3) I remove the protective sleeve; 4) it takes
a good fraction of a second for the display to actually show something (I think
it is the latency of the proximity sensor + latency of the UI); 5) after
another fraction of a second, the image flickers as the phone adjusts to its
orientation, rotating the image accordingly; 6) finally, the phone settles and
it is possible to answer the phone.

I think it is fair to say that, after having the phone in the hand, it takes at
least 1 or 2 seconds before I can actually answer the call. 

The situation gets even worse when, for some "borderline" orientations, the
phone is not sure whether it is being held in portrait or landscape mode, and
the orientation of the screen changes maybe two times before it finally
settles.

My impression is that the accelerometer is disabled when the the proximity
sensor suggests that the phone is in a pocket or in the sleeve, which is a
sensible thing. But on an incoming call, the accelerometer should immediately
wake up and the UI should get ready to draw the screen appropriately, even if
the proximity sensor says that the phone is still in the pocket/sleeve. This
way, as soon as the phone pops out of the sleeve the screen could immediately
display the incoming call screen with the proper orientation. Does it make
sense at all?

I Have the same problem. The behavior of the phone on receiving a call is
basically not predictable. But basically what happens is that: 1) phone rings;
2) I take it out of the pocket; 3) I remove the protective sleeve; 4) it takes
a good fraction of a second for the display to actually show something (I think
it is the latency of the proximity sensor + latency of the UI); 5) after
another fraction of a second, the image flickers as the phone adjusts to its
orientation, rotating the image accordingly; 6) finally, the phone settles and
it is possible to answer the phone.

I think it is fair to say that, after having the phone in the hand, it takes at
least 1 or 2 seconds before I can actually answer the call. 

The situation gets even worse when, for some "borderline" orientations, the
phone is not sure whether it is being held in portrait or landscape mode, and
the orientation of the screen changes maybe two times before it finally
settles.

My impression is that the accelerometer is disabled when the the proximity
sensor suggests that the phone is in a pocket or in the sleeve, which is a
sensible thing. But on an incoming call, the accelerometer should immediately
wake up and the UI should get ready to draw the screen appropriately, even if
the proximity sensor says that the phone is still in the pocket/sleeve. This
way, as soon as the phone pops out of the sleeve the screen could immediately
display the incoming call screen with the proper orientation. Does it make
sense at all?

Comment 46 Eero Tamminen 2010-12-13 12:07:19 UTC

(In reply to comment #45)
> I Have the same problem. The behavior of the phone on receiving a call is
> basically not predictable. But basically what happens is that: 1) phone
> rings; 2) I take it out of the pocket; 3) I remove the protective sleeve;
> 4) it takes a good fraction of a second for the display to actually show
> something (I think it is the latency of the proximity sensor + latency of
> the UI); 5)

My guess is that the proximity sensor latency is intended.  Otherwise one might
get unintended UI presses (like reject call) when one gets a phone (without
protective sleeve) out of the pocket.


> My impression is that the accelerometer is disabled when the the proximity
> sensor suggests that the phone is in a pocket or in the sleeve, which is a
> sensible thing. But on an incoming call, the accelerometer should immediately
> wake up and the UI should get ready to draw the screen appropriately, even if
> the proximity sensor says that the phone is still in the pocket/sleeve. This
> way, as soon as the phone pops out of the sleeve the screen could immediately
> display the incoming call screen with the proper orientation. Does it make
> sense at all?

I think it might help only if the event would be sent only to the phone
application (I don't think there's currently an API for that), not broadcast to
the system like it's currently done.

Do you typically have applications on background when you get calls?  If yes,
do they react to the orientation message although they're on background?  If
yes, that most likely affects the speed more than the other things (-> please
file bugs against them).

(In reply to comment #46)

> My guess is that the proximity sensor latency is intended.  Otherwise one might
> get unintended UI presses (like reject call) when one gets a phone (without
> protective sleeve) out of the pocket.

It makes sense, but it should be possible to use the accelerometer info to draw
the UI in the background while still ignoring the input. When the proximity
sensor goes off, the UI would be displayed and the input enabled. This way you
would have the best of both worlds: preemptive UI rendering and no involuntary
input:

  on incoming call:
    while proximity is on:
      read_orientation
      render_UI
    display_UI
    enable_input

> Do you typically have applications on background when you get calls?  If yes,
> do they react to the orientation message although they're on background?  If
> yes, that most likely affects the speed more than the other things (-> please
> file bugs against them).

No, that's not really the case. I am a very uncomplicated user, I basically use
the phone only for calling and receiving, and occasionally for browsing the
web. When the phone is resting in my pocket, there are no applications running.
Widgets on the desktop are reduced to a minimum, bluetooth and wifi radios are
off.

Andre:
Split this bug into:
(1) the glitch and twisted display that is shown at times when a call is
received. This may even be related to GSM signal interference, the Hildon
desktop, transitions and collapse of the device in being unable to meet timing
requirements.
(2) Bug 10778 - Incoming call notification is too slow (causes missed call)
     This is that the Application called "Phone" on the N900 is not started in
time so something can be shown and cause calls to be dropped because IN reaches
TIMEOUT. 

This is like merging "The car has a punctured tyre" with "The car run slowly on
diesel and finally breaks down completely". The inability to respond
disqualifies the right to use the term "GSM Handset" - since the network will
consider the phone broker - bust. This bug can show lightning and thunder, the
display looks twisted and it is impossible to determine where on the screen the
"Answer" and "Hangup" is located. This is bad for the user, but the operator
could not care less.  The inability to respond on time generates a ticker with
the OSS at the operator, a possible network error. So when you call CS and ask
about the handset, they can tell you "that we have some problems with the
handset, seems to drop a lot of calls during call set-up". Vodafone, T-Mobile,
Orange and the lot do not read this site, but I do. Since the phone is "Out of
reach" there is no liability for "Dropped Call Compensation" and you end up
having to make a return call from your phone, maybe to the UAE / Enitel that
will charge you £2.00 per minute. After a couple of these I have paid for a new
iPhone or Android handset.

Comment 49 Andre Klapper 2012-07-24 18:27:56 UTC

(In reply to comment #48)
> Andre: > Split this bug into:

Feel free to go ahead, though it very likely won't change anything regarding
fixing the problem *itself*.

(In reply to comment #49)
> (In reply to comment #48)
> > Andre: > Split this bug into:
> 
> Feel free to go ahead, though it very likely won't change anything regarding
> fixing the problem *itself*.

Andre, drop the descending tone.
To describe a bug and then solve it is the purpose here. It is not to
"simplify", part of the solution is to identify the difference, unique problem
so they can be solved and closed.

I relate this bug to "Transitions" and I believe should be solved by those that
work with that, maybe "Swappolube" - to configure the memory so the dispatcher
gets the memory pressure right. I ask all of them to install "Swappolube", and
use "Proposed" settings. If this solves the visual glitches, then this bug is
related to memory pressure, set "Swappiness" to 30, default setting (100) is
wrong.

Then: Can "Priority Class" be set in "Transitions"? 
----
Inability to respond can be related to wrong usage of memory, to lock chunks of
memory from being swapped, regardless of what "Swappolube" may come to would
improve. This has to be right. You solve one bug and introduce four new ones.
<b>Nokia knows how to make the phone software and I really doubt that this
needs any change</b>. I expect that the GSM driver is in the RT timeslice
class. They have locked the memory the driver needs, but the driver needs the
user to respond. With a Bluetooth headset I can press "receive" and it works.
If the Phone application finally shows the green are red buttons that I press -
then it is another lost call. It is also a lost "event" in the IN, making the
technicians in Vodafone to conclude - "The N900 is not up to it - mine is fine
but its too easy to muck around with". Address their TT ("Trouble Ticket").

Comment 51 Eero Tamminen 2012-07-25 12:25:25 UTC

> set "Swappiness" to 30, default setting (100) is wrong.

The default is there to even out swapping activity by doing it pre-emptively.  

high swappiness = swapping happens (potentially much) more often, but the
effect is smaller when device runs badly out of memory.

low swappiness = if not much memory is used, device might not swap at all, but
when it runs out of memory, the effect is much worse.  Device can be frozen for
longer period.

What is better value depends from your use-cases and how much they use memory;
have you disabled pre-starting of the apps, how many apps you typically keep
open and how much content in them i.e. how memory hungry they are, do you close
them etc.

Whether you like to avoid harder swapout freezes at random times, or have in
most use-cases more responsive device may also be down to a personal
preference.


Note that you see the main effect of swappiness setting only over longer period
of time.  Immediately after changing the setting & booting, the lower
swappiness value of course appears more interactive which makes people somehow
believe that it's also unconditionally a better value.

(In reply to comment #51)
> > set "Swappiness" to 30, default setting (100) is wrong.
> 
> The default is there to even out swapping activity by doing it pre-emptively.  
> 
> high swappiness = swapping happens (potentially much) more often, but the
> effect is smaller when device runs badly out of memory.
:::
> Note that you see the main effect of swappiness setting only over longer period
> of time.  Immediately after changing the setting & booting, the lower
> swappiness value of course appears more interactive which makes people somehow
> believe that it's also unconditionally a better value.

THANKS, Eero for a wonderful, simple explanation.

Now: can the wrong setting of "Swappiness" (that can cause the phone to freeze)
also cause this bug? 
I use the phone in Landscape only now, and use 30 on "Swappiness" and the
problem has almost disappeared 
What other parameter in "Swappolube" can be used to ensure that the Phone
application always is secured enough memory - and ensures that all the other
applications are swapped out when a call is received?

Please, those who has reported this issue, try if setting "Swappiness" solves
the glitches and halt of the display.

Comment 53 Eero Tamminen 2012-07-25 17:03:02 UTC

(In reply to comment #52)
> Now: can the wrong setting of "Swappiness" (that can cause the phone to
> freeze) also cause this bug? 

Neither swappiness of 0 or 100 are any definitive causes for freeze (with zero
it's still swapping, only just very very late), they just affect how much
things slow down and is it early or late.  Which one is better from the slow
down point of view, actually depends on current device memory utilization (but
if you're worried about Flash wearing out, number closer to 0 may be better).

--

What is causing the freeze is there not being enough RAM for the given
situation and therefore swap being actively used, for app you try to use.

If a lot of swap gets written at the same time phone app and all related
daemons try to get paged in, things slow down a lot. If I remember right,
simultenous writes slow down Flash reads to ~1/4 of normal read speed.


To answer your question, yes, a large swappiness value may have caused phone
call related functionality to be swapped out more i.e. make switching to it
slower as it requires paging more data into RAM from disk.

HOWEVER, something hogging all memory on the background and being active, i.e.
actively causing memory to be swapped in and out for it, like was case in
comment 43, makes things much worse than swappiness setting could ever do it.


> I use the phone in Landscape only now, and use 30 on "Swappiness" and the
> problem has almost disappeared 
> What other parameter in "Swappolube" can be used to ensure that the Phone
> application always is secured enough memory - and ensures that all the other
> applications are swapped out when a call is received?

Best way is not to keep open apps that take huge amounts of memory *and* are
constantly active, like e.g. Browser + Flashplayer can.


Btw. Remember also the comment about the proximity sensor.  Proximity sensor
activates screen input lock and I think there's a deliberate delay on releasing
it when the sensor isn't covered.  I.e. accidentally having finger on the
sensor isn't good thing either. :-)