Re: Finding the mmc cards
On 8/29/07, Tony Maro [EMAIL PROTECTED] wrote: After our thread some weeks ago regarding reading the serial number from a MMC card, I've since implemented detection of the MMC card's presence by the existence of those same files. I know my solution works on my device perfectly. Hello I use cat /proc/partitions on my desktop system to see what the partition are available on my desktop system bus perhaps listening to dbus or kernel events is the right way :) looking at mtab or the output of mount will also help greetings I figure it's probably a bad decision, because the architecture could change somewhat with the next hardware or software release. Can someone tell me, is there an approved / documented way of identifying the location of any MMC cards currently installed? I've noticed you can't simply look for /media/mmcX because that directory will exist even if there is no card inserted. Also, what determines MMC1 vs MMC2 as the card's path for internal/external? Is it possible these paths would change at some date? I know some Linux distro's with SATA drives had a problem with the drives changing their /dev/sdX path every reboot. I know that MY Nokia isn't doing anything similar, but I figure it's possible that my /media/mmc1 might be internal, but for someone else it could be the external slot - or maybe in the next hardware revision or something. I did find the alias names located in the /sys/ path that specify internal is for one and external or removable or something for the other. Also, are the names and paths the same for the 770's? Since I have an n800 I don't know. I'm hesitant to read too much data from /sys/ because it all looks _so_ Maemo-specific I wonder if I will tie my code too closely to one hardware revision. Just looking for the most _compatible_ way to identify if/when and where a media card is present. And as usual, from Python. Thanks, Tony ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Finding the mmc cards
I agree that assuming mmc1 and mmc2 is potentially dangerous. In an answer to my original question on this subject, someone suggested that mmc0 and mmc1 were the correct names, whereas in my Scratchbox environment they are mmc1 and mmc2. Consequently, when I was implementing a scan for memory cards, I opted to look in the /media folder for files whose names begin "mmc", and to assume that any such file I find might be a memory card. This appears to work (in the test/development environment), but personally I hate making those kinds of assumptions. I would far rather have a definitive statement from someone to the effect that "if you do X, this will guarantee to find the memory cards and nothing else". For me, this is particularly important, as my application will be sold commercially and needs to work under all circumstances. David Hazel After our thread some weeks ago regarding reading the serial number from a MMC card, I've since implemented detection of the MMC card's presence by the existence of those same files. I know my solution works on my device perfectly. I figure it's probably a bad decision, because the architecture could change somewhat with the next hardware or software release.Can someone tell me, is there an approved / documented way of identifying the location of any MMC cards currently installed? I've noticed you can't simply look for /media/mmcX because that directory will exist even if there is no card inserted. Also, what determines MMC1 vs MMC2 as the card's path for internal/external? Is it possible these paths would change at some date? I know some Linux distro's with SATA drives had a problem with the drives changing their /dev/sdX path every reboot. I know that MY Nokia isn't doing anything similar, but I figure it's possible that my /media/mmc1 might be internal, but for someone else it could be the external slot - or maybe in the next hardware revision or something. I did find the alias names located in the /sys/ path that specify "internal" is for one and "external" or removable or something for the other. Also, are the names and paths the same for the 770's? Since I have an n800 I don't know. I'm hesitant to read too much data from /sys/ because it all looks _so_ Maemo-specific I wonder if I will tie my code too closely to one hardware revision. Just looking for the most _compatible_ way to identify if/when and where a media card is present.And as usual, from Python.Thanks,Tony ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Python and GStreamer
Hi! gstreamer is poo. plain and simple. Yes, you need to recreate the pipeline. If you don't, bad things happen, like hanging and such after EOS. And no, EOS detection still doesn't work well in that class despite my many tries. That sounds like a bug, have you cared to file it? Does the same happen when you try the same pipeline on a PC? We abandoned gstreamer support in Kagu for a reason. It's poo. It's much easier to just use OSSO Media Server via dbus and let *it* deal with gstreamer for us. OSSO Media Player is there for a reason and that is to save you from gstreamer coding but that doesn't transate to 'gstreamer is a poo'. Gstreamer attacks a very complicated problem domain (much larger than just playing an mp3) and the current API provides the simplest possible solution for it. Concluding that the whole API (and even the project) is 'poo' looking at a bug, isn't very reasonable IMHO. Just the opinion of a developer who hung out on the #gstreamer IRC channel while writing gstplayer.py and saw every suggestion by the folks on that channel go up in smoke under one condition or another until the API was so riddled with inconsistencies that it was a smoking pile of garbage. I don't exactly see what you mean by API was so riddled with inconsistencies, API of what? your application? What you are trying to do *should* really be simple and if it isn't, you've found a bug (not necessarily in gstreamer even). And no, before you ask, I don't think it's not Nokia's fault. gstreamer is just unexpectedly buggy. Too bad ALSA doesn't support inline mp3 decoders... life would be easier for all of us... That might be because ALSA developers realize that decoding mp3 doesn't lie under the domain of ALSA project and that if it doesn't work in gstreamer, it's a bug we need to file and fix. -- Regards, Zeeshan Ali FSF member#5124 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Finding the mmc cards
Hi, Please file a documentation bug into Maemo Bugzilla. We need this documented. Handling of removable medias, especially with file systems as easily corrupted as FAT, needs special care from applications (stop using files when pre-unmount message is delivered on them so that unmounts succeed, do better error handling etc.) - Eero ext [EMAIL PROTECTED] wrote: I agree that assuming mmc1 and mmc2 is potentially dangerous. In an answer to my original question on this subject, someone suggested that mmc0 and mmc1 were the correct names, whereas in my Scratchbox environment they are mmc1 and mmc2. Consequently, when I was implementing a scan for memory cards, I opted to look in the /media folder for files whose names begin mmc, and to assume that any such file I find might be a memory card. This appears to work (in the test/development environment), but personally I hate making those kinds of assumptions. I would far rather have a definitive statement from someone to the effect that if you do X, this will guarantee to find the memory cards and nothing else. For me, this is particularly important, as my application will be sold commercially and needs to work under all circumstances. David Hazel After our thread some weeks ago regarding reading the serial number from a MMC card, I've since implemented detection of the MMC card's presence by the existence of those same files. I know my solution works on my device perfectly. I figure it's probably a bad decision, because the architecture could change somewhat with the next hardware or software release. Can someone tell me, is there an approved / documented way of identifying the location of any MMC cards currently installed? I've noticed you can't simply look for /media/mmcX because that directory will exist even if there is no card inserted. Also, what determines MMC1 vs MMC2 as the card's path for internal/external? Is it possible these paths would change at some date? I know some Linux distro's with SATA drives had a problem with the drives changing their /dev/sdX path every reboot. I know that MY Nokia isn't doing anything similar, but I figure it's possible that my /media/mmc1 might be internal, but for someone else it could be the external slot - or maybe in the next hardware revision or something. I did find the alias names located in the /sys/ path that specify internal is for one and external or removable or something for the other. Also, are the names and paths the same for the 770's? Since I have an n800 I don't know. I'm hesitant to read too much data from /sys/ because it all looks _so_ Maemo-specific I wonder if I will tie my code too closely to one hardware revision. Just looking for the most _compatible_ way to identify if/when and where a media card is present. And as usual, from Python. Thanks, Tony ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Finding the mmc cards
ext Tony Maro [EMAIL PROTECTED] writes: Also, what determines MMC1 vs MMC2 as the card's path for internal/external? The internal card is always mounted on /media/mmc2, and the external card is always mounted on /media/mmc1. You can also use the environment variables MMC_MOUNTPOINT and INTERNAL_MMC_MOUNTPOINT, but then you have to make sure that they are always set correctly in your environment. (I don't think using environment variables for this kind of system information is a good idea.) The device files are not constant like this: the internal card might be /dev/mmcblk0 or /dev/mmcblk1, as far as I understand. Someone with better low-level knowledge please correct me. Is it possible these paths would change at some date? It is possible, but I guess we stick with these locations for a long time. We could and should provide mechanisms so that applications don't need to hardcode the locations, but I don't see a reason why we should break applications that do hardcode them. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Python and GStreamer
Zeeshan Ali wrote: Hi! gstreamer is poo. plain and simple. Yes, you need to recreate the pipeline. If you don't, bad things happen, like hanging and such after EOS. And no, EOS detection still doesn't work well in that class despite my many tries. That sounds like a bug, have you cared to file it? Does the same happen when you try the same pipeline on a PC? Why would I file a bug? I need something that works on all firmwares. Filing a bug won't help that. Besides, I'm sure Nokia's developers couldn't help noticing that gstreamer was broken when they wrote OSSO Media Server. Why didn't *they* file a bug, eh? In addition, why don't you file a bug for me if it bothers you? I do that for Kagu's users all the time. I'm not really sure why everyone in the open source world expects end-users to file their own bugs. That doesn't seem very practical. You should consider this email a bug report, and you can consider the link to gstplayer.py in the previous email my test case. And if you need additional information, this thread will do nicely. Back on the subject of whether or not gstreamer is useful: Perhaps it's just a broken version of gstreamer that maemo uses, or perhaps the bug is elsewhere. It's just that it's broken for me/Kagu/us/maemo-users, so it isn't very useful to Kagu in it's current state and probably not very useful to Tony. Ultimately, I'm a selfish software developer and I've found my solution elsewhere. That's the extent of my interest. I have to move on to other things or else I'll never get anything done. -- Jesse Guardiani Programmer/Sys Admin [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Python and GStreamer
Hello again! Why would I file a bug? I need something that works on all firmwares. Filing a bug won't help that. Besides, I'm sure Nokia's developers couldn't help noticing that gstreamer was broken when they wrote OSSO Media Server. Why didn't *they* file a bug, eh? I wouldn't know, i am not a MediaServer developer but I don't see them saying 'gstreamer is poo' or moving to some other framework so that is why *you* need to file a bug, not them. In addition, why don't you file a bug for me if it bothers you? I do that for Kagu's users all the time. I'm not really sure why everyone in the open source world expects end-users to file their own bugs. If i find a bug in gstreamer (or any software), *I* will file a bug but it was you who found the bug so why am *i* supposed to file it? Back on the subject of whether or not gstreamer is useful: Perhaps it's just a broken version of gstreamer that maemo uses, or perhaps the bug is elsewhere. It's just that it's broken for me/Kagu/us/maemo-users, so it isn't very useful to Kagu in it's current state and probably not very useful to Tony. Concidering all these possibilities, I ask you again, is it reasonable to conclude gstreamer is poo and advertising that to others as a fact? Ultimately, I'm a selfish software developer and I've found my solution elsewhere. That's the extent of my interest. I have to move on to other things or else I'll never get anything done. That is fine, you should use whatever works for you. Nobody is forcing you to use gstreamer. -- Regards, Zeeshan Ali FSF member#5124 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Python and GStreamer
Zeeshan Ali wrote: Hello again! Why would I file a bug? I need something that works on all firmwares. Filing a bug won't help that. Besides, I'm sure Nokia's developers couldn't help noticing that gstreamer was broken when they wrote OSSO Media Server. Why didn't *they* file a bug, eh? I wouldn't know, i am not a MediaServer developer but I don't see them saying 'gstreamer is poo' or moving to some other framework so that is why *you* need to file a bug, not them. I just don't have any interest in filing a bug. Sorry. I already explained that. In addition, why don't you file a bug for me if it bothers you? I do that for Kagu's users all the time. I'm not really sure why everyone in the open source world expects end-users to file their own bugs. If i find a bug in gstreamer (or any software), *I* will file a bug but it was you who found the bug so why am *i* supposed to file it? Because you seem to be the one who cares about filing a bug. I don't. Back on the subject of whether or not gstreamer is useful: Perhaps it's just a broken version of gstreamer that maemo uses, or perhaps the bug is elsewhere. It's just that it's broken for me/Kagu/us/maemo-users, so it isn't very useful to Kagu in it's current state and probably not very useful to Tony. Concidering all these possibilities, I ask you again, is it reasonable to conclude gstreamer is poo and advertising that to others as a fact? Well, considering that this is a maemo list, yes, I think it's fair to declare that gstreamer is poo, and everyone should automatically assume that I mean gstreamer on maemo is poo. I'm not writing this on any other list, and you shouldn't assume that I mean any other platform other than maemo. -- Jesse Guardiani Programmer/Sys Admin [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Latest Release of UKMP does not Install Correctly
ext Acadia Secure Networks [EMAIL PROTECTED] writes: It now reads 1.621. So I went ahead and tried the click to install and this time it worked! Ok, so the author of ukmp (Urho?) has probably changed something. Interestingly, the message that came up while it was installing specified that it was installing version 1.61 not 1.621. That is likely because of bad bad packaging practices of the ukmp author. I know Urho likes to make packages without using the Debian tools and it is thus likely that his packages do not conform to Debian policy as well as they should. Using different versions in the filename and the meta data could be one example. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Finding the mmc cards
On 8/29/07, Marius Vollmer [EMAIL PROTECTED] wrote: The internal card is always mounted on /media/mmc2, and the external card is always mounted on /media/mmc1. And when the Nokia n900 (just guessing) gets released, and it has a memory stick socket or some other type of memory card, I assume we won't be able to rely on this anymore. But, sounds like for at least the short term (or long term in Internet years) relying on mount and /media/mmc* is the way to go. Assuming you don't need notifications of card insert. You can also use the environment variables MMC_MOUNTPOINT and INTERNAL_MMC_MOUNTPOINT, but then you have to make sure that they are always set correctly in your environment. (I don't think using environment variables for this kind of system information is a good idea.) Agreed. Especially with the numbers of morons like me that are likely to screw those up ;-) The device files are not constant like this: the internal card might be /dev/mmcblk0 or /dev/mmcblk1, as far as I understand. Someone with better low-level knowledge please correct me. I had thought this might be the case, especially since my /dev/mmcblk0 goes to /media/mmc2 and /dev/mmcblk1 goes to /media/mmc1 on my device. Seemed kind of reversed to me. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Doxygen?
On Tuesday 28 Aug 2007, Murray Cumming wrote: Where was doxygen actually? I've just noticed that the ARM doxygen package in Maemo Sardine doesn't actually seem to install a doxygen binary as it does in the X86 target. But maybe I'm not looking in all the right places. I found it (well that's actually a lie, find found it) in /scratchbox/devkits/doctools/bin -- Tony Green Ipswich, Suffolk, England http://www.beermad.org.uk http://no2id-ip.web-brewer.co.uk ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Running Microb after building it
With the help of timelyx and pupnik (IRC), I was able to build microb. I have microb-engine_1.0.3-13_armel.deb and other .debs under SDK_ARMEL. I tried dpkg -i and installation was successful (I had to install other .debs to get there). But I am not able to see Microb under Web in maemo (Xephyr). In some IRC log, I found that I need to do GRE_HOME=. and USE_LOCAL_GRE=1 and ./run-mozilla.sh ./TestGtkEmbed If I do this, yesterday I got error related to starting xpcom. Today, I am getting -- Couldn't find GTKMozEmbed symbols. Can somebody help me how to run the microb I built? As you can see, I built for SDK_ARMEL. Do I need to built for X86? In some IRC log I found that microb does not build for X86. How can I see my armel .deb running? Do I need to use QEMU ( I need to read about it yet) Help! ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Running Microb after building it
Antonio, Thanks. I checked out and did dpkg buildpackage -us -uc -nc -d. It failed with the following error. Looks like xpidl under microb-engine is missing. Do I need to build and install xpidl separately? I already installed libidl-dev. --- /scratchbox/tools/bin/sh: line 1: /usr/lib/microb-engine/xpidl: No such file or directory make[3]: *** [gtkmozembedmarshal.h] Error 127 make[3]: Leaving directory `/home/skumar/libgtkembedmoz/obj-arm-linux-gnueabi/sr c' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/skumar/libgtkembedmoz/obj-arm-linux-gnueabi' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/skumar/libgtkembedmoz/obj-arm-linux-gnueabi' make: *** [build-stamp] Error 2 --- On side notes, I mistakenly did apt-get install libgtkmozembed (not libgtkembedmoz) and after that It seemed to do something better, but failed eventually. I got the following error while Xphyr/af-fb.. is active. --- [sbox-SDK_ARMEL: ~/microb-engine-1.0.3/build-tree/obj-edyn-arm-sb-buildgtk2/dist/bin] export GRE_HOME=. [sbox-SDK_ARMEL: ~/microb-engine-1.0.3/build-tree/obj-edyn-arm-sb-buildgtk2/dist/bin] export USE_LOCAL_GRE=1 [sbox-SDK_ARMEL: ~/microb-engine-1.0.3/build-tree/obj-edyn-arm-sb-buildgtk2/dist/bin] export DISPLAY=:2 [sbox-SDK_ARMEL: ~/microb-engine-1.0.3/build-tree/obj-edyn-arm-sb-buildgtk2/dist/bin] ./run-mozilla.sh ./TestGtkEmbed www.google.com defined GRE_HOME=. defined DISPLAY=:2 new_gtk_browser menu bar tool bar location bar status bar qemu: uncaught target signal 11 (Segmentation fault) - exiting I then closed Xephyr, and then I got the following error. -- [sbox-SDK_ARMEL: ~/microb-engine-1.0.3/build-tree/obj-edyn-arm-sb-buildgtk2/dist/bin] ./run-mozilla.sh ./TestGtkEmbed www.google.com defined GRE_HOME=. defined DISPLAY=:2 Unsupported setsockopt level=1 optname=9 Unsupported setsockopt level=1 optname=9 Unsupported setsockopt level=1 optname=9 Unsupported setsockopt level=1 optname=9 Unsupported setsockopt level=1 optname=9 Unsupported setsockopt level=1 optname=9 TestGtkEmbed[4031]: GLIB WARNING ** Gtk - cannot open display: - Thanks, SP On 8/29/07, Antonio Gomes [EMAIL PROTECTED] wrote: sp, have you installed libgtkembedmoz as well ? https://garage.maemo.org/svn/browser/mozilla/trunk/libgtkembedmoz/ maybe installing it, and trying something like: $ cd /usr/lib/microb-engine $ export GRE_HOME=. $ export LD_LIBRARY_PATH=. $ ./run-mozilla.sh ./TestGtkEmbed google.com ? On 8/29/07, S P [EMAIL PROTECTED] wrote: With the help of timelyx and pupnik (IRC), I was able to build microb. I have microb-engine_1.0.3-13_armel.deb and other .debs under SDK_ARMEL. I tried dpkg -i and installation was successful (I had to install other .debs to get there). But I am not able to see Microb under Web in maemo (Xephyr). In some IRC log, I found that I need to do GRE_HOME=. and USE_LOCAL_GRE=1 and ./run-mozilla.sh ./TestGtkEmbed If I do this, yesterday I got error related to starting xpcom. Today, I am getting -- Couldn't find GTKMozEmbed symbols. Can somebody help me how to run the microb I built? As you can see, I built for SDK_ARMEL. Do I need to built for X86? In some IRC log I found that microb does not build for X86. How can I see my armel .deb running? Do I need to use QEMU ( I need to read about it yet) btw, try building it for i386 first ...;) -- --Antonio Gomes ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
OSSO Media Server and system pauses
Okay, so I ripped out gstreamer and put in OSSO Media Server code. The thing I've noticed is that there's a distinct pause of about 1 second in my code when you start a new song playing. I didn't have this issue with gstreamer (though the other issues with gstreamer far outweigh the new problem.) Without using threads it was nearly a 2.5 second pause, so using a thread helped. For a media player app this wouldn't be a problem, but for a game, it's murder. I've run cProfile and it says there's only a .02 second delay in the send_cmd function, but there's a definite pause in user input of about one second. I'm going through all this pain because the pygame sound routines can't use the Maemo sound hardware... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: OSSO Media Server and system pauses
Yeah, it's using dbus, which is a bit less than instantaneous in this case. Sorry, I don't have any suggestions. Tony Maro wrote: Okay, so I ripped out gstreamer and put in OSSO Media Server code. The thing I've noticed is that there's a distinct pause of about 1 second in my code when you start a new song playing. I didn't have this issue with gstreamer (though the other issues with gstreamer far outweigh the new problem.) Without using threads it was nearly a 2.5 second pause, so using a thread helped. For a media player app this wouldn't be a problem, but for a game, it's murder. I've run cProfile and it says there's only a .02 second delay in the send_cmd function, but there's a definite pause in user input of about one second. I'm going through all this pain because the pygame sound routines can't use the Maemo sound hardware... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- Jesse Guardiani Programmer/Sys Admin [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: OSSO Media Server and system pauses
I may have found the issue - in the Kagu code. Investigating further still. I noticed that it was creating a new thread and RPC every time you start a new song, and things seem to work just fine without doing that... On 8/29/07, Tony Maro [EMAIL PROTECTED] wrote: Okay, so I ripped out gstreamer and put in OSSO Media Server code. The thing I've noticed is that there's a distinct pause of about 1 second in my code when you start a new song playing. I didn't have this issue with gstreamer (though the other issues with gstreamer far outweigh the new problem.) Without using threads it was nearly a 2.5 second pause, so using a thread helped. For a media player app this wouldn't be a problem, but for a game, it's murder. I've run cProfile and it says there's only a .02 second delay in the send_cmd function, but there's a definite pause in user input of about one second. I'm going through all this pain because the pygame sound routines can't use the Maemo sound hardware... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Is Nokia 770 Supported ?
Hi Folks, I have been trying to build gtk with the latest root strap from http://repository.maemo.org/stable/gregale/armel/Maemo_Dev_Platform_v2.2_armel-rootstrap.tgz without much success. It fails in config. After reading though the mailing list I get the sense that this is a legacy product for Nokia. Regards Vasant Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7 ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: OSSO Media Server and system pauses
Feel free to post a patch if you've got one. Tony Maro wrote: I may have found the issue - in the Kagu code. Investigating further still. I noticed that it was creating a new thread and RPC every time you start a new song, and things seem to work just fine without doing that... On 8/29/07, *Tony Maro* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Okay, so I ripped out gstreamer and put in OSSO Media Server code. The thing I've noticed is that there's a distinct pause of about 1 second in my code when you start a new song playing. I didn't have this issue with gstreamer (though the other issues with gstreamer far outweigh the new problem.) Without using threads it was nearly a 2.5 second pause, so using a thread helped. For a media player app this wouldn't be a problem, but for a game, it's murder. I've run cProfile and it says there's only a .02 second delay in the send_cmd function, but there's a definite pause in user input of about one second. I'm going through all this pain because the pygame sound routines can't use the Maemo sound hardware... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- Jesse Guardiani Programmer/Sys Admin [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Rotated tabs not supported by Hildon
It is possible to get the theme to work on rotated tabs using the procedure that I outlined. The only useful documentation I found was at the maemo site: http://maemo.org/development/documentation/how-tos/3-x/howto_customization_bora.html I never did find any documentation on parameters in gtkrc (e.g., the border and gap_side parameters in the image structure). However, I made some guesses that seem to work. It would still be interesting to know where the documentation is hiding. I'll check with the gtk+ newsgroup. -- Jeffrey Barish ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
osso.Context vs. PyGame: osso.DeviceState(context).display_blanking_pause() issue
Some of you might have seen the screenshot of my (work-in-progress)
Python-based maemoClock application on the itt forum
However, I've now wasted too many evenings trying to fix a strange issue and
would be very glad for any help/ideas:
I'm trying to use the osso.DeviceState(context).display_blanking_pause() in
Python to keep the screen from dimming and blanking.
However, while the following codesnippet works on Benoit's (pygtkeditor) IT, it
just won't work on my N800, freshly flashed, Python 2.5 installed :-(
Here is the relevant code prototype:
##
#!/usr/bin/python
import pygame
from pygame.locals import *
import os
import datetime
import math
import osso
import gobject
#from sun import *
EVT_STEP = pygame.USEREVENT
EVT_STEPSCREEN = pygame.USEREVENT+1
backBottom = pygame.Surface((800, 80))
# Class that handles all display stuff
class display:
def __init__(self):
pygame.init()
pygame.display.set_caption('maemoClock')
self.scale = False
self.screen = pygame.display.set_mode((800,480),FULLSCREEN,16)
self.back = pygame.Surface((800, 480))
def UpdateTime(self):#Simply write time and date onto the screen
#Reset bottom to black
self.screen.blit(backBottom, (0,400))
#Update time
font = pygame.font.Font(None, 96)
theTime = datetime.datetime.now().strftime(%X)
theDate = datetime.datetime.now().strftime(%a %d %b)
textTime = font.render(theTime, 1, (128, 128, 255, 192))
textDate = font.render(theDate, 1, (128, 128, 255, 192))
self.screen.blit(textTime,
(0,self.screen.get_height()-textTime.get_height()))
self.screen.blit(textDate,
(self.screen.get_width()-textDate.get_width(),self.screen.get_height()-textTime.get_height()))
#Update display
pygame.display.flip()
#Display-
def keepDisplayOn(device_state):
print keepDisplayOn() at + datetime.datetime.now().strftime(%X)
if device_state is not None:
device_state.display_blanking_pause()
print display_blanking_pause() at +
datetime.datetime.now().strftime(%X)
return True#or gobject will stop calling the timeout_add
def main():
osso_ctxt = osso.Context(com.tomch.maemoclock, 0.1, False)
applic = osso.Application(osso_ctxt)
device_state = osso.DeviceState(osso_ctxt)
d = display()
d.UpdateTime()
pygame.time.set_timer(EVT_STEP, 1000)#Update the seconds display
every second
pygame.time.set_timer(EVT_STEPSCREEN, 8000) #Re-activate the screen every
8 seconds
pygame.mouse.set_visible(False) #disable the cursor
# Wait for user input
while True:
event = pygame.event.wait()
if (event.type == KEYUP) and (event.key == 287): # Fullscreen button / F6
: Toggle fullscreen
pygame.display.toggle_fullscreen()
elif (event.type == EVT_STEP): #Timer-Event
d.UpdateTime()
elif (event.type == EVT_STEPSCREEN) : #Timer-Event
keepDisplayOn(device_state)
elif (event.type == MOUSEBUTTONDOWN): #Touchscreen-Event
break
print Event + str(event.type)
if __name__ == '__main__':
main()
##
While the events get called, nothing ever happens with the display on my N800 -
it simply keeps dimming and blanking...
OTOH, If I call the display_blanking_pause() in the main() loop, the call will
work (for once). So the API does work.
If I play around with the examples from the wiki doc
(osso_test_device_blank_pause.py, osso_test_device_on.py), they both work, too.
However, once I start shifting the timer from a gobject.timeout_add to an
pygame.time.set_timer, the calls to display_blanking_pause (in the function
called by the timer) won't do anything anymore.
My guess is that I'm somehow losing the osso.context.
Helpy anbody? Does that code snippet work on your device, keeping your screen
from dimming and blanking?
Anybody who can explain what is happening?
Thanks!
-Tom (desperate, bordering towards madness :-)
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: General Maemo/Scratchbox/N800 help
Some people seem to have issues that completely corrupt beyond repair a MMC card and it seems to be possibly tied to using the USB cable to transfer files to/from your PC and the MMC card in the Nokia. It's possible that cards experiencing this problem are not completely corrupted beyond repair, but that they've simply had their FAT tables damaged to the point where most software can't deal with them. FAT32 devices seem to have a particular problem, in that if certain elements of the FAT table get corrupted, they appear to be completely unusable. This kind of damage can be repaired using the Disk Manager on Windows XP or 2000. If you use this to reformat such a device, it will come back to life quite successfully (but be prepared for a bit of a wait while the Disk Manager decides that the device is not properly formatted and that it can't therefore show its current format). David Hazel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: OSSO Media Server and system pauses
This is the result of communicating with Tony and Kemal (disq) off list: https://www.guardiani.us/projects/kagu/changeset/483 Seems to have always been that way. Probably just a typo. Jesse Guardiani wrote: Feel free to post a patch if you've got one. Tony Maro wrote: I may have found the issue - in the Kagu code. Investigating further still. I noticed that it was creating a new thread and RPC every time you start a new song, and things seem to work just fine without doing that... On 8/29/07, *Tony Maro* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Okay, so I ripped out gstreamer and put in OSSO Media Server code. The thing I've noticed is that there's a distinct pause of about 1 second in my code when you start a new song playing. I didn't have this issue with gstreamer (though the other issues with gstreamer far outweigh the new problem.) Without using threads it was nearly a 2.5 second pause, so using a thread helped. For a media player app this wouldn't be a problem, but for a game, it's murder. I've run cProfile and it says there's only a .02 second delay in the send_cmd function, but there's a definite pause in user input of about one second. I'm going through all this pain because the pygame sound routines can't use the Maemo sound hardware... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers -- Jesse Guardiani Programmer/Sys Admin [EMAIL PROTECTED] ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Finding the mmc cards
I've added bug #1930. I hope I've done it right, because even that procedure isn't particularly clear. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Eero Tamminen Sent: 29 August 2007 10:40 To: ext [EMAIL PROTECTED] Cc: maemo-developers@maemo.org Subject: Re: Finding the mmc cards Hi, Please file a documentation bug into Maemo Bugzilla. We need this documented. Handling of removable medias, especially with file systems as easily corrupted as FAT, needs special care from applications (stop using files when pre-unmount message is delivered on them so that unmounts succeed, do better error handling etc.) - Eero ext [EMAIL PROTECTED] wrote: I agree that assuming mmc1 and mmc2 is potentially dangerous. In an answer to my original question on this subject, someone suggested that mmc0 and mmc1 were the correct names, whereas in my Scratchbox environment they are mmc1 and mmc2. Consequently, when I was implementing a scan for memory cards, I opted to look in the /media folder for files whose names begin mmc, and to assume that any such file I find might be a memory card. This appears to work (in the test/development environment), but personally I hate making those kinds of assumptions. I would far rather have a definitive statement from someone to the effect that if you do X, this will guarantee to find the memory cards and nothing else. For me, this is particularly important, as my application will be sold commercially and needs to work under all circumstances. David Hazel After our thread some weeks ago regarding reading the serial number from a MMC card, I've since implemented detection of the MMC card's presence by the existence of those same files. I know my solution works on my device perfectly. I figure it's probably a bad decision, because the architecture could change somewhat with the next hardware or software release. Can someone tell me, is there an approved / documented way of identifying the location of any MMC cards currently installed? I've noticed you can't simply look for /media/mmcX because that directory will exist even if there is no card inserted. Also, what determines MMC1 vs MMC2 as the card's path for internal/external? Is it possible these paths would change at some date? I know some Linux distro's with SATA drives had a problem with the drives changing their /dev/sdX path every reboot. I know that MY Nokia isn't doing anything similar, but I figure it's possible that my /media/mmc1 might be internal, but for someone else it could be the external slot - or maybe in the next hardware revision or something. I did find the alias names located in the /sys/ path that specify internal is for one and external or removable or something for the other. Also, are the names and paths the same for the 770's? Since I have an n800 I don't know. I'm hesitant to read too much data from /sys/ because it all looks _so_ Maemo-specific I wonder if I will tie my code too closely to one hardware revision. Just looking for the most _compatible_ way to identify if/when and where a media card is present. And as usual, from Python. Thanks, Tony ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: General Maemo/Scratchbox/N800 help
On 8/29/07, David Hazel [EMAIL PROTECTED] wrote: It's possible that cards experiencing this problem are not completely corrupted beyond repair, but that they've simply had their FAT tables damaged to the point where most software can't deal with them. FAT32 devices seem to have a particular problem, in that if certain elements of the FAT table get corrupted, they appear to be completely unusable. This kind of damage can be repaired using the Disk Manager on Windows XP or 2000. If you use this to reformat such a device, it will come back to life quite successfully (but be prepared for a bit of a wait while the Disk Manager decides that the device is not properly formatted and that it can't therefore show its current format). I didn't mean to turn this into a discussion of the bug, but from what I've read there are some apparently very technically capable people who have tried to low-level format cards after the failure using Windows and they refuse to be fixed. Anyway it's just a caution, it hasn't happened to me personally. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Finding the mmc cards
You can also use the environment variables MMC_MOUNTPOINT and INTERNAL_MMC_MOUNTPOINT, but then you have to make sure that they are always set correctly in your environment. (I don't think using environment variables for this kind of system information is a good idea.) Those environment variables seem oddly inconsistent to an ex-VMS man like me. Why not EXTERNAL_MMC_MOUNTPOINT and INTERNAL_MMC_MOUNTPOINT? Otherwise it's necessary to remember which one the unqualified MMC_MOUNTPOINT refers to (e.g. by remembering that the other one starts with INTERNAL rather than EXTERNAL - which itself is counter-intuitive, as I would expect the internal one to be the more important and therefore the unqualified one). I also picked up on Tony's reply regarding the way in which /dev/mmcblk0 and /dev/mmcblk1 seem to be reversed in semantics with respect to the cards they relate to. With these two examples of inconsistency in card mappings, it seems all the more important to me that some kind of API is provided that can enumerate the cards with certainty (and with logical/naming consistency, please!) and can determine a range of useful information about the cards. Here are some ideas for the kind of information such an API might want to be able to retrieve: - serial number - capacity - whether FAT16 or FAT32 formatted - mountpoint - device file name - whether write protected (yes, you can write-protect an SD card) David Hazel ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Finding the mmc cards
On 8/29/07, David Hazel [EMAIL PROTECTED] wrote: - whether write protected (yes, you can write-protect an SD card) Yes, but the Nokia's do not support or honor that switch. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Python and GStreamer
Jesse Guardiani [EMAIL PROTECTED] wrote: And no, before you ask, I don't think it's not Nokia's fault. gstreamer is just unexpectedly buggy. Too bad ALSA doesn't support inline mp3 decoders... life would be easier for all of us... I've been wondering: what is the performance hit for not going through gstreamer? So based on my understanding, going through gstreamer, the mp3 is decoded on the DSP. Supposing it was decoded on the cpu and sent out through alsa, which of the following is likely to be true: - The CPU wouldn't be able to handle it (playback would skip) - The CPU could handle it just as well as the DSP but the rest of the system might be less usable - The battery life would decrease (how much?) - some other reason this wouldn't work well? And the related question is: given an existing program that sends stuff out to ALSA and doesn't use gstreamer, how difficult is it generally to port it so that it works properly? By this, I'm thinking of a typical C program that plays mp3 files. Would it likely require a complete rework of the code structure or is it probably a trivial replacement of function calls? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Python and GStreamer
On 8/30/07, Austin Che [EMAIL PROTECTED] wrote: I've been wondering: what is the performance hit for not going through gstreamer? So based on my understanding, going through gstreamer, the mp3 is decoded on the DSP. Supposing it was decoded on the cpu and sent out through alsa, which of the following is likely to be true: Well I can only say this - my experience now using osso media player instead of gstreamer is that I can play, pause, start and stop my MP3 media stream without affecting the frame rate of my game, and if it's not affecting my frame rate, I'm unconcerned with if it happens in the DSP or not ;-) Also, Kagu is very good on battery life when using it, so I'm not too concerned about battery suck with it. But obviously I'm no expert - I've only used it for a day. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
