[maemo-developers] modifying root filesystem

[Lorn Potter]

I tried the instructions and scripts for modifying the root filesystem,
http://maemo.org/platform/docs/howtos/howto_use_flasher_rootfs.html

It seems the rootfs.packages and sources.list are out of date, or there are a 
few packages missing (hildon-status-bar-display).

The make_rootimage.sh script seems a bit unfinished, as it's help lists 
--outprefix and --jffs2 which do not work.
(looking at the script, it seems there are a few missplaced 'x' characters, 
and variable not all caps)

I manually tar.gz the resulting root filesystem (the web page doesn't mention 
the need to do this part), and ran the tar2jffs2.sh, script, flashed the 
device, but the device keeps rebooting..
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] modifying root filesystem

[Devesh Kothari]

ext Lorn Potter wrote:

>I tried the instructions and scripts for modifying the root filesystem,
>http://maemo.org/platform/docs/howtos/howto_use_flasher_rootfs.html
>
>It seems the rootfs.packages and sources.list are out of date, or there are a 
>few packages missing (hildon-status-bar-display).
>
>The make_rootimage.sh script seems a bit unfinished, as it's help lists 
>--outprefix and --jffs2 which do not work.
>(looking at the script, it seems there are a few missplaced 'x' characters, 
>and variable not all caps)
>
>I manually tar.gz the resulting root filesystem (the web page doesn't mention 
>the need to do this part), and ran the tar2jffs2.sh, script, flashed the 
>device, but the device keeps rebooting..
>___
>maemo-developers mailing list
>maemo-developers@maemo.org
>https://maemo.org/mailman/listinfo/maemo-developers
>  
>
make sure you dont miss this step below

The reference root filesystem includes some binary modules that can be
downloaded separately. These packages are not necessary, you may create
a root filesystem without them, but some functionality will be missing.
To download these packages, please follow this link
.

http://maemo.org/downloads/d2.php

If you have successfuly downloaded those packages, then create a
workarounds/ directory under your rootfs working directory and copy the
binary packages there.


Devesh


___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Maemo Wiki - Application Catalog.

[Henry Tang]

Hi,
 
SDK version 1.1 comes with a new version of qemu, it is now possible to execute programs in arm target!
 
Regards,
 
Henry
On 1/16/06, Antonio Gomes <[EMAIL PROTECTED]> wrote:
hi there,First of all, if you wanna to run apps in a desktop box, you have to have an i386 target set up ... Regarding the error, try to set you LD_LIBRARY_PATH to your target directory (it is not the best way, but works) 
e.g. ./configure *--prefix=/usr* && make && make installLD_LIBRARY_PATH=/usr/lib/gpe_webbrowser_libs_path:$LD_LIBRARY_PATH*run-it*regards 

On 1/14/06, Edlinoor Syahril Ramlan <[EMAIL PROTECTED]
> wrote: 
Yup, it could run but I keep on getting this error when i click on theapplication in the xephyr window:
"/var/lib/install/usr/bin/gpe-mini-browser: error while loading sharedlibraries: libgpewidget.so.1 : cannot open shared object file: No such file ordirectory"I've been trying everything:
1) Installing the latest version of libgpewidget1_0.105m1-1_arm.deb2) Manually installed libgpewidget1_0.105m1-1_arm.deb by unpacking it manually and add libgpewidget.so.1 into /var/lib/install/usr/lib3) changing 
ld.so.confat /scratchbox/users/edlinoor/targets/SDK_ARM/etc/ld.so.conf andadding /var/lib/install/usr/lib into it4) executing "fakeroot ldconfig" before i execute " af-sb-init.sh start"
All failed!  I don't understand what is going on.  By the way I just upgradingthe SDK to version 1.1.  Does that have anything to do with the error?  Iguest not.  The application that I wanted to install is gpe-mini-browser. 
Need help please... any idea?Ed.On Friday 13 January 2006 04:44, you wrote:> On Fri, 2006-01-13 at 18:21 +0800, Edlinoor Syahril Ramlan wrote:> > Hi,> >> > I've been browsing maemo wiki and found that the "Application Catalog" 
> > listed quite a number of applications that I found interesting.> >> > But:> >> > 1) Is it possible for me to download those applications and> > install them into the Maemo SDK installed in my PC? In other words is 
> > it possible to install those applications in scratchbox?> > 2) Can I run and use the application by using the Xephyr?>> absolutely. Switch to ARM target and then,>> [beagle SDK_ARM] app-installer-tool install uber-maemo-app_arm.deb 
>-- --Antonio Gomeshttp:// tonikitoo (dot) blogspot (dot) com (slash)Nokia Technology Institute (INdT)___
maemo-developers mailing listmaemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Porting ipsec-tools (POSSIBLY SOLVED)

[Mika Bostrom]

On Fri, 13 Jan 2006, Vladislav Grinchenko wrote:
> Mika,
> 
> you might want to try relative path instead.
>
> >   In a nutshell: I'm trying to port ipsec-tools. After satisfying a
> > set of build-dependencies and dancing around a few more by selectively
> > mangling build scripts, I'm a bit stumped. After all the efforts, it is
> > ipsec-tools package itself that fails to build, which I can't help but
> > appreciate with certain sense of irony.

  The proposed solution would be optimal, but I could not figure out how
to achieve it. The following (rather brutal) patch is all that is needed
to build ipsec-tools inside scratchbox (pulled from subversion):

  I will feed the patch upstream as well, in hopes that it will
eventually evolve to a proper fix.

  Take care.


Index: configure
===
--- configure   (revision 9138)
+++ configure   (revision 9139)
@@ -24267,7 +24267,7 @@
 fi
 rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
 
-   CPPFLAGS_ADD="$CPPFLAGS_ADD -I./\${top_srcdir}/src/racoon/missing"
+   CPPFLAGS_ADD="$CPPFLAGS_ADD -I\${top_srcdir}/src/racoon/missing"
 
 fi
 
Index: debian/control
===
--- debian/control  (revision 9138)
+++ debian/control  (revision 9139)
@@ -2,7 +2,7 @@
 Section: net
 Priority: extra
 Maintainer: Ganesan Rajagopal <[EMAIL PROTECTED]>
-Build-Depends: debhelper (>= 4.0.0), flex, bison, libssl-dev (>= 0.9.6), 
libreadline5-dev
+Build-Depends: debhelper (>= 4.0.0), flex, bison, libssl-dev (>= 0.9.6), 
libreadline4-dev
 Build-Conflicts: bison++
 Standards-Version: 3.6.2
 
Index: src/racoon/nattraversal.h
===
--- src/racoon/nattraversal.h   (revision 9138)
+++ src/racoon/nattraversal.h   (revision 9139)
@@ -47,6 +47,14 @@
 #defineNON_ESP_MARKER_LEN  sizeof(u_int32_t)
 #defineNON_ESP_MARKER_USE(iph1)((iph1)->natt_flags & 
NAT_ADD_NON_ESP_MARKER)
 
+/* Required for building inside scratchbox (Maemo, Nokia N770's
+ * development kit.) This is usually found in  but is not
+ * defined in scratchbox (as of Maemo 1.1)
+ */
+#ifndef UDP_ENCAP_ESPINUDP_NON_IKE
+#define UDP_ENCAP_ESPINUDP_NON_IKE  1   /* draft-ietf-ipsec-nat-t-ike-00/01 */
+#endif
+
 /* These are the values from parsing "remote {}" 
block of the config file. */
 #define NATT_OFF   FLASE   /* = 0 */

-- 
 Mika Boström \-/  "World peace will be achieved
 [EMAIL PROTECTED]  Xwhen the last man has killed
 +358 40 759 0016 /-\   the second-to-last." -anon?


signature.asc
Description: Digital signature
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] swapfile is a huge improvement!

[Dave Neuer]

On 1/14/06, Juha Yrjölä <[EMAIL PROTECTED]> wrote:
> On Sat, 2006-01-14 at 10:33 +, ext Clemens Eisserer wrote:
>
> > But keep in mind that a swap-file means meany reads/writes to the same
> > areas of flash which will for sure lead to the death of the mmc later
> > or sooner.
>
> Not really, since the flash controller on an MMC card is supposed to do
> wear-levelling. The FAT blocks, for example, would die pretty quickly
> otherwise, since they're written to very often.

So, is there any benefit to JFFS2 on MMC other than compression (which
I guess for swap is either not necessary or even counter-productive)?

Dave
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

[maemo-developers] Gpe-mini-browser (web browser based on

[tzwolf]

Hi Phillippe,

First sorry for my pool english.

That's the problem:

I check out "gpe-mini-browser" from gpe cvs ":pserver:[EMAIL PROTECTED]:/cvs"

and download gtk-webcore from "gtk-webcore.sourceforge.net".

But when i build "gpe-mini-browser", it seems "webi.h" can't find.  I find no 
"webi.h" in "gtk-webcore".

Could you tell me how to build "gpe-mini-browser" succeed.

Thank you!___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Nokia 770 thinks my MMC card is corrupted

[Kimmo Hämäläinen]

Hi,

If this happens with W47 or newer rootfs, please make a bug to:
https://maemo.org/bugzilla/. Early software versions didn't support MMCs
without partition tables, but it is now fixed.

BR, Kimmo


On Fri, 2006-01-13 at 19:07, ext Israel Herraiz wrote:
> Hi everybody,
> 
> I have just flashed my device with the last firmware available from
> nokia.com, I am having a strange behaviour.
> 
> Each time I put in the MMC card in the device, a message tells me that
> "Memory card is corrupted or unformatted".
> 
> However, if I plug in the USB cable, I can mount the card in my computer.
> 
> Also, I can mount /media/mmc1 in the device and look inside with a
> terminal. In fact, I copied everything from the card to my computer and
> all the files are right.
> 
> So MMC card seems to be right.
> 
> If I try to format it with the File Manager, it tells me that "No card
> is inserted". As I can mount the card, it does not seem to be a hardware
> problem (it worked fine before the upgrade).
> 
> Any idea?
> 
> Regards,
> Israel Herraiz
> 
> __
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://maemo.org/mailman/listinfo/maemo-developers
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] swapfile is a huge improvement!

[Israel Herraiz]

Larry Battraw wrote:
> hangup is having to manually remount it after a reboot, but it's worth
> the trouble.  A GUI tool for toggling swap and mounts would sure be
> neat! 

Well, not properly a GUI tool but two menu entries for adding and
removing swap, I think this could useful for you [1].

