Send buglog mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openmoko.org/mailman/listinfo/buglog
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of buglog digest..."
Today's Topics:
1. Re: Openmoko Bug #2019: Headphone Jack Event
(Openmoko Public Trac)
2. Re: Openmoko Bug #2019: Headphone Jack Event
(Openmoko Public Trac)
3. Re: Openmoko Bug #1994: Links in qthumbstyle are too great
(Openmoko Public Trac)
4. Re: Openmoko Bug #1997: Qtopia - clear dialed number menu
item (Openmoko Public Trac)
5. Re: Openmoko Bug #1976: Redial last called number
(Openmoko Public Trac)
6. Re: Openmoko Bug #1971: keep retrieving all SMS list even
there is no message in SIM (Openmoko Public Trac)
7. Openmoko Bug #2020: USB connection messes with suspend/resume
state machine (Openmoko Public Trac)
8. Re: Openmoko Bug #1976: Redial last called number
(Openmoko Public Trac)
--- Begin Message ---
#2019: Headphone Jack Event
------------------------+---------------------------------------------------
Reporter: Zoup | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component: unknown | Version: Om2008.8
Severity: normal | Resolution:
Keywords: | Blockedby:
Reproducible: always | Blocking:
------------------------+---------------------------------------------------
Comment(by zecke):
Could you please paste:
cat /proc/interrupts before and after inserting the headset
cat /sys/class/input/event0/device/name
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2019#comment:2>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2019: Headphone Jack Event
------------------------+---------------------------------------------------
Reporter: Zoup | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component: unknown | Version: Om2008.8
Severity: normal | Resolution:
Keywords: | Blockedby:
Reproducible: always | Blocking:
------------------------+---------------------------------------------------
Comment(by Zoup):
sure boss :
BEFORE :
CPU0
16: 314298 s3c-ext0 lis302dl
17: 1 s3c-ext0 modem
30: 628904 s3c S3C2410 Timer Tick
33: 13430 s3c s3c24xx_hcd
37: 95561 s3c S3c24xx SDIO host controller
41: 683 s3c s3c2410_udc
42: 0 s3c ohci_hcd:usb1
43: 1195 s3c s3c2440-i2c
48: 0 s3c-ext Neo1973 Headphone Jack
49: 0 s3c-ext ar6000
50: 5 s3c-ext Neo1973 AUX button
51: 3 s3c-ext Neo1973 HOLD button
53: 8 s3c-ext pcf50633
60: 1 s3c-ext lis302dl
70: 8435 s3c-uart0 s3c2440-uart
71: 1609 s3c-uart0 s3c2440-uart
73: 0 s3c-uart1 s3c2440-uart
74: 2 s3c-uart1 s3c2440-uart
76: 0 s3c-uart2 s3c2440-uart
77: 20 s3c-uart2 s3c2440-uart
79: 439 s3c-adc s3c2410_action
80: 106342 s3c-adc s3c2410_action
Err: 0
AFTER :
CPU0
16: 315386 s3c-ext0 lis302dl
17: 1 s3c-ext0 modem
30: 631005 s3c S3C2410 Timer Tick
33: 13468 s3c s3c24xx_hcd
37: 95906 s3c S3c24xx SDIO host controller
41: 745 s3c s3c2410_udc
42: 0 s3c ohci_hcd:usb1
43: 1195 s3c s3c2440-i2c
48: 0 s3c-ext Neo1973 Headphone Jack
49: 0 s3c-ext ar6000
50: 5 s3c-ext Neo1973 AUX button
51: 3 s3c-ext Neo1973 HOLD button
53: 8 s3c-ext pcf50633
60: 1 s3c-ext lis302dl
70: 8435 s3c-uart0 s3c2440-uart
71: 1609 s3c-uart0 s3c2440-uart
73: 0 s3c-uart1 s3c2440-uart
74: 2 s3c-uart1 s3c2440-uart
76: 0 s3c-uart2 s3c2440-uart
77: 20 s3c-uart2 s3c2440-uart
79: 439 s3c-adc s3c2410_action
80: 106342 s3c-adc s3c2410_action
and event0 device name is 'Neo1973 Buttons' , and i does response when i
press AUX key .
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2019#comment:3>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1994: Links in qthumbstyle are too great
----------------------------+-----------------------------------------------
Reporter: Treviño | Owner: zecke
Type: enhancement | Status: closed
Priority: normal | Milestone:
Component: Qtopia | Version: Om2008.9-dev
Severity: blocker | Resolution: fixed
Keywords: | Blockedby:
Reproducible: always | Blocking:
----------------------------+-----------------------------------------------
Changes (by zecke):
* status: new => closed
* resolution: => fixed
Comment:
Thanks, applied. SRCREV will be bumped soon as well.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1994#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1997: Qtopia - clear dialed number menu item
----------------------------+-----------------------------------------------
Reporter: Treviño | Owner: zecke
Type: enhancement | Status: closed
Priority: normal | Milestone:
Component: Qtopia | Version:
Severity: normal | Resolution: fixed
Keywords: HasPatch | Blockedby:
Reproducible: | Blocking:
----------------------------+-----------------------------------------------
Changes (by zecke):
* status: new => closed
* resolution: => fixed
Comment:
Thanks.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1997#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1976: Redial last called number
-----------------------------+----------------------------------------------
Reporter: Treviño | Owner: zecke
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: Qtopia | Version: Om2008.8
Severity: normal | Resolution:
Keywords: HasPatch, PM | Blockedby:
Reproducible: | Blocking:
-----------------------------+----------------------------------------------
Changes (by zecke):
* keywords: HasPatch => HasPatch, PM
Comment:
Replying to [comment:2 Treviño]:
> Replying to [comment:1 zecke]:
> > @Implementation: It is fine, maybe the valuespace is not populated
from the callhistory
>
> No, it isn't... What do you think about implementing the "search-last-
dialed-number" feature? Do you think it would be much slower?
No, finding the last dialed number of the callhistory should be quite easy
and fast enough. The question is if you want to have redial around reboots
but it would not hurt.
> > @Approach:
> > - Having a feature that is not easy to discover (no button for it),
that can be accidently triggered (someone pressed call with an empty
number accidently and then a complete number gets dialer) are violations
of common usability standards.
>
> Well, that's not completely true... Yes, there's no button for it, but
redialing pressing the "green button" is a common phone feature. However
With my patch to re-dial the "LastDialedCall" you need to press the call
button twice, not once!
> In fact, if the text string is empty and you press the call button, that
text area just populated with the latest called string. If you want to
dial that number, instead, you've to press the call button another time. I
think that this is a reasonable approach.
Yes, but that is a hardware button in most cases and I doubt the "Call"
button in the UI has the same functionality?
> > @Proposal: Add a redial action to the menu of the dialer. This will
take two clicks (open menu, click on redial) and we can consider
exchanging the SMS button with the redial action (easy once the code for
the action is there) in the future. Would you be willing to give that a
try?
>
> I could do it, but imho adding a button is redundant while using the
menu action is not so intuitive. I'd exchange the SMS button with a "clear
number", instead...
I added PM as I don't want to make a decision on that. I will talk with
some local folks about it as well.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1976#comment:3>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1971: keep retrieving all SMS list even there is no message in SIM
--------------------------+-------------------------------------------------
Reporter: erin_yueh | Owner: zecke
Type: defect | Status: closed
Priority: normal | Milestone: Om2008.9
Component: Qtopia | Version: Om2008.8
Severity: normal | Resolution: fixed
Keywords: sms | Blockedby:
Reproducible: always | Blocking:
--------------------------+-------------------------------------------------
Changes (by zecke):
* keywords: sms, hasPatch => sms
* status: in_testing => closed
* resolution: => fixed
Comment:
Closing it.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1971#comment:7>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2020: USB connection messes with suspend/resume state machine
---------------------+------------------------------------------------------
Reporter: vnevoa | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component: unknown | Version: Om2008.8
Severity: normal | Keywords:
Blockedby: | Reproducible: always
Blocking: |
---------------------+------------------------------------------------------
Software: up-to-date "OM2008.8-update" with original feeds (Timestamp =
Mon 15 Sep 2008 09:58:59 +0800)
Blank time = 15 seconds.
Suspend aftr blank time = 1 second.
Steps to reproduce:
1 - with FR suspended, connect USB cable -> FR resumes;
2 - wait for suspend timeouts -> FR dimms the screen but does not suspend
(charging LED stays on, illume icons are visible if an external light
source is used) and will not suspend while USB is connected;
This seems ok to me. Continuing...
3 - disconnect USB cable -> charging LED turns off but:
-> screen does not glow back up;
-> FR will not suspend after any timeouts, stays always on;
Both of these things seem wrong to me!
4 - touch the screen -> FR glows up the screen;
5 - wait for suspend timeouts -> FR dimms but does not suspend;
6 - touch the screen -> FR glows up the screen;
7 - wait for suspend timeouts -> FR does dimm and suspend;
Now I know how my FR sometimes exausts the battery at night!! It is still
turned on, but the screen is dimmed.
The same can happen if the USB is connected. Reproduce steps 1 and 2, then
don't disconnect USB, and steps 4 to 7 still happen.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2020>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1976: Redial last called number
-----------------------------+----------------------------------------------
Reporter: Treviño | Owner: zecke
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: Qtopia | Version: Om2008.8
Severity: normal | Resolution:
Keywords: HasPatch, PM | Blockedby:
Reproducible: | Blocking:
-----------------------------+----------------------------------------------
Comment(by Treviño):
Replying to [comment:3 zecke]:
> Replying to [comment:2 Treviño]:
> > Replying to [comment:1 zecke]:
> > > @Implementation: It is fine, maybe the valuespace is not populated
from the callhistory
> >
> > No, it isn't... What do you think about implementing the "search-last-
dialed-number" feature? Do you think it would be much slower?
>
> No, finding the last dialed number of the callhistory should be quite
easy and fast enough. The question is if you want to have redial around
reboots but it would not hurt.
I figure that it should be useful having a redial after reboot... So ASAP
I'll try to parse the last call from the history.
> > > @Approach:
> > > - Having a feature that is not easy to discover (no button for
it), that can be accidently triggered (someone pressed call with an empty
number accidently and then a complete number gets dialer) are violations
of common usability standards.
> >
> > Well, that's not completely true... Yes, there's no button for it, but
redialing pressing the "green button" is a common phone feature. However
With my patch to re-dial the "LastDialedCall" you need to press the call
button twice, not once!
> > In fact, if the text string is empty and you press the call button,
that text area just populated with the latest called string. If you want
to dial that number, instead, you've to press the call button another
time. I think that this is a reasonable approach.
>
> Yes, but that is a hardware button in most cases and I doubt the "Call"
button in the UI has the same functionality?
Imho it's the same... All the people tried my phone, instinctively,
pressed that button to redial a number; that's why I've added this kind of
implementation.
I don't think that nowadays people see so much difference in a hardware
and software buttons...
> > > @Proposal: Add a redial action to the menu of the dialer. This will
take two clicks (open menu, click on redial) and we can consider
exchanging the SMS button with the redial action (easy once the code for
the action is there) in the future. Would you be willing to give that a
try?
> >
> > I could do it, but imho adding a button is redundant while using the
menu action is not so intuitive. I'd exchange the SMS button with a "clear
number", instead...
>
>
> I added PM as I don't want to make a decision on that. I will talk with
some local folks about it as well.
Of course... BTW, let us (me) know about this decision! :)
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1976#comment:4>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
