Re: [MeeGo-dev] Sensor Framework : Is input devices are must for acceleromter/magnetometer
Thanks Timo Markus for information -Original Message- From: Rongas Timo [mailto:timo.ron...@digia.com] Sent: Tuesday, November 30, 2010 4:02 PM To: Preetham-rao K; meego-dev@meego.com Subject: RE: [MeeGo-dev] Sensor Framework : Is input devices are must for acceleromter/magnetometer From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of Preetham-rao K We are seeing many adopter examples in Sensor framework, Is input device interface a must for accelerometer/magnetometer or Sysfs interface will do(as supported by Sysfsadopter?) Sysfs interface will work just as well, as long as there is a suitable adaptor plug-in in sensorfw. Currently there is only input device plug-in for accelerometer, so you will have to add a new one to read your interface. // Timo ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Sensor Framework: Show_als application not working on QT mobility level
We are just wondering about the messages.
We have written just a adopter plug-in (as attached in previous mail)
and we have debug messages in als adopter but none seems to be coming..
Is there a way to test it in client API test(like alsadopter and alssensor are
working properly)?
By default code is this one...
void ClientApiTest::testALSSensor()
{
QString sensorName(alssensor);
SensorManagerInterface sm = SensorManagerInterface::instance();
QVERIFY( sm.isValid() );
// Attempt to get another control session
ALSSensorChannelInterface* failIfc =
ALSSensorChannelInterface::controlInterface(sensorName);
QVERIFY2(!failIfc, Got another control session);
}
This is what we understand for MeeGO
Qt mobility:
Application--(Qsensor. QAmbientLightReading)--(sensor backend/our case it may
falling to mameo6)
Sensor Framework:(Sensor backend)
Plug-in interface--(alssensor and alsadopter)
-Original Message-
From: Rongas Timo [mailto:timo.ron...@digia.com]
Sent: Wednesday, December 01, 2010 1:26 PM
To: Preetham-rao K; meego-dev@meego.com
Subject: RE: [MeeGo-dev] Sensor Framework: Show_als application not working on
QT mobility level
-Original Message-
From: meego-dev-boun...@meego.com
[mailto:meego-dev-boun...@meego.com] On Behalf Of Preetham-rao K
Sent: Tuesday, November 30, 2010 12:42 PM
To: meego-dev@meego.com
Subject: [MeeGo-dev] Sensor Framework: Show_als application
not working on QT mobility level
Hi Timo Markus,
We want to test qt mobility test application given for sensors
like show_als
We have written adopter for BH1780 ALS using sysfs adopter
class in meego sensor framework(0.6.19)
Please see the code attached (based on BH1780 driver in linux kernel)
But when we run the test we are getting following log.
Have we done something wrong?
[r...@localhost bin]# ./show_als
loaded the Generic plugin
loaded the grue plugin
Loaded the Maemo 6 sensor plugin
Request for control interface not granted...
New listen sensor alssensor interface created with session id 3 ...
Data rate in don't care mode (interval 0 ms) for alssensor
The log seems to be fine. It just shows that sensord did not grant you control
session for ALS, and as a fallback you got a listen session. There is no
practical difference between control/listen anymore, and the whole concept
could get deprecated.
You might want to define a default interval for your adaptor with
setDefaultInterval(), as it runs in busypoll mode. You will still see '0' as
the value via QtMobility to notify 'I don't care', but the adaptor behaves
reasonably. If there's no default, it defaults to zero, which means it will
keep reading as fast as the system allows it to.
setDefaultInterval() is available from sensord-0.6.28. If you need things to
run nicely with 0.6.19, you need to handle the interval setting directly with
the interval property.
Do you have trouble seeing ALS values, or were you just wondering about the
messages?
// Timo
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] LibGRSS packaged for Meego
Hi all, For those interested in developing something using LibGRSS [1] on Meego, i've packaged it on OBS here: https://build.pub.meego.com/package/show?package=libgrssproject=home:netvandal This also allow to compile tracker with rss support. Hope that is useful for someone :) Michele [1] http://live.gnome.org/Libgrss -- michele tameni ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Urgent: We need community ftp space or similar
Till Harbaum wrote: Hi list, i would really like to release some ready-to-run beagleboard meego image. But unfortunately we are missing a place to store files in the gigabyte range for public download. Other meego projects and even the n900/n8x0 adaption teams are facing the same problem. Can we please have such a place? Till __ Why don't you fold your work back into the build process so the images are produced under http://repo.meego.com/MeeGo/builds? Joel ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Sensor Framework: Show_als application not working on QT mobility level
Hi Timo,
We understood the different logging levels in sensord.
Infact we enabled debug level.
We hard coded in ../sensord/loggin.cpp
SensordLogLevel SensordLogger::outputLevel = SensordLogDebug;
We are getting following messages for ALS in sensoradopter test
*
[r...@localhost bin]# ./sensoradaptors-test
* Start testing of AdaptorTest *
Config: Using QTest library 4.7.0, Qt 4.7.0
PASS : AdaptorTest::initTestCase()
*DEBUG* 2000-01-01 00:06:49 [Sensord]
[../../../adaptors/alsadaptor/alsadaptor.cpp:51:ALSAdaptor::ALSAdaptor(const
QString)] ALSAdaptor::ALSAdaptorBH1780
*DEBUG* 2000-01-01 00:06:49 [Sensord]
[../../../adaptors/alsadaptor/alsadaptor.cpp:73:virtual bool
ALSAdaptor::startSensor(const QString)] ALSAdaptor::startSensor
*DEBUG* 2000-01-01 00:06:49 [Sensord]
[../../../adaptors/alsadaptor/alsadaptor.cpp:98:virtual void
ALSAdaptor::stopSensor(const QString)] ALSAdaptor::stopSensor
PASS : AdaptorTest::testALSAdaptor()
**
As you said,if sensord test are not intended for overall functionality testing
then qt mobility examples are only alternative.
Let us do some more testing before identifying if there is a problem.
By the way,are there any test cases at sensor
level(\meego-middleware-sensorfw\sensors\alssensor\)?
Thanks Regards,
Preetham
-Original Message-
From: Rongas Timo [mailto:timo.ron...@digia.com]
Sent: Wednesday, December 01, 2010 2:26 PM
To: Preetham-rao K
Cc: meego-dev@meego.com
Subject: RE: [MeeGo-dev] Sensor Framework: Show_als application not working on
QT mobility level
-Original Message-
From: Preetham-rao K [mailto:preetham@stericsson.com]
Sent: Wednesday, December 01, 2010 10:18 AM
To: Rongas Timo; meego-dev@meego.com
Subject: RE: [MeeGo-dev] Sensor Framework: Show_als
application not working on QT mobility level
We are just wondering about the messages.
We have written just a adopter plug-in (as attached in previous mail)
and we have debug messages in als adopter but none seems to be coming..
There are 4 different logging levels in sensord: test, debug, warning,
critical. Which level your log message goes to depends on X in sensordLogX()
(X=[T,D,W,C] respectively). You are (correcty) using T and D.
By default only criticals and warnings are written to syslog. Have a look at
--log-target and --log-level parameters for sensord. Or for debugging purposes
just make your output go to level 'Warning'.
Is there a way to test it in client API test(like alsadopter
and alssensor are working properly)?
There is no automatic test that would verify that you are actually getting some
data. These are tricky to create, as you often need the hardware to experience
some change in order to get samples. Sensord tests basically only poke
different functions, verify that settings get changed correctly, test dataflow
with generated data etc.
If you confirm that your adaptor is propagating data to the framework, but
nothing is shown with show_als, please file a bug :)
// Timo
By default code is this one...
void ClientApiTest::testALSSensor()
{
QString sensorName(alssensor);
SensorManagerInterface sm = SensorManagerInterface::instance();
QVERIFY( sm.isValid() );
// Attempt to get another control session
ALSSensorChannelInterface* failIfc =
ALSSensorChannelInterface::controlInterface(sensorName);
QVERIFY2(!failIfc, Got another control session);
}
This is what we understand for MeeGO
Qt mobility:
Application--(Qsensor. QAmbientLightReading)--(sensor
backend/our case it may falling to mameo6)
Sensor Framework:(Sensor backend)
Plug-in interface--(alssensor and alsadopter)
-Original Message-
From: Rongas Timo [mailto:timo.ron...@digia.com]
Sent: Wednesday, December 01, 2010 1:26 PM
To: Preetham-rao K; meego-dev@meego.com
Subject: RE: [MeeGo-dev] Sensor Framework: Show_als
application not working on QT mobility level
-Original Message-
From: meego-dev-boun...@meego.com
[mailto:meego-dev-boun...@meego.com] On Behalf Of Preetham-rao K
Sent: Tuesday, November 30, 2010 12:42 PM
To: meego-dev@meego.com
Subject: [MeeGo-dev] Sensor Framework: Show_als application
not working on QT mobility level
Hi Timo Markus,
We want to test qt mobility test application given for sensors
like show_als
We have written adopter for BH1780 ALS using sysfs adopter
class in meego sensor framework(0.6.19)
Please see the code attached (based on BH1780 driver in linux kernel)
But when we run the test we are getting following log.
Have we done something wrong?
[r...@localhost bin]# ./show_als
loaded the Generic plugin
loaded the grue plugin
Loaded the Maemo 6 sensor plugin
Request for control interface not
Re: [MeeGo-dev] Urgent: We need community ftp space or similar
2010/12/1 Clark, Joel joel.cl...@intel.com: Till Harbaum wrote: Hi list, i would really like to release some ready-to-run beagleboard meego image. But unfortunately we are missing a place to store files in the gigabyte range for public download. Other meego projects and even the n900/n8x0 adaption teams are facing the same problem. Can we please have such a place? Till __ Why don't you fold your work back into the build process so the images are produced under http://repo.meego.com/MeeGo/builds? I think the challenge is that while there's development ongoing, for something that might at one point be contributed to the release process, until you have QA personell and the rest of the needed MeeGo bureaucracy in place, you need a place to dump your development work as you can't release from repo.meego.com without this :) Ideally Harbaum's work will turn into the basis for IVI ARM reference device (beagleboard). As an example, up to now in Nokia N900 we've used an internal Nokia 'exchange area' for daily acceptance/sanity testing images for QA, or development images, while there has been no legal need to not have this in public. So a 'MeeGo.com' exchange area could come in handy. BR Carsten Munk ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo trademark compliance and double standards??
Hi, Peter Robinson wrote: Is this a commercial vs open source community distro license agreement or allowance? I'm somewhat confused! Do Linpus have an exception to the requirements of using connman or do they provide (and are allowed to do so) a library to provide an api glue between the two? Or are they wrongly advertising features that they can't legally provide if they wish to adhere to the current Presumably Linpus adhere to the LF's agreement to use the trademarks as is currently announced or otherwise I've apparently missed something or some process announcement. I suspect that this is an invalid assumption on your part. I bet that Linpus didn't consider that there was any need to ask for trademark approval after this change. The interesting bit will be to see what the reaction will be now that you have (officially) made everyone aware of this potential trademark infringement. Also worth noting is that Linpus operates primarily in China, and trademark protections are not so strong there... is this something to bear in mind? I don't know. IANAL. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] broken links to development images
Hi, Tom Chen wrote: maybe you could get one form http://repo.meego.com/MeeGo/builds/trunk/. hope this could help you. I thhink the images are in http://repo.meego.com/MeeGo/builds/trunk/1.1.80.8.20101130.1/core/images/ The problem with this link is that it will be out of date straight away - and there doesn't seem to be a latest link pointing to the most recent images. We should definitely have correct links in Developing in a Meego Environment (ahem... that page proably needs to be moved to something with a shorter better name that doesn't capitalise Environment too), but we shouldn't consciously point to images which will quickly be out of date. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo trademark compliance and double standards??
On Wed, Dec 1, 2010 at 10:12 AM, Dave Neary dne...@maemo.org wrote: Hi, Peter Robinson wrote: Is this a commercial vs open source community distro license agreement or allowance? I'm somewhat confused! Do Linpus have an exception to the requirements of using connman or do they provide (and are allowed to do so) a library to provide an api glue between the two? Or are they wrongly advertising features that they can't legally provide if they wish to adhere to the current Presumably Linpus adhere to the LF's agreement to use the trademarks as is currently announced or otherwise I've apparently missed something or some process announcement. I suspect that this is an invalid assumption on your part. I bet that Linpus didn't consider that there was any need to ask for trademark approval after this change. The interesting bit will be to see what the reaction will be now that you have (officially) made everyone aware of this potential trademark infringement. Also worth noting is that Linpus operates primarily in China, and trademark protections are not so strong there... is this something to bear in mind? I don't know. IANAL. In the past they were the primary OS/UI provider for Linux based Acer netbooks which are sold everywhere, they also had quite a presence at the meego conf so while they might well be located in Asia they're products certainly aren't restricted to there. Peter ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Urgent: We need community ftp space or similar
Hi, Carsten Munk wrote: 2010/12/1 Clark, Joel joel.cl...@intel.com: Why don't you fold your work back into the build process so the images are produced under http://repo.meego.com/MeeGo/builds? I think the challenge is that while there's development ongoing, for something that might at one point be contributed to the release process, until you have QA personell and the rest of the needed MeeGo bureaucracy in place, you need a place to dump your development work as you can't release from repo.meego.com without this :) ... and I would say that if there are enough people proposing custom MeeGo images that disk space is a concern, then that's a nice problem to have ;-) Till doesn't need anonftp or anything, but something with trust-based access rights (where you have to ask to get a password allowing you to upload images) with directories organised by username (so you know whose images you're downloading) would be great as a way for people to share their work in an informal way. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Sensor Framework: Show_als application not working on QT mobility level
More to add
In debug messages
New listen sensor alssensor interface created with session id 3 ...
Data rate in don't care mode (interval 0 ms) for alssensor
Is it mean only session is created ? Is it also implies Sensor channel is
created (ALSSensorChannel::ALSSensorChannel)?
What is the flow for opening one ALSSensorChannel::ALSSensorChannel?
Because we can see sensor channel is responsible for creating graph(als,
source, buffer, sink) and using adopter.
-Original Message-
From: Preetham-rao K
Sent: Wednesday, December 01, 2010 3:18 PM
To: 'Rongas Timo'
Cc: meego-dev@meego.com
Subject: RE: [MeeGo-dev] Sensor Framework: Show_als application not working on
QT mobility level
Hi Timo,
We understood the different logging levels in sensord.
Infact we enabled debug level.
We hard coded in ../sensord/loggin.cpp
SensordLogLevel SensordLogger::outputLevel = SensordLogDebug;
We are getting following messages for ALS in sensoradopter test
*
[r...@localhost bin]# ./sensoradaptors-test
* Start testing of AdaptorTest *
Config: Using QTest library 4.7.0, Qt 4.7.0
PASS : AdaptorTest::initTestCase()
*DEBUG* 2000-01-01 00:06:49 [Sensord]
[../../../adaptors/alsadaptor/alsadaptor.cpp:51:ALSAdaptor::ALSAdaptor(const
QString)] ALSAdaptor::ALSAdaptorBH1780
*DEBUG* 2000-01-01 00:06:49 [Sensord]
[../../../adaptors/alsadaptor/alsadaptor.cpp:73:virtual bool
ALSAdaptor::startSensor(const QString)] ALSAdaptor::startSensor
*DEBUG* 2000-01-01 00:06:49 [Sensord]
[../../../adaptors/alsadaptor/alsadaptor.cpp:98:virtual void
ALSAdaptor::stopSensor(const QString)] ALSAdaptor::stopSensor
PASS : AdaptorTest::testALSAdaptor()
**
As you said,if sensord test are not intended for overall functionality testing
then qt mobility examples are only alternative.
Let us do some more testing before identifying if there is a problem.
By the way,are there any test cases at sensor
level(\meego-middleware-sensorfw\sensors\alssensor\)?
Thanks Regards,
Preetham
-Original Message-
From: Rongas Timo [mailto:timo.ron...@digia.com]
Sent: Wednesday, December 01, 2010 2:26 PM
To: Preetham-rao K
Cc: meego-dev@meego.com
Subject: RE: [MeeGo-dev] Sensor Framework: Show_als application not working on
QT mobility level
-Original Message-
From: Preetham-rao K [mailto:preetham@stericsson.com]
Sent: Wednesday, December 01, 2010 10:18 AM
To: Rongas Timo; meego-dev@meego.com
Subject: RE: [MeeGo-dev] Sensor Framework: Show_als
application not working on QT mobility level
We are just wondering about the messages.
We have written just a adopter plug-in (as attached in previous mail)
and we have debug messages in als adopter but none seems to be coming..
There are 4 different logging levels in sensord: test, debug, warning,
critical. Which level your log message goes to depends on X in sensordLogX()
(X=[T,D,W,C] respectively). You are (correcty) using T and D.
By default only criticals and warnings are written to syslog. Have a look at
--log-target and --log-level parameters for sensord. Or for debugging purposes
just make your output go to level 'Warning'.
Is there a way to test it in client API test(like alsadopter
and alssensor are working properly)?
There is no automatic test that would verify that you are actually getting some
data. These are tricky to create, as you often need the hardware to experience
some change in order to get samples. Sensord tests basically only poke
different functions, verify that settings get changed correctly, test dataflow
with generated data etc.
If you confirm that your adaptor is propagating data to the framework, but
nothing is shown with show_als, please file a bug :)
// Timo
By default code is this one...
void ClientApiTest::testALSSensor()
{
QString sensorName(alssensor);
SensorManagerInterface sm = SensorManagerInterface::instance();
QVERIFY( sm.isValid() );
// Attempt to get another control session
ALSSensorChannelInterface* failIfc =
ALSSensorChannelInterface::controlInterface(sensorName);
QVERIFY2(!failIfc, Got another control session);
}
This is what we understand for MeeGO
Qt mobility:
Application--(Qsensor. QAmbientLightReading)--(sensor
backend/our case it may falling to mameo6)
Sensor Framework:(Sensor backend)
Plug-in interface--(alssensor and alsadopter)
-Original Message-
From: Rongas Timo [mailto:timo.ron...@digia.com]
Sent: Wednesday, December 01, 2010 1:26 PM
To: Preetham-rao K; meego-dev@meego.com
Subject: RE: [MeeGo-dev] Sensor Framework: Show_als
application not working on QT mobility level
-Original Message-
From: meego-dev-boun...@meego.com
[mailto:meego-dev-boun...@meego.com] On Behalf
Re: [MeeGo-dev] Sensor Framework: Show_als application not working on QT mobility level
Oops..so we have to run sensord in background to get all sensors to registered.
-Original Message-
From: Preetham-rao K
Sent: Wednesday, December 01, 2010 4:23 PM
To: 'Rongas Timo'
Cc: 'meego-dev@meego.com'
Subject: RE: [MeeGo-dev] Sensor Framework: Show_als application not working on
QT mobility level
More to add
In debug messages
New listen sensor alssensor interface created with session id 3 ...
Data rate in don't care mode (interval 0 ms) for alssensor
Is it mean only session is created ? Is it also implies Sensor channel is
created (ALSSensorChannel::ALSSensorChannel)?
What is the flow for opening one ALSSensorChannel::ALSSensorChannel?
Because we can see sensor channel is responsible for creating graph(als,
source, buffer, sink) and using adopter.
-Original Message-
From: Preetham-rao K
Sent: Wednesday, December 01, 2010 3:18 PM
To: 'Rongas Timo'
Cc: meego-dev@meego.com
Subject: RE: [MeeGo-dev] Sensor Framework: Show_als application not working on
QT mobility level
Hi Timo,
We understood the different logging levels in sensord.
Infact we enabled debug level.
We hard coded in ../sensord/loggin.cpp
SensordLogLevel SensordLogger::outputLevel = SensordLogDebug;
We are getting following messages for ALS in sensoradopter test
*
[r...@localhost bin]# ./sensoradaptors-test
* Start testing of AdaptorTest *
Config: Using QTest library 4.7.0, Qt 4.7.0
PASS : AdaptorTest::initTestCase()
*DEBUG* 2000-01-01 00:06:49 [Sensord]
[../../../adaptors/alsadaptor/alsadaptor.cpp:51:ALSAdaptor::ALSAdaptor(const
QString)] ALSAdaptor::ALSAdaptorBH1780
*DEBUG* 2000-01-01 00:06:49 [Sensord]
[../../../adaptors/alsadaptor/alsadaptor.cpp:73:virtual bool
ALSAdaptor::startSensor(const QString)] ALSAdaptor::startSensor
*DEBUG* 2000-01-01 00:06:49 [Sensord]
[../../../adaptors/alsadaptor/alsadaptor.cpp:98:virtual void
ALSAdaptor::stopSensor(const QString)] ALSAdaptor::stopSensor
PASS : AdaptorTest::testALSAdaptor()
**
As you said,if sensord test are not intended for overall functionality testing
then qt mobility examples are only alternative.
Let us do some more testing before identifying if there is a problem.
By the way,are there any test cases at sensor
level(\meego-middleware-sensorfw\sensors\alssensor\)?
Thanks Regards,
Preetham
-Original Message-
From: Rongas Timo [mailto:timo.ron...@digia.com]
Sent: Wednesday, December 01, 2010 2:26 PM
To: Preetham-rao K
Cc: meego-dev@meego.com
Subject: RE: [MeeGo-dev] Sensor Framework: Show_als application not working on
QT mobility level
-Original Message-
From: Preetham-rao K [mailto:preetham@stericsson.com]
Sent: Wednesday, December 01, 2010 10:18 AM
To: Rongas Timo; meego-dev@meego.com
Subject: RE: [MeeGo-dev] Sensor Framework: Show_als
application not working on QT mobility level
We are just wondering about the messages.
We have written just a adopter plug-in (as attached in previous mail)
and we have debug messages in als adopter but none seems to be coming..
There are 4 different logging levels in sensord: test, debug, warning,
critical. Which level your log message goes to depends on X in sensordLogX()
(X=[T,D,W,C] respectively). You are (correcty) using T and D.
By default only criticals and warnings are written to syslog. Have a look at
--log-target and --log-level parameters for sensord. Or for debugging purposes
just make your output go to level 'Warning'.
Is there a way to test it in client API test(like alsadopter
and alssensor are working properly)?
There is no automatic test that would verify that you are actually getting some
data. These are tricky to create, as you often need the hardware to experience
some change in order to get samples. Sensord tests basically only poke
different functions, verify that settings get changed correctly, test dataflow
with generated data etc.
If you confirm that your adaptor is propagating data to the framework, but
nothing is shown with show_als, please file a bug :)
// Timo
By default code is this one...
void ClientApiTest::testALSSensor()
{
QString sensorName(alssensor);
SensorManagerInterface sm = SensorManagerInterface::instance();
QVERIFY( sm.isValid() );
// Attempt to get another control session
ALSSensorChannelInterface* failIfc =
ALSSensorChannelInterface::controlInterface(sensorName);
QVERIFY2(!failIfc, Got another control session);
}
This is what we understand for MeeGO
Qt mobility:
Application--(Qsensor. QAmbientLightReading)--(sensor
backend/our case it may falling to mameo6)
Sensor Framework:(Sensor backend)
Plug-in interface--(alssensor and alsadopter)
-Original Message-
From: Rongas Timo
Re: [MeeGo-dev] build script fails on Ubuntu
It seems new changes have been pushed for 'build' in the repo that might fix this issue. Though the issue seems to be that liblua is missing from the build configs. Just add 'liblua' in the Preinstall section in the build config file you are using, for example: /usr/lib/build/configs/default.conf Regards, On 12/01/2010 12:31 AM, AndrewT wrote: Dear All, Does anybody run build script on Ubuntu ? It complains about liblua-5.1.so rpm: error while loading shared libraries: liblua-5.1.so: cannot open shared object file: No such file or directory I tried to run the following command: $sudo build --repository http://repo.meego.com/MeeGo/builds/trunk/1.1.80.8.20101130.1/core/repos/ia32/packages/ - -arch i686 cpio-2.11-2.6.src.rpm Thanks, Andrew ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] mkcal: separate notebooks + UID conflicts
Hello! Let me share an observation, just in case that it is relevant for other developers. mkcal supports multiple notebooks inside the same calendar database. However, these notebooks are not as independent from each other as one might expect: if notebook A has an event with UID=foo, then notebook B cannot also have an event with that same UID. I suppose this works as intended, but it is not how other PIM storages work. I also find it a too limiting and wonder how this feature is used. If one notebook is say, synchronized with Google, and the other notebook is for a local calendar, then I would get conflicts when a meeting invitation is processed by both Google and the local app. The only solution that I see is to not use the notebook feature and instead use separate calendar .db files. Alvaro, do I miss something? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Urgent: We need community ftp space or similar
Carsten Munk wrote: 2010/12/1 Clark, Joel joel.cl...@intel.com: Why don't you fold your work back into the build process so the images are produced under http://repo.meego.com/MeeGo/builds? I think the challenge is that while there's development ongoing, for something that might at one point be contributed to the release process, until you have QA personell and the rest of the needed MeeGo bureaucracy in place, you need a place to dump your development work as you can't release from repo.meego.com without this :) BR Carsten Munk First we need someone to be the image maintainer for the beagleboard. Someone to own bugs found. If Till is building images to share with the community then please just go the next step and agree to maintain that image, so we can leverage the existing build and bugs infrastructure to support the beagleboard community.I don't believe there is significant additional needed MeeGo bureaucracy. 2 or 3 folks would be nice but 1 person could do it. What is needed is a kernel maintainer for beagleboard, platform maintainer for beagleboard, and someone to ensure the build scripts (i.e. kickstart) is right and the resulting images actually boots. Sure it would be nice to have a full QA team dedicated to the board, but the community can provide that capability and file any bugs found. But someone has to own the bugs found. Let's use the processes already in place rather than fork off a whole new process. regards Joel ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Urgent: We need community ftp space or similar
I second Joel's motion. A ready to go image is good to get people jumpstarted but eventually we need the full infrastructure and a responsible maintainer. There are also different revisions of the Beagle and some known issues with graphics and acceleration. These are barriers of entry and need to be made transparent. Rudi On Dec 1, 2010 8:28 AM, Clark, Joel joel.cl...@intel.com wrote: Carsten Munk wrote: 2010/12/1 Clark, Joel joel.cl...@intel.com: Why don't you fold your work back into the build process so the images are produced under http:... BR Carsten Munk First we need someone to be the image maintainer for the beagleboard. Someone to own bugs found. If Till is building images to share with the community then please just go the next step and agree to maintain that image, so we can leverage the existing build and bugs infrastructure to support the beagleboard community.I don't believe there is significant additional needed MeeGo bureaucracy. 2 or 3 folks would be nice but 1 person could do it. What is needed is a kernel maintainer for beagleboard, platform maintainer for beagleboard, and someone to ensure the build scripts (i.e. kickstart) is right and the resulting images actually boots. Sure it would be nice to have a full QA team dedicated to the board, but the community can provide that capability and file any bugs found. But someone has to own the bugs found. Let's use the processes already in place rather than fork off a whole new process. regards Joel ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://l... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Urgent: We need community ftp space or similar
Hi, Clark, Joel wrote: First we need someone to be the image maintainer for the beagleboard. Someone to own bugs found. If Till is building images to share with the community then please just go the next step and agree to maintain that image, so we can leverage the existing build and bugs infrastructure to support the beagleboard community. I don't believe there is significant additional needed MeeGo bureaucracy. 2 or 3 folks would be nice but 1 person could do it. What is needed is a kernel maintainer for beagleboard, platform maintainer for beagleboard, and someone to ensure the build scripts (i.e. kickstart) is right and the resulting images actually boots. Sure it would be nice to have a full QA team dedicated to the board, but the community can provide that capability and file any bugs found. But someone has to own the bugs found. Does all of this really need to be a prerequisite to allowing a long-time, active community member to upload distribute an image? We can help draft the big red-type disclaimer on the top, if you like, that will say This is not an official image! Beware, it may break stuff, and it'll all be your fault! Don't come crying to us afterwards, we'll only tell you we told you so! And then Till can write, in really small letters underneath, If anyone has problems with the image, contact me at till.harb...@my-nice-domain.com and then Till will be doing your triage for you. I'm all for process before we ship software on devices and put it in the hands of people who don't know what they're getting into - but downloading binary images for the beagleboard does not fall into that category - can't we make it easier for people to get hold of the work of other community members? The parallel I would make is with the various staging trees the old ac kernels. People knew what they were getting when they got it, you didn't accidentally download an ac kernel on the front page of kernel.org, and Caveat Emptor was in full effect. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Urgent: We need community ftp space or similar
2010/12/1 Clark, Joel joel.cl...@intel.com: Dave Neary wrote: Does all of this really need to be a prerequisite to allowing a long-time, active community member to upload distribute an image? Till can write, in really small letters underneath, If anyone has problems with the image, contact me at till.harb...@my-nice-domain.com and then Till will be doing your triage for you. Cheers, Dave. I don't get it either. If the long-time, active community member is willing to build, test, upload, distribute and deal with problems from anybody who uses his image, why not take advantage of the existing automated processes for code management, build, distribution and issue tracking? Is the goal here to make sure the beagleboard is not supported on meego.com? I think we're going in a circle here. Long story short: When development is being done, especially proof of concepts, there will always be images created that doesn't fit in an ordinary release process. But has to be shared with a MeeGo contributor audience such as a team. So what's proposed is an exchange area, where people can upload and other people download. Images would be deleted after a time period. It would also make sure that teams don't end up using internal company infrastructure for such things - like we do with our acceptance/sanity images currently. These should be publically accessible for those wanting to get into daily testing. An example can be for example development images related to integrating a new graphics driver where I'd have to share it with QA guys to verify nothing is going sour. For the Beagleboard image, such an area would allow for a process where the kickstart file is evolved to an initial working state, images published to the relevant teams and interested contributors. Based on that work FEA#'s set up for the hardware adaptation, the needed roles attached and included as part of the real release process. That's obviously where things should go eventually. But in the very early stages, release process is overkill for the initial images to get things started. .. I don't think we should be in a position where we put any incoming hardware adaptation, even the proof of concepts into the MeeGo release process. If something is released from repo.meego.com it should be quality. We did it like this in the N900 hardware adaptation, starting out as a quite broken proof of concept of MeeGo on ARM, evolving into something part of the release process and now automatically generated alongside the rest. BR Carsten Munk ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Urgent: We need community ftp space or similar
Carsten Munk wrote: Joel Clark wrote: I don't get it either. If the long-time, active community member is willing to build, test, upload, distribute and deal with problems from anybody who uses his image, why not take advantage of the existing automated processes for code management, build, distribution and issue tracking? Is the goal here to make sure the beagleboard is not supported on meego.com? I think we're going in a circle here. Long story short: When development is being done, especially proof of concepts, there will always be images created that doesn't fit in an ordinary release process. But has to be shared with a MeeGo contributor audience such as a team. So what's proposed is an exchange area, where people can upload and other people download. Images would be deleted after a time period. That's why I pointed to the build repos, not the release repos. You describe exactly what they are for. It would also make sure that teams don't end up using internal company infrastructure for such things - like we do with our acceptance/sanity images currently. I'm not sure what internal company infrastructure you are referring too. I was referring to the LF MeeGo.com infrastructure. An example can be for example development images related to integrating a new graphics driver where I'd have to share it with QA guys to verify nothing is going sour. i.e. build repos For the Beagleboard image, such an area would allow for a process where the kickstart file is evolved to an initial working state, images published to the relevant teams and interested contributors. Based on that work FEA#'s set up for the hardware adaptation, the needed roles attached and included as part of the real release process. That's obviously where things should go eventually. But in the very early stages, release process is overkill for the initial images to get things started. i.e. build repos .. I don't think we should be in a position where we put any incoming hardware adaptation, even the proof of concepts into the MeeGo release process. If something is released from repo.meego.com it should be quality. Agree about the use of release repos BR Carsten Munk regards Joel ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Urgent: We need community ftp space or similar
Hi, Clark, Joel wrote: Dave Neary wrote: Does all of this really need to be a prerequisite to allowing a long-time, active community member to upload distribute an image? snip I don't get it either. If the long-time, active community member is willing to build, test, upload, distribute and deal with problems from anybody who uses his image, why not take advantage of the existing automated processes for code management, build, distribution and issue tracking? Is the goal here to make sure the beagleboard is not supported on meego.com? I get the feeling we're talking at cross purposes :) Going back to Till's original message, he's asking for a distribution channel to be created on meego.com where he (and others) can upload custom meego images they build. You are proposing that this uploading distribution of imageshave some QA stuff as a prerequisite: some place in Bugzilla where bugs against the image get created assigned to the image creator, integration into the existing build infrastructure (which, presumably, will require some extra access), associate the distribution of the image with a named kernel maintainer, platform maintainer and build scripts maintainer. Rudolf suggested that eventually we'll need the full infrastructure, implying even more overhead. I don't understand why all of this is necessary before you can allow someone to upload an image publish a URL to it, so that interested parties can download play with it. Creating the necessary bugzilla build stuff will add hours or days to requests, and is not a scalable approach to community builds. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Urgent: We need community ftp space or similar
Andrew Flegg wrote: Isn't it possible that MeeGo is *not* supported on the Beagleboard at the moment, and the handful of people working on getting it to that point have asked for a place they can exchange large files... Obviously I believe the build repos is the place to make this exchange. ...And that any such momentum may be killed by such a ferocious backlash? What backlash? Please explain? Why would there be backlash at adding support for another MeeGo platform? Support isn't going to appear from nowhere! Agree, so let's move it forward. Cheers, Andrew regards Joel ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Urgent: We need community ftp space or similar
On Wed, 2010-12-01 at 09:21 +0100, ext Till Harbaum / Lists wrote: Hi list, i would really like to release some ready-to-run beagleboard meego image. But unfortunately we are missing a place to store files in the gigabyte range for public download. Other meego projects and even the n900/n8x0 adaption teams are facing the same problem. Can we please have such a place? Can you please submit a request at http://bugs.meego.com ? It's ok to send an email to meego-dev pointing to that request so anybody interested can chime in and follow, but discussing this whole request here is a bit overkill (with thousand of subscribers). Even meego-community would be more on-topic since it's there where the community infrastructure is discussed. Thank you for your understanding. -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Urgent: We need community ftp space or similar
2010/12/1 Clark, Joel joel.cl...@intel.com: Carsten Munk wrote: Joel Clark wrote: I don't get it either. If the long-time, active community member is willing to build, test, upload, distribute and deal with problems from anybody who uses his image, why not take advantage of the existing automated processes for code management, build, distribution and issue tracking? Is the goal here to make sure the beagleboard is not supported on meego.com? I think we're going in a circle here. Long story short: When development is being done, especially proof of concepts, there will always be images created that doesn't fit in an ordinary release process. But has to be shared with a MeeGo contributor audience such as a team. So what's proposed is an exchange area, where people can upload and other people download. Images would be deleted after a time period. That's why I pointed to the build repos, not the release repos. You describe exactly what they are for. It would also make sure that teams don't end up using internal company infrastructure for such things - like we do with our acceptance/sanity images currently. I'm not sure what internal company infrastructure you are referring too. I was referring to the LF MeeGo.com infrastructure. An example could be Intel SDK guys initially uploading stuff to internal Intel servers or us in N900 team uploading to an internal Nokia exchange area for our QA images. So it's not only images but also random file exchange, such as SDK installers, etc.. An example can be for example development images related to integrating a new graphics driver where I'd have to share it with QA guys to verify nothing is going sour. i.e. build repos OK, so where can I submit random kickstart files for inclusion in build/ repos or getting upload rights there? That'd sound like a cool place, but it's the first time I've heard of this being used as such :) Even '1.1.80.8.20101130.1/' repos and to some extent images are semi-official weekly releases and imported by vendors. For the Beagleboard image, such an area would allow for a process where the kickstart file is evolved to an initial working state, images published to the relevant teams and interested contributors. Based on that work FEA#'s set up for the hardware adaptation, the needed roles attached and included as part of the real release process. That's obviously where things should go eventually. But in the very early stages, release process is overkill for the initial images to get things started. i.e. build repos .. I don't think we should be in a position where we put any incoming hardware adaptation, even the proof of concepts into the MeeGo release process. If something is released from repo.meego.com it should be quality. Agree about the use of release repos regards Joel ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Urgent: We need community ftp space or similar
Dave Neary wrote You are proposing that this uploading distribution of imageshave some QA stuff as a prerequisite: The only QA I ask for was someone to see if the image booted on the target board. some place in Bugzilla where bugs against the image get created assigned to the image creator, very easy to do integration into the existing build infrastructure (which, presumably, will require some extra access), The build infrastructure is ready to turn this on as soon as there is maintainer associate the distribution of the image with a named kernel maintainer, platform maintainer and build scripts maintainer. Yes, the key point of what is needed. Is this one or more persons? How about Till, Dave and Carsten? Rudolf suggested that eventually we'll need the full infrastructure, implying even more overhead. He wants to see released products. I'd like to see baby steps first. I don't understand why all of this is necessary before you can allow someone to upload an image publish a URL to it, so that interested parties can download play with it. Creating the necessary bugzilla build stuff will add hours or days to requests, and is not a scalable approach to community builds. Cheers, Dave It's not that hard. Just need a maintainer volunteer can work within the MeeGo build system to make images for everyone to work with rather than keeping this stuff private and unmaintained. OK fine. I've tried more than I probably should. If anybody decides they want to see Beagleboard images built within the MeeGo build system and are willing to work to make that happen please speak up. Until then I'll shut-up. regards Joel ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Agenda of TSG meeting *today*
Here is the agenda for the Technical Steering Group meeting held today - actually in a bit more than one hour, at 20:00 UTC. * MeeGo Compliance discussion update (Mark Skarpness). http://wiki.meego.com/Quality/Compliance * Quality Team nominations (Veli-Pekka Vatula). http://wiki.meego.com/Quality/meetings/QANominations101201 * Toolchain Change Proposal for MeeGo Release 1.2 (Jarmo Kant). http://wiki.meego.com/SDK/Toolchains/ToolchainChangeProposal * Next TSG Meeting * All other business (Open Items and General Questions) More information about Technical Steering Group meetings at http://wiki.meego.com/Technical_Steering_Group_meetings See you there! -- Quim Gil ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Urgent: We need community ftp space or similar
2010/12/1 Clark, Joel joel.cl...@intel.com: I don't understand why all of this is necessary before you can allow someone to upload an image publish a URL to it, so that interested parties can download play with it. Creating the necessary bugzilla build stuff will add hours or days to requests, and is not a scalable approach to community builds. Cheers, Dave It's not that hard. Just need a maintainer volunteer can work within the MeeGo build system to make images for everyone to work with rather than keeping this stuff private and unmaintained. OK fine. I've tried more than I probably should. If anybody decides they want to see Beagleboard images built within the MeeGo build system and are willing to work to make that happen please speak up. Until then I'll shut-up. For good measure - thanks for explaining these issues - we're not disagreeing that it would be a good thing to be part of the release process :) I think the problem was/is the procedures for getting to be part of release process isn't well-explained or even specced out on wiki anywhere (tacit knowledge in us that works in Release Engineering). You've helped get a better look at this and how to get BeagleBoard images into release process - and thanks for that. Maybe we should work this thread into explaining how to become part of release process in practice? I think there's many teams around who's not sure where they should put on-going MeeGo work and be a part of the release process. BR Carsten Munk ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo release process (was Urgent: We need community ftp space or similar)
- Original message - From: Carsten Munk cars...@maemo.org To: Clark, Joel joel.cl...@intel.com cc: meego-...@meego.com meego-dev@meego.com Subject: Re: [MeeGo-dev] Urgent: We need community ftp space or similar Date: Wed, 1 Dec 2010 19:53:10 +0100 For good measure - thanks for explaining these issues - we're not disagreeing that it would be a good thing to be part of the release process :) I think the problem was/is the procedures for getting to be part of release process isn't well-explained or even specced out on wiki anywhere (tacit knowledge in us that works in Release Engineering). You've helped get a better look at this and how to get BeagleBoard images into release process - and thanks for that. Maybe we should work this thread into explaining how to become part of release process in practice? I think there's many teams around who's not sure where they should put on-going MeeGo work and be a part of the release process. � Good points Carsten, as�this naturally goes beyond Beagleboard, as TI is demonstrating with Pandaboard:� http://www.slideshare.net/menonnishanth/meego�,�http://pandaboard.org/content/meego-arm-unofficial-hardware-adaptation � -Randy -- Ovi Mail: Making email access easy http://mail.ovi.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] MeeGo development HW
Hello dear All, I'd like to ask community to help in choosing a development board for MeeGo SW development. We need to connect our device over I2C bus and over UART so therefore would like to have those interface on board. And the main thing is that we need a possibility to build MeeGo itself and compile our own SW (pure C language) without any big troubles meaning that tool chain, documentation for the board and system bring up process should be good. Google reports several boards, but I am mostly interesting about real experience of people who works with real devices. Thank you in advance, Regards, Roman Gezikov. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo development HW
Hi, the various beagleboards as well as the pandaboard seem to be the only hardware developments boards that currently support meego. They are imho the only plattforms that give you direct access to i2c and legacy uart (and many many more interfaces). If you want to run the netbook ux, then a netbook with usb-uart and usb-i2c converters may be an option. If you want the handset ux you'd have to deal with usb otg interfaces for this which imho currently isn't properly supported on any handset. Till Am Mittwoch 01 Dezember 2010 schrieb Roman Gezikov: Hello dear All, I'd like to ask community to help in choosing a development board for MeeGo SW development. We need to connect our device over I2C bus and over UART so therefore would like to have those interface on board. And the main thing is that we need a possibility to build MeeGo itself and compile our own SW (pure C language) without any big troubles meaning that tool chain, documentation for the board and system bring up process should be good. Google reports several boards, but I am mostly interesting about real experience of people who works with real devices. Thank you in advance, Regards, Roman Gezikov. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo development HW
Thank you for your reply! Well, actually we develop SW for the chip that we manufacture and sell, so we need direct i2c connection to the application processor to truly mimic customer's platform. panda- and beagleboard are both ARM based. What's about atom based ones? Are there any on the market that developer can buy and start making own system? Sorry, I forgot to mention about architecture in my first e-mail. Roman. On Wed, Dec 1, 2010 at 9:46 PM, Till Harbaum / Lists li...@harbaum.orgwrote: Hi, the various beagleboards as well as the pandaboard seem to be the only hardware developments boards that currently support meego. They are imho the only plattforms that give you direct access to i2c and legacy uart (and many many more interfaces). If you want to run the netbook ux, then a netbook with usb-uart and usb-i2c converters may be an option. If you want the handset ux you'd have to deal with usb otg interfaces for this which imho currently isn't properly supported on any handset. Till Am Mittwoch 01 Dezember 2010 schrieb Roman Gezikov: Hello dear All, I'd like to ask community to help in choosing a development board for MeeGo SW development. We need to connect our device over I2C bus and over UART so therefore would like to have those interface on board. And the main thing is that we need a possibility to build MeeGo itself and compile our own SW (pure C language) without any big troubles meaning that tool chain, documentation for the board and system bring up process should be good. Google reports several boards, but I am mostly interesting about real experience of people who works with real devices. Thank you in advance, Regards, Roman Gezikov. -- Best regards, Roman Gezikov. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Urgent: We need community ftp space or similar
Hi, Am Mittwoch 01 Dezember 2010 schrieb Clark, Joel: It's not that hard. Just need a maintainer volunteer can work within the MeeGo build system to make images for everyone to work with rather than keeping this stuff private and unmaintained. Not all systems are equal. And building an image for a different plattform isn't just changing two lines in the kickstart and be done. Building a beagleboard image e.g. requires to build a very special/odd sd card image with a very special vfat boot partition ... As we speak people are working on patches for mic to do that. In order to have auto generated beagle images, these patches have to be finihsed and included into the official mic. I on the other hand can just run a few shell scripts here and there (and yes, i'll document that in the wiki) to build an image that runs on the beagle. I don't see a reason not to give this to people to play with. Till ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo development HW
- Original message - From: Roman Gezikov rgesi...@gmail.com To: meego-dev@meego.com Subject: [MeeGo-dev] MeeGo development HW Date: Wed, 1 Dec 2010 21:32:49 +0200 Hello dear All, ���I'd like to ask community to help in choosing a development board for MeeGo SW development. We need to connect our device over I2C bus and over UART so therefore would like to have those interface on board. And the main thing is that we need a possibility to build MeeGo itself and compile our own SW (pure C language) without any big troubles meaning that tool chain, documentation for the board and system bring up process should be good. Google reports several boards, but I am mostly interesting about real experience of people who works with real devices. �Thank you in advance, �Regards,Roman Gezikov. 2.dat I'll second Till's suggestion for Beagleboard or Pandaboard.� Resources and references on the MeeGo wiki: http://wiki.meego.com/ARM Randall Arnold -- Ovi Mail: Making email access easy http://mail.ovi.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Meego Handset UX - Rotate Screen
Hi, Is there any Command to rotate the screen manually? Or any other why to get the screen rotated during developement on a real Hardware device? Regards Jörn ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Handset UX - Rotate Screen
2010/12/1 joern kitestud...@googlemail.com: Hi, Is there any Command to rotate the screen manually? Or any other why to get the screen rotated during developement on a real Hardware device? Try Ctrl-shift-R /Carsten ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Handset UX - Rotate Screen
I think this is the right way for the Virtual PC SDK, but I'am Developing on a real Hardware Device (Gumstix Overo) without Keyboard. So I hope that there will be a trick to do screen rotation without Keyboard, too. On 01.12.2010 21:19, Carsten Munk wrote: 2010/12/1 joernkitestud...@googlemail.com: Hi, Is there any Command to rotate the screen manually? Or any other why to get the screen rotated during developement on a real Hardware device? Try Ctrl-shift-R /Carsten ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo development HW
Roman Gezikov had written, on 12/01/2010 01:47 PM, the following: Thank you for your reply! Well, actually we develop SW for the chip that we manufacture and sell, so we need direct i2c connection to the application processor to truly mimic customer's platform. panda- and beagleboard are both ARM based. What's about atom based ones? Looking at your requirements: 1 Device is over I2C bus and over UART 2 build MeeGo itself 3 compile our own SW (pure C language) 4 without any big troubles meaning: 4.1 tool chain, 4.2 documentation for the board 4.3 system bring up process should be good 5 Able to buy the platform Lets take these one by one: 1 Device is over I2C bus and over UART if you are using Linux (and MeeGo is Standard Linux to the roots! ): A) your app is pure userspace, you'd use i2c: i2c chardev uart: tty B) your device support in kernel, you'd use: i2c: i2c slave uart: tty in either case, your app'd not care anything at all on which platform it runs on, because Linux abstracts the actual hardware controller into standard interfaces for device drivers to use regardless of the underlying platform at all. 2. Build MeeGo itself cool - beagleboard and pandaboard have meego builds - so do other atom based ones. 3 compile our own SW (pure C language) excellent - as you probably already know - Linux is not really C - but Gcc C ;) - as long as you dont use custom #pragma of some weirdo compiler and are C99 or ANSI C compliant or just plain compilable with gcc - you should be good *But* be aware that gcc in MeeGo is gcc 4.5 - there are some quirks around it as well.. oh and by the way - you can build with gcc on beagle or panda itself just like you can do on atom or a PC ;) one major delta between beagle and Panda however is SMP - Panda is OMAP4 with dual cores and beagle is OMAP3 with a single core - if you'd like your app to run on really every possible platforms - choose SMP - SMP programming is more fun and picks up quiet a bit of interesting bugs in s/w - and most serious developers I know at least, choose some SMP platform as well for getting the bugs out of their code ;) Bottom line - you are perfectly placed in MeeGo to use C and any type of hardware. 4 without any big troubles meaning: 4.1 tool chain, No problems there - just use gcc 4.5 ;) native builds are possible as well.. just do zypper install gcc :D 4.2 documentation for the board beagleboard (beagleboard.org) and pandaboard(pandaboard.org) both provide extensive details - schematics, board files, chip TRMs etc.. + there are mailing lists and irc channels to talk to other folks on similar platforms (at the time of this email, #pandaboard has 127 members and #beagle 190 members on freenode.net) I am not very knowledgeable about Atom ones unfortunately. mebbe others in the list can help here.. 4.3 system bring up process should be good beagle and panda both have documented bring up procedure - wiki.meego.com has details :) 5 Able to buy the platform easy - beagleboard.org - beagle regular is now 125$ and beagleboard Xm is 150$, pandaboard is 174$ (at least last I checked ;) ).. and you can get it from distributors - but be warned - waiting lines exist even now. beagle however has an edge of being around for quiet some time now probably with a wider distributor base Again, my ignorance of Atom platform does'nt help me give you anything useful here :(. folks on list, please help.. Given your requirements, as far as I personally see it - it just does'nt matter which platform you develop on.. just choose the one you are personally comfortable with and start hacking some code ;) --- Regards, Nishanth Menon ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Handset UX - Rotate Screen
On 1 December 2010 21:26, joern kitestud...@googlemail.com wrote: I think this is the right way for the Virtual PC SDK, but I'am Developing on a real Hardware Device (Gumstix Overo) without Keyboard. So I hope that there will be a trick to do screen rotation without Keyboard, too. try something like : xrandr -o inverted xrandr -h may be of interest ;-) Brendan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Handset UX - Rotate Screen
On 12/01/10 12:17, joern wrote: Hi, Is there any Command to rotate the screen manually? Or any other why to get the screen rotated during developement on a real Hardware device? xrandr is your friend - just run `xrandr -o left` or similar. Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo development HW
- Original message - From: Nishanth Menon n...@ti.com To: Roman Gezikov rgesi...@gmail.com cc: meego-dev@meego.com Subject: Re: [MeeGo-dev] MeeGo development HW Date: Wed, 01 Dec 2010 14:26:48 -0600 Roman Gezikov had written, on 12/01/2010 01:47 PM, the following: Thank you for your reply! Well, actually we develop SW for the chip that we manufacture and sell, so we need direct i2c connection to the application processor to truly mimic customer's platform. panda- and beagleboard are both ARM based. What's about atom based ones? Looking at your requirements: (lots of great info from Nishanth) Regards, Nishanth Menon Very useful info for the MeeGo ARM�wiki Nishanth!� ; )� By the way I took the liberty of adding your presentation there (http://wiki.meego.com/ARM#OMAP4). FYI�everyone else, Nishanth presented his OMAP4 MeeGo project at our local (DFW) MeeGo Network meetup last Monday.� He is certainly very passionate about the possibilities and I'm very glad to have him in the community. :) Randy -- Ovi Mail: Making email access easy http://mail.ovi.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [MeeGo-community] Agenda of TSG meeting *today*
Hi, Quim Gil wrote: Here is the agenda for the Technical Steering Group meeting held today - actually in a bit more than one hour, at 20:00 UTC. snip Would it be possible to have a TSG meeting confirmation reminder sent out more than 24 hours in advance, please? A number of TSG meetings have been cancelled at relatively short notice, so saying there's a regular meeting isn't quite sufficient. 24 hour notice would also allow late proposals to be suggested for the agenda based on discussions since the previous TSG meeting. Thanks! Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo development HW
Hi Nishanth, Thanks for detailed analysis. Actually, our SW perfectly runs on Linux, Android, Win32 and WinCE. But different flavours of those systems have different frameworks on top of their kernels. And we need to interface to them. We don't want to spend time for porting. We just want to buy a board where we can run MeeGo with all its components. Atom based. With I2C. With UART if possible. And we sell what we test. So testing on beagle and selling to customer making device on atom is not acceptable for us. So, coming back to original question: does anybody have real experience with any atom board? I am wondering why Intel ignores that segment and doesn't make some development board like for instance Samsung does for their processors. Regards, Roman. On Dec 1, 2010 10:26 PM, Nishanth Menon n...@ti.com wrote: Roman Gezikov had written, on 12/01/2010 01:47 PM, the following: Thank you for your reply! Well, actually we develop SW for the chip that we manufacture and sell, so we need direct i2c connection to the application processor to truly mimic customer's platform. panda- and beagleboard are both ARM based. What's about atom based ones? Looking at your requirements: 1 Device is over I2C bus and over UART 2 build MeeGo itself 3 compile our own SW (pure C language) 4 without any big troubles meaning: 4.1 tool chain, 4.2 documentation for the board 4.3 system bring up process should be good 5 Able to buy the platform Lets take these one by one: 1 Device is over I2C bus and over UART if you are using Linux (and MeeGo is Standard Linux to the roots! ): A) your app is pure userspace, you'd use i2c: i2c chardev uart: tty B) your device support in kernel, you'd use: i2c: i2c slave uart: tty in either case, your app'd not care anything at all on which platform it runs on, because Linux abstracts the actual hardware controller into standard interfaces for device drivers to use regardless of the underlying platform at all. 2. Build MeeGo itself cool - beagleboard and pandaboard have meego builds - so do other atom based ones. 3 compile our own SW (pure C language) excellent - as you probably already know - Linux is not really C - but Gcc C ;) - as long as you dont use custom #pragma of some weirdo compiler and are C99 or ANSI C compliant or just plain compilable with gcc - you should be good *But* be aware that gcc in MeeGo is gcc 4.5 - there are some quirks around it as well.. oh and by the way - you can build with gcc on beagle or panda itself just like you can do on atom or a PC ;) one major delta between beagle and Panda however is SMP - Panda is OMAP4 with dual cores and beagle is OMAP3 with a single core - if you'd like your app to run on really every possible platforms - choose SMP - SMP programming is more fun and picks up quiet a bit of interesting bugs in s/w - and most serious developers I know at least, choose some SMP platform as well for getting the bugs out of their code ;) Bottom line - you are perfectly placed in MeeGo to use C and any type of hardware. 4 without any big troubles meaning: 4.1 tool chain, No problems there - just use gcc 4.5 ;) native builds are possible as well.. just do zypper install gcc :D 4.2 documentation for the board beagleboard (beagleboard.org) and pandaboard(pandaboard.org) both provide extensive details - schematics, board files, chip TRMs etc.. + there are mailing lists and irc channels to talk to other folks on similar platforms (at the time of this email, #pandaboard has 127 members and #beagle 190 members on freenode.net) I am not very knowledgeable about Atom ones unfortunately. mebbe others in the list can help here.. 4.3 system bring up process should be good beagle and panda both have documented bring up procedure - wiki.meego.com has details :) 5 Able to buy the platform easy - beagleboard.org - beagle regular is now 125$ and beagleboard Xm is 150$, pandaboard is 174$ (at least last I checked ;) ).. and you can get it from distributors - but be warned - waiting lines exist even now. beagle however has an edge of being around for quiet some time now probably with a wider distributor base Again, my ignorance of Atom platform does'nt help me give you anything useful here :(. folks on list, please help.. Given your requirements, as far as I personally see it - it just does'nt matter which platform you develop on.. just choose the one you are personally comfortable with and start hacking some code ;) --- Regards, Nishanth Menon ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Handset UX - Rotate Screen
I've tested to rotate with xrandr. But it doesn't seems to work: [me...@localhost ~]$ xrandr -o left X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 149 (RANDR) Minor opcode of failed request: 2 (RRSetScreenConfig) Serial number of failed request: 14 Current serial number in output stream: 14 I've tested all other orientation settings, but only normal works. -o normal,inverted,left,right,0,1,2,3 or --orientation normal,inverted,left,right,0,1,2,3 Regards Jörn On 01.12.2010 21:33, Auke Kok wrote: On 12/01/10 12:17, joern wrote: Hi, Is there any Command to rotate the screen manually? Or any other why to get the screen rotated during developement on a real Hardware device? xrandr is your friend - just run `xrandr -o left` or similar. Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Handset UX - Rotate Screen
I think xrandr is not the right way, I've found this in archive: [MeeGo-dev] Handset UX rotation -- how is it implemented? It's implemented by applying a 90° rotation on the world transform in the main QGraphicsView. So the rotation is entirely done by the application. Remember that it's not just showing the rotated screen, but also showing the rotation animation. There's no way to do that with the rotation being done outside of the application. Any Idea telling the Home-screen-application to rotate? Regards Jörn On 01.12.2010 22:12, joern wrote: I've tested to rotate with xrandr. But it doesn't seems to work: [me...@localhost ~]$ xrandr -o left X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 149 (RANDR) Minor opcode of failed request: 2 (RRSetScreenConfig) Serial number of failed request: 14 Current serial number in output stream: 14 I've tested all other orientation settings, but only normal works. -o normal,inverted,left,right,0,1,2,3 or --orientation normal,inverted,left,right,0,1,2,3 Regards Jörn On 01.12.2010 21:33, Auke Kok wrote: On 12/01/10 12:17, joern wrote: Hi, Is there any Command to rotate the screen manually? Or any other why to get the screen rotated during developement on a real Hardware device? xrandr is your friend - just run `xrandr -o left` or similar. Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] MeeGo development HW
- Original message - From: Roman Gezikov rgesi...@gmail.com To: Nishanth Menon n...@ti.com cc: meego-dev@meego.com Subject: Re: [MeeGo-dev] MeeGo development HW Date: Wed, 1 Dec 2010 22:57:39 +0200 Hi Nishanth, Thanks for detailed analysis. Actually, our SW perfectly runs on Linux, Android, Win32 and WinCE. But different flavours of those systems have different frameworks on top of their kernels. And we need to interface to them. We don't want to spend time for porting. We just want to buy a board where we can run MeeGo with all its components. Atom based. With I2C. With UART if possible. And we sell what we test. So testing on beagle and selling to customer making device on atom is not acceptable for us. So, coming back to original question: does anybody have real experience with any atom board? I am wondering why Intel ignores that segment and doesn't make some development board like for instance Samsung does for their processors. Regards, Roman. I found the following using Google (atom +development +board): http://www.eurotech-inc.com/atom-dev-system.asp I'm sure there are more... I didn't click many of the returned links. Randy -- Ovi Mail: Making email access easy http://mail.ovi.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Handset UX - Rotate Screen
On 12/01/10 13:12, joern wrote: I've tested to rotate with xrandr. But it doesn't seems to work: [me...@localhost ~]$ xrandr -o left X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 149 (RANDR) Minor opcode of failed request: 2 (RRSetScreenConfig) Serial number of failed request: 14 Current serial number in output stream: 14 I've tested all other orientation settings, but only normal works. -onormal,inverted,left,right,0,1,2,3 or --orientationnormal,inverted,left,right,0,1,2,3 Regards Jörn Try using the alternative method to pass rotation per-screen : --output output and --rotate normal,inverted,left,right see xrandr --help for more. If that doesn't work, your gfx driver needs to be taught how to talk xrandr Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Handset UX - Rotate Screen
On Wed, Dec 1, 2010 at 3:25 PM, Auke Kok auke-jan.h@intel.com wrote: On 12/01/10 13:12, joern wrote: I've tested to rotate with xrandr. But it doesn't seems to work: [me...@localhost ~]$ xrandr -o left X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 149 (RANDR) Minor opcode of failed request: 2 (RRSetScreenConfig) Serial number of failed request: 14 Current serial number in output stream: 14 I've tested all other orientation settings, but only normal works. -onormal,inverted,left,right,0,1,2,3 or --orientationnormal,inverted,left,right,0,1,2,3 Regards Jörn Try using the alternative method to pass rotation per-screen : --output output and --rotate normal,inverted,left,right see xrandr --help for more. If that doesn't work, your gfx driver needs to be taught how to talk xrandr Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev If that doesn't work, try by direct on its sysfs entry; since you are working on a handset device is very likely it have an path like: /sys/devices/omapdss/display0/ check it out so if is there then look at that folder: ls /sys/devices/omapdss/display0/ ls /sys/devices/platform/omapdss/display0/ A called rotate entry must be there, if so then just set the rotate value you need. echo 90 /sys/.../rotate ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Meego Handset UX - Rotate Screen
On 12/01/2010 01:22 PM, joern wrote: I think xrandr is not the right way, I've found this in archive: Assuming you want to change the orientation of the application, and not rotate the display (xrandr would be rotating the display) then you need to change the Screen.TopEdge contextkit property. Before you launch your application, you can use context-provider to provide the Screen.TopEdge property: $ context-provider add string Screen.TopEdge Then once your application is running, you can change the value in the context-provider terminal: Screen.TopEdge = left Screen.TopEdge = top etc. James [MeeGo-dev] Handset UX rotation -- how is it implemented? It's implemented by applying a 90° rotation on the world transform in the main QGraphicsView. So the rotation is entirely done by the application. Remember that it's not just showing the rotated screen, but also showing the rotation animation. There's no way to do that with the rotation being done outside of the application. Any Idea telling the Home-screen-application to rotate? Regards Jörn On 01.12.2010 22:12, joern wrote: I've tested to rotate with xrandr. But it doesn't seems to work: [me...@localhost ~]$ xrandr -o left X Error of failed request: BadMatch (invalid parameter attributes) Major opcode of failed request: 149 (RANDR) Minor opcode of failed request: 2 (RRSetScreenConfig) Serial number of failed request: 14 Current serial number in output stream: 14 I've tested all other orientation settings, but only normal works. -o normal,inverted,left,right,0,1,2,3 or --orientation normal,inverted,left,right,0,1,2,3 Regards Jörn On 01.12.2010 21:33, Auke Kok wrote: On 12/01/10 12:17, joern wrote: Hi, Is there any Command to rotate the screen manually? Or any other why to get the screen rotated during developement on a real Hardware device? xrandr is your friend - just run `xrandr -o left` or similar. Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Urgent: We need community ftp space or similar
On 12/1/10 10:27 AM, Quim Gil quim@nokia.com wrote: On Wed, 2010-12-01 at 09:21 +0100, ext Till Harbaum / Lists wrote: Hi list, i would really like to release some ready-to-run beagleboard meego image. But unfortunately we are missing a place to store files in the gigabyte range for public download. Other meego projects and even the n900/n8x0 adaption teams are facing the same problem. Can we please have such a place? Can you please submit a request at http://bugs.meego.com ? It's ok to send an email to meego-dev pointing to that request so anybody interested can chime in and follow, but discussing this whole request here is a bit overkill (with thousand of subscribers). Even meego-community would be more on-topic since it's there where the community infrastructure is discussed. Thank you for your understanding. I second Quim's suggestion here. Please submit a request to Bugzilla. I would also suggest that TSG approval would be needed if we wanted to distribute unofficial images from meego.com. I understand the need, but if we're already talking that we might need a disclaimer, then I think approval would be required. Ryan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] MeeGo and 3G/4G
Hi: Has anyone tested any USB based 3G/4G cards and whether it is compatible with MeeGo? Alternatively, do you know if MeeGo will be compatible on Dell Mini 10 4G which is a netbook with 4G built-in? thanks Mark ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] build script fails on Ubuntu
This has been a huge help! Thanks a lot. It successfully builds binary package, but at the final stage it starts RPMLINT report that fails with: IOError: [Errno 2] No such file or directory: '/tmp/rpmlint.cpio-2.11-2.6.src.rpm.xWnjow/cpio.spec' Is this something important or can be ignored? Thanks! Andrew It seems new changes have been pushed for 'build' in the repo that might fix this issue. Though the issue seems to be that liblua is missing from the build configs. Just add 'liblua' in the Preinstall section in the build config file you are using, for example: /usr/lib/build/configs/default.conf Regards, On 12/01/2010 12:31 AM, AndrewT wrote: Dear All, Does anybody run build script on Ubuntu ? It complains about liblua-5.1.so rpm: error while loading shared libraries: liblua-5.1.so: cannot open shared object file: No such file or directory I tried to run the following command: $sudo build --repository http://repo.meego.com/MeeGo/builds/trunk/1.1.80.8.20101130.1/core/repos/ia32/packages/ - -arch i686 cpio-2.11-2.6.src.rpm Thanks, Andrew ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] build script fails on Ubuntu
Make sure you have enough space left in the image. Regards, On 12/01/2010 09:02 PM, AndrewT wrote: This has been a huge help! Thanks a lot. It successfully builds binary package, but at the final stage it starts RPMLINT report that fails with: IOError: [Errno 2] No such file or directory: '/tmp/rpmlint.cpio-2.11-2.6.src.rpm.xWnjow/cpio.spec' Is this something important or can be ignored? Thanks! Andrew It seems new changes have been pushed for 'build' in the repo that might fix this issue. Though the issue seems to be that liblua is missing from the build configs. Just add 'liblua' in the Preinstall section in the build config file you are using, for example: /usr/lib/build/configs/default.conf Regards, On 12/01/2010 12:31 AM, AndrewT wrote: Dear All, Does anybody run build script on Ubuntu ? It complains about liblua-5.1.so rpm: error while loading shared libraries: liblua-5.1.so: cannot open shared object file: No such file or directory I tried to run the following command: $sudo build --repository http://repo.meego.com/MeeGo/builds/trunk/1.1.80.8.20101130.1/core/repos/ia32/packages/ - -arch i686 cpio-2.11-2.6.src.rpm Thanks, Andrew ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] broken links to development images
On Wed, Dec 1, 2010 at 6:20 PM, Dave Neary dne...@maemo.org wrote: Hi, Tom Chen wrote: maybe you could get one form http://repo.meego.com/MeeGo/builds/trunk/. hope this could help you. I thhink the images are in http://repo.meego.com/MeeGo/builds/trunk/1.1.80.8.20101130.1/core/images/ The problem with this link is that it will be out of date straight away - and there doesn't seem to be a latest link pointing to the most recent images. We should definitely have correct links in Developing in a Meego Environment (ahem... that page proably needs to be moved to something with a shorter better name that doesn't capitalise Environment too), but we shouldn't consciously point to images which will quickly be out of date. I'm totally agree this. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org -- Br Tom Chen tom.c...@teleca.com Teleca Chengdu Ltd. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] why my helloworld can not be displayed on the top of the window
Hi all: I install the MaddeSDK and setup the *meego-core-armv7l-1.1* target . Follow the instructions, I write my first QT application for Arm version. I can install to my device, but I can not see my app, actually it run on the background. I write the simple XLib based app, still launched on the background, I dont know how does meego manage its apps, or related with WM? Can someone explain to me, how to install and run a arm based application correctly? B.R Leo ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] why my helloworld can not be displayed on the top of the window
Hi Tom: Sure I build it into rpm and copy to the device, rpm -i XX. And when I run the app, it is always on the background. If I kill the process(all process about launcher and the other meego apps...), then I could see my app's UI. that seems WM has ignore my app, does not put it into its list. I'm not clear what caused this . [?] -- Hi, Leo do you use rpm install your app to device? how launch your app? i mean from terminal or ui? On Thu, Dec 2, 2010 at 11:18 AM, Leo leo20090916 at gmail.com http://lists.meego.com/listinfo/meego-dev wrote: * Hi all: ** I install the MaddeSDK and setup the *meego-core-armv7l-1.1* target ** . ** Follow the instructions, I write my first QT application for Arm version. ** I can install to my device, but I can not see my app, actually it run on ** the background. ** ** I write the simple XLib based app, still launched on the background, I dont ** know how does meego ** manage its apps, or related with WM? ** ** Can someone explain to me, how to install and run a arm based application ** correctly? ** ** B.R ** ** Leo ** ** ___ ** MeeGo-dev mailing list ** MeeGo-dev at meego.com http://lists.meego.com/listinfo/meego-dev ** http://lists.meego.com/listinfo/meego-dev ** ** * 361.gif___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] [Sensorfw] Open the sensordlog
hihi~~ I can't open the Sensordlog by command in sensord.(--log-level) Anyone know how to open the log on console? Thanks. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-touch-dev] meegotouch-inputmethodkeyboard 0.5.15-1 has been tagged
Hi, meego-keyboard (0.5.15-1) unstable; urgency=low * Changes: Catch up with meegotouch-inputmethodengine update on Version 0.4 . * Changes: use cursor position to locate wordtracker. * Fixes: NB#206444 - Strange behavior of Smiley Picker and Done/Send buttons in Conversational View * Fixes: NB#204964 - Toolbar button label is truncated in portrait mode Gibran ___ MeeGo-touch-dev mailing list MeeGo-touch-dev@meego.com http://lists.meego.com/listinfo/meego-touch-dev
