Re: Howto revert a gtk_widget_tap_and_hold_setup
Kalle Vahlman wrote: 2007/4/17, Sergio Villar Senin [EMAIL PROTECTED]: Hi, is there any way to revert a gtk_widget_tap_and_hold_setup? I mean I have a widget that shows a popup as response to a tap and hold event. I want to change the contents of that popup menu in execution time. So I want to unregister the old one and setup a new one. If possible, I'd suggest carrying the existing menu pointer to the code that wants to change it and operate on that (it's just a container after all, adding/removing items is possible). Yeah, that was my second choice :-). But I wanted to know also, why gtk+ is not working as expected, because the tap_and_hold_setup method to attach the menu to the widget: http://maemo.org/lxr/source/gtk%2B/gtk/gtkwidget.c#8111 Furthermore, if the contents are not totally dynamic, a more convenient solution might be using UI Manager[1] to change the menu. It takes a bit more effort to set up than just adding menuitems to a menu, but once the initial work is done it is very flexible and simplifies code a lot. [1] http://live.gnome.org/GnomeLove/UIManagerTutorial Actually I use the ui manager a lot :), but the contents are in fact, totally dynamic. Br ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: No more 770 bug activity?
Quim: Maybe you could put on the roadmap an item to better define the relationship and goals for at least the Maemo platform, but preferrably a general goal for the IT200X as well. No need to put this in the roadmap since it is our current ToDo. I'm willing to complete this task by June 1st. Hopefully that day we will show a revised picture that makes sense for everybody, including all the pieces of the puzzle we are discussing these days, and the wider context. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Cross compiling under debian
Hi,
compiling my packages with Java-JNI-code (e.g. classpath) for maemo does
not work out of the box, because scratchbox does not have all the
required build tools (javac, javah, jar). My long-term goal would be to
use openembedded, but this will need much work, I think.
So, at the moment I cross compile from my x86 debian, which seems to
work fine except of the following problems with the debian packaging:
1. dh_strip -a (from x86) does not know, how to handle the arm binaries.
(I have disabled it with: DEB_BUILD_OPTIONS=nostrip)
2. dh_shlibdeps does not work, because the ldd (from the toolchain)
tries to use ld-linux.so.3 from my host instead from the rootstrap.
/home/asteban/maemo/toolchain/scratchbox/compilers/arm-linux-2006q3-27/arm-none-linux-gnueabi/libc/usr/bin/ldd:
line 166: /lib/ld-linux.so.3: No such file or directory
3. dpkg-architecture does not know 'arml'
It would be possible to hack a fix in the script, like the one in
scratchbox:
sub debian_arch_fix
{
local ($os, $cpu) = @_;
...
} elsif ($os-$cpu eq gnueabi-linux-arm) {
return armel;
...
}
The problem 2. is my biggest one. Any suggestions? Cleaner solutions?
My setup is as follows:
TOOLCHAIN=~/maemo/toolchain/scratchbox
ROOTSTRAP=~/maemo/toolchain/rootstrap
export
PATH=$TOOLCHAIN/compilers/arm-linux-2006q3-27/bin/:$TOOLCHAIN/compilers/arm-linux-2006q3-27/arm-none-linux-gnueabi/libc/usr/bin/:$PATH
export CC=`which arm-none-linux-gnueabi-gcc`
export LD=`which arm-none-linux-gnueabi-ld`
export AR=`which arm-none-linux-gnueabi-ar`
export PKG_CONFIG_PATH=$ROOTSTRAP/usr/lib/pkgconfig/
alias pkg-config='pkg-config --define-variable=prefix=$ROOTSTRAP/usr'
# no a nice soution
export DEB_BUILD_OPTIONS=nostrip
Then I simply run 'fakeroot dpkg-buildpackage -d'
Regards,
Sebastian
--
tarent Gesellschaft für Softwareentwicklung und IT-Beratung mbH
Heilsbachstr. 24, 53123 Bonn| Poststr. 4-5, 10178 Berlin
fon: +49(228) / 52675-0 | fon: +49(30) / 27594853
fax: +49(228) / 52675-25| fax: +49(30) / 78709617
durchwahl: +49(228) / 52675-17 | mobil: +49(171) / 7673249
Geschäftsführer:
Boris Esser, Elmar Geese, Thomas Müller-Ackermann
HRB AG Bonn 5168
Ust-ID: DE122264941
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
n800 - most libraries compiled witout -fPIC, intentional?
Hello, I tried prelink on latest N800 firmware and it looks like most libraries (gtk,dbus,SDL,..) are not compiled with -fPIC. I see Cannot prelink against non-PIC shared library error message for most libraries. Is this a bug or is there a reason? In previous version it was just libSDL, now it is almost everything. Is this some sort of optimization? It may not matter much when using the maemo-invoker but it may cause higher memory consumption and slower dynamic linking for normal cases. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: disabling pressure information (for x11vnc)
Hi, ext Mike Cowlishaw wrote: Hi, I am going to have to try this before the weekend -- x11vnc seems to be the only game in town for a demo of N800 apps to an audience using a projector. I'm happy for this to be a one-off 'turn off pressure information' as I never use that feature anyway (I tried it, but the screen got so mucky so fast...). Your instructions are a bit vague, however. When you say: If you want to disable pressure information usage, you need to run the device X server with XInput protocol/extension disabled. Just add -extension XInputExtension to the /etc/init.d/x-server file X server options and reboot the device. It's not clear where to add it. I would add it to the end of the ARGS= string, preceded by a space. Is that correct? Yes. You can test what Xserver thinks about it with: Xomap -mouse tslib -nozap -wr -nolisten tcp -extension XInputExtension If you use something else, you can see what kind of an error X server would give (at startup) if the X server argument is not correct. [Subsidiary question .. is there a way to use maemopad to edit files on the internal filesystem? Copying to an mmc card and editing there or on another machine sounds a bad idea for system files...] Applications are run under user user, so it cannot edit files that are not writable by user. - Eero Thanks! Mike -Original Message- ext Mike Cowlishaw wrote: I get the same problem as you with the x11vnc not responding to clicks on the docking/application bar. It's frustrating as heck because it was inversely so neat to even find a vnc server for this. It is definately an x11vnc issue as I tried 2 different VNC viewers, and if I maximize applications I can still register clicks in that area. I think the issue is that x11vnc uses the XTest protocol/extension to simulate the events at the device and XTest doesn't support pressure information. Pressure information is needed for detecting whether the device is used with fingers or stylus. If you want to disable pressure information usage, you need to run the device X server with XInput protocol/extension disabled. Just add -extension XInputExtension to the /etc/init.d/x-server file X server options and reboot the device. Note that if you make a mistake and X server doesn't start, your device could end up in a reboot loop. That sounds promising! Is there a 'safe' way to disable this (e.g., via an installable applet)? To disable X server extensions/protocols you need to start X server without them. Only way X server provides for this is the command line options (in the kdrive build configuration, with the Linux Desktop X server you can change the configuration also from the /etc/X11/xorg.conf file and then restart the X server). I think Gtk/Gdk check the extensions availability also only at process startup. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: n800 - most libraries compiled witout -fPIC, intentional?
Hi, ext Frantisek Dufka wrote: I tried prelink on latest N800 firmware and it looks like most libraries (gtk,dbus,SDL,..) are not compiled with -fPIC. I see Cannot prelink against non-PIC shared library error message for most libraries. Is this a bug or is there a reason? In previous version it was just libSDL, now it is almost everything. Is this some sort of optimization? It may not matter much when using the maemo-invoker but it may cause higher memory consumption and slower dynamic linking for normal cases. It was a (new) bug noticed too little time before the latest release so there was not enough time to find the root cause fix re-build everything needed. The effect is a couple of secs lost at bootup and a couple of MB of RAM lost after device is up (compared to system that would be fully prelinked). It will be fixed in the next release whenever that will happen (hopefully along with libSDL :-)). - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
Hi, ext Sean Luke wrote: The problem is not widgets telling what is their maximum size (doesn't fit to available space) or minimum size (doesn't show enough useful information to the user), but somehow things deciding what is the the optimum size for them. Programmer just hard-coding the widget width in pixels is not really a solution. It's not an easy problem to solve. So trying to understand what you're going after, I finally made my way here, following some transitivity in Murray's pointer: http://live.gnome.org/MathiasHasselmann/NewLayoutManager What I gather here is that GTK widgets can't specify maximum size and, They can. more importantly, they can't specify a preferred (as in Java) or natural (as Mathias puts it) size. How this works in Java? Okay, fine. But this isn't because the problem is hard. It's because of a significant misfeature in GTK. If widgets were able to specify at least natural sizes, the problem would essentially go away, would it not? How widgets could specify a preferred size? Their contents could be anything. The above link is about how widget *containers* can better deduct what would be best size between the minimum and maximum as: - minimum is too small for strings that are set as ellipsizable (...) - maximum can go out of screen But to get back on track: this is essentially orthogonal to the issue of giving developers the *option* of moving and resizing dialogs. Developers already have that. They can (from code) set dialog to any size and position at any time they want to. Indeed the problem will show up in fixed-size dialogs as well: just have the user change the default system font size. Yes, things will break because Gtk cannot yet handle well enough content which is resizable, it will (usually) show such content as too small, unless a fixed size is used... So, some of the dialogs in the device might have fixed sizes (which is a bad thing). In ideal situation the Gtk containers could size things so that user doesn't feel the need for resizing. So: why are we restricted to being unable to make dialogs which can be dragged and resized? Why can't the developer be given the option to handle these corner cases himself? You're asking for an option to set that dialog should be resizable and movable? (that's different from what you asked earlier) Btw. If you want to know more about the standard for application and window manager communication, see: http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
wtmp, getty over serial running, Re: n800 - most libraries compiled witout -fPIC, intentional?
Eero Tamminen wrote: It was a (new) bug noticed too little time before the latest release so there was not enough time to find the root cause fix re-build everything needed. The effect is a couple of secs lost at bootup and a couple of MB of RAM lost after device is up (compared to system that would be fully prelinked). I see, thanks. I was thinking that perhaps I missed something and prelink in not that useful or something. Should I bother to create bugzilla entry for this? Also there are other issues with the firmware. It looks like /var/run/wtmp growing problem is back (was in some n770 firmware but was solved if I remember correctly). On n800 it is even created again if deleted so I had to make softlink to /dev/null. Anyone else see this too? I'm not sure if it is caused by something I installed. This should go to bugzilla, right? Another thing is getty running on /dev/ttyS0, I think I removed it from inittab and it appeared again. RD mode is disabled. Does this cause higher power consumption or is harmless? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: gtk-server quick test
Yey! I was thinking on this port few time ago. I find it very useful, so it can be used together with menush: http://news.nopcode.org/menush.tar.gz menush is a bunch of shellscripts and a minimal terminal handler for creating menu entries and program launchers from command line for the n770/n800 (use the arrow keys). Have fun. --pancake Hello, I guess I need to create blog, this is typical material for it :-) After the discussion about language bindings here in the list I finally tried gtk-server. It compiles fine in scratchbox but needs ffcall (available in debian). Good news is that it runs fine (at least on os2007on770) and startup speed is quite good even on n770. Both the simple demo with one button and a bit more complex calculator example using glade starts in approx. 1 second :-) This is perfectly usable for small shell hacks that don't need full python and pygtk. In fact it can be used in python without pygtk too. Startup speed is worse then from shell but still better than with pygtk. Here is quick hack including compiled libffcall deb an few examples. http://fanoush.wz.cz/maemo/gtk-server.tgz Binaries were build in bora taget so probably you need device with IT2007 too. For quick test extract it, install the deb and go to gtk-server directory at try to run the demo and calculator scripts. Demo in python obviously needs python :-) Yo can also install menu shortcut for demo calculator via ./install_shortcut.sh (sudo gainroot needed) and try it from menu. Startup speed is similar/same to default calculator tool. Unless there is some major problem with gtk-server (like inability to use methods with pointers) this looks pretty usable and worth packaging. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: wtmp, getty over serial running, Re: n800 - most libraries compiled witout -fPIC, intentional?
Hi, ext Frantisek Dufka wrote: It was a (new) bug noticed too little time before the latest release so there was not enough time to find the root cause fix re-build everything needed. The effect is a couple of secs lost at bootup and a couple of MB of RAM lost after device is up (compared to system that would be fully prelinked). I see, thanks. I was thinking that perhaps I missed something and prelink in not that useful or something. Should I bother to create bugzilla entry for this? That's not necessary, it will most definitely be fixed in next release. Also there are other issues with the firmware. It looks like /var/run/wtmp growing problem is back (was in some n770 firmware but was solved if I remember correctly). On n800 it is even created again if deleted so I had to make softlink to /dev/null. Anyone else see this too? I'm not sure if it is caused by something I installed. This should go to bugzilla, right? I don't have this file. Another thing is getty running on /dev/ttyS0, I think I removed it from inittab and it appeared again. RD mode is disabled. Does this cause higher power consumption or is harmless? Nor getty. So, might be because of something you installed... - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: wtmp, getty over serial running, Re: n800 - most libraries compiled witout -fPIC, intentional?
Eero Tamminen wrote: Also there are other issues with the firmware. It looks like /var/run/wtmp growing problem is back (was in some n770 firmware but was solved if I remember correctly). Sorry, it is in /var/log ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: No more 770 bug activity?
On Tue, Apr 17, 2007 at 06:18:16PM -0700, ext Ian wrote: If the vehicle gets bogged down anywhere or can't find its way, please Nokia send all returned 770's to Brazil. We [1] will use them. I have added a section: Implement a Coherent Recycling Strategy for all Nokia Maemo Devices. This is out of our (the people hacking on the Internet Tablets) hands: Nokia as a corporation has a global recycling strategy for all their products, which includes reuse of components and materials, sensitive disposal of that which cannot be reused or recycled, et al. Can probably be found on a Nokia site somewhere. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: wtmp, getty over serial running, Re: n800 - most libraries compiled witout -fPIC, intentional?
Hi, ext Frantisek Dufka wrote: Also there are other issues with the firmware. It looks like /var/run/wtmp growing problem is back (was in some n770 firmware but was solved if I remember correctly). Sorry, it is in /var/log That I have, but it's only 6kB after several days of device being on/online. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
On Wed, 2007-04-18 at 12:20 +0300, Eero Tamminen wrote: [snip] You're asking for an option to set that dialog should be resizable and movable? (that's different from what you asked earlier) Btw. If you want to know more about the standard for application and window manager communication, see: http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html Isn't this just an issue of the MatchBox window manager. It generally prefers to fullscreen windows and doesn't allow secondary windows to be moved or resized by the user, at least on Maemo. Obviously a user can move and resize windows on a regular GNOME desktop. That seems to be a fairly sane decision by the Maemo UI people in order to simplify the UI. It might not be to everyone's liking. -- Murray Cumming [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: wtmp, getty over serial running, Re: n800 - most libraries compiled witout -fPIC, intentional?
On 4/18/07, Eero Tamminen [EMAIL PROTECTED] wrote: Sorry, it is in /var/log That I have, but it's only 6kB after several days of device being on/online. mine was 62-megs (of course what i did immediately is ln -sf /dev/null /var/log/wtmp) (latest firmware) -- Kemal ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
ext Murray Cumming wrote: On Wed, 2007-04-18 at 12:20 +0300, Eero Tamminen wrote: [snip] You're asking for an option to set that dialog should be resizable and movable? (that's different from what you asked earlier) Btw. If you want to know more about the standard for application and window manager communication, see: http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html Isn't this just an issue of the MatchBox window manager. It generally prefers to fullscreen windows and doesn't allow secondary windows to be moved or resized by the user, at least on Maemo. Obviously a user can move and resize windows on a regular GNOME desktop. That seems to be a fairly sane decision by the Maemo UI people in order to simplify the UI. It might not be to everyone's liking. Yes, this is what it is. It is possible to have movable and resizable dialogs with Matchbox, we just don't want them. // Tapani ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: wtmp, getty over serial running, Re: n800 - most libraries compiled witout -fPIC, intentional?
2007/4/18, Eero Tamminen [EMAIL PROTECTED]: Hi, ext Frantisek Dufka wrote: Also there are other issues with the firmware. It looks like /var/run/wtmp growing problem is back (was in some n770 firmware but was solved if I remember correctly). Sorry, it is in /var/log That I have, but it's only 6kB after several days of device being on/online. Mine is ~5MB and this is the new firmware... (6kb / Several days) * several months == a figure that might be significant? -- 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
Trying to retrieve battery info on N800
Hi, I've been trying to find a way to retrieve battery information for a N800. I am not able to isolate the function call used in getting this information. I tried listening to D-BUS messages, but this only works when the user manually launches the battery applet (on the top status bar). I am not able to find any HAL libraries on the device either, so am not sure whether HAL exists for the device or not. Could you give me any information on how this data can be retrieved? Thanks and Regards, T Chaitanya ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Trying to retrieve battery info on N800
There seem to be a DBUS request/reply used by the battery applet to request current level, see here: http://maemo.org/pipermail/maemo-developers/2007-March/009300.html Plus messages sent when the level changes. However my question: I couldn't find documentation on the maemo site for these bme/mce messages, is the protocol I described considered stable (eg: supported for new releases)? Did I miss obvious messages or got wrong semantics? Went unanswered, may be I should open a bugzilla for more visibility? Laurent On Wed, 2007-04-18 at 16:14 +0530, [EMAIL PROTECTED] wrote: Hi, I've been trying to find a way to retrieve battery information for a N800. I am not able to isolate the function call used in getting this information. I tried listening to D-BUS messages, but this only works when the user manually launches the battery applet (on the top status bar). I am not able to find any HAL libraries on the device either, so am not sure whether HAL exists for the device or not. Could you give me any information on how this data can be retrieved? Thanks and Regards, T Chaitanya ___ 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: wtmp
Kemal Hadimli wrote: On 4/18/07, Eero Tamminen [EMAIL PROTECTED] wrote: Sorry, it is in /var/log That I have, but it's only 6kB after several days of device being on/online. mine was 62-megs (of course what i did immediately is ln -sf /dev/null /var/log/wtmp) (latest firmware) OK, so I reopened https://maemo.org/bugzilla/show_bug.cgi?id=448 ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Trying to retrieve battery info on N800
On ons, 2007-04-18 at 13:06 +0200, ext Laurent GUERBY wrote: There seem to be a DBUS request/reply used by the battery applet to request current level, see here: http://maemo.org/pipermail/maemo-developers/2007-March/009300.html Plus messages sent when the level changes. However my question: I couldn't find documentation on the maemo site for these bme/mce messages, is the protocol I described considered stable (eg: supported for new releases)? Did I miss obvious messages or got wrong semantics? We cannot make any firm commitments about the interfaces, since they aer designed for internal use, but they will only be changed if there's a real need for it. As for documentation for the mce D-Bus interfaces, you can install mce-dev and read the documentation in the *.h files. Regards: David ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: wtmp
ext Frantisek Dufka wrote: Kemal Hadimli wrote: On 4/18/07, Eero Tamminen [EMAIL PROTECTED] wrote: Sorry, it is in /var/log That I have, but it's only 6kB after several days of device being on/online. mine was 62-megs (of course what i did immediately is ln -sf /dev/null /var/log/wtmp) Ok, I found it here also. On a device which has been used 5 weeks, the size was ~100MB. However, wtmp data is very redundant so it compresses to 3MB - its Flash usage is not that large as Flash is internally compressed. (latest firmware) OK, so I reopened https://maemo.org/bugzilla/show_bug.cgi?id=448 Thanks. It could be related to the X terminal being used in the device... - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
RE: python sound
Hi Matthew, You have to use pygstreamer in order to play sounds using python for maemo. Regards, Luciano -Original Message- From: [EMAIL PROTECTED] on behalf of ext Matthew R. Gattis Sent: Tue 4/17/2007 10:45 AM To: maemo-developers@maemo.org Subject: python sound Has anyone gotten sound in python to work on one of the tablets? I'm curious to know how you did it. I tried using pyalsaaudio but no luck with recording for some reason (it just records blank audio). I can't use ossaudiodev because they took it out of the maemo python versions. Is there an easy way to put it back in? Thanks ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Kernel compilation (Bora 3.1)
Good catch. Thanks. This will be fixed. -M On Apr 17, 2007, at 7:25 PM, ext Leandro Melo de Sales wrote: Hi, The guide is incorrect. It is necessary to setup the debian devkit, which is not specified in the instructions given by the guide. When it is created the MaemoKernel target the guide author didn't specify the debian devkit. I'll send to maemo guys the parts that are missing. Thank you, Leandro. 2007/4/17, Frantisek Dufka [EMAIL PROTECTED]: Leandro Melo de Sales wrote: Hi all, I'm trying to compile kernel to n800. I followed the instructions in http://www.maemo.org/platform/docs/howtos/ howto_kernel_guide_bora.html, but I can't. After create MaemoKernel target, update the apt repository, I tried to install kernel-source-rx-34 as described in the manual NOt sure what is the problem but try to compile it in normal bora SDK_ARM target if you have one. It may be easier and even save some disk space. From the howto: It is not mandatory to set up a separate target for kernel compilation but in this example we do it in case you have modified your default armel target in some special way. Frantisek ___ 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: wtmp, getty over serial running, Re: n800 - most libraries compiled witout -fPIC, intentional?
Hi, ext Frantisek Dufka wrote: Another thing is getty running on /dev/ttyS0, I think I removed it from inittab and it appeared again. RD mode is disabled. Does this cause higher power consumption or is harmless? Are you building your own kernel which is newer than the one coming with the latest release?I heard that with some of the newer versions /etc/init.d/ttyusb0 could start getty and the script needs to be updated for newer kernel. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
On Apr 18, 2007, at 5:20 AM, Eero Tamminen wrote: ext Sean Luke wrote: What I gather here is that GTK widgets can't specify maximum size and, They can. They can? All I see is set_size_request(), which sets minimum sizes. How do you set the maximum size? (still no preferred size though. :-( ) more importantly, they can't specify a preferred (as in Java) or natural (as Mathias puts it) size. How this works in Java? In Java every widget can tell you its minimum, maximum, and preferred size. A container will do everything it can to keep its children from going smaller than their minimum size. Likewise widgets can refuse to be made larger than a maximum size -- stretching beyond it will just add more padding. Okay, good enough. A widget's preferred size tells its container the size it'd like to be set to if at all possible. Containers then will resize widgets such that everything gets its preferred size if possible, and the remainder is filled by widgets which have been positioned to stretch. Thus in the dialog at http:// preview.tinyurl.com/ytzfsh the top row is what GTK does and the bottom row is what Java typically does. A container's own minimum, maximum, and preferred sizes are calculated on-the-fly from laying out its children accordingly. And the outermost container (a window) can be set to its preferred size -- and thus set all of its subsidiary widgets to their preferred sizes -- through the pack() method. Okay, fine. But this isn't because the problem is hard. It's because of a significant misfeature in GTK. If widgets were able to specify at least natural sizes, the problem would essentially go away, would it not? How widgets could specify a preferred size? Their contents could be anything. Not true. What you're mistaking here is thinking that YOU tell widgets what their preferred is. While you can often do this, in fact Java widgets typically compute their preferred sizes on the fly and provide them to YOU (or actually to their container) when asked. Java widgets specify minimum/maximum/preferred sizes through methods you can call: widget.getPreferredSize() widget.getMaximumSize() widget.getMinimumSize() For Java's equivalent of a one-line GTK.label, or GTK.entry, or GTK.button with one-line text: getMaximumSize() returns the largest size the widget will allow (for these, it's infinity in the X direction, and TEXT_HEIGHT in the Y direction) getMinimumSize() returns the minimum size possible ( [0,TEXT_HEIGHT] say, or maybe the size necessary to display ... ). getPreferredSize() returns the minimum size necessary to display _all_ of its text: [text's string width, TEXT_HEIGHT] Now what happens if it's a multi-line label with word-wrap? What you'd want are two additional functions, something like: getPreferredWidthForThisHeight(height) getPreferredHeightForThisWidth(width) ...which tell the container: if you resize me to 100 pixels wide, then here's the height I'd need to display all my text. Java doesn't have that, a weakness -- but that's okay for Java because it has no widgets with wrappable text which don't prefer to fill the whole space. Java's labels and buttons are one-line or multi-line but with hard-returns. Still, a far sight better than GTK's situation. But to get back on track: this is essentially orthogonal to the issue of giving developers the *option* of moving and resizing dialogs. Developers already have that. They can (from code) set dialog to any size and position at any time they want to. Is there a standard API for developers turn on a switch in their application (not a global switch for all apps) that says let the user resize this particular dialog from a resize box or let the user drag dialogs by their title bars, short of making a global modification to the window manager? That's what spawned this thread. So: why are we restricted to being unable to make dialogs which can be dragged and resized? Why can't the developer be given the option to handle these corner cases himself? You're asking for an option to set that dialog should be resizable and movable? (that's different from what you asked earlier) Hmmm, I'm pretty sure that's what I asked. But let me be more specific to summarize my requests in the discussion so far. First, I'd like the option, as a developer, to: - set a specific dialog as movable - set a specific dialog as resizable - set a specific dialog as non-modal - set a specific dialog as closeable or minaturizable Second, I believe that Nokia should set many of its dialog boxes as resizable, and *all* of its dialog boxes as movable. Third, I believe Nokia should place notifications somewhere where they don't cover widgets (the right half of the menu bar is the obvious place), and at the very least, make notifications dismissable by clicking on them. No notifications should be permitted
Re: Boot bora as root
That was my assumption also. I changed the occurances of use/users (one occurance of systemui/users) to root/root in the init scripts so I changed out all the references to /home/user to /home/root and made a symlink from /home/root to point to /root I then copied over (without overwrite) all the /home/user/.stuff over to root's home dir I'm booting as root now something onto the mameo wiki ... what say everyone? What was the real reason for that? I second your wish for login option. But, it is far away from all power root all the time. There exist programs that cannot work as root. In case you don't go wireless, you could play as you like, no harm. I envision troubles when particular app tries to fork and finds wrong permission. Anyway, if you have fun, it's your playground. Zoran ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
Hi, ext Sean Luke wrote: [...] Thanks for the information! It's better that some developer more familiar with Gtk answers these, I'm not completely sure on all of this (I've done very little with Gtk). But to get back on track: this is essentially orthogonal to the issue of giving developers the *option* of moving and resizing dialogs. Developers already have that. They can (from code) set dialog to any size and position at any time they want to. Is there a standard API for developers turn on a switch in their application (not a global switch for all apps) that says let the user resize this particular dialog from a resize box or let the user drag dialogs by their title bars, short of making a global modification to the window manager? That's what spawned this thread. No. So: why are we restricted to being unable to make dialogs which can be dragged and resized? Why can't the developer be given the option to handle these corner cases himself? You're asking for an option to set that dialog should be resizable and movable? (that's different from what you asked earlier) Hmmm, I'm pretty sure that's what I asked. There are now three different things being discussed: 1. Being able to set dialog size position from code - already possible 2. Original issue: all dialogs in the device being resizable and movable by the user - Already possible, but only by setting the corresponding DIALOGMODE in /etc/osso-af-init/matchbox.defs (this is given as command line option to matchbox window manager) - This UI policy is not going to be changed as it's against Maemo UI policy and need for that just indicates either bad application UI design or implementation (ie. bug) - If UI policy is not at Maemo site, IMHO it should... 3. Being able to set just specific dialog to be user movable resizable - Not possible But let me be more specific to summarize my requests in the discussion so far. First, I'd like the option, as a developer, to: - set a specific dialog as movable - set a specific dialog as resizable - set a specific dialog as non-modal This can be already done. - set a specific dialog as closeable or minaturizable This might be something that you could control from Matchbox theme file, see its documentation at: http://matchbox-project.org/ Then you could create a theme that does that and install it. Second, I believe that Nokia should set many of its dialog boxes as resizable, and *all* of its dialog boxes as movable. I'm pretty sure this is not going to happen (dialogs in phones are not movable either + their UI is also very modal). Third, I believe Nokia should place notifications somewhere where they don't cover widgets (the right half of the menu bar is the obvious place), Many of the banners come from dimmed menu items, so then the banners would cover the item you just tapped (they are quite high), which would be even more annoying I think. and at the very least, make notifications dismissable by clicking on them. This has already a bug. No notifications should be permitted to be on-screen more than a very short time (the present 3 second length is irritatingly way too long -- perhaps this could be a control panel setting?). It's very little detail to be put in control panel, but file it to Bugzilla. Maybe it could be just a Gconf setting, then somebody else could provide the applet for setting that? (I'm not deciding on these, but you could get the hildon sources and provide a patch for this in bugzilla, that could help) IMHO above feature is more useful though. And violating notifications, such as email's deleting message notification, which keep the notification up for minutes at a time, should be eliminated. Fourth, it'd be nice if Nokia significantly reduced the height of the Dialog's title bar given the small size of the screen. Bug? - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Cross compiling under debian
Hi,
On Wed, 2007-04-18 at 09:43:32 +0200, ext Sebastian Mancke wrote:
So, at the moment I cross compile from my x86 debian, which seems to
work fine except of the following problems with the debian packaging:
1. dh_strip -a (from x86) does not know, how to handle the arm binaries.
(I have disabled it with: DEB_BUILD_OPTIONS=nostrip)
You need to install binutils-multiarch.
2. dh_shlibdeps does not work, because the ldd (from the toolchain)
tries to use ld-linux.so.3 from my host instead from the rootstrap.
/home/asteban/maemo/toolchain/scratchbox/compilers/arm-linux-2006q3-27/arm-none-linux-gnueabi/libc/usr/bin/ldd:
line 166: /lib/ld-linux.so.3: No such file or directory
Neither dh_shlibdeps nor dpkg-shlibdeps should be using ldd on the latest
Debian versions. Also dpkg-shlibdeps needs access to the dpkg db, to
match sonames with package names, so this will not work yet. You could
fix some of the problems with -L, but you'll need dpkg svn's trunk to
get the new --admindir. But admindir is not propagated to the child dpkg,
this needs to be fixed in general so that child processes inherit the
admindir variables (I talked about this in a thread about sbox2).
3. dpkg-architecture does not know 'arml'
It would be possible to hack a fix in the script, like the one in
scratchbox:
sub debian_arch_fix
{
local ($os, $cpu) = @_;
...
} elsif ($os-$cpu eq gnueabi-linux-arm) {
return armel;
...
}
It needs a bit more fixing than that, it's on the 1.14.0 roadmap.
Should be uploaded into unstable RSN.
The problem 2. is my biggest one. Any suggestions? Cleaner solutions?
Either you wait, or you mess with the two scripts.
My setup is as follows:
TOOLCHAIN=~/maemo/toolchain/scratchbox
ROOTSTRAP=~/maemo/toolchain/rootstrap
export
PATH=$TOOLCHAIN/compilers/arm-linux-2006q3-27/bin/:$TOOLCHAIN/compilers/arm-linux-2006q3-27/arm-none-linux-gnueabi/libc/usr/bin/:$PATH
export CC=`which arm-none-linux-gnueabi-gcc`
export LD=`which arm-none-linux-gnueabi-ld`
export AR=`which arm-none-linux-gnueabi-ar`
export PKG_CONFIG_PATH=$ROOTSTRAP/usr/lib/pkgconfig/
alias pkg-config='pkg-config --define-variable=prefix=$ROOTSTRAP/usr'
# no a nice soution
export DEB_BUILD_OPTIONS=nostrip
Then I simply run 'fakeroot dpkg-buildpackage -d'
Ideally you should be able to use -aarmel and get it working, but we
are not there yet.
regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
RE: disabling pressure information (for x11vnc)
Hi, many thanks ... I can form that: If you want to disable pressure information usage, you need to run the device X server with XInput protocol/extension disabled. Just add -extension XInputExtension to the /etc/init.d/x-server file X server options and reboot the device. Where it is added to the end of the ARGS= string, preceded by a space. Does indeed mean that the mouse over X11vnc now works on the task manager pane on the left. Many thanks! It doesn't completely fix the problems though .. the other big problem is still there, in that in X-terminal pressing the enter key brings up the thumb keyboard and does not enter the data. One can achieve an Enter by clicking on the window (which brings up the stylus keyboard) and then on the Enter key there, but that's terribly inconvenient. Any suggestions? mfc ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
On Apr 18, 2007, at 10:58 AM, Eero Tamminen wrote: - set a specific dialog as closeable or minaturizable This might be something that you could control from Matchbox theme file, see its documentation at: http://matchbox-project.org/ Then you could create a theme that does that and install it. No, that's a *global* change, and a major, brickable, modification which is not acceptable for me to make on a person's computer for them just to use my application. I should be able to enable a *specific* window to be resizable/movable. Second, I believe that Nokia should set many of its dialog boxes as resizable, and *all* of its dialog boxes as movable. I'm pretty sure this is not going to happen (dialogs in phones are not movable either + their UI is also very modal). Does Nokia really perceive the N800 UI in phone terms? If so, Apple is going to eat your lunch. Third, I believe Nokia should place notifications somewhere where they don't cover widgets (the right half of the menu bar is the obvious place), Many of the banners come from dimmed menu items, so then the banners would cover the item you just tapped (they are quite high), which would be even more annoying I think. You don't need to actually have a *window*. Just change part of the text of the menu bar (and maybe its color) temporarily. Sean ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: disabling pressure information (for x11vnc)
Hi, ext Mike Cowlishaw wrote: Hi, many thanks ... I can form that: If you want to disable pressure information usage, you need to run the device X server with XInput protocol/extension disabled. Just add -extension XInputExtension to the /etc/init.d/x-server file X server options and reboot the device. Where it is added to the end of the ARGS= string, preceded by a space. Does indeed mean that the mouse over X11vnc now works on the task manager pane on the left. Many thanks! It doesn't completely fix the problems though .. the other big problem is still there, in that in X-terminal pressing the enter key brings up the thumb keyboard and does not enter the data. You can disable thumb keyboard from control panel, but then you get the normal input method (HWR or VKB). One can achieve an Enter by clicking on the window (which brings up the stylus keyboard) and then on the Enter key there, but that's terribly inconvenient. Any suggestions? If you have full (bluetooth) keyboard, use keypad enter instead. (I'm not sure whether this kludge still works) - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: [maemo-developers] How to extend Hildon Input Methods
Hello Mohammad, Since your reply to my questions, the wiki page http://www.maemo.org/platform/docs/howtos/howto_him_bora.html has not been updated :( More over, http://repository.maemo.org/stable/3.1/content_comparison.html indicates that packages libhildon-input-method-framework-header-sdk-dev and libhildon-input-method-ui-header-sdk-dev have been removed. As a consequence, it is not possible anymore to compile the sample input method plugin at http://www.maemo.org//downloads/him-plugin-examples/him-plugins-sdk-example-0.0.2.tar.gz As a workaround, I will revert to bora 3.0. However, what's the solution for bora 3.1 ? Regards, G. Mohammad Anwari wrote: Pada hari Senin, tanggal 15/01/2007 pukul 13:45 +0100, ext Guard][an menulis: The tutorial mentions libhildon-input-method-header-sdk-dev and libhildon-input-method-framework-header-sdk-dev packages but the real name of the first package seems to be libhildon-input-method-ui-header-sdk-dev. You are correct. I'm cc:-ing bora-feedback hoping they can fix this. Also, it would be nice to have more detailed documentation on key types and attributes usage. For instance, the key alpha=ALPHA size=2q/key markup seems rather obscure to me, particularly the alpha=ALPHA part. Also, how do you define a modifier key ? Unfortunately, there is no modifier key :( And how do you specify tabs like the abc ABC 1!+ tabs on the thumb keyboard. In fact, having Put label attribute in the sublayout tag. ... keyboard layout=THUMB sublayout type=LOWERCASE label=abc variance_index=1 ... the xml versions of the .vkb files deployed on the device would really help understanding how to achieve the abc/ABC click on the same tab changes the case behavior. Use variance index for that, so we would have: ... keyboard layout=THUMB sublayout type=LOWERCASE label=abc variance_index=1 ... sublayout type=UPPERCASE label=ABC variance_index=0 ... ... Is there any plan to make these .xml files available ? Sorry, no plan for that. Regards. G. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Moving windows in Maemo
Hi, ext Sean Luke wrote: - set a specific dialog as closeable or minaturizable This might be something that you could control from Matchbox theme file, see its documentation at: http://matchbox-project.org/ Then you could create a theme that does that and install it. No, that's a *global* change, and a major, brickable, modification which is not acceptable for me to make on a person's computer for them just to use my application. I should be able to enable a *specific* window to be resizable/movable. Sorry, those are the only options you have currently available. (and based on Intel's recent powerpoints linked to this list they might be adopting Hildon too. :-)) Second, I believe that Nokia should set many of its dialog boxes as resizable, and *all* of its dialog boxes as movable. I'm pretty sure this is not going to happen (dialogs in phones are not movable either + their UI is also very modal). Does Nokia really perceive the N800 UI in phone terms? I don't know. I don't. :-) If so, Apple is going to eat your lunch. That would be oh, so naughty... Third, I believe Nokia should place notifications somewhere where they don't cover widgets (the right half of the menu bar is the obvious place), Many of the banners come from dimmed menu items, so then the banners would cover the item you just tapped (they are quite high), which would be even more annoying I think. You don't need to actually have a *window*. Just change part of the text of the menu bar (and maybe its color) temporarily. Titlebar is owned by the window manager and AFAIK there's currently no way to do this (see the ewmh spec link). You could discuss this feature on the Matchbox mailing list (or freedesktop specs list). - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: wtmp, getty over serial running, Re: n800 - most libraries compiled witout -fPIC, intentional?
Eero Tamminen wrote: Are you building your own kernel which is newer than the one coming with the latest release?I heard that with some of the newer versions /etc/init.d/ttyusb0 could start getty and the script needs to be updated for newer kernel. Own kernel from bora 3.1 repository with mmc patches from http://intr.overt.org/n800-sdhc-kernel/ and some small (non-invasive) custom hacks. The mmc patches are fairly invasive but just to the mmc layer. I don't have the device now but I'll check details. I definitely remember about having to disable it in inittab more times but that may be because I have more copies of rootfs (1 in flash + 3 on mmc) so it is sometimes hard to track changes :-) But still, getty over ttyS0 should not be enabled at all. I never played with various flasher flags on my N800 yet. ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: disabling pressure information (for x11vnc)
On Wed, Apr 18, 2007 at 04:09:17PM +0100, ext Mike Cowlishaw wrote: It doesn't completely fix the problems though .. the other big problem is still there, in that in X-terminal pressing the enter key brings up the thumb keyboard and does not enter the data. One can achieve an Enter by clicking on the window (which brings up the stylus keyboard) and then on the Enter key there, but that's terribly inconvenient. Any suggestions? Use Enter on your numpad. This is a broken UI specification and apparently isn't going to be changed. Cheers, Daniel signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Intel's Internet Mobile Device
Hi, I just came across this news at Endgatget. http://feeds.engadget.com/~r/weblogsinc/engadget/~3/109417695/ Here a technical the presentation: https://intel.wingateweb.com/published/UMGS003/UMGS003_100eng.pdf Looks interesting. Same approach than Nokia. They actually even plan to use Hildon. And they claim to have 20+ applications ready to go, many (according to the gallery) apparently Hildonized. If those applications are free software, it may be trivial to port them over to the 770 / N800 ... I may be being over-dramatic, but this feels to me like crunch time for Nokia. They will either decide now to accept the potential of their platform and go fully free -- or they will batten down the hatches in any way they can, in an attempt to prevent other players from leveraging their work. This is a positive development for Nokia and other companies building or planning to build devices on GNOME software. Intel's use of Hildon is welcome and seen as positive development. There should be plenty of opportunity for collaboration. Maemo as a whole has been so far primarily seen by Nokia as a application development platform though there is increasing interest in Nokia in the possibility of open platform development at the full Maemo scope. Hildon however has been for quite some time totally open-source and developed in the open. The code is available in stage.maemo.org. and we work directly from there. Frequent releases are made to Sardine. Not only there is no attempt to frequent other plays from using Hildon, it is actually encouraged. There's still a way to go in terms of making thedevelopment process more transparent particularly in terms of planning, but that is slowly improving. Br, Carlos ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
getty over serial is running
Frantisek Dufka wrote: Eero Tamminen wrote: Are you building your own kernel which is newer than the one coming with the latest release?I heard that with some of the newer versions /etc/init.d/ttyusb0 could start getty and the script needs to be updated for newer kernel. Well, I do have /dev/ttyS0 device file. dd read test for serial in /etc/init.d/ttyusb0 does not fail Nokia-N800-10:~# /etc/init.d/ttyusb0 start 1+0 records in 1+0 records out so the scripts uncomments line #T0:12345:respawn:/sbin/getty -L ttyS0 115200 vt100 and I see Nokia-N800-10:~# ps -ef | grep getty 1550 root460 S /sbin/getty -L ttyS0 115200 vt100 Workaround is to comment inittab line with two #'s. How is this supposed to work in theory? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Boot bora as root
Well, still no luck on getting application installer to run the window pops up and nothing is drawn to the screen anyone have any ideas? I may have to compile up a custom version of the application installer and see where it's crapping out as far as some programs not working when unning as root per Zoran's comment, I see no reason why they shouldn't (I accept that they might not, but they probably should IMO) ... these internet tablets have a LOT of potential it's just a matter of time until Nokia or someone can squeeze whatever electronics into one of these so they can go celluar, link it with a bt headset ... combine with voice activated dialing . the more mature and closer to a multi-user environment we can the IT's the better off everyone will be ... just one man's opinion ... -Chris ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Boot bora as root
2007/4/18, Chris Taylor [EMAIL PROTECTED]: Well, still no luck on getting application installer to run the window pops up and nothing is drawn to the screen anyone have any ideas? FWIW, I have this same problem, and the process seems to block somewhere using the apt-worker sockets: open(/tmp/apt-worker.to, O_WRONLY (the line is left unfinished). A full trace showing some funny references to scratchbox and AFAICS the apt side dying (child exited) is available for further investigations from: http://iki.fi/zuh/appman-stracelog.gz (I tend to just use apt-get so not really motivated to look into this... ;) -- 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: 3.2007.10-7 - Detailed change log?
Did you (or anyone else) manage to make any progress on a changelog for 3.2007.10-7? I have started the internal discussion with the aim of having a changelog linking to maemo's bugzilla being published together with the next IT OS release notes. And improve from that point in next releases. Still a proposal, but looking good. Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Intel's Internet Mobile Device
Carlos Guerreiro [EMAIL PROTECTED] writes: This is a positive development for Nokia and other companies building or planning to build devices on GNOME software. Intel's use of Hildon is welcome and seen as positive development. There should be plenty of opportunity for collaboration. That's really good news. I'm glad that Nokia are seeing things this way. Thank you for commenting. Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
N800 experimental host mode patches available
Hi all, I've been meaning to do this for a while, but only now got into it after sorting out one more issue with the N800 USB DMA. I've posted some experimental N800 host mode patches to [1] for people to play with. Although the N800 is not built to support host or OTG mode and does not have a mini-B connector, you can still use it via some software hacks. The patches are from the linux-omap git tree at [2] with some extra patches to force N800 into host mode. The driver is still very much experimental and can cause file system corruption on USB drives, so YMMV :) Anyways, let me know of issues and fixes. Regards, Tony [1] http://muru.com/linux/n800-usb-host/ [2] http://master.kernel.org/git/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=summary ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
getty over serial is running
I heard that with some of the newer versions /etc/init.d/ttyusb0 could start getty and the script needs to be updated for newer kernel. Mystery solved. There is clear bug in the script. While the comment above dd talks about reading it writes to /dev/ttyS0 creating 1 byte regular file in /dev. #test if we can read ttyS0, we have serial console if dd of=/dev/ttyS0 count=1 bs=1 if=/dev/zero ; then So everybody should have getty running in latest FW. Or did I change the script while sleeping? Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
Re: Boot bora as root
Kalle,
I did an strace:
# strace -f /usr/bin/osso-application-installer
but I died at a completly different location:
execve(/usr/bin/osso-application-installer,
[/usr/bin/osso-application-instal...], [/* 54 vars */]) = 0
uname({sys=Linux, node=Nokia-N800-10, ...}) = 0
brk(0) = 0x12000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=17592186044416, ...}) = 0
mmap2(NULL, 20758, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4000
close(3)= 0
open(/lib/libc.so.6, O_RDONLY)= 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\30\275\3..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=17592186044416, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x40006000
mmap2(0x41028000, 1083444, PROT_READ|PROT_EXEC,
MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x41028000
mprotect(0x41124000, 51252, PROT_NONE) = 0
mmap2(0x4112b000, 16384, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xfb) = 0x4112b000
mmap2(0x4112f000, 6196, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x4112f000
close(3)= 0
mprotect(0x4112b000, 8192, PROT_READ) = 0
mprotect(0x4101e000, 4096, PROT_READ) = 0
munmap(0x4000, 20758) = 0
brk(0) = 0x12000
brk(0x33000)= 0x33000
getpriority(PRIO_PROCESS, 0)= 20
socket(0x973c /* PF_??? */, 0xbe99086f /* SOCK_??? */, 35736) = 3
connect(38716, {sa_family=0x752f /* AF_??? */,
sa_data=sr/bin/osso-ap}, 35736) = 0
write(3, \227\0\0, 4)= 4
read(3, \227\0\0, 4) = 4
write(3, \227\0\0, 4)= 4
write(3, \1\0\0\0, 4) = 4
write(3, /usr/bin/osso-application-instal..., 36) = 36
read(3, \0\0\0\0, 4) = 4
write(3, \0\0\0\0, 4) = 4
write(3, $\0\0\0, 4) = 4
write(3, /usr/bin/osso-application-instal..., 43) = 43
read(3, \0\0\0\0, 4) = 4
write(3, \0\0\0\0, 4) = 4
write(3, \0\0\0\0, 4) = 4
write(3, +\0\0\0, 4) = 4
write(3, /usr/bin/osso-application-instal..., 36) = 36
read(3, \0\0\0\0, 4) = 4
write(3, \0\0\0\0, 4) = 4
write(3, \0\0\0\0, 4) = 4
read(3, \0\0\0\0, 4) = 4
write(3, \0\0\0\0, 4) = 4
read(3, \0\0\255\336, 4) = 4
read(3, \0\0\35\35, 4)= 4
read(3, \0\0\35\35, 4)= 4
rt_sigaction(SIGHUP, {0x8984, [], SA_RESTART|0x400}, NULL, 8) = 0
rt_sigaction(SIGINT, {0x8984, [], SA_RESTART|0x400}, NULL, 8) = 0
rt_sigaction(SIGQUIT, {0x8984, [], SA_RESTART|0x400}, NULL, 8) = 0
rt_sigaction(SIGTERM, {0x8984, [], SA_RESTART|0x400}, NULL, 8) = 0
rt_sigaction(SIGUSR1, {0x8984, [], SA_RESTART|0x400}, NULL, 8) = 0
rt_sigaction(SIGUSR2, {0x8984, [], SA_RESTART|0x400}, NULL, 8) = 0
rt_sigaction(SIGWINCH, {0x41051a50, [], 0}, NULL, 8) = 0
read(3, 0xbe990534, 4) = ? ERESTARTSYS (To be restarted)
--- SIGWINCH (Window changed) @ 0 (0) ---
kill(1220, SIGWINCH)= 0
sigreturn() = ? (mask now [QUIT ILL TRAP
ABRT KILL SEGV])
read(3, unfinished ...
had to ctl-c it nothing was getting drawn to the screen
looks like you ran strace with /usr/bin/run-standalone.sh
/usr/bin/maemo-summoner /usr/bin/osso-application-launcher I
couldn't get that to work .
looks like I have some of the same communication problems you're having
also looks like there might be some problems with gtk ... that's the
best reasoning I can come up with to explain things not getting drawn
to screen ... I'm going to try to compile up application-installer and
see where things go bad
-Chris
___
maemo-developers mailing list
maemo-developers@maemo.org
https://maemo.org/mailman/listinfo/maemo-developers
Re: Boot bora as root
2007/4/19, Chris Taylor [EMAIL PROTECTED]: looks like you ran strace with /usr/bin/run-standalone.sh /usr/bin/maemo-summoner /usr/bin/osso-application-launcher I couldn't get that to work . I ran it like this (from a ssh shell): strace /usr/bin/maemo-summoner /usr/bin/osso-application-installer.launch The .launch-file is the real binary, the one without is just a symlink to maemo-invoker that tells a separate maemo-launcher process to load and run the .launch (simple, eh?-). This is a gross hack (though it does work ;) to speed up application startup time. Maemo-summoner is a tool to do that directly so you can run strace and gdb for them without recompiling to a normal binary. also looks like there might be some problems with gtk ... that's the best reasoning I can come up with to explain things not getting drawn to screen If the socket read/open blocks, it won't refresh the UI either. It's not a threaded application AFAICT. -- 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
