[maemo-developers] [maemo-developers] Newbie Question

Thu Feb 8 23:42:42 EET 2007

SR TECHNOLOGIES, INC PROPRIETARY INFORMATION:
Proprietary information owned by SR Technologies, Inc that require protection from unauthorized disclosure.

Hi,
I am an extreme newbie at this. I have a C app that I have compiled
using gcc. I tested in Scratchbox (SDK_ARMEL) and low and behold it
works... Now, this application is run from the command line. These are
my questions to the gurus out there:

1. How do I copy it on the N800 so that I can run with xterm (with
gainroot)? When I copy it to the mmc1 and attempt to run it from there I
encounter an error saying : "Syntax error: "(" expected.

2. How do I install it into Xephyr in order to test it on my Ubuntu
machine?

I have done a lot of reading, but am still unable to figure it out. I
was hoping that someone out there would be able to help out.

Thanks.
Michael

-----Original Message-----
From: maemo-developers-bounces at maemo.org
[mailto:maemo-developers-bounces at maemo.org] On Behalf Of
maemo-developers-request at maemo.org
Sent: Thursday, February 08, 2007 11:08 AM
To: maemo-developers at maemo.org
Subject: maemo-developers Digest, Vol 22, Issue 50

Send maemo-developers mailing list submissions to
	maemo-developers at maemo.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://maemo.org/mailman/listinfo/maemo-developers
or, via email, send a message with subject or body 'help' to
	maemo-developers-request at maemo.org

You can reach the person managing the list at
	maemo-developers-owner at maemo.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of maemo-developers digest..."

Today's Topics:

   1. RE: Xvideo support for Nokia 770? (Devesh.Kothari at nokia.com)
   2. Re: MMH project started (Zoran Kolic)
   3. RE: Dream Scenario (Re: Maemo roadmap,	SDK improvements...)
      (Devesh.Kothari at nokia.com)
   4. Re: Dream Scenario (Re: Maemo roadmap,	SDK improvements...)
      (Dave Neuer)
   5. RE: Xvideo support for Nokia 770? (Simon Pickering)
   6. Re: Can we launch Maemo UI by multiple users	connected to a
      server (Kalle Vahlman)
   7. Re: Re: MMH project started (Aniello Del Sorbo)

----------------------------------------------------------------------

Message: 1
Date: Thu, 8 Feb 2007 17:29:02 +0200
From: <Devesh.Kothari at nokia.com>
Subject: RE: [maemo-developers] Xvideo support for Nokia 770?
To: <siarhei.siamashka at gmail.com>, <maemo-developers at maemo.org>
Message-ID:

<99AAA0EB3F96B04CAAA1935181CF6DE5039D7BFD at esebe104.NOE.Nokia.com>
Content-Type: text/plain;	charset="US-ASCII"

>-----Original Message-----
>From: maemo-developers-bounces at maemo.org 
>[mailto:maemo-developers-bounces at maemo.org] On Behalf Of ext 
>Siarhei Siamashka
>Sent: 08 February, 2007 09:16
>To: maemo-developers at maemo.org
>Subject: Re: [maemo-developers] Xvideo support for Nokia 770?
>
>Hello, 
>
>It would be probably a good idea to discuss different 
>possibilities for improving multimedia support on 770/N800.
>
>Now we have a fast JIT scaler that runs on ARM core, it solves 
>all the video resolution related performance problems. I'm 
>going to work on improving quality, performance and its 
>inclusion into upstream ffmpeg library, this task is in my 
>nearest plans:
>http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2007-January/0
>51209.html
>
>As for the ways of improving multimedia support on Nokia 770, 
>it may be done in the following ways (in no particular order):
>1. Continue ffmpeg optimizations (motion compensation 
>functions, finetune idct, have a look at the possibilities to 
>optimize codecs other than mpeg4 and its variants) 2. 
>Implement Xvideo extension support for Nokia 770 (using 
>scaling done on ARM core) 3. Implement XvMC in some way (using 
>C55x DSP for it as it is supposedly good for IDCT and motion 
>compensation stuff) 4. Improve GStreamer plugins (replacements 
>for dspfbsink and dspmpeg4sink running on ARM core, it could 
>probably improve mpeg4 playback performance a lot and allow 
>using higher video bitrates and resolutions that are currently 
>available in MPlayer) 5. Try to relay color format conversion 
>and scaling to DSP. If it works as expected, video scaling can 
>be done with almost zero overhead for ARM core. Theoretically 
>the same trick could probably also work for GStreamer if video 
>output sink can provide its own buffer (::buffer_alloc). The 
>first step would be to try just doing nonscaled color format 
>conversion. If it is successful, some more advanced stuff can 
>be tried such as JIT dynamic code generation on C55x.
>6. Try porting vorbis decoder (tremor) to DSP 7. Try porting 
>libmpeg2 to DSP. With audio decoding and scaling done on ARM 
>core, it might improve overall mpeg2 playback performance, I 
>wonder if nonconverted DVD video playback is even 
>theoretically possible on Nokia 770.
>
>That's quite a big list and it contains some things that might 
>be generally nice to have, but have relatively low practical 
>value and are actually not worth efforts implementing :)
>
>There are two issues that need to be solved for this all to 
>become reality:
>1. We need some way of applying community developed upgrades 
>for core system components such as xserver and xlib (if we go 
>after Xvideo support on Nokia 770). They must be easy to 
>install by end users, otherwise this all development does not 
>make much sense. It would be also nice to integrate these 
>improvements into official firmware later, but I wonder if 
>Nokia has spare resources for doing this integration and its 
>quality assurance.

>2. Reliable information that is detailed enough for performing 
>graphics and audio output from DSP, see 
>http://maemo.org/pipermail/maemo-developers/2007-February/007949.html

Again throwing some options in the air
1. Dump DSP. If I remember the driver for the audio chip is in the omap
tree. So (probably never tried) is to remove all dsp related components
from the image, and then have everything purely on ARM [maybe worth a
shot]
2. use ALSA DSP

Devesh

>_______________________________________________
>maemo-developers mailing list
>maemo-developers at maemo.org
>https://maemo.org/mailman/listinfo/maemo-developers
>

------------------------------

Message: 2
Date: Thu, 8 Feb 2007 16:32:34 +0100
From: Zoran Kolic <zkolic at sbb.co.yu>
Subject: [maemo-developers] Re: MMH project started
To: maemo-developers at maemo.org
Message-ID: <20070208153234.GA986 at faust.net>
Content-Type: text/plain; charset=us-ascii

> I have started a new project on the garage.maemo.org

It looks like sound idea. A little bit closer to big box feeling. Just
would like to suggest "getmail" as mail fetcher, since it doesn't wait
for something on port 25. Connects to ports 110 and 995 on remote ser-
ver and puts the content right to mbox or maildir, whereever you want.
No need to do anything, hence it is python. My favorite "mutt" is now in
colection. "Procmail" could filter to different directories as you
expect, if really necessary. Little mail sender could be added. I liked
"ssmtp", but "esmtp" is fine also. "Mutt" could be configured to pipe
outgoing mail to "ssmtp" to reach remote smtp server. No big deal, as I
see it. I have getmail and mutt working on 770, just ssmtp has to be
compiled. I remember cacher for mutt, if you want the mail to be spooled
and sent from file/directory.
Memory footprint is the only backward of any idea in this direction. I
agree that postfix cannot be taken as solution. Never used procmail and
have nothing to say pro or contra. Little perl script that reads headers
accordingly?
Btw, yesterday I found it impossible to update repositories. Something
changed?
Best regards

                                            Zoran

------------------------------

Message: 3
Date: Thu, 8 Feb 2007 17:36:23 +0200
From: <Devesh.Kothari at nokia.com>
Subject: RE: [maemo-developers] Dream Scenario (Re: Maemo roadmap,
SDK
	improvements...)
To: <abos at hanno.de>, <maemo-developers at maemo.org>
Message-ID:

<99AAA0EB3F96B04CAAA1935181CF6DE5039D7C1F at esebe104.NOE.Nokia.com>
Content-Type: text/plain;	charset="US-ASCII"

One way to start would be 

- look at the developer rootfs (it includes the package db). I think
this info is also available from package list, which enable you to
create your own packages (sometimes also refered to as black list ;)
- cross check with the ones available in maemo repo

You will get the number of binary only packages. This gives a start
point. 
Would be interesting to know the number so we can quantify what % of the
total is closed binary only. On top of my head that number would be less
than 5%. How about Maemo team ??? Any takers :)

Devesh

>-----Original Message-----
>From: maemo-developers-bounces at maemo.org 
>[mailto:maemo-developers-bounces at maemo.org] On Behalf Of ext 
>Hanno Zulla
>Sent: 07 February, 2007 12:53
>To: maemo-developers at maemo.org
>Subject: Re: [maemo-developers] Dream Scenario (Re: Maemo 
>roadmap,SDK improvements...)
>
>Jorge Salamero Sanz schrieb:
>> so why nokia is claiming they have an oss product if they are not 
>> making any effort to open it ?
>
>Allow me to rephrase this a bit less harsh. Nokia, so far, is 
>doing a really good job and just because the flamewar is the 
>de-facto mode of discussion between most FOSS developers, I'm 
>not trying to flame Nokia into submission to my wishes...
>
>So far, Nokia has tried to attract application developers. 
>That's the layer above the platform.
>
>I would like to tinker with the platform, though.
>
>Making this possible will require an added layer of 
>development material for non-Nokia folks.
>
>It would be nice if Nokia could make this possible and I am 
>naive enough to believe that this is doable /and/ in the best 
>interest for both parties.
>
>(Nokia developers, if there is a way where we can - politely - 
>ask for this from your keepers / project managers, let me know.)
>
>Regards,
>
>Hanno
>
>
>_______________________________________________
>maemo-developers mailing list
>maemo-developers at maemo.org
>https://maemo.org/mailman/listinfo/maemo-developers
>

------------------------------

Message: 4
Date: Thu, 8 Feb 2007 10:40:52 -0500
From: "Dave Neuer" <dave.neuer at pobox.com>
Subject: Re: [maemo-developers] Dream Scenario (Re: Maemo roadmap,
SDK
	improvements...)
To: "Devesh.Kothari at nokia.com" <Devesh.Kothari at nokia.com>
Cc: maemo-developers at maemo.org, Daniel.Stone at nokia.com
Message-ID:
	<161717d50702080740qc4c3e2bpb56d3e0421e94cbc at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

On 2/8/07, Devesh.Kothari at nokia.com <Devesh.Kothari at nokia.com> wrote:
> >>
> >> Also, the FIASCO generator would presumably have to be
> >opened for this
> >> to happen.
> >
> >Carl said this too, and I'm unclear as to the dependency of an
> >all-open-source FIASCO image on opening the flasher tool; it
> >seems like I can already package up a new image using the
> >closed-source flasher, no?
>
> Its been a while, don't know if that has changed
> FIASCO is more of a container, flasher is able to seperately flash
> kernel, jffs2 rootfs etc. I think if I remember correctly you could
even
> extract different parts in a FIASCO image using the flasher.
>

Right, I guess I assumed (incorrectly, it turns out) that since the
flasher can take the apart, it can also put them together.

While it seems ideally that one would like to have a tool that can
assemble and flash a full image, it's obviously not necessary.

Also, it seems like the FIASCO image can't be much more than the
sections w/ some kind of header, and maybe a checksum; it seems like
they could be trivially reverse engineered by someone who hadn't
agreed to the EULA (or lived in a country where the EULA restrictions
on reverse engineering were unenforceable).

Dave

------------------------------

Message: 5
Date: Thu, 8 Feb 2007 15:46:28 -0000
From: Simon Pickering <S.G.Pickering at bath.ac.uk>
Subject: RE: [maemo-developers] Xvideo support for Nokia 770?
To: Devesh.Kothari at nokia.com, siarhei.siamashka at gmail.com,
	maemo-developers at maemo.org
Message-ID: <036d01c74b98$4c7114e0$6f41268a at enpcsmm11>
Content-Type: text/plain;	charset="us-ascii"

> >2. Reliable information that is detailed enough for performing
graphics 
> >and audio output from DSP, see 
> >http://maemo.org/pipermail/maemo-developers/2007-February/007949.html
> 
> Again throwing some options in the air
> 1. Dump DSP. If I remember the driver for the audio chip is 
> in the omap tree. So (probably never tried) is to remove all 
> dsp related components from the image, and then have 
> everything purely on ARM [maybe worth a shot] 2. use ALSA DSP

It seems a shame to drop use of the DSP. It may be generally hard to
program
well, but even off-loading some parts (of otherwise ARM code) to the DSP
will
free up the ARM CPU to do more.

Add to this the interest involved in hacking/writing code for the DSP
and this
is something I certainly want to pursue.

As a final point, if the hardware is there, don't you find it
frustrating not
being able to use it? DSP, IVA, 2D/3D acceleration - all just sat there
waiting
to be exploited (if we can find out how to do so)!

It would just be nice if the DSP learning curve could be made a little
less
steep (and less opaque). With that said I'll keep fiddling with the DSP
tools in
the hope I find the right combination.

Cheers,

Simon

------------------------------

Message: 6
Date: Thu, 8 Feb 2007 17:56:23 +0200
From: "Kalle Vahlman" <kalle.vahlman at gmail.com>
Subject: Re: [maemo-developers] Can we launch Maemo UI by multiple
	users	connected to a server
To: "Sampath Goud" <sampath.baddam at gmail.com>
Cc: maemo-developers at maemo.org
Message-ID:
	<177e83dd0702080756k6b895c0eq8b5b607b446336fd at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed

2007/2/8, Sampath Goud <sampath.baddam at gmail.com>:
> Hi,
> Can somebody let me know if we can lauch Maemo UI from different
logins:

Yes, it can be done, though it might require some effort. The problems
arise from the fact that the maemo initscripts and such do not ensure
their presence in /tmp is unique to the user (or in some cases like
D-Bus, unique at all).

That's why Sapwood refuses to start another instance of itself, why
D-Bus isn't able to start the session bus etc.

I've done it, but it required some mucking around in /etc changing the
configs (for example D-Bus) and/or the initscripts to make them add a
user prefix/suffix to their /tmp stuff. Unfortunately it was a while
ago and I didn't take the details down...

The other solution might be to mount a per-user tmp over the tmp which
is visible inside Scratchbox, but I'm not sure if that's possible (SB
is a web of links and mounts so it's hard to tell directly what will
happen... ;). But worth a try I guess.

-- 
Kalle Vahlman, zuh at iki.fi
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi

------------------------------

Message: 7
Date: Thu, 08 Feb 2007 17:07:40 +0100
From: Aniello Del Sorbo <anidel at gmail.com>
Subject: Re: [maemo-developers] Re: MMH project started
To: maemo-developers at maemo.org
Message-ID: <45CB4ACC.6080308 at gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Zoran Kolic wrote:
>> I have started a new project on the garage.maemo.org
> 
> It looks like sound idea. A little bit closer to big box feeling. Just
> would like to suggest "getmail" as mail fetcher, since it doesn't wait
> for something on port 25. Connects to ports 110 and 995 on remote ser-
> ver and puts the content right to mbox or maildir, whereever you want.
> No need to do anything, hence it is python. My favorite "mutt" is now
in
> colection. "Procmail" could filter to different directories as you
> expect, if really necessary. Little mail sender could be added. I
liked
> "ssmtp", but "esmtp" is fine also. "Mutt" could be configured to pipe
> outgoing mail to "ssmtp" to reach remote smtp server. No big deal, as
I
> see it. I have getmail and mutt working on 770, just ssmtp has to be
> compiled. I remember cacher for mutt, if you want the mail to be
spooled
> and sent from file/directory.
> Memory footprint is the only backward of any idea in this direction. I
> agree that postfix cannot be taken as solution. Never used procmail
and
> have nothing to say pro or contra. Little perl script that reads
headers
> accordingly?
> Btw, yesterday I found it impossible to update repositories. Something
> changed?
> Best regards
> 
>                                             Zoran

I think I will skip procmail has it has some problems. On the fetchmail 
homepage they talk about it and say it does not report errors correctly 
so people risk to loose mails without noticing, and I do not like that 
at all. Also on the maildrop website they also report another problem 
with procmail, that is it will read the ENTIRE mail in memory before 
processing it! That's completely unacceptable for us. Moreover it's 
procmailrc uses a very complicated syntax.
So I am pretty sure I will skip it, probably in favor of maildrop.

I will take a look at getmail, even if right now it seems that fetchmail

does everything I need. It can be configured to get mail from almost 
every server out there (and I did succeed for example in getting mail 
from gmail) and it can be configured to deliver mail via a local MDA 
(like maildrop for instance) that can filter and deliver locally the
mails.
If getmail does support filtering, I might consider it.
If not I think the combination of fetchmail+maildrop should be enough to

locally deliver mail.
(EDIT: I just read the getmail FAQ "Why did you write getmail? Why not 
just use fetchmail?". I will take a deep check on getmail, thanks!)

To correctly handle mails with MIME support, correct replying AND 
sending, I was thinking about nmh (hence the name 'mmh').
It is a set of command line tools to 'handle' mails. Handling means also

sending it directly to the remote MX (so to fill up the gap on sending 
e-mails).
In the case the user wants a delayed deliver, I can simply use "at" or 
cron or something that can invoke the command line command at a 
specified time.

Indeed the footprint IS an issue.
'nmh' is quite big and python is big also.
But I think, with the advent of programs like Obscura and gPodder, many 
people will install python anyway, so that should not be a big issue.
(also if I/we choose getmail, it won't be an option, it'll be mandatory
:) )

I am aware of little mail senders, but I still prefer the nmh path as it

also gives me mail handling. Thus the Python UI will 'just' have to show

everything in a friendly manner.

Everything in the spirit of Unix:
Each tool can do one simple thing, and do it better!

Thanks a lot for your suggestions.

--
anidel

------------------------------

_______________________________________________
maemo-developers mailing list
maemo-developers at maemo.org
https://maemo.org/mailman/listinfo/maemo-developers

End of maemo-developers Digest, Vol 22, Issue 50
************************************************