I turn on swap only when I need it (for example, I am reading a PDF,
listening to MP3 and browsing the web), and turn off when I need for
example to remove the card.

Regards,
Israel Herraiz

[1] http://n770.herraiz.org/archives/15


signature.asc
Description: OpenPGP digital signature
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re:[maemo-developers] Gpe-mini-browser (web browser based on

[Philippe De Swert]

Hi!

> I check out "gpe-mini-browser" from gpe cvs
":pserver:[EMAIL PROTECTED]:/cvs"
>
> and download gtk-webcore from "gtk-webcore.sourceforge.net".
>
> But when i build "gpe-mini-browser", it seems "webi.h" can't find.  I find
no "webi.h" in "gtk-webcore".

For this you need to get the code from cvs. You also need to use a cvsdate
because otherwise you will not be able to compile it decently. (With GPE we
use 30 april I believe.) You will also need a number of small patches to
gtk-webcore. At least you will need the one that fixes the pixbuf issue on ARM
so you can see images.

The patches (and some source archives where you need to strip out part of the
path to get to the source) can be found at 
www.handhelds.org/~philippe/gtk-webcore

> Could you tell me how to build "gpe-mini-browser" succeed.

I made some changes recently (released a new version for GPE) and have made a
rather important fix in gtk-webcore so I might be making a new package for
maemo soon too.

If you need other help you can always ask me. Take into account that
gtk-webcore is a bit flaky atm, so 99% of the crashes you might experience are
related to that.

Regards,

Philippe

| Philippe De Swert
|
| GPE developer: http://gpe.handhelds.org
| Emdebian developer: http://www.emdebian.org
|
| Please do not send me documents in a closed
| format.(*.doc,*.xls,*.ppt)
| Use the open alternatives. (*.pdf,*.ps,*.html,*.txt)
| http://www.gnu.org/philosophy/no-word-attachments.html  

---
A free anti-spam and anti-virus filter on all Scarlet mailboxes
More info on http://www.scarlet.be/

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Nokia 770 thinks my MMC card is corrupted

[Israel Herraiz]

Sorry for the autoresponse.

It was my fault. I changed /etc/sudoers and kept it from the previous
firmware. That file has changed in the new firmware, and it seems the
system is unable to read the MMC card without the proper permissions in
sudo.

I recovered the original file, and all is working fine now.

Regards,
Israel

Israel Herraiz wrote:
> Hi everybody,
> 
> I have just flashed my device with the last firmware available from
> nokia.com, I am having a strange behaviour.
> 
> Each time I put in the MMC card in the device, a message tells me that
> "Memory card is corrupted or unformatted".
> 
> However, if I plug in the USB cable, I can mount the card in my computer.
> 
> Also, I can mount /media/mmc1 in the device and look inside with a
> terminal. In fact, I copied everything from the card to my computer and
> all the files are right.
> 
> So MMC card seems to be right.
> 
> If I try to format it with the File Manager, it tells me that "No card
> is inserted". As I can mount the card, it does not seem to be a hardware
> problem (it worked fine before the upgrade).
> 
> Any idea?


signature.asc
Description: OpenPGP digital signature
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Nokia 770 thinks my MMC card is corrupted

[Jussi Kukkonen]

On Fri, 2006-01-13 at 18:07 +0100, Israel Herraiz wrote:
> 
> 
> Also, I can mount /media/mmc1 in the device and look inside with a
> terminal. In fact, I copied everything from the card to my computer
> and
> all the files are right.
> 
> So MMC card seems to be right.
> 
> If I try to format it with the File Manager, it tells me that "No card
> is inserted". As I can mount the card, it does not seem to be a
> hardware problem (it worked fine before the upgrade). 

I had very similar symptoms -- the mmc wouldn't mount when inserted, but
sometimes would from terminal -- In the end it did turn out to be a
hardware problem (sort of). Before sending the device to Nokia, try
swiping the MMC contacts vigorously with a clean cloth.

Someone at #maemo also suggested using contact spray, but the swiping
did it for me.

HTH,

-- 
Jussi Kukkonen

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Nokia 770 thinks my MMC card is corrupted

[Laurent Lieben]

I had the same problem while i partitionned the mmc in two parts,  
then formated with Mac OSX tool.


The N770 didn't like it.

Even after partitionning back with one partition.

The only way i had to get it back was to format the mmc with a Nokia  
Series 60 SymbianOS phone.


so i think the N770 lacks a feature that could permit to format a  
card back to a clean state.

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Gwconnect problem search BT

[Kimmo Hämäläinen]

On Sat, 2006-01-14 at 15:25, ext 程波 程 wrote:
> simple a button,press it then begin to BT search 
> I do like this:
> button_clicked_cb
> {
> osso_rpc_run_with_defaults(osso_context,"btsearch","start_search",NULL,NULL,
> DBUS_TYPE_INVALID);
> );
> 
> }
> the problem is how  I should write to get the signal
> from com.nokia.btsearch.signal interface.
> anybody help me? thanks very much!!

I think you have to use the DBus API directly. For example, use
dbus_connection_add_filter() to register a callback function and
subscribe to the signal with dbus_bus_add_match(). You can get the DBus
connection from Libosso with osso_get_sys_dbus_connection().

BR; Kimmo

> 
> 
>   
> 
>   
>   
> ___ 
> 雅虎1G免费邮箱百分百防垃圾信 
> http://cn.mail.yahoo.com/
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://maemo.org/mailman/listinfo/maemo-developers
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

[maemo-developers] Usage of hildon_appview_add_with_scrollbar()

[Luca Donaggio]

Hi,I'm porting an app to Maemo and I came to a point where it seems convenient to use hildon_appview_add_with_scrollbar function from hildon-lgp.Original code after minimal and preliminary hildonization looks like this:
[code]  main = HILDON_APPVIEW (hildon_appview_new ("Main view"));  hildon_appview_set_fullscreen_key_allowed(main, TRUE );  gtk_widget_show (GTK_WIDGET (main));    main_icon_pixbuf = create_pixbuf ("
grsync.png");  if (main_icon_pixbuf)    {  gtk_window_set_icon (GTK_WINDOW (main), main_icon_pixbuf);  gdk_pixbuf_unref (main_icon_pixbuf);    }  scrolledwindow1 = gtk_scrolled_window_new (NULL, NULL);
  gtk_container_add (GTK_CONTAINER (main), scrolledwindow1);  gtk_scrolled_window_set_policy (GTK_SCROLLED_WINDOW (scrolledwindow1), GTK_POLICY_AUTOMATIC, GTK_POLICY_AUTOMATIC);  gtk_widget_show (scrolledwindow1);
    viewport1 = gtk_viewport_new (NULL, NULL);  gtk_widget_show (viewport1);  gtk_container_add (GTK_CONTAINER (scrolledwindow1), viewport1);[end code]Of course to viewport1 are added all the widget used by the application and the HildonAppView is added to a HildonApp object.
It works unmodified, but then I tried to avoid using the scrolled window: Maemo API documentation for HildonAppView (http://www.maemo.org/platform/docs/api/hildon-docs/lgpl-html/HildonAppView.html
) states thathildon_appview_add_with_scrollbar ()voidhildon_appview_add_with_scrollbar(HildonAppView *self, GtkWidget *child);

Adds the child to the self(HildonAppView) and creates a scrollbar
to it. Similar as adding first a GtkScrolledWindow and then the
child to it.Resulting code is:[code]  main = HILDON_APPVIEW (hildon_appview_new ("Main view"));  hildon_appview_set_fullscreen_key_allowed(main, TRUE );
  gtk_widget_show (GTK_WIDGET (main));  main_icon_pixbuf = create_pixbuf ("grsync.png");  if (main_icon_pixbuf)    {  gtk_window_set_icon (GTK_WINDOW (main), main_icon_pixbuf);  gdk_pixbuf_unref (main_icon_pixbuf);
    }  viewport1 = gtk_viewport_new (NULL, NULL);  gtk_widget_show (viewport1);  hildon_appview_add_with_scrollbar(main, viewport1);  [/end code]It produces no compiler error, but by running it (inside scratchbox and on the real device) produces only a blank window with no widget drawn.
What am I doing wrong?Luca Donaggio
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Usage of hildon_appview_add_with_scrollbar()

[Kalle Vahlman]

On 1/16/06, Luca Donaggio <[EMAIL PROTECTED]> wrote:
> [code]
>
>   main = HILDON_APPVIEW (hildon_appview_new ("Main view"));
>   hildon_appview_set_fullscreen_key_allowed(main, TRUE );
>   gtk_widget_show (GTK_WIDGET (main));
>   main_icon_pixbuf = create_pixbuf ("grsync.png");
>   if (main_icon_pixbuf)
> {
>   gtk_window_set_icon (GTK_WINDOW (main), main_icon_pixbuf);
>   gdk_pixbuf_unref (main_icon_pixbuf);
> }
>
>   viewport1 = gtk_viewport_new (NULL, NULL);
>   gtk_widget_show (viewport1);
>   hildon_appview_add_with_scrollbar(main, viewport1);
>
> [/end code]
>
> It produces no compiler error, but by running it (inside scratchbox and on
> the real device) produces only a blank window with no widget drawn.
> What am I doing wrong?

My guess is that you don't do gtk_widget_show_all() on the HildonApp?
The add_with_scrollbar creates a ScrolledWindow but does not show()
it.

Btw, you don't need to use the viewport with add_with_scrollbar(), it
does basically the same thing that your first code snippet (it's not
an error though).

--
Kalle Vahlman, [EMAIL PROTECTED]
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Gwconnect problem search BT

[Hedberg Johan (Nokia-M/Helsinki)]

On Mon, Jan 16, 2006, Kimmo Hämäläinen wrote:
> On Sat, 2006-01-14 at 15:25, ?? ??? wrote:
> > simple a button,press it then begin to BT search 
> > I do like this:
> > button_clicked_cb
> > {
> > osso_rpc_run_with_defaults(osso_context,"btsearch","start_search",NULL,NULL,
> > DBUS_TYPE_INVALID);
> > );
> > 
> > }
> > the problem is how  I should write to get the signal
> > from com.nokia.btsearch.signal interface.
> > anybody help me? thanks very much!!
> 
> I think you have to use the DBus API directly. For example, use
> dbus_connection_add_filter() to register a callback function and
> subscribe to the signal with dbus_bus_add_match(). You can get the DBus
> connection from Libosso with osso_get_sys_dbus_connection().

Also, are you sure that osso_rpc_run_with_defaults uses the system bus?
(btsearch currently doesn't work with the session bus)

Johan
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Usage of hildon_appview_add_with_scrollbar()

[Luca Donaggio]

2006/1/16, Kalle Vahlman <[EMAIL PROTECTED]>:
On 1/16/06, Luca Donaggio <[EMAIL PROTECTED]> wrote:> [code]>>   main = HILDON_APPVIEW (hildon_appview_new ("Main view"));>   hildon_appview_set_fullscreen_key_allowed(main, TRUE );
>   gtk_widget_show (GTK_WIDGET (main));>   main_icon_pixbuf = create_pixbuf ("grsync.png");>   if (main_icon_pixbuf)> {>   gtk_window_set_icon (GTK_WINDOW (main), main_icon_pixbuf);
>   gdk_pixbuf_unref (main_icon_pixbuf);> }>>   viewport1 = gtk_viewport_new (NULL, NULL);>   gtk_widget_show (viewport1);>   hildon_appview_add_with_scrollbar(main, viewport1);
>> [/end code]>> It produces no compiler error, but by running it (inside scratchbox and on> the real device) produces only a blank window with no widget drawn.> What am I doing wrong?
My guess is that you don't do gtk_widget_show_all() on the HildonApp?The add_with_scrollbar creates a ScrolledWindow but does not show()it.Btw, you don't need to use the viewport with add_with_scrollbar(), it
does basically the same thing that your first code snippet (it's notan error though).--Kalle Vahlman, [EMAIL PROTECTED]Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fiThanks Kalle,you're right I just did a gtk_widget_sow() on the HildonApp!Regarding the viewport, I think it acts like a container for all subsequent widgets in this app - to avoid using it I've to set up another container for those widgets and add_with_scrollbar() it to the appview. Or is there another way?
Luca Donaggio
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] swapfile is a huge improvement!

[Urho Konttori]

Israel Herraiz wrote:

  Larry Battraw wrote:
  
  
hangup is having to manually remount it after a reboot, but it's worth
the trouble.  A GUI tool for toggling swap and mounts would sure be
neat! 

  
  
Well, not properly a GUI tool but two menu entries for adding and
removing swap, I think this could useful for you [1].

I turn on swap only when I need it (for example, I am reading a PDF,
listening to MP3 and browsing the web), and turn off when I need for
example to remove the card.

Regards,
Israel Herraiz

This is just a suggestion, but could the following be safe enough for
consumer grade swap use on Nokia 770:

If user has swapon. User opens MMC door. System pops up a large RED GUI
that states: You have swap active. Please turn off swap before removing
MMC from the slot. GUI would have one large button (turn off swap).
After swapoff, GUI would turn green and say, it's safe to detach MMC
now.

On USB cable insertion, the same GUI would popup and tell user that MMC
cannot be mounted on PC until swap is off. Again, nice large button to
turn swap off.

When MMC inserted back from either USB connection or physically, system
would check if previous state was swapon and popup a gui asking if swap
should be resumed. 

Kind regards,
Urho Konttori




___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Usage of hildon_appview_add_with_scrollbar()

[Kalle Vahlman]

On 1/16/06, Luca Donaggio <[EMAIL PROTECTED]> wrote:
> Thanks Kalle,
>
> you're right I just did a gtk_widget_sow() on the HildonApp!
>
> Regarding the viewport, I think it acts like a container for all subsequent
> widgets in this app - to avoid using it I've to set up another container for
> those widgets and add_with_scrollbar() it to the appview. Or is there
> another way?

Both HildonAppView and GtkViewPort are GtkBins (able to hold only one
child), so you need to have some additional container for multiple
widgets anyway, it's just a matter of having the viewport in between
made by you or automatically.

I would guess that the application you are porting puts more than one
widget in the viewport so it probabl already has a suitable "toplevel"
container (most likely either a VBox or a HBox) that you can pack into
the appview instead of the viewport.

--
Kalle Vahlman, [EMAIL PROTECTED]
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Maemo Alarm/Notifier Interface

[Igor Stoppa]

On Fri, 2006-01-13 at 16:11 +0100, ext Nils Faerber wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Igor Stoppa schrieb:
[snip]
> > Obviously they have different wakeup latencies but all of them are
> > insignificant, when compared to the delay that would be introduced by a
> > traditional suspend-to-disk, which is the closer state to the "poweroff"
> > that youu are mentioning. 
> 
> Well, power-off is something like shutdown in the first place, not
> necessarily connected to suspend to disk - you could simply reboot the
> device loosing your state.
That's not really desired in a consumer device.
> 
> But as someone ales already pointed out I would also accept and even
> expect that a device that is switched off (770 power button -> switch
> off) will indeed keep being switched off despite of any occuring alarms.
> The user should know what he does when switching off his/her device. So
> I think we can basically ignore the power off problem and concentrate on
> the other above mentioned power/sleep states.
> 
Again, we are talking about something that is actually meant to be sold,
so it has to behave nicely. Personally I like to have my alarms to be
fire & forget. What's the point of setting an alarm if I have to
remember to take care of the thing that should remind me of it?

Even if we can achieve roughly 10 days of standby time, that's not much
compared to the power saving that can be achieved by effectively
switching off the device over very long periods of inactivity.
That would be compromised by such an approach of delivering alarms only
when the device is on.

These small details make the difference between a "device for hackers
only" and a device that can leverage the benefits of running linux and
yet provide a good user experience even to the regular users.

> >>As long as there is such a timer which can be used that would be fine. 
> >>Sounds a
> >>little bit similar to what we do on the iPAQ.
> > I used generic terms, but the Omap RTC is what I had in my mind.
> > However this fine-grained resolution would be lost when the device is
> > _really_ off and the usual trick to wake up and wait would be required.
> > 
> > And the RTC has to be added to the list of wakeup sources that can
> > trigger the transition from any sleep state to running.
> 
> That is just a bit in some regsiter - a very trivial kernel
> modification. The more problem would be to write an OMAP RTC compatible
> driver for the 1710 (if not yet existent, which it IMHO is not) since
> there is not documentation for the 1710 publically available.
I checked it some time ago for a basic wakeup functionality and apart
for a few changes that functionality was already provided.
> 
> I wrote the first SA1110 RTC driver and this was pretty easy given you
> have the docs. After toggling the wakeup source register bit for RTC we
> had proper wakeup alarms on the iPaq ;) This was basically one weekend's
> work without prior experience with RTC code. No big deal.
> Next was RTC support for atd, or in fact Rus Nelson started a
> specialised small scale atd for iPaq and then RTC was added to it. This
> forms the alarm framework for Familar Linux.
> 
> Cheers
>   nils faerber
> 
> - --
> kernel concepts  Tel: +49-271-771091-12
> Dreisbachstr. 24 Fax: +49-271-771091-19
> D-57250 Netphen  Mob: +49-176-21024535
> - --
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFDx8MFJXeIURG1qHgRAoMbAJ0Sh0Gmj/y6rxxPJmZ3AP6fQiaVjwCeOlz3
> Xhixt4nciHrthDbaY7LtTpo=
> =q0Yx
> -END PGP SIGNATURE-
-- 
Igor Stoppa (Nokia M - OSSO / Tampere)
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Usage of hildon_appview_add_with_scrollbar()

[Luca Donaggio]

2006/1/16, Kalle Vahlman <[EMAIL PROTECTED]>:
On 1/16/06, Luca Donaggio <[EMAIL PROTECTED]> wrote:> Thanks Kalle,>> you're right I just did a gtk_widget_sow() on the HildonApp!>> Regarding the viewport, I think it acts like a container for all subsequent
> widgets in this app - to avoid using it I've to set up another container for> those widgets and add_with_scrollbar() it to the appview. Or is there> another way?Both HildonAppView and GtkViewPort are GtkBins (able to hold only one
child), so you need to have some additional container for multiplewidgets anyway, it's just a matter of having the viewport in betweenmade by you or automatically.I would guess that the application you are porting puts more than one
widget in the viewport so it probabl already has a suitable "toplevel"container (most likely either a VBox or a HBox) that you can pack intothe appview instead of the viewport.--Kalle Vahlman, 
[EMAIL PROTECTED]Powered by http://movial.fiInteresting stuff at http://syslog.movial.fi
Kalle,again, thanks, now it really works!Luca Donaggio
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Wavemon or other monitoring application for WLAN

[Kalle Valo]

"ext Dirk Kuijsten" <[EMAIL PROTECTED]> writes:

> Other topic: I noticed the connection manager will configure an autoconf
> IP address (APIPA 169.254.x.x) very fast. When connecting to access points
> with a moderate signal strength the 770 sometimes doesn't get an IP
> address. But it will not retry to get a good IP address via DHCP. But the
> connection manager and iwconfig show the client is connected to the AP,
> thus should be able to do networking.
> Maybe this is just a problem with those AP's and could be solved, so I
> will test this again later, because DHCP always works for my home AP. If
> not, my suspicion goes to a possible timeout used with the DHCP client.

The DHCP client asks for address from a DHCP server four times before
it sets an IPv4 link-local address. And after that it will try once a
minute to get an address from a DHCP server. If that's not happening,
something is wrong and you should file a bug to bugzilla. Which AP
were you using?

-- 
Kalle Valo

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Maemo Alarm/Notifier Interface

[Nils Faerber]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Igor Stoppa schrieb:
> On Fri, 2006-01-13 at 16:11 +0100, ext Nils Faerber wrote:
> Igor Stoppa schrieb:
>> [snip]
>>Obviously they have different wakeup latencies but all of them are
>>insignificant, when compared to the delay that would be introduced by a
>>traditional suspend-to-disk, which is the closer state to the "poweroff"
>>that youu are mentioning. 
> Well, power-off is something like shutdown in the first place, not
> necessarily connected to suspend to disk - you could simply reboot the
> device loosing your state.
>> That's not really desired in a consumer device.

I just meant the runtime-state, i.e. all running applications will
simply be closed. All data will of course be preserved.

> But as someone ales already pointed out I would also accept and even
> expect that a device that is switched off (770 power button -> switch
> off) will indeed keep being switched off despite of any occuring alarms.
> The user should know what he does when switching off his/her device. So
> I think we can basically ignore the power off problem and concentrate on
> the other above mentioned power/sleep states.
>> Again, we are talking about something that is actually meant to be sold,
>> so it has to behave nicely. Personally I like to have my alarms to be
>> fire & forget. What's the point of setting an alarm if I have to
>> remember to take care of the thing that should remind me of it?
> 
>> Even if we can achieve roughly 10 days of standby time, that's not much
>> compared to the power saving that can be achieved by effectively
>> switching off the device over very long periods of inactivity.
>> That would be compromised by such an approach of delivering alarms only
>> when the device is on.

Well, judging from the rest of the software of the 770 I do not see the
off case as a regular use case. It is to me more something like a state
to safe the battery from 100% depletion.

>> These small details make the difference between a "device for hackers
>> only" and a device that can leverage the benefits of running linux and
>> yet provide a good user experience even to the regular users.

Well, comparing with today's other PDA like devices this behaviour seems
pretty normal for me - a switched off PocketPC will be off, no matter
what (even worse, some of them cannot be switched of at all in the first
place causing their batteries to be drained 100% whan not taken care of!
This is very bad with devices with fixed built in batteries which is why
I guess that Nokia implemented the Switch-Off). I also guess that most
Palms and alike behave the same - off is off. Only exception from that
rule I know of are (some) mobile phones.

I see that it would be a nice feature but I also see that it is too much
hassle to implement. Please observe that not only the switch-on from
power-off case is a problem but also how to handle the reverse
direction. After having half booted the machine to signal the alarm you
would have to automatically shut it down again.
Then think about plane rides - say the offline mode is not activated,
i.e. the wireless modules have been on at shut-down time. Now you travel
in a plane and an alarm goes off in your pocket, bootig the device up.
Shall the radio be activated according to last saved state or should it
be switched off? What about user experience here? Last time the user
shut the device off the radio was on but now it is shut off? Why?

No, sorry, I still see the switch-off case as far too problematic to
deal with, at least at this point. Since 90% of the system has to be
booted again to signal an alarm (GUI + DSP sound) it will cause a lot of
hassle to get this right. The resume from suspend will be good enough as
a start and can, if someone really wants to, be extended to wake from off.

> That is just a bit in some regsiter - a very trivial kernel
> modification. The more problem would be to write an OMAP RTC compatible
> driver for the 1710 (if not yet existent, which it IMHO is not) since
> there is not documentation for the 1710 publically available.
>> I checked it some time ago for a basic wakeup functionality and apart
>> for a few changes that functionality was already provided.

Oh, great!
Though the typical /proc/drivers/rtc is missing on the 770 so I guess
that this 1710 RTC driver does not exist in the 770 kernel (build) yet.

Cheers
  nils faerber

- --
kernel concepts  Tel: +49-271-771091-12
Dreisbachstr. 24 Fax: +49-271-771091-19
D-57250 Netphen  Mob: +49-176-21024535
- --
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDy55vJXeIURG1qHgRAgzzAJ9eqOn/GIPbqHUKekD8vyve/cmPaACeNKTl
ugKTtw571ApbvGFg8Jw0EQw=
=R+Ho
-END PGP SIGNATURE-
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Wavemon or other monitoring application for WLAN

[Kalle Valo]

"ext Johannes Eickhold" <[EMAIL PROTECTED]> writes:

> *think out loud* something like the options in
> debians /etc/network/interfaces stanzas should be used. Like "post-up
> [command]". But there are no config files there on the 770 for interface
> configuration. Events (dbus messages) are way cooler (modern), but are
> they the easiest way to go for such things?

Actually we have been thinking about something similar, there is
definitely a need for that. Most likely we will implement a directory
where all applications can install scripts and which will be executed
when connected to a network.

-- 
Kalle Valo

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Maemo Alarm/Notifier Interface

[Frederic Crozat]

Le lundi 16 janvier 2006 à 14:24 +0100, Nils Faerber a écrit :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Igor Stoppa schrieb:
>
> >> These small details make the difference between a "device for hackers
> >> only" and a device that can leverage the benefits of running linux and
> >> yet provide a good user experience even to the regular users.
> 
> Well, comparing with today's other PDA like devices this behaviour seems
> pretty normal for me - a switched off PocketPC will be off, no matter
> what (even worse, some of them cannot be switched of at all in the first
> place causing their batteries to be drained 100% whan not taken care of!
> This is very bad with devices with fixed built in batteries which is why
> I guess that Nokia implemented the Switch-Off). I also guess that most
> Palms and alike behave the same - off is off. Only exception from that
> rule I know of are (some) mobile phones.

No, all PalmOS PDA (I'm not sure about smartphones based on PalmOS)
can't be turned off. They are always in standby mode and are always able
to wake up for alarms.

-- 
Frederic Crozat <[EMAIL PROTECTED]>

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] swapfile is a huge improvement!

[Juha Yrjölä]

On Mon, 2006-01-16 at 13:55 +0200, ext Urho Konttori wrote:

> This is just a suggestion, but could the following be safe enough for
> consumer grade swap use on Nokia 770:
> 
> If user has swapon. User opens MMC door. System pops up a large RED
> GUI that states: You have swap active. Please turn off swap before
> removing MMC from the slot. GUI would have one large button (turn off
> swap). After swapoff, GUI would turn green and say, it's safe to
> detach MMC now.

We really can't rely on the user nicely waiting for any kind of
permission from our UI.  There _will_ be cases when the MMC is abruptly
removed.  It is unacceptable for an end-user device to go down in flames
whenever this happens.

The issues regarding what happens when a swap device disappears from
underneath have to fixed first.

Cheers,
Juha


___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] swapfile is a huge improvement!

[Frantisek Dufka]

Well it is solvable but hard. You could halt everything and display 
something like 'Poor human, give me my card back or I will reboot'. But 
this has to be done in low level (kernel thread?, direct framebuffer 
access?) because anything in userspace can segfault when swap is removed.


I know similar things worked on Amiga. You removed floppy when writing 
and it opened a dialog 'error writing sector x, please insert disk' and 
when you gave it back it worked and continued. Or when the disk was full 
in the middle of writing of one file you could let the dialog be, delete 
other files and click continue and it worked. Never seen this type of 
recovery later on any newer system :-)


Frantisek

Juha Yrjölä wrote:


We really can't rely on the user nicely waiting for any kind of
permission from our UI.  There _will_ be cases when the MMC is abruptly
removed.  It is unacceptable for an end-user device to go down in flames
whenever this happens.

The issues regarding what happens when a swap device disappears from
underneath have to fixed first.

Cheers,
Juha


___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers


___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Maemo Alarm/Notifier Interface

[Frantisek Dufka]

Nils Faerber wrote:

 I also guess that most
Palms and alike behave the same - off is off. Only exception from that
rule I know of are (some) mobile phones.


No in PalmOS off is not off. On Tungsten T2 you can set it to be waked 
up by initiating bluetooth connection with it when it is 'off'. You can 
also schedule alarm procedure which gets executed and the display is 
even not waked up if you wish. Unlike with N770 you really can't 
shutdown PalmOS and battery is not removable in most units so there is 
not this type of problem there. Solution for N770 would be to remove the 
poweroff item to make it behave like PalmOS and maybe also implement 
suspend in kernel which pauses all tasks and powers off unneeded 
hardware. But the current system is also good, just don't let users 
shutdown the device so easily.


Frantisek
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

[maemo-developers] Developer Device Program

[radu]

Hello,
I'm interested in developing applications for Maemo Platform. Although I 
know about Maemo for quite some time now, I've just recently heard about 
the Developer Device Program from a friend that is already part of the 
program. Since I haven't been involved yet in any open source projects, 
I want to know what are my chances of getting a device. I am considering 
buying one, but I can't afford to buy it from Romania since it's much 
more expensive.


I'm using Linux since 2003. I'm mainly interested in gtk, Mono Platform 
and gtk#. Currently I'm working on a personal project which makes use of 
gtk# ant other Mono libraries.


Currently I am student of "Gh. Asachi" Technical University of Iasi, 
Faculty of Automatic Control and Computers, Romania.


I apologize if this was the wrong place to ask this kind of questions.

Radu
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

[maemo-developers] g_signal_connect and "show" signal not working in hildon applications (Maemo 1.1)?

[Luca Donaggio]

