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 #1651: Incoming call tone has fixed repeat
rate (Openmoko Public Trac)
2. Re: Openmoko Bug #1250: No Wifi in Managed Mode
(Openmoko Public Trac)
3. Re: Openmoko Bug #1915: verify porting of pulseaudio related
apps from 2007.2 (Openmoko Public Trac)
4. Re: Openmoko Bug #1904: om2008.8 wifi don't get always an
ipv4 ip (Openmoko Public Trac)
5. Re: Openmoko Bug #1728: SMS parser bug? (Openmoko Public Trac)
6. Re: Openmoko Bug #1974: Enlightenment is slow to start /
restart / update (Openmoko Public Trac)
7. Re: Openmoko Bug #1250: No Wifi in Managed Mode
(Openmoko Public Trac)
8. Re: Openmoko Bug #1974: Enlightenment is slow to start /
restart / update (Openmoko Public Trac)
--- Begin Message ---
#1651: Incoming call tone has fixed repeat rate
---------------------------+------------------------------------------------
Reporter: stephelton | Owner: openmoko-devel
Type: defect | Status: new
Priority: high | Milestone:
Component: unknown | Version:
Severity: normal | Resolution:
Keywords: | Blockedby:
Reproducible: | Blocking:
---------------------------+------------------------------------------------
Comment(by antisol):
this only affects 2007.2
if you edit your /etc/pulse/session file to use a different ringtone, and
the ringtone you use is longer than about 1.7 seconds, when the phone
rings you hear it playing over itself - it starts playing again before it
has finished playing through the first time.
it would appear that the ringtone's length is hardcoded into the software
somewhere rather than being detected from the ringtone file.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1651#comment:2>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1250: No Wifi in Managed Mode
------------------------------------+---------------------------------------
Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED]
Type: defect | Status: reopened
Priority: highest | Milestone:
Component: System Software | Version: unspecified
Severity: critical | Resolution:
Keywords: | Blockedby:
Reproducible: | Blocking:
------------------------------------+---------------------------------------
Comment(by werner):
I had a quick look in my books about those preambles. Here's what
I found:
- the preamble can be long or short. New equipment, particularly .11g,
supports short preambles.
- the AP should signal if short preambles are okay
- if a station tries to use short preambles but the AP doesn't support
them, you get that error 19
Now, this raises a few questions:
1) why does the AP not support short preambles ? They're good for
performance, so one shouldn't suppress them needlessly.
2) does it signal that they're not supported and the Atheros stack or
firmware ignores that ? Or does the AP fail to signal this ?
3) Can we make the AR6k not try to use them ?
The answer to 2) may be in the logs. Haven't looked at them yet.
The answer to 1) is Mickey's problem :-)
Perhaps I can help with 3):
svn co
http://svn.openmoko.org/trunk/src/target/AR6kSDK.build_sw.18/host/tools/wmiconfig
cd wmiconfig
make CC=arm-angstrom-linux-gnueabi-gcc
scp wmiconfig neo:
ssh neo ./wmiconfig -i eth0 --setlongpreamble 1
Does this help ? By the way, thanks to Marek ! Your hunch about wmiconfig
may have been right.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1250#comment:25>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1915: verify porting of pulseaudio related apps from 2007.2
------------------------+---------------------------------------------------
Reporter: aleix | Owner: shr-owner
Type: task | Status: new
Priority: normal | Milestone: SHR
Component: unknown | Version:
Severity: normal | Resolution:
Keywords: | Blockedby:
Reproducible: | Blocking:
------------------------+---------------------------------------------------
Comment(by hedora):
openmoko-mediaplayer2 works just fine if you remove the package
dependencies on pulseaudio, and change the line that hardcodes it to a
pulseaudio sink to hardcode for an alsa sink.
I've tested the alsasink change with and without pulseaudio running on
2007.2, 2008.8 and FSO. I've never hit a problem with it. The only
noticible difference is decreased CPU time. The 2007.2 phone stack isn't
being ported.
If it hasn't been done already, I can produce a diff to repackage
openmoko-mediaplayer2 for FSO MS3 once it's out.
What other apps have sound, and need to be ported?
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1915#comment:3>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1904: om2008.8 wifi don't get always an ipv4 ip
------------------------+---------------------------------------------------
Reporter: dolfje | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component: unknown | Version:
Severity: normal | Resolution:
Keywords: | Blockedby:
Reproducible: | Blocking:
------------------------+---------------------------------------------------
Comment(by dolfje):
Sorry, I can't test it now, my WiFi router has left the building. But when
I get it back, I will report. That will be Friday or Saturday.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1904#comment:7>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1728: SMS parser bug?
-----------------------+----------------------------------------------------
Reporter: odlg | Owner: tick
Type: defect | Status: closed
Priority: high | Milestone:
Component: Qtopia | Version: Om2008.8
Severity: major | Resolution: fixed
Keywords: | Blockedby:
Reproducible: | Blocking:
-----------------------+----------------------------------------------------
Comment(by Treviño):
I reopen this ticket, since as you can see from this attached screenshot I
got this badly decoded SMS:
[[Image(https://docs.openmoko.org/trac/raw-
attachment/ticket/1728/Screenshot-24.png)]]
I don't really know what's inside... A PDU I can get from logread is (not
coming from the SMS above, btw):
{{{
Sep 10 00:15:42 om-gta02 user.notice root: AtChat : F :
"0791934329002000840C9193335522291600008090608155708099D6A2B32825264FA098EC95033DA545902C064A3A41D3A236F9741641D264D5997C3A8B206A71E84C0E83A0A750C84C1E83D4A7341964399F4ED0F4E97C8282CD66713A2D8282D369D1A92DBA40C46733
}}}
PS: Why not storing also the PDU not to loose the message for decoding
errors?
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1728#comment:29>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1974: Enlightenment is slow to start / restart / update
---------------------------+------------------------------------------------
Reporter: Treviño | Owner: raster
Type: defect | Status: new
Priority: normal | Milestone:
Component: E - Illume | Version: Om2008.8
Severity: normal | Resolution:
Keywords: | Blockedby:
Reproducible: always | Blocking:
---------------------------+------------------------------------------------
Comment(by Treviño):
Ok, I've updated the illume packages (well I didn't before since I was
worried by the idea of losing your keyboard), but I was wrong.
Now illume loads correctly in few seconds so this is all a my fault and I
figure that you can close this bug as invalid :P
PS: just two OT things:
1. Isn't there a way to override a system keyboard adding one with the
same name in userspace?
2. Is there a possibility to get the desktop icons scroll smooth as it is
in the configuration or in the words list? I hope you could do some
optimizations (well using an iphone-like style [that I don't like too
much] maybe could be a workaround?)
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1974#comment:3>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1250: No Wifi in Managed Mode
------------------------------------+---------------------------------------
Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED]
Type: defect | Status: reopened
Priority: highest | Milestone:
Component: System Software | Version: unspecified
Severity: critical | Resolution:
Keywords: | Blockedby:
Reproducible: | Blocking:
------------------------------------+---------------------------------------
Comment(by werner):
Okay, I decoded part of the dump. The answer to 2) is that the AP
claims that it supports the short preamble:
The first packet in bug1250-wifiproblem.dump is a beacon frame and
its capability field has the following settings:
(ESS, !IBSS) = it's an AP
(!CF-Pollable, !CF-PollReq) = no point coordination
!Privacy = no WEP
ShortPreamb = network uses short preambles
!PBCC = no packet binary convolution coding
!ChannelAg = no channel agility
ShortSlot = supports 802.11g shorter slot
!DSSS-OFDM = duh, too lazy to look that one up
If setting the long preamble with wmiconfig still causes a failure,
but this time with code 25 (0x19), then the AP is also confused about
the short slot option.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1250#comment:26>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1974: Enlightenment is slow to start / restart / update
---------------------------+------------------------------------------------
Reporter: Treviño | Owner: raster
Type: defect | Status: closed
Priority: normal | Milestone:
Component: E - Illume | Version: Om2008.8
Severity: normal | Resolution: fixed
Keywords: | Blockedby:
Reproducible: always | Blocking:
---------------------------+------------------------------------------------
Changes (by raster):
* status: new => closed
* resolution: => fixed
Comment:
1)
a. keyboards are pluggable (if it's 3rd party keyboard apps that you mean)
and illume has a gui config to select what one to run (or use illume's
built-in). just need "Keyboard" in the Categories list for the .desktop
for the kbd to run.
b. if you mean personal .kbd layout files - yes. put your personal
Default.kbd, Numbers.kbd ... or anything else in ~/.e/e/keyboards/ and it
will take preference over the system package installed one :) same for
~/.e/e/dicts/ :)
2)
scrolling is done the exact same way in both situations - objects are
moved around and thus the areas that change are redrawn (as things are
moving over a static background with alpha a redraw is required). the
difference is that the icons are well just more complex to draw, more
things to draw. more work - thus slower to update. a combination of memory
bandwidth and cpu in general as wel as the glamo has made this way of
doing things really not work as well as it does on many other embedded
platforms (the n800 does this much more smoothly - even at 300mhz for
example). even my ancient zaurus sl-c860 (i bought (400mhz xscale with an
ati imageon @ 640x480) does better (visibly...) and that came out about 4
years ago. in general the FR is particularly poor with being able to do
redraws where every "embedded system" i have used and coded for and
ported/run evas stuff on (zaurus sl5500/sl-c860, ipaq 3660, nokia n800,
and other prototype hardware not released) has coped amazingly well.
generally the "redraw it all using the cpu" works almost as well as
accelerated blitting - if the platform has it, or well. enough, but the
bonuses of having alpha blending, layers etc. are worth the swap. :) on
the FR this equation has not come to be true. the fact is that trying to
use hardware blit will be tricky as it totally bypasses the rendering
pipeline and will limit you to a ui style that in all other places is
possible and easy to do, so making the FR an exception to the rule.
so as such. nothing to be done. well not without impacting development for
many other devices. if it were me i'd not have scrolling. i'd paginate the
display and you flip pages, not scroll. iphone-style still scrolls as
such, but i don't intend to really address this stuff - i'm currently
quite busy :(
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1974#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
