Ticket #1845 (assigned defect)

Opened 5 years ago

Last modified 5 years ago

PIN-dialog show up too slow

Reported by: wendy_hung Owned by: erin_yueh
Priority: high Milestone: Om2008.10
Component: Qtopia Version:
Severity: critical Keywords:
Cc: testing@… Blocked By: #69, #1722
Blocking: Estimated Completion (week):
HasPatchForReview: no PatchReviewResult:
Reproducible: always

Description

test with Om 2008.8 image

Current result:
1) boot the device
2) after boot check the PIN-dialog
3) Home screen show up at first, 30 seconds later is the PIN-dialog

Expected:
PIN-dialog show up before goes to the home screen

Change History

comment:1 Changed 5 years ago by regina_kim

  • Component changed from unknown to Qtopia

comment:2 follow-up: ↓ 3 Changed 5 years ago by erin_yueh

why pin-dialog must show up before the home screen? this behavior is for normal mobile phones. But NEO is a mobile device, it's not just with a GSM modem. It has other functions, like WiFi?, bluetooth, GPS, .....etc. PIN code is only for GSM network! We need to run normal boot-up procedures. Even you cannot use GSM network, we are still able to run other applications.

comment:3 in reply to: ↑ 2 Changed 5 years ago by will

Replying to erin_yueh:

why pin-dialog must show up before the home screen?

What this means is that a PIN dialog should show up only after the device recognizes a sim card that needs a PIN. That's all.
We are not trying to force a PINs if there isn't one inside.

comment:4 Changed 5 years ago by stiell

FYI, 2007.2 was able to ask for the PIN code and register to the GSM network much faster. It would usually show the PIN dialog while openmoko-today was still loading. 2008.8 seems much slower both in asking for the PIN code and registering to the network after the code has been entered.

comment:5 Changed 5 years ago by regina_kim

  • Milestone changed from Om2008.9 to Om2008.10

comment:6 Changed 5 years ago by zecke

  • Blocked By 69, 1722 added

@stiell: The gsmd was started way earlier, qpe gets started after X11 gets launched, so Qtopia, E and other processes all try to access our slow flash at once.

What is the relation with #1722. Basicly there is little to fix in this bug. The root is the way we initialize the system, our slow flash. So when #1722 and #69 are solved this should be much faster as well... Trying to change the Qtopia code would not change much, the fix is somewhere else (this does not say that we are not able to speed it up by a second or two but compared to 3 minute boot time...)

comment:7 Changed 5 years ago by john_lee

  • Status changed from new to assigned
  • Owner changed from zecke to erin_yueh
  • HasPatchForReview unset

should be fixed along with the boot time improvement. of course we don't force it to show up before home.

Note: See TracTickets for help on using tickets.