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 #1928: Settings don't change the suspend
time (Openmoko Public Trac)
2. Re: Openmoko Bug #1972: Wifi interferes with Bluetooth
(Openmoko Public Trac)
3. Openmoko Bug #1973: Enlightenment is slow to start / restart
/ update (Openmoko Public Trac)
4. Openmoko Bug #1974: Enlightenment is slow to start / restart
/ update (Openmoko Public Trac)
5. Re: Openmoko Bug #1974: Enlightenment is slow to start /
restart / update (Openmoko Public Trac)
6. Re: Openmoko Bug #1902: Wifi can't connect at all
(Openmoko Public Trac)
7. Re: Openmoko Bug #1973: Enlightenment is slow to start /
restart / update (Openmoko Public Trac)
8. Openmoko Bug #1973: Enlightenment is slow to start / restart
/ update (Openmoko Public Trac)
--- Begin Message ---
#1928: Settings don't change the suspend time
-------------------------+--------------------------------------------------
Reporter: wilk | Owner: marek
Type: defect | Status: closed
Priority: normal | Milestone: Om2008.9
Component: Settings | Version:
Severity: blocker | Resolution: fixed
Keywords: | Blockedby:
Reproducible: always | Blocking:
-------------------------+--------------------------------------------------
Comment(by h.koenig):
Replying to [comment:13 flamma]:
>
> I have it again on screen. The exact message is:
>
> xset: unable to open display ""
I see the same messages on the text console after stopping X.
this xset is called from "ompower" during suspend/resume
and ompower doesn't have $DISPLAY set:
F UID PID PPID PRI NI VSZ RSS WCHAN STAT TTY TIME
COMMAND
0 0 1440 1 20 0 2660 776 wait S ? 0:00
ompower
0 0 2944 1440 20 0 2724 564 wait S ? 0:00 sh -c
xset s reset
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1928#comment:25>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1972: Wifi interferes with Bluetooth
----------------------------------------------------+-----------------------
Reporter: Mercury | Owner:
openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component: unknown | Version:
Severity: normal | Resolution:
Keywords: bluetooth, wifi, interference, a2dp | Blockedby:
Reproducible: | Blocking:
----------------------------------------------------+-----------------------
Comment(by werner):
If the throughput of WLAN is reduced by the same ratio as the throughput
that
BT gets, and vice versa, then things should be okay. E.g., if you measure
the
throughput of each alone as WLAN_solo and BT_solo, and again with both
active
as WLAN_shared and BT_shared, you should roughly obtain
~100% <= WLAN_shared/WLAN_solo+BT_shared/BT_solo <= ~200%
for any coexistence solution.
What coexistence in its most primitive form (and I think that's what we
have)
does is to make sure that they don't send at the same time. So they don't
create situations where both try to occupy the same frequency, resulting
in
neither being heard, and not only this transmission being lost, but also
more
time lost to recovery.
Here's a good introduction to the issue:
http://focus.ti.com/pdfs/vf/bband/coexistence.pdf
If you do the calculation from above on the data in that paper for a
distance
of 50ft, you obtain roughly 25% for WLAN and 10% for BT, resulting in 35%
bandwidth utilization for uncoordinated sharing. (Under, I presume,
otherwise
ideal conditions.)
- Werner
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1972#comment:3>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1973: 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 | Keywords:
Blockedby: | Reproducible: always
Blocking: |
------------------------+---------------------------------------------------
I've installed the Rasterman Image weeks ago, then I've updated it (but
holding the illume package) using the zecke feeds and now I'm using only
the Om2008.8 repository.
So now I'm running e-wm 0.16.999.043+svnr35818-r12 and illume
0.0+svnr215-r8.
However until the 0.16.999.043+svnr35727-r12 update (two updates ago),
Enlightenment loaded well and I was able to restart it quickly; it was
quick to update itself when I was updating a desktop file too. I've also
some slowdowns while I'm loading an application (I get the loading screen
and after few seconds it hangs for some seconds, until I get the
application in my screen).
Now, instead, Enlightenment takes about 3-5 minutes to load, a little less
to reload, and about a minute to update the desktop on changes.
Also if I didn't installed so many more apps since when E was working
well, I've noticed that if I move all the
/usr/share/applications/*.desktop in a temporary location E loads quickly
and any other issue reported seems to disappear.
I thought that this could have been due to a bad formatted desktop file,
but also re-adding them one per time I can't find the problem.
So I'm attaching here my desktop files (they're concatenated in a file).
Another thing I lost updating E is that I can't configure anymore is the
Finger scrolling from the illume config, but this is another bug report :P
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1973>
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 | Keywords:
Blockedby: | Reproducible: always
Blocking: |
------------------------+---------------------------------------------------
I've installed the Rasterman Image weeks ago, then I've updated it (but
holding the illume package) using the zecke feeds and now I'm using only
the Om2008.8 repository.
So now I'm running e-wm 0.16.999.043+svnr35818-r12 and illume
0.0+svnr215-r8.
However until the 0.16.999.043+svnr35727-r12 update (two updates ago),
Enlightenment loaded well and I was able to restart it quickly; it was
quick to update itself when I was updating a desktop file too. I've also
some slowdowns while I'm loading an application (I get the loading screen
and after few seconds it hangs for some seconds, until I get the
application in my screen).
Now, instead, Enlightenment takes about 3-5 minutes to load, a little less
to reload, and about a minute to update the desktop on changes.
Also if I didn't installed so many more apps since when E was working
well, I've noticed that if I move all the
/usr/share/applications/*.desktop in a temporary location E loads quickly
and any other issue reported seems to disappear.
I thought that this could have been due to a bad formatted desktop file,
but also re-adding them one per time I can't find the problem.
So I'm attaching here my desktop files (they're concatenated in a file).
Another thing I lost updating E is that I can't configure anymore is the
Finger scrolling from the illume config, but this is another bug report :P
PS: removing my ~/.e configuration doesn't solve too!
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1974>
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):
Ops trac made for me two tickets... Please remove the #1973!
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1974#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1902: Wifi can't connect at all
--------------------------------------------------------------------------+-
Reporter: hiciu |
Owner: hardware
Type: defect |
Status: new
Priority: normal |
Milestone:
Component: hardware |
Version: GTA02v6
Severity: normal |
Resolution:
Keywords: wireless wifi wlan set essid failed invalid argument 8B1A |
Blockedby:
Reproducible: always |
Blocking:
--------------------------------------------------------------------------+-
Comment(by werner):
Indeed, there's some confusion in the Atheros stack about how the ESSID is
passed and stored. It also gets confused if the ESSID has a length of 32
bytes. This might be because the format of the data passed in the ioctl
has
changed from including the final \0 to not including it anymore.
I don't want to change this before having a better understanding of what's
happening with the ESSID inside the stack. So I'd recommend, as a
work-around, to avoid ESSIDs of length 1 or anything larger than 31 bytes.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1902#comment:3>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1973: 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: duplicate
Keywords: | Blockedby:
Reproducible: always | Blocking:
---------------------------+------------------------------------------------
Changes (by roh):
* status: new => closed
* resolution: => duplicate
Comment:
see #1974
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1973#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1973: 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 | Keywords:
Blockedby: | Reproducible: always
Blocking: |
------------------------+---------------------------------------------------
I've installed the Rasterman Image weeks ago, then I've updated it (but
holding the illume package) using the zecke feeds and now I'm using only
the Om2008.8 repository.
So now I'm running e-wm 0.16.999.043+svnr35818-r12 and illume
0.0+svnr215-r8.
However until the 0.16.999.043+svnr35727-r12 update (two updates ago),
Enlightenment loaded well and I was able to restart it quickly; it was
quick to update itself when I was updating a desktop file too. I've also
some slowdowns while I'm loading an application (I get the loading screen
and after few seconds it hangs for some seconds, until I get the
application in my screen).
Now, instead, Enlightenment takes about 3-5 minutes to load, a little less
to reload, and about a minute to update the desktop on changes.
Also if I didn't installed so many more apps since when E was working
well, I've noticed that if I move all the
/usr/share/applications/*.desktop in a temporary location E loads quickly
and any other issue reported seems to disappear.
I thought that this could have been due to a bad formatted desktop file,
but also re-adding them one per time I can't find the problem.
So I'm attaching here my desktop files (they're concatenated in a file).
Another thing I lost updating E is that I can't configure anymore is the
Finger scrolling from the illume config, but this is another bug report :P
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1973>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
