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 #1549: [exposure] want to launch exposure
again while it is in the e-illume bar, need 5~10 sec
(Openmoko Public Trac)
2. Openmoko Bug #1656: Bad A2DP performance (Openmoko Public Trac)
3. Re: Openmoko Bug #1656: Bad A2DP performance
(Openmoko Public Trac)
4. Re: Openmoko Bug #1522: Update packages (Openmoko Public Trac)
5. Re: Openmoko Bug #1522: Update packages (Openmoko Public Trac)
6. Re: Openmoko Bug #1655: Remove button no longer removes apps
(Openmoko Public Trac)
7. Re: Openmoko Bug #1654: [illume] Manually showing and hiding
the keyboard. (was: Qwerty keyboard launcher in ASU)
(Openmoko Public Trac)
--- Begin Message ---
#1549: [exposure] want to launch exposure again while it is in the e-illume bar,
need 5~10 sec
------------------------+---------------------------------------------------
Reporter: wendy_hung | Owner: marek
Type: defect | Status: assigned
Priority: normal | Milestone: ASU
Component: E - Illume | Version:
Severity: normal | Resolution:
Keywords: must have | Blocking:
Blockedby: |
------------------------+---------------------------------------------------
Comment(by raster):
1. i could have the animation happen on mouseup, but it happens to be on
mouse down to provide instant feedback.
2. async - efl is perfectly great at async... it is NOT threadsafe.
everything you have been doing is doing things from threads or from what
effectively acts as a thread (signals handlers interrupt any execution and
jump straight to the handler - just like an preempting of a processor
thread would just remove control on a single-cpu system to another
thread). i have lots of async code. LOTS. you are just chosing to always
do things with threads even though EFL is not threadsafe. BTW - you'd have
the same problem with gtk and qt - if you DIDNT call some sort of "flush"
to flush the x pipeline as you have written a command to a buffer - but
that command isn't write()en to the file descriptor to x until you flush
or it fills up. nothing to do with EFL here - it's to do with using
thread-constructs and not flushing buffers. if the buffers were flushed
it'd work (by sheer luck), but u'd have a thread-bug waiting to happen.
making a system threadsafe is a huge amount of work and is runtime
overhead (all data that could be shared between threads needs locking and
unlocking at all points and it's not an insignificant amount of code that
sooner or later you forget a lock or unlock somewhere, or u happen to
create a deadlock condition). i chose not to do it from early on. btw -
anyone who has done work with gui's and x will tell you not to use signal
handlers to do actual gui work - as they can pretty much destroy the flow
of logic, order of operation, create deadlocks etc. you should always do
as absolutely little as possible in a signal handler and keep it really
simple.
anyway - as for using ecore's handlers, in c it's very simple.
static int my_callback(void *data, int type, void *event_in) {
Ecore_Event_Signal_User *ev = event_in; // get event info
if (ev->number == 2) ecore_evas_activate(data); // if sugusr2 (2 vs 1
for sigusr1)
return 1; // let someone else handle the event if they like - return 1
}
// in init code for canvas
Ecore_Evas *my_ecore_evas_handle; // handle for the canvas window
// assuming you set up the canvas at some point with handle of
my_ecore_evas_handle
Ecore_Event_Handler *handler; // handler handle
handler = ecore_event_handler_add(ECORE_EVENT_SIGNAL_USER, my_callback,
my_ecore_evas_handle);
//... other stuff
// when done - ie dont need handler anymore (shutdown or deletion of
canvas)
ecore_event_handler_del(handler);
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1549#comment:14>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1656: Bad A2DP performance
---------------------+------------------------------------------------------
Reporter: Mercury | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component: unknown | Version:
Severity: normal | Keywords:
Blocking: | Blockedby:
---------------------+------------------------------------------------------
I tried setting up A2DP.
First I bonded my freerunner with my headphones using instructions from
here:
http://wiki.bluez.org/wiki/HOWTO/Bonding
Then I added an entry in asound.conf like this:
----
pcm.!default {
type bluetooth
device "AA:BB:CC:DD:EE:FF"
}
----
Then I followed some instructions on the openmoko wiki and ran a script
like this:
----
#!/usr/bin/python
import dbus
bus = dbus.SystemBus()
manager = dbus.Interface(bus.get_object('org.bluez', '/org/bluez'),
'org.bluez.Manager')
conn = manager.ActivateService('audio')
audio = dbus.Interface(bus.get_object(conn, '/org/bluez/audio'),
'org.bluez.audio.Manager')
path = audio.CreateDevice('00:15:0E:A0:63:5A')
audio.ChangeDefaultDevice(path)
sink = dbus.Interface(bus.get_object(conn, path), 'org.bluez.audio.Sink')
sink.Connect()
----
It worked, but I got extremely bad performance. It was so choppy it was
completely unlistenable. Maybe 5% of the sound made it to my ears.
I tried it with another A2DP headset, and I got the same results.
I don't know if I'm doing something wrong, if there's a bug, if there's a
flaw in the freerunner, or if the chip isn't capable of the bandwidth
needed for this?
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1656>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1656: Bad A2DP performance
---------------------+------------------------------------------------------
Reporter: Mercury | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component: unknown | Version:
Severity: normal | Resolution:
Keywords: | Blocking:
Blockedby: |
---------------------+------------------------------------------------------
Comment(by Mercury):
l2ping looked like this when I tried playing at 44100Hz sound sample rate:
[EMAIL PROTECTED]:/# l2ping 00:15:0E:A0:63:5A
Ping: 00:15:0E:A0:63:5A from 00:06:6E:17:24:C5 (data size 44) ...
4 bytes from 00:15:0E:A0:63:5A id 0 time 16.62ms
4 bytes from 00:15:0E:A0:63:5A id 1 time 34.33ms
4 bytes from 00:15:0E:A0:63:5A id 2 time 31.22ms
4 bytes from 00:15:0E:A0:63:5A id 3 time 41.30ms
4 bytes from 00:15:0E:A0:63:5A id 4 time 46.31ms
4 bytes from 00:15:0E:A0:63:5A id 5 time 26.58ms
4 bytes from 00:15:0E:A0:63:5A id 6 time 26.49ms
4 bytes from 00:15:0E:A0:63:5A id 7 time 29.40ms
4 bytes from 00:15:0E:A0:63:5A id 8 time 30.37ms
4 bytes from 00:15:0E:A0:63:5A id 9 time 36.55ms
4 bytes from 00:15:0E:A0:63:5A id 10 time 33.41ms
4 bytes from 00:15:0E:A0:63:5A id 11 time 35.38ms
4 bytes from 00:15:0E:A0:63:5A id 12 time 33.41ms
4 bytes from 00:15:0E:A0:63:5A id 13 time 32.40ms
4 bytes from 00:15:0E:A0:63:5A id 14 time 40.53ms
4 bytes from 00:15:0E:A0:63:5A id 15 time 45.44ms
4 bytes from 00:15:0E:A0:63:5A id 16 time 197.87ms
no response from 00:15:0E:A0:63:5A: id 17
no response from 00:15:0E:A0:63:5A: id 18
no response from 00:15:0E:A0:63:5A: id 19
no response from 00:15:0E:A0:63:5A: id 20
no response from 00:15:0E:A0:63:5A: id 21
no response from 00:15:0E:A0:63:5A: id 22
no response from 00:15:0E:A0:63:5A: id 23
no response from 00:15:0E:A0:63:5A: id 24
no response from 00:15:0E:A0:63:5A: id 25
4 bytes from 00:15:0E:A0:63:5A id 26 time 3809.00ms
4 bytes from 00:15:0E:A0:63:5A id 27 time 37.09ms
4 bytes from 00:15:0E:A0:63:5A id 28 time 34.14ms
4 bytes from 00:15:0E:A0:63:5A id 29 time 35.09ms
4 bytes from 00:15:0E:A0:63:5A id 30 time 36.10ms
And it looked like this when I tried it at 16000Hz
[EMAIL PROTECTED]:/# l2ping 00:15:0E:A0:63:5A
Ping: 00:15:0E:A0:63:5A from 00:06:6E:17:24:C5 (data size 44) ...
4 bytes from 00:15:0E:A0:63:5A id 0 time 10.78ms
4 bytes from 00:15:0E:A0:63:5A id 1 time 30.08ms
4 bytes from 00:15:0E:A0:63:5A id 2 time 34.22ms
4 bytes from 00:15:0E:A0:63:5A id 3 time 41.09ms
4 bytes from 00:15:0E:A0:63:5A id 4 time 27.22ms
4 bytes from 00:15:0E:A0:63:5A id 5 time 80.34ms
4 bytes from 00:15:0E:A0:63:5A id 6 time 10.36ms
no response from 00:15:0E:A0:63:5A: id 7
4 bytes from 00:15:0E:A0:63:5A id 8 time 10060.39ms
4 bytes from 00:15:0E:A0:63:5A id 9 time 2219.70ms
4 bytes from 00:15:0E:A0:63:5A id 10 time 28.56ms
4 bytes from 00:15:0E:A0:63:5A id 11 time 33.69ms
4 bytes from 00:15:0E:A0:63:5A id 12 time 34.57ms
4 bytes from 00:15:0E:A0:63:5A id 13 time 28.71ms
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1656#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1522: Update packages
-------------------------+--------------------------------------------------
Reporter: wendy_hung | Owner: tick
Type: enhancement | Status: in_testing
Priority: high | Milestone: ASU
Component: Assassin | Version:
Severity: normal | Resolution:
Keywords: must have | Blocking:
Blockedby: |
-------------------------+--------------------------------------------------
Changes (by tick):
* status: accepted => in_testing
Comment:
I think this had been solved. after opkg 4545
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1522#comment:6>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1522: Update packages
-------------------------+--------------------------------------------------
Reporter: wendy_hung | Owner: tick
Type: enhancement | Status: in_testing
Priority: high | Milestone: ASU
Component: Assassin | Version:
Severity: normal | Resolution:
Keywords: must have | Blocking:
Blockedby: |
-------------------------+--------------------------------------------------
Comment(by will):
very cool. should we use today 7/23 or tomorrow's 7/24 image to test?
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1522#comment:7>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1655: Remove button no longer removes apps
------------------------+---------------------------------------------------
Reporter: kenrestivo | Owner: openmoko-devel
Type: defect | Status: new
Priority: normal | Milestone:
Component: unknown | Version:
Severity: normal | Resolution:
Keywords: | Blocking:
Blockedby: |
------------------------+---------------------------------------------------
Changes (by zecke):
* cc: [EMAIL PROTECTED] (added)
Comment:
Please specify what versions you use. The term "Today's" ASU update is
pretty weak. As there is at least asu.dev and asu.stable. And besides you
we no slightest clue what feed you are using, if you are compiling
yourself etc.
For this bug at least include the following information:
- Version of illume
- Version of efl (like efreet, evas..., ecore.. should all be roughly
the same)
- What you actually do. Say which app you have open. Say which app
you request to remove but doesn't....
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1655#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#1654: [illume] Manually showing and hiding the keyboard.
------------------------+---------------------------------------------------
Reporter: kenrestivo | Owner: openmoko-devel
Type: defect | Status: closed
Priority: normal | Milestone:
Component: unknown | Version: GTA02v5
Severity: normal | Resolution: community
Keywords: | Blocking:
Blockedby: |
------------------------+---------------------------------------------------
Changes (by zecke):
* cc: [EMAIL PROTECTED], [EMAIL PROTECTED] (added)
* status: new => closed
* resolution: => community
Comment:
I'm trying something new here. I close this bug as "community". It is a
design decision by our product manager to not be able to manually
show/hide the keyboard. This has been discussed on openmoko-devel (or
distro-devel) and the community mailinglist. We engineer's raised our
concerns, at the end of the day PM decides.
It is technically possible to change the illume-theme to include the
QWERTY button as of now we will not do this for ASU.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1654#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog
