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 #1904: om2008.8 wifi don't get always an
ipv4 ip (Openmoko Public Trac)
2. Re: Openmoko Bug #1904: om2008.8 wifi don't get always an
ipv4 ip (Openmoko Public Trac)
3. Re: Openmoko Bug #1904: om2008.8 wifi don't get always an
ipv4 ip (Openmoko Public Trac)
4. Re: Openmoko Bug #1904: om2008.8 wifi don't get always an
ipv4 ip (Openmoko Public Trac)
5. Openmoko Bug #2011: Include python-mokoui in libmokoui2
compilation (Openmoko Public Trac)
6. Re: Openmoko Bug #2011: Include python-mokoui in libmokoui2
compilation (Openmoko Public Trac)
7. Re: Openmoko Bug #2011: Include python-mokoui in libmokoui2
compilation (Openmoko Public Trac)
--- 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 danielhedblom):
Replying to [comment:17 andy]:
> Can you define a simple test that shows it, which is easily repeatable,
then?
On my phone a simple test is to just try to get packets out over wifi.
Since the high packetloss makes getting a DHCP conversation trough very
hard i recommend setting a static ip.
>
> For example, just pinging something on local network at one packet a
second shows high packetloss? Or we need to do bulk transfer?
Set the AP as an open system and try to ping it. Also try to ping the FR
from another computer on the same wired network as the AP. The packetloss
is very high, sometimes 100%.
The thing that strikes me as rather strange is this output from ifconfig
after trying to unsuccessfully ping my AP:
eth0 Link encap:Ethernet HWaddr 00:12:CF:8E:FC:12
inet addr:192.168.1.66 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::212:cfff:fe8e:fc12/64 Scope:Link
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:3103 errors:0 dropped:0 overruns:0 frame:0
TX packets:758 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1430550 (1.3 MiB) TX bytes:32423 (31.6 KiB)
The packets are registered but somewhere sent to the bitbucket.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1904#comment:18>
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 andy):
I didn't have this issue last time I talked to unencrypted AP (which did
work fine). Is everyone seeing the packetloss also running ipv6? I don't
run it.
What happens if you do the ping in the background and tcpdump -i eth0 also
on the FR, do we see ping and pong coming in?
Just to confirm, what does
route -n
say? Does it help if you disable ipv6?
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1904#comment:19>
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 danielhedblom):
Replying to [comment:19 andy]:
> I didn't have this issue last time I talked to unencrypted AP (which did
work fine). Is everyone seeing the packetloss also running ipv6? I don't
run it.
>
> What happens if you do the ping in the background and tcpdump -i eth0
also on the FR, do we see ping and pong coming in?
Dont have ipv6, gotto get back on that one.
>
> Just to confirm, what does
>
> route -n
>
> say?
[EMAIL PROTECTED]:/sbin# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use
Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0
eth0
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0
usb0
0.0.0.0 192.168.1.254 0.0.0.0 UG 0 0 0
eth0
Does it help if you disable ipv6?
Sorry but i cant find out how. I have always disabled it by blocking
modules but i cant find any other way on the interweb.
:/
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1904#comment:20>
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 danielhedblom):
Replying to [comment:20 danielhedblom]:
> Dont have ipv6, gotto get back on that one.
Dont have tcpdump on my FR yet was what i should have written.
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/1904#comment:21>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2011: Include python-mokoui in libmokoui2 compilation
-------------------------+--------------------------------------------------
Reporter: Treviño | Owner: julian_chu
Type: enhancement | Status: new
Priority: highest | Milestone:
Component: Distro | Version: Om2008.9-dev
Severity: blocker | Keywords:
Blockedby: | Reproducible:
Blocking: |
-------------------------+--------------------------------------------------
One of the coolest and useful projects of Om2007.2 imho is the libmokoui2
library and its moko-finger-scroll.
It allows easily to add better finger usability to gtk applications (i.e.
[http://3v1n0.tuxfamily.org/openmoko/tangogps-libmokoui2-scrolled.patch
tangoGPS]) with few lines of code.
The Openmoko repositories includes only the C libraries. What about
including also the python-mokoui bindings?
They would be so much appreciated by all the users that are writing pygtk
apps for openmoko.
To test some community python apps (i.e pythm media browser), I've tried
to compile it with the toolchain, and after some tweaking I got it working
well in the Freerunner.
Is this package not built due to the python-gnome dependency? Well,
according to what I've seen in my tests, that dependency is not required
at all for standard usage. In fact I've compiled my version of python-
mokoui without any python-gnome sources (I've disabled it in configure)
and the bindings are working well anyway!
So why not adding them? :P
Now I'm also going quite OT, but I'd also add more acceleration to the
libmokoui2 base settings. I've changed it to allow to scroll faster and
works better imho:
{{{
=== modified file 'libmokoui/moko-finger-scroll.c'
--- libmokoui/moko-finger-scroll.c 2008-06-30 06:16:56 +0000
+++ libmokoui/moko-finger-scroll.c 2008-09-17 00:36:00 +0000
@@ -253,11 +253,11 @@
priv->ix = priv->x;
priv->iy = priv->y;
/* Don't allow a click if we're still moving fast, where fast is
- * defined as a quarter of our top possible speed.
+ * defined as 1/10 of our top possible speed.
* TODO: Make 'fast' configurable?
*/
- if ((ABS (priv->vel_x) < (priv->vmax * 0.25)) &&
- (ABS (priv->vel_y) < (priv->vmax * 0.25)))
+ if ((ABS (priv->vel_x) < (priv->vmax * 0.10)) &&
+ (ABS (priv->vel_y) < (priv->vmax * 0.10)))
priv->child = moko_finger_scroll_get_topmost (
GTK_BIN (priv->align)->child->window,
event->x, event->y, &x, &y);
@@ -959,7 +959,7 @@
"Maximum scroll velocity",
"Maximum distance the child widget should scroll "
"per 'frame', in pixels.",
- 0, G_MAXDOUBLE, 48,
+ 0, G_MAXDOUBLE, 96,
G_PARAM_READWRITE | G_PARAM_CONSTRUCT));
g_object_class_install_property (
}}}
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2011>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2011: Include python-mokoui in libmokoui2 compilation
----------------------------+-----------------------------------------------
Reporter: Treviño | Owner: julian_chu
Type: enhancement | Status: new
Priority: highest | Milestone:
Component: Distro | Version: Om2008.9-dev
Severity: blocker | Resolution:
Keywords: | Blockedby:
Reproducible: | Blocking:
----------------------------+-----------------------------------------------
Comment(by Treviño):
Well, I didn't set these priority flags... I don't really think that this
is blocker or that it has an highest priority!
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2011#comment:1>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
--- Begin Message ---
#2011: Include python-mokoui in libmokoui2 compilation
----------------------------+-----------------------------------------------
Reporter: Treviño | Owner: julian_chu
Type: enhancement | Status: new
Priority: highest | Milestone:
Component: Distro | Version: Om2008.9-dev
Severity: blocker | Resolution:
Keywords: | Blockedby:
Reproducible: | Blocking:
----------------------------+-----------------------------------------------
Comment(by Treviño):
Ops... I forgot to attach an ipk containing the python-mokoui2 lib for who
would like to test it:
- [http://downloads.tuxfamily.org/3v1deb/openmoko/python-
mokoui2_0.1.0+svnr4342_armv4t.ipk python-
mokoui2_0.1.0+svnr4342_armv4t.ipk]
--
Ticket URL: <https://docs.openmoko.org/trac/ticket/2011#comment:2>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac
--- End Message ---
_______________________________________________
buglog mailing list
[email protected]
http://lists.openmoko.org/mailman/listinfo/buglog