It seems that the following doesn't work:[code]g_signal_connect (G_OBJECT (main), "show",    G_CALLBACK (on_main_create),    NULL);[/end code]
where main is a HildonAppView object. Basically it should execute on_create_main() for initial configuration stuff upon displaying the AppView. Printing of debugging messages to console shows that on_main_create() is never executed, maybe on Maemo the "show" signal is not defined / recognized / fired up when showing a widget (I've tried with other widget than an HildonAppView too, withaout any result so far) ?
Luca Donaggio
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Maemo Alarm/Notifier Interface

[Weinehall David (Nokia-M/Tampere)]

On mån, 2006-01-16 at 15:58 +0100, ext Frantisek Dufka wrote:
> Nils Faerber wrote:
> >  I also guess that most
> > Palms and alike behave the same - off is off. Only exception from that
> > rule I know of are (some) mobile phones.
> 
> No in PalmOS off is not off. On Tungsten T2 you can set it to be waked 
> up by initiating bluetooth connection with it when it is 'off'. You can 
> also schedule alarm procedure which gets executed and the display is 
> even not waked up if you wish. Unlike with N770 you really can't 
> shutdown PalmOS and battery is not removable in most units so there is 
> not this type of problem there. Solution for N770 would be to remove the 
> poweroff item to make it behave like PalmOS and maybe also implement 
> suspend in kernel which pauses all tasks and powers off unneeded 
> hardware. But the current system is also good, just don't let users 
> shutdown the device so easily.

Why?!?

A mechanism for wake-up from power-off exists (yes, it's a bit sucky,
so we'll have to have a workaround for alarms >24h into the future,
but at least it's possible) -- check

Power management efficient enough to make suspend meaningless -- check

I cannot really understand why a lot of people here seem to want
crippled functionality just because other platforms have limitations.


Regards: David Weinehall
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Maemo Alarm/Notifier Interface

[Igor Stoppa]

On Mon, 2006-01-16 at 14:24 +0100, ext Nils Faerber wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Igor Stoppa schrieb:
> > On Fri, 2006-01-13 at 16:11 +0100, ext Nils Faerber wrote:
> > Igor Stoppa schrieb:
> >> [snip]
> >>Obviously they have different wakeup latencies but all of them are
> >>insignificant, when compared to the delay that would be introduced by a
> >>traditional suspend-to-disk, which is the closer state to the "poweroff"
> >>that youu are mentioning. 
> > Well, power-off is something like shutdown in the first place, not
> > necessarily connected to suspend to disk - you could simply reboot the
> > device loosing your state.
> >> That's not really desired in a consumer device.
> 
> I just meant the runtime-state, i.e. all running applications will
> simply be closed. All data will of course be preserved.
My point is that when it gets to usability, the 770 is as close as
possible to any other _Nokia_ consumer devices, i.e. phones, therefore
it has some of those harder constraints.

Of course Meamo is not the 770 but still these features are good, imho.
> 
> > But as someone ales already pointed out I would also accept and even
> > expect that a device that is switched off (770 power button -> switch
> > off) will indeed keep being switched off despite of any occuring alarms.
> > The user should know what he does when switching off his/her device. So
> > I think we can basically ignore the power off problem and concentrate on
> > the other above mentioned power/sleep states.
> >> Again, we are talking about something that is actually meant to be sold,
> >> so it has to behave nicely. Personally I like to have my alarms to be
> >> fire & forget. What's the point of setting an alarm if I have to
> >> remember to take care of the thing that should remind me of it?
> > 
> >> Even if we can achieve roughly 10 days of standby time, that's not much
> >> compared to the power saving that can be achieved by effectively
> >> switching off the device over very long periods of inactivity.
> >> That would be compromised by such an approach of delivering alarms only
> >> when the device is on.
> 
> Well, judging from the rest of the software of the 770 I do not see the
> off case as a regular use case. It is to me more something like a state
> to safe the battery from 100% depletion.
Which is indeed something one might want to do when recharging is not
going to be easy, like when traveling, hicking, you name it.
> 
> >> These small details make the difference between a "device for hackers
> >> only" and a device that can leverage the benefits of running linux and
> >> yet provide a good user experience even to the regular users.
> 
> Well, comparing with today's other PDA like devices this behaviour seems
> pretty normal for me - a switched off PocketPC will be off, no matter
> what (even worse, some of them cannot be switched of at all in the first
> place causing their batteries to be drained 100% whan not taken care of!
And is that good? ;-)

> This is very bad with devices with fixed built in batteries which is why
> I guess that Nokia implemented the Switch-Off). 
I don't get it: the battery is removable :-/
> I also guess that most
> Palms and alike behave the same - off is off. Only exception from that
> rule I know of are (some) mobile phones.
Nope. 
> 
> I see that it would be a nice feature but I also see that it is too much
> hassle to implement. Please observe that not only the switch-on from
> power-off case is a problem but also how to handle the reverse
> direction.
poweroff command works just fine

>  After having half booted the machine to signal the alarm you
> would have to automatically shut it down again.
so?

> Then think about plane rides - say the offline mode is not activated,
> i.e. the wireless modules have been on at shut-down time. Now you travel
> in a plane and an alarm goes off in your pocket, bootig the device up.
> Shall the radio be activated according to last saved state or should it
> be switched off? What about user experience here? Last time the user
> shut the device off the radio was on but now it is shut off? Why?
> 
We _don't_ turn on radio components by default. Your point doesn't
really exist. It's yet another complication coming from suspend.

Sleeping while idle avoids taking care of all these issues.

When I take a plane, I put my 770 in flight mode, so I make sure that it
won't try to connect to my phone because of something I might do, like
opening the filemanager. 
But even if it was coming up from OFF state because an alarm triggers,
it wouldn't certainly establish any connection at all, unless I'm the
cause. And then it would be _my_ fault for not selecting flight mode.

> No, sorry, I still see the switch-off case as far too problematic to
> deal with, at least at this point. 
As simple as adding yet another boot reason.

> Since 90% of the system has to be
> booted again to signal an alarm (GUI + DSP sound) it will cause a lot of
> ha

Re: [maemo-developers] Maemo Alarm/Notifier Interface

[Igor Stoppa]

On Mon, 2006-01-16 at 17:21 +0200, ext Weinehall David (Nokia-M/Tampere)
wrote:
> On mån, 2006-01-16 at 15:58 +0100, ext Frantisek Dufka wrote:
> > Nils Faerber wrote:
> > >  I also guess that most
> > > Palms and alike behave the same - off is off. Only exception from that
> > > rule I know of are (some) mobile phones.
> > 
> > No in PalmOS off is not off. On Tungsten T2 you can set it to be waked 
> > up by initiating bluetooth connection with it when it is 'off'. You can 
> > also schedule alarm procedure which gets executed and the display is 
> > even not waked up if you wish. Unlike with N770 you really can't 
> > shutdown PalmOS and battery is not removable in most units so there is 
> > not this type of problem there. Solution for N770 would be to remove the 
> > poweroff item to make it behave like PalmOS and maybe also implement 
> > suspend in kernel which pauses all tasks and powers off unneeded 
> > hardware. But the current system is also good, just don't let users 
> > shutdown the device so easily.
> 
> Why?!?
> 
> A mechanism for wake-up from power-off exists (yes, it's a bit sucky,
> so we'll have to have a workaround for alarms >24h into the future,
> but at least it's possible) -- check
> 
> Power management efficient enough to make suspend meaningless -- check
> 
> I cannot really understand why a lot of people here seem to want
> crippled functionality just because other platforms have limitations.

I understand that if we want to have a consistent crossdevice platform,
then it should be able to deal with other hw that doesn't have as many
power management features as Omap, but that is not really a good reason
to discard what we _do_ have.

Suspend is good compared to poweroff because it can retain the state of
the device and usually trim down startup/shutdown times, but it's
useless if the device actually manages to transparently and silently
save energy.

> 
> 
> Regards: David Weinehall
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://maemo.org/mailman/listinfo/maemo-developers
-- 
Igor Stoppa (Nokia M - OSSO / Tampere)
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

RE: [maemo-developers] Missing control panel

[Matti Reijonen]

Hello,

I decided to go other way and installed Ubuntu, I was previously using Red Hat,
now control panel and also everything else (I had also trouble with 
app-installer..)
seems to be working fine. It just seems that maemo sdk works much better 
with Ubuntu..

I dont know what was the problem,.. but
..anyway, thanks for your help.

  - Matti


At 11:04 12.1.2006, you wrote:

Hi,

next trick to try is to check that hildon-control-panel is installed. You 
can check this with:


   $ dpkg -l hildon-control-panel


The result should look something like (the version number may vary):



[sbox-SDK_PC: ~] > dpkg -l hildon-control-panel
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: 
uppercase=bad)

||/ Name   VersionDescription
+++-==-==-
ii  hildon-control 0.11.2 Hildon Control Panel



If the output you get states that it is installed (ii), try to 
re-installing the package with:


   $ fakeroot apt-get remove hildon-control-panel
   $ fakeroot apt-get install hildon-control-panel hildon-control-panel-dev

Regards,

- Pete -


-Original Message-
From: Matti Reijonen [mailto:[EMAIL PROTECTED]
Sent: Thu 1/12/2006 11:03 AM
To: Hagg Peter; maemo-developers@maemo.org
Subject: RE: [maemo-developers] Missing control panel


Hi,

I tried the rc7 upgrade, but it did not help,.. the control panel is still
missing.
also the 1200_Control_Panel.desktop does exist /etc/others-menu/

  - Matti


___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] swapfile is a huge improvement!

[Dave Neuer]

On 1/16/06, Juha Yrjölä <[EMAIL PROTECTED]> wrote:
> On Mon, 2006-01-16 at 13:55 +0200, ext Urho Konttori wrote:
>
> > This is just a suggestion, but could the following be safe enough for
> > consumer grade swap use on Nokia 770:
> >
> > If user has swapon. User opens MMC door. System pops up a large RED
> > GUI that states: You have swap active. Please turn off swap before
> > removing MMC from the slot. GUI would have one large button (turn off
> > swap). After swapoff, GUI would turn green and say, it's safe to
> > detach MMC now.
>
> We really can't rely on the user nicely waiting for any kind of
> permission from our UI.  There _will_ be cases when the MMC is abruptly
> removed.  It is unacceptable for an end-user device to go down in flames
> whenever this happens.

Well, if by end user device, you mean "something as simple as a
phone," certainly. However, all kinds of nasty things can happen to a
desktop PC if a user does something stupid, and still PCs are hugely
useful devices which a growing majority of even non-technically minded
people in the developed world own.

I understand that Nokia would probably like the appeal of the 770 to
be similar to the appeal of their phones; it does what you expect and
just works. But the fact is, the 770 isn't a phone. I know, it's not a
desktop PC, either.

But, where a developed market for the device doesn't exist, one has to
seriously ask the question whether simplicity and reliability are a
substitute for flexibility and openess to experimentation, with the
risk that the complexities inherent in a flexible,
not-as-intuitive-as-a-phone device will sometimes cause problems for
some users.

>
> The issues regarding what happens when a swap device disappears from
> underneath have to fixed first.

Is there a roadmap for solving that problem? Will it be solved on
LKML, or by Nokia in-house? Or will Nokia open up the device specs &
software more so developers can experiment with neat little tricks
when the door opens/cards are inserted, etc. so that anyone is able to
happily stumble upon the "right solution?"

I think Nokia has done a lot of things right w/ the 770, but I do have
to say that I think the idea that the 770 will be a huge consumer
success by being more "like a phone" than "like a computer" is wrong.
Most of the people I've showed the 770 to have been confused about
what it would be useful for. For me, it's useful precisely because
it's cool and more-or-less hackable, and I might find something really
great to do with it, not because it plays songs (iPods and even
cheaper devices lining the shelves at Best Buy play songs, and the
iPod has iTunes) or lets me check my mail or surf the web (I can do
that at work or at home) or listen to Internet radio (is there even
anything on internet radio I want to listen to?).

It's cool to me precisely because it's a computer but fits in my
pocket, and I can do almost anything with it that I can do with my
computer.

Sorry for wandering a bit from the particular topic (swap).

Dave
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Building Maemo from scratch

[Russell Geldmacher]

Hi Devesh,

For now I was starting with the OpenEmbedded build of Maemo, even
though it seems like only Maemo 1.0 is available in OE. It seems to me
that OE automates exactly what is needed to create a Maemo rootstrap.
Once that rootstrap is created, porting the necessary pacakges to a
new device should be straightforward: you modify the build under the
OE working directory, create a new ipkg and a patch, and apply those
changes to your recipe.

Which brings me to two questions:

1. Is Maemo going to be maintained in OE?
2. I've been working a little from the Maemo/OE document available at:
http://downloads.kernelconcepts.de/maemo-oe.txt -- is the author of
that document on this list, and available for me to ask some questions
to?

Thanks,
rusty

On 1/12/06, Devesh Kothari <[EMAIL PROTECTED]> wrote:
> ext Florian Boor wrote:
>
> >Helo,
> >
> >Russell Geldmacher wrote:
> >
> >
> >
> >>So, as I'd assume, there are package-specific patches for Maemo? These
> >>apply to the pristine tarballs I'm guessing? Where can one get these
> >>patches? (Is that a dumb question showing I know nothing about OE?)
> >>
> >>
> >
> >well... you have two sorts of patches:
> >The maemo source packages are Debian-style sources which sometimes contain
> >patches to be applied before building the source. In addition you sometimes 
> >need
> >patches to apply additional fixes to build the sources with OE. These patches
> >are managed in OE, but so far OE doesn't have a mechanism to handle the 
> >patches
> >included in the source package. Of course you can extract these patches and 
> >add
> >them to OE manually, but it makes maintainance of it much more complicated.
> >
> >
> >Greetings
> >
> >Florian
> >
> >
> >
> Wouldnt it be just easier to do it the debian way inside SB.
>
> 1. get the list of packages right so the dependencies are met.
> 2. If you need to modify or add some components then have them available
> in a different local repo [building, packaging and resolving their
> dependencies is a step that should be done seperately, possibly in
> another SB maemo rootstrap]
> 3. for nokia 770 add the magic packages from nokia binary distribution
>
> and you have your new rootfs for nokia 770.
>
> For other devices, to use maemo, you would have to provide device
> specific stuff. Or even better to get the reverse dependencies on what
> packages depend on packages provided by nokia, and approximate what in
> functionality they would mean for the different device, and have
> packages (dummy or providing similar functionality but for your device
> like device state management, battery management, input methods and VKB etc)
>
> Then comes the desktop part etc, which is hildon, remove all af-desktop
> related components from your build as hildon is  quite n770 800x480
> resolution tied. See what could be used from e.g GPE etc package them as
> debian [that could be quite a work]
>
> Also lot of device startup procedure would have to be streamlined
>
> would be quite lot of work but IMHO doable :) Just IN MY PERSONAL
> OPINION, it would great to see option of 2 toolkits (GPE , Hildon), a
> core base maemo platform + adaptation layers , and device specific
> layer, and common set of development tools and environment [SB etc, with
> different toolkits etc]
>
> Devesh
>
>
>
>
>
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Building Maemo from scratch

[Florian Boor]

Hi,

Russell Geldmacher wrote:
> 1. Is Maemo going to be maintained in OE?

lets say i hope so. I started to do some work into this direction, but my free
time is a little bit limited at the moment. What we currently suffer from is the
problem that OE doesn't have a mechanism to build the packages from the original
sources directly without adding all the included patches to OE manually. I
started to code such a bitbake class, but like mentioned before it takes some
time. Having such a tool it becomes much easier maintaining the packages in OE.

> 2. I've been working a little from the Maemo/OE document available at:
> http://downloads.kernelconcepts.de/maemo-oe.txt -- is the author of
> that document on this list, and available for me to ask some questions
> to?

Oh... that document is missing a name. I wrote that, and of course i'll try to
answer questions as good and fast as possible. :-)

Greetings

Florian

-- 
The dream of yesterday  Florian Boor
is the hope of todayTel: 0271-771091-14
and the reality of tomorrow.Fax: 0271-771091-19
[Robert Hutchings Goddard, 1904][EMAIL PROTECTED]

6C 44 30 4C 43 20 6B 61  16 07 0F AA E6 97 70 A8
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Maemo Alarm/Notifier Interface

[Dave Neuer]

On 1/16/06, Igor Stoppa <[EMAIL PROTECTED]> wrote:
>
> That's not really desired in a consumer device.

I can see I'm going to run a risk here of alienating myself early from
the Nokia employees on the list, as I keep coming to this same point
when reading a lot of the posts here, and think it still remains an
open question (hopefully my comments will be received in the
enthusiastic and constructive light with which they're intended):

Is the 770 a consumer device? I mean _right_now_, is it a hit w/
consumers? How many "internet appliances" have made it in the
marketplace? Larry Ellison would be a rich man if that whole paradigm
were as valuable to consumers as tech pundits think ;-)

>
> These small details make the difference between a "device for hackers
> only" and a device that can leverage the benefits of running linux and
> yet provide a good user experience even to the regular users.

Well, 10 years ago, PC's running linux were "device[s] for hackers
only." Now companies run parellel virtualized Linux instances on
massive big iron systems to run their businesses. Did we get to that
point because IBM massively invested early in making the
Linux-on-server user experience good?

It was possible in the firstplace to leverage the benefits of Linux
because it spent a decade as a _totally_ open platform for
experimentation. Those areas where it lagged, it often lagged
precisely because of the closed nature of some piece or other or
hardwre (think winmodems, think graphics, think  wireless).

If making a device for hackers isn't the "leverage" that attaches to
running linux, what is (besides low cost and OS vendor lock-in)?

I'm really interested in the answer of both Nokia people and other
developers to this question, but since I've brought it up more than
once on this list OT, I'll shut up about it now except to ask, is
anyone else interested in having the conversation, and if so, where?

Dave
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Maemo Alarm/Notifier Interface

[Dave Neuer]

On 1/16/06, Igor Stoppa <[EMAIL PROTECTED]> wrote:
> On Mon, 2006-01-16 at 17:21 +0200, ext Weinehall David (Nokia-M/Tampere)
> wrote:
> >
> > A mechanism for wake-up from power-off exists (yes, it's a bit sucky,
> > so we'll have to have a workaround for alarms >24h into the future,
> > but at least it's possible) -- check
> >
> > Power management efficient enough to make suspend meaningless -- check
> >
> > I cannot really understand why a lot of people here seem to want
> > crippled functionality just because other platforms have limitations.
>
> I understand that if we want to have a consistent crossdevice platform,
> then it should be able to deal with other hw that doesn't have as many
> power management features as Omap, but that is not really a good reason
> to discard what we _do_ have.
>
> Suspend is good compared to poweroff because it can retain the state of
> the device and usually trim down startup/shutdown times, but it's
> useless if the device actually manages to transparently and silently
> save energy.

I agree. There is the issue of API -- that is where cross-platform
comes in. Designing a good API for this IMO would take the ALSA
approach; the API should have sane defaults and the library sane
default configurations to make simpler hardware work w/ minimal
effort, but don't dumb down the interface or implementation to the
point where more advanced hardware can't be fully exploited.

Dave
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] modifying root filesystem

[Dave Neuer]

On 1/16/06, Devesh Kothari <[EMAIL PROTECTED]> wrote:
> ext Lorn Potter wrote:
>
> >I tried the instructions and scripts for modifying the root filesystem,
> >http://maemo.org/platform/docs/howtos/howto_use_flasher_rootfs.html
> >
> >It seems the rootfs.packages and sources.list are out of date, or there are a
> >few packages missing (hildon-status-bar-display).



> make sure you dont miss this step below
>
> The reference root filesystem includes some binary modules that can be
> downloaded separately. These packages are not necessary, you may create
> a root filesystem without them, but some functionality will be missing.
> To download these packages, please follow this link
> .
>
> http://maemo.org/downloads/d2.php
>
> If you have successfuly downloaded those packages, then create a
> workarounds/ directory under your rootfs working directory and copy the
> binary packages there.

I tried this part too, but I think that part of the instructions seem
a little confusing or misleading; without the binary-only packages,
the make_rootimage.sh command fails when dpkg hits the missing
dependancies (and what's even worse, it seems to delete everything
under the actual contents of the rootfs from the rootstrap image).

Dave
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] swapfile is a huge improvement!

[Juha Yrjölä]

On Mon, 2006-01-16 at 11:12 -0500, Dave Neuer wrote:

> But, where a developed market for the device doesn't exist, one has to
> seriously ask the question whether simplicity and reliability are a
> substitute for flexibility and openess to experimentation, with the
> risk that the complexities inherent in a flexible,
> not-as-intuitive-as-a-phone device will sometimes cause problems for
> some users.

We're not going to start limiting anyone's experimentation.  Maemo is a
very open platform and experimentation with it rather easy.

The users can make their devices as complex they want (and possibly as
unstable).  We're responsible of keeping the software _we_ ship stable.

> > The issues regarding what happens when a swap device disappears from
> > underneath have to fixed first.
> 
> Is there a roadmap for solving that problem? Will it be solved on
> LKML, or by Nokia in-house? Or will Nokia open up the device specs &
> software more so developers can experiment with neat little tricks
> when the door opens/cards are inserted, etc. so that anyone is able to
> happily stumble upon the "right solution?"

_More_?  What on earth could you still want?  We use standard kernel
interfaces as much as possible, and the kernel source is freely
available.  Even loading and booting a custom kernel is extremely
simple:

# flasher -k /path/to/zImage -lb

User-space will get notifications about the MMC events through the
standard uevent interface.

As for where this problem might be solved, LKML is definitely the right
place.  I'm not yet personally convinced on the merits of having swap on
MMC, but anyone who is can of course start the thread.

> It's cool to me precisely because it's a computer but fits in my
> pocket, and I can do almost anything with it that I can do with my
> computer.

It's cool to me precisely for the same reason.  But, as you probably
realize, different people value different things.

Cheers,
Juha


___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] swapfile is a huge improvement!

[Kalle Vahlman]

On 1/16/06, Dave Neuer <[EMAIL PROTECTED]> wrote:
> I think Nokia has done a lot of things right w/ the 770, but I do have
> to say that I think the idea that the 770 will be a huge consumer
> success by being more "like a phone" than "like a computer" is wrong.

Yeah, the huge consumer success they prepared for by manufacturing a
big batch of devices straight off so everyone would get theirs. Oh,
wait! ;)

> Most of the people I've showed the 770 to have been confused about
> what it would be useful for.

Judging from the LugRadio interview while back, the guys just hacked
around and it suddenly became the 770. So I'm not so sure even Nokia
has a clear goal for the device (apart from the obvious web
applications) but are instead hoping it would find one with the help
of open source community. And I've already heard dozens of interesting
ideas how it could be utilized, so it's probably working :)

(Obligatory disclaimer: this is a personal view and not connected in
any way to the company mentioned below)

--
Kalle Vahlman, [EMAIL PROTECTED]
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] swapfile is a huge improvement!

[Brad Midgley]

Urho

> If user has swapon. User opens MMC door. System pops up a large RED GUI
> that states: You have swap active. Please turn off swap before removing
> MMC from the slot. GUI would have one large button (turn off swap).
> After swapoff, GUI would turn green and say, it's safe to detach MMC now.

if a user opens the door, you must assume they are going to eject the
card. this is what nokia does with the fat partition. you should pop up
your gui and make a beep and run swapoff. the message should say 'do not
eject the card yet'

i believe it's possible for swapoff to fail if memory is overcommitted,
so you have another case to worry about. the device should tell you
you'll have to close apps or turn off the nokia first and possibly give
you buttons to do that.

> On USB cable insertion, the same GUI would popup and tell user that MMC
> cannot be mounted on PC until swap is off. Again, nice large button to
> turn swap off.

why bother the user? we should be using a swap partition--not a swapfile
on the fat fs--right? every usb-host OS will leave the swap partition
alone by default.

> When MMC inserted back from either USB connection or physically, system
> would check if previous state was swapon and popup a gui asking if swap
> should be resumed.

i would make the swapon automatic whenever a swap partition is found on
rsmmc, but then it could be a 'remember this decision' checkbox on your gui.

brad
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] modifying root filesystem

[Lorn Potter]

On Monday 16 January 2006 19:04, Devesh Kothari wrote:
>
> make sure you dont miss this step below
>
> The reference root filesystem includes some binary modules that can be
> downloaded separately. These packages are not necessary, you may create
> a root filesystem without them, but some functionality will be missing.
> To download these packages, please follow this link
> .
>
> http://maemo.org/downloads/d2.php
>
> If you have successfuly downloaded those packages, then create a
> workarounds/ directory under your rootfs working directory and copy the
> binary packages there.

yep. Did this too. Got through the rootfs creation. Failed without it, 
although the web page makes it seem like its optional.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

[maemo-developers] swapfile is a huge improvement!

[Dave Neuer]

On 1/16/06, Juha Yrjölä <[EMAIL PROTECTED]> wrote:
> On Mon, 2006-01-16 at 11:12 -0500, Dave Neuer wrote:
>
> The users can make their devices as complex they want (and possibly as
> unstable).  We're responsible of keeping the software _we_ ship stable.

That's completely reasonable, and I'd expect the same from every
computer vendor or Linux distributor (w/ the intro of the 770, Nokia
has become both).

>
> > > The issues regarding what happens when a swap device disappears from
> > > underneath have to fixed first.
> >
> > Is there a roadmap for solving that problem? Will it be solved on
> > LKML, or by Nokia in-house? Or will Nokia open up the device specs &
> > software more so developers can experiment with neat little tricks
> > when the door opens/cards are inserted, etc. so that anyone is able to
> > happily stumble upon the "right solution?"
>
> _More_?  What on earth could you still want?

Source, or comprehensive docs for the flasher tool? An explanation of
what each of the FIASCO image compenents is and does? A list of any
proprietary kernel modules (which may or may not be legal) and a
description of what they do/why they're neccessary? A list of same for
non-kernel software modules in the initfs and rootfs images? Waiver
from Nokia of the prohibition against me reverse-engineering their
non-OSS software?

>
> # flasher -k /path/to/zImage -lb

Will this work if I use the latest OMAP 2.6.15 from Linus' git repo?
What about ensuring that the kernel is compatible w/ the initfs?

>
> User-space will get notifications about the MMC events through the
> standard uevent interface.

Does this include the "door is open/closed" information? Where is that
documented?

>
> As for where this problem might be solved, LKML is definitely the right
> place.  I'm not yet personally convinced on the merits of having swap on
> MMC, but anyone who is can of course start the thread.
>
> > It's cool to me precisely because it's a computer but fits in my
> > pocket, and I can do almost anything with it that I can do with my
> > computer.
>
> It's cool to me precisely for the same reason.  But, as you probably
> realize, different people value different things.

I do realize that, and like I said, I think Nokia have released a very
cool device. I sincerely hope it takes off. The size and orientation
of the screen, user-replaceable, (somewhat) standard battery and the
built-in expansion slot are huge improvements over previous entries
into this "computer in your hand" product category.

I'm simply saying that absent much of the inrormation in my response
to your question "what more," the ability of developers (at least this
one) to feel comfortable experimenting with the device is less than
than it could be.

E.g., I asked for pointers to info like the above before (even just a
description of the FIASCO components and info like size constraints),
and the only answer I got was someone I believe was not a Nokia
employee and which said "search the mail archives" and had a pointer
to the flasher-tool howto.

>
> Cheers,
> Juha

Likewise,
Dave
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] swapfile is a huge improvement!

[Israel Herraiz]

Dave Neuer wrote:
> Does this include the "door is open/closed" information? Where is that
> documented?

In the latest firmware, there are scripts which are executed when those
events occurr. Take a look at /usr/sbin/osso-{mmc-mount, mmc-umount,
cover-open,cover-closed,usb-cable-attached,usb-cable-dettached,etc}.sh

Well, maybe it is not the paradise of documentation, but at least from
the names you can figure out how to execute something when such events
occur ;-).

Regards,
Israel Herraiz


signature.asc
Description: OpenPGP digital signature
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] swapfile is a huge improvement!

[Dave Neuer]

On 1/16/06, Dave Neuer <[EMAIL PROTECTED]> wrote:
>
> E.g., I asked for pointers to info like the above before (even just a
> description of the FIASCO components and info like size constraints),
> and the only answer I got was someone I believe was not a Nokia
> employee and which said "search the mail archives" and had a pointer
> to the flasher-tool howto.

My apologies to Devesh, who upon review appears to be a Nokia employee
and whose answer (also upon review) was a little more informative and
helpful than I recalled.

Also thanks to Israel for his follow-up to this thread.

Dave
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Maemo Alarm/Notifier Interface

[Frantisek Dufka]

Weinehall David (Nokia-M/Tampere) wrote:


No in PalmOS off is not off. On Tungsten T2 you can set it to be waked 
up by initiating bluetooth connection with it when it is 'off'. You can 
also schedule alarm procedure which gets executed and the display is 
even not waked up if you wish. Unlike with N770 you really can't 
shutdown PalmOS and battery is not removable in most units so there is 
not this type of problem there. Solution for N770 would be to remove the 
poweroff item to make it behave like PalmOS and maybe also implement 
suspend in kernel which pauses all tasks and powers off unneeded 
hardware. But the current system is also good, just don't let users 
shutdown the device so easily.



Why?!?


Why not let users shutdown easily? Because you keep the state and don't
need to boot the device through tons of /etc/rcx.D/* (and do it in 
advance without user noticing anything) to handle single alarm and then 
shutdown it again. Because with proper suspend (or should it be called 
standby?) instead of poweroff you may save enough battery to have it 
look like real poweroff without any ill effects. Because this is a PDA 
or 'Internet Tablet' not unix server that can take minutes to boot or 
shutdown and noone cares because you do it once per several years.


Current 'Switch off!' mode should be something people should do only 
when the want to put the device to drawer for months and want the 
battery charged (which you could do by removing battery anyway). On ipaq 
you have very awkward key combo for this mode buried deep in manual on 
page noone reads. Not directly in menu on device. And yes in this mode 
alarms are not supposed to wake up the device :-)




Power management efficient enough to make suspend meaningless 


If the suspend is taken as replacement of poweroff the reason is here 
because it should pause the device in the midle of playing video or 
sound. Take it as the current 'Lock touchscreen and keys' plus pausing 
sound and network plus anything that takes power or keeps state that is 
useless after couple of minutes.


Maybe suspending tasks is not needed after all just send them different 
signal so they know device will be paused for many minutes and may wake 
up in different environment so they should really finish/stop what they 
do. So it is probably about more device modes than current offline or 
flight mode (are they same?) and normal.



I cannot really understand why a lot of people here seem to want
crippled functionality just because other platforms have limitations.


Instant poweron and proper pausing of everything when you press one 
button is not crippled functionality but very simple and neat thing Palm 
devices do and people expect.


Regards,
Frantisek
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] g_signal_connect and "show" signal not working in hildon applications (Maemo 1.1)?

[Lassi Syrjälä]

Luca Donaggio kirjoitti 16.1.2006 kello 17.09:


It seems that the following doesn't work:

[code]

g_signal_connect (G_OBJECT (main), "show",
G_CALLBACK (on_main_create),
NULL);


[/end code]


Hi,

I'd assume it works, but only if you connect the handler before  
showing the widget. "Show" is anyway not the most useful of signals,  
since it's synchronously and only ever emitted when you  
gtk_widget_show (main). In this case, it probably gains you nothing,  
since you could as well write:


gtk_widget_show (main);
on_main_create (main, NULL);

Instead, you could try something like:

g_signal_connect_after (main, "map", G_CALLBACK (on_main_create), NULL);

If that does not do the trick, adding a low priority idle function  
with a return value of FALSE might help.


BR,
Lassi

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

RE: [maemo-developers] Maemo Alarm/Notifier Interface

[Jason Mills]

On 2006-01-16, Dave Neuer wrote:
> 
> On 2006-01-16, Igor Stoppa wrote:
> > 
> > On Mon, 2006-01-16 at 17:21 +0200, ext David Weinehall wrote:
> > >
> > > A mechanism for wake-up from power-off exists (yes, it's a bit sucky,
> > > so we'll have to have a workaround for alarms >24h into the future,
> > > but at least it's possible) -- check
> > >
> > > Power management efficient enough to make suspend meaningless -- check
> > >
> > > I cannot really understand why a lot of people here seem to want
> > > crippled functionality just because other platforms have limitations.
> >
> > I understand that if we want to have a consistent crossdevice platform,
> > then it should be able to deal with other HW that doesn't have as many
> > power management features as OMAP, but that is not really a good reason
> > to discard what we _do_ have.
> >
> > Suspend is good compared to poweroff because it can retain the state of
> > the device and usually trim down startup/shutdown times, but it's
> > useless if the device actually manages to transparently and silently
> > save energy.
> 
> I agree. There is the issue of API -- that is where cross-platform
> comes in. Designing a good API for this IMO would take the ALSA
> approach; the API should have sane defaults and the library sane
> default configurations to make simpler hardware work w/ minimal
> effort, but don't dumb down the interface or implementation to the
> point where more advanced hardware can't be fully exploited.
> 
> Dave


The overall Maemo / Hildon interface specification is still young enough that
one could do it right, the first time.

Based on how that specific piece of hardware behaves, one can map an
arbitrary location in N-space (based on _end user_ interface responses) to a
specific set of actual hardware settings, without having to expose the actual
hardware at the _application_ or _end user_ layers.


For example:

A Control Panel widget which has the following sliders (some are binary
sliders, mind you)...

Optimize CPU for:
Performance .^.. Per-Charge Run-Time
(Enables / disables DynTick, for example)

Deliver Alarms:
   As Scheduled ^... At Subsequent Wake-Up
   (Enables / disables wake-on-alarm, for example)

Optimize System Suspend for:
  Fast Wake ..^. Power Efficiency
  (Enables suspend-to-ram vs suspend-to-disk)

...etc...


Anyhow, the point is that if you ask questions which are logical from an end
user's perspective, they can be mapped to most any hardware back-end. Geeks
could always tweak the values of the sliders directly via GConf, causing the
UI to reflect new slider locations.

-JMills

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Sketch like pointer movement detection

[Celso Pinto]

Hello,

thanks for your helpful pointers but I have one doubt: if I invoke
gdk_event_get() in my motion event callback, is it positive that all
next events are going to be motion events? 

If those events aren't motion events, I'd be able to skip them but
wouldn't I lose the skipped events?

Furthermore, if I ask for the next event by calling gdk_event_get(),
will my pointer motion callback be invoked later for the returned event?

Thanks once again. 

Regards,
Celso



On Sat, 2006-01-14 at 14:55 +0100, Øyvind Kolås wrote:
> On 1/14/06, Celso Pinto <[EMAIL PROTECTED]> wrote:
> > Hi everyone,
> >
> > I'm developing a small app just for kicks and I want to have a drawing
> > area similar to Sketch. I've followed the GTK tutorial, the Scribble
> > example part, on how to detect mouse movement and translate that to a
> > drawing.
> >
> > The thing is that compared to Scribble, Sketch is really slick because
> > Scribble fails a lot of movements,probably because drawing to the screen
> > is expensive, because the pixels only get drawn on screen with big
> > intervals.
> >
> > I was just wondering if it is possible to improve pointer motion by
> > having some other masks besides GDK_POINTER_MOTION_MASK? I've removed
> > the GDK_POINTER_MOTION_MASK_HINT but it hasn't improved the drawing.
> >
> > I want to improve on Scribble, so I'm already thinking about
> > alternatives like queuing all motion events and have a separate thread
> > doing the drawing bits if that is the only way to have slick motion
> > detection.
> 
> The best way of doing such things in my experience is:
> 
> 1: collect all motion events until the queue is empty
> 2: draw strokes/update screeen
> 
> No seperate thread should be needed since the xserver/gdk will have
> their own queues of events. Using event collapsing might not be what
> you want either, but you should strive towards minimizing the amount
> of work needed at each redraw.
> 
> My attempt at drawing doesn't use gtk/gdk, but xevents directly, since
> I also have added the option of using information about the amount of
> pressure.
> 
> The drawing application I am working on
> http://pippin.gimp.org/horizon/ is still not ready for prime time,
> thus it only exist in the work in process portion of the application
> catalog.
> 
> /Øyvind K.
> --
> «The future is already here. It's just not very evenly distributed»
>  -- William Gibson
> http://pippin.gimp.org/http://ffii.org/
> 

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

[maemo-developers] Bluetooth keyboard update

[Tomas Junnonen]

Hi,A new version of the Bluetooth keyboard plugin is available from http://770.fs-security.com/keyboards.htmlNew stuff:- You can search for keyboards and choose a specific one to connect to.
- You can pair the keyboard to the 770. Once paired, powering on the  keyboard will associate it with the 770 and you can simply start  typing away. Convenient!- You can choose a keyboard layout, currently I have a Scandinavian
  and a German layout bundled. Send me your layout if you want  it included (see the hacking section on the homepage).- Matthew's screen blanking fix is integrated (thanks!), but it doesn't  seem to work all the time, needs some looking into.
Regards,Tomas
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] Bluetooth keyboard update

[Simon Budig]

Tomas Junnonen ([EMAIL PROTECTED]) wrote:
> - You can search for keyboards and choose a specific one to connect to.
> - You can pair the keyboard to the 770. Once paired, powering on the
>   keyboard will associate it with the 770 and you can simply start
>   typing away. Convenient!

That rocks!

> - You can choose a keyboard layout, currently I have a Scandinavian
>   and a German layout bundled. Send me your layout if you want
>   it included (see the hacking section on the homepage).

That as well. I just wonder what crack the Notetaking application has
smoked to ignore the german umlauts. As you've noted on your homepage
they work in Opera and xterm, so it seems to be the fault of the
Hildonized GTK+ (they don't work in the GPE-PIM stuff either).

Thanks a lot!

Bye,
Simon
-- 
  [EMAIL PROTECTED]  http://simon.budig.de/
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] swapfile is a huge improvement!

[Andy]

On Sat, 2006-01-14 at 01:30 -0700, Brad Midgley wrote:
> hey
> 
> I decided to try the swap partition on my flash card and it made a HUGE
> difference. Even with only 25mb swap (30mb wouldn't work for me), now
> memory is not nearly the concern it was. I can run multiple apps, look
> at complex pdf documents, etc. Just like I expected my 770 to do in the
> first place!

What do you mean "30mb wouldn't work"?  I put a 32meg swapFILE on the
64meg mmc I received and it worked fine (/proc/meminfo and /proc/swaps
showed swap usage, and I could get numerous things running with out
problems.  Now I'm trying to partition a 512meg MMC into two partitions,
and neither 128meg nor 64meg of swap as a dedicated partition
(/dev/mmcblk0p2) works.  As soon as I issue swap on, the "low on memory,
close some applications" window pops up.  I can immediately exit the
shell, but if I wait too long, I start getting "sh: can't fork" (a usual
OOM sign).  If I can get back to the home interface, I can't do anything
and it keeps telling me "Not enough memory" or some such.  It did
hardcrash, auto-reboot at one point also (I assume an OOM condition).

Is there some upper limit on the size of the allowed swap file on this
arch?  I could get 32meg to work, but you say you couldn't get 30?

I swear I saw something about the max size of the swap file for the 770,
but I can't find it now.

-- 
Andy <[EMAIL PROTECTED]>

___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

RE: [maemo-developers] Missing control panel

[Peter.Hagg]

Hi, 

there are issues with QEMU on Red Hat. However, this should affect the ARM 
rootstrap only, so there was probably something else wrong with the 
environment. Out of curiousity: did you try to re-install the rootstrap? Also, 
make sure you run the right rootstrap inside the right Scratchbox target. 
Installing an i386 rootstrap on an ARM target is usually a bad idea, but 
possible ;-)

Tip of the day: Maemo development on Debian-based systems is highly recommended 
;-)

Regards, 

- Pete - 

-Original Message-
From: [EMAIL PROTECTED] on behalf of Matti Reijonen
Sent: Mon 1/16/2006 3:57 PM
To: Hagg Peter; maemo-developers@maemo.org
Subject: RE: [maemo-developers] Missing control panel
 
Hello,

I decided to go other way and installed Ubuntu, I was previously using Red Hat,
now control panel and also everything else (I had also trouble with 
app-installer..)
seems to be working fine. It just seems that maemo sdk works much better 
with Ubuntu..
I dont know what was the problem,.. but
..anyway, thanks for your help.

   - Matti
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] modifying root filesystem

[Lorn Potter]

On Monday 16 January 2006 19:04, Devesh Kothari wrote:
> ext Lorn Potter wrote:
> >I tried the instructions and scripts for modifying the root filesystem,
> >http://maemo.org/platform/docs/howtos/howto_use_flasher_rootfs.html
> >
> >It seems the rootfs.packages and sources.list are out of date, or there
> > are a few packages missing (hildon-status-bar-display).
> >
> >The make_rootimage.sh script seems a bit unfinished, as it's help lists
> >--outprefix and --jffs2 which do not work.
> >(looking at the script, it seems there are a few missplaced 'x'
> > characters, and variable not all caps)
> >
> >I manually tar.gz the resulting root filesystem (the web page doesn't
> > mention the need to do this part), and ran the tar2jffs2.sh, script,
> > flashed the device, but the device keeps rebooting..
> >___
> >maemo-developers mailing list
> >maemo-developers@maemo.org
> >https://maemo.org/mailman/listinfo/maemo-developers
>
> make sure you dont miss this step below
>
> The reference root filesystem includes some binary modules that can be
> downloaded separately. These packages are not necessary, you may create
> a root filesystem without them, but some functionality will be missing.
> To download these packages, please follow this link
> .
>
> http://maemo.org/downloads/d2.php
>
> If you have successfuly downloaded those packages, then create a
> workarounds/ directory under your rootfs working directory and copy the
> binary packages there.
>
>
> Devesh

Must be something missing in the scripts. I mounted and extracted the dev 
platform v1.1 rootfilesystem and used the mkfs.jffs2 and sumtool lines out of 
tar2jffs2.sh script to make an image... which didn't boot and acted like the 
other rootimages I tried to make (reboot over and over). The resulting file 
wasn't even the same size as the 'official'.

Must be some magic not in the scripts or documents.
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

Re: [maemo-developers] g_signal_connect and "show" signal not working in hildon applications (Maemo 1.1)?

[Luca Donaggio]

2006/1/16, Lassi Syrjälä <[EMAIL PROTECTED]>:
Luca Donaggio kirjoitti 16.1.2006 kello 17.09:> It seems that the following doesn't work:>> [code]>> g_signal_connect (G_OBJECT (main), "show",> G_CALLBACK (on_main_create),
> NULL);>>> [/end code]Hi,I'd assume it works, but only if you connect the handler beforeshowing the widget. "Show" is anyway not the most useful of signals,
since it's synchronously and only ever emitted when yougtk_widget_show (main). In this case, it probably gains you nothing,since you could as well write:gtk_widget_show (main);on_main_create (main, NULL);
Instead, you could try something like:g_signal_connect_after (main, "map", G_CALLBACK (on_main_create), NULL);If that does not do the trick, adding a low priority idle functionwith a return value of FALSE might help.
BR,LassiThanks a lot Lassi, g_signal_connect_after() works smoothly!Luca Donaggio
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers