Re: [MeeGo-dev] how to control backligh on handset device
2011/3/18 Arjan van de Ven > On 3/17/2011 8:24 PM, JK wrote: > >> Hi, >> I want to add adjust back-light control application on handset device. >> > > there is a very nice XBacklight extension. > > > > http://cgit.freedesktop.org/xorg/app/xbacklight/ > > is an example app of on how to use it... > > Does it works on meego now?? thanks. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] how to control backligh on handset device
On 3/17/2011 8:24 PM, JK wrote: Hi, I want to add adjust back-light control application on handset device. there is a very nice XBacklight extension. http://cgit.freedesktop.org/xorg/app/xbacklight/ is an example app of on how to use it... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] how to control backligh on handset device
Hi, I want to add adjust back-light control application on handset device. How to do it? Thanks, ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [MeeGo-community] GSOC 2011: Idea
On Thu, Mar 17, 2011 at 5:24 PM, Hartti Suomela wrote: > FWIW > Google already uses this kind of approach in gathering traffic data (in > addition to other sources) > > http://googleblog.blogspot.com/2009/08/bright-side-of-sitting-in-traffic.html > Uhm...this is very similar to what I wanted to do (also if it not displays information splitted by date/time). Maybe now I can change this idea to only simple import Google MyLocation (and others) to meego (wondering if it possible...) > Also Nokia has done some research on this a few years ago > http://research.nokia.com/news/600 > There might be some other activities as well, but these are the two I knew > of the top of my head (without starting large scale googling :-). > > Hartti > Thanks for the informations! > > > On Thu, Mar 17, 2011 at 9:49 AM, Daniele Maio >>> wrote: >>> > Hello, >>> > >>> > I've an idea for the Google Summer of Code 2011, and I wuold like to >>> discuss >>> > it here before updating the wiki. >>> > My idea is to create an application to monitoring traffic on >>> streets/routes. >>> > With this application everyone with a device >>> (smartphone/laptop/whatever) >>> > with a gps can trace some route. >>> > While tracking, in addition to the coordinates also the istant speed >>> and a >>> > timestamp will be registered. >>> > This application would have a daemon that does this job (tracking), a >>> simple >>> > UI that show a map (using google maps api) >>> > through which you can search for a street (or a route) and it will give >>> you >>> > information about the average speed (also filtered by time). >>> > One more thing is the necessity to have a 'server' where the registered >>> data >>> > have to be sended. This data has to be stored in a database, >>> > and the server has to be capable of doing operation for calculating the >>> > average speed and filtering results. >>> > You can also consider this application as a 'social application' : >>> everyone >>> > everywhere can help tracking any street/route. >>> > I would like to do this application with meego since it cover a large >>> number >>> > of devices (don't forget IVI). >>> > So, any comments/feedback ? >>> >>> >>> > Best Regards, Daniele Maio. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [MeeGo-community] MeeGo Conferece: non-commercial proposals are also welcome!
I wonder what we can do to avoid this kind of mis conceptions in the future - I guess this also worth discussion at the conf :-) Thanks for the note! -Sivan On Thu, Mar 17, 2011 at 6:43 PM, Quim Gil wrote: > CROSSPOSTING ON PURPOSE - please reply only to meego-events. > > Loud and clear: 100% community - non-profit - hobbyist submissions are > also welcome at the MeeGo Conference > http://sf2011.meego.com/program/call-session-proposals > > Just like in Dublin. Hurry up! > > I'm sending this because I just realized at #meego IRC channel that many > people thought the San Francisco conference was *exclusively* for > commercial parties and topics like e.g. apps.meego.com or the community > OBS were not wanted. > > Good that I asked and we found the problem. I'm not part of the content > committee but I believe everybody in the conference organization assumes > that any relevant community activity related to the MeeGo project is > worth a submission proposal. > > -- > Quim > > ___ > MeeGo-community mailing list > meego-commun...@meego.com > http://lists.meego.com/listinfo/meego-community > http://wiki.meego.com/Mailing_list_guidelines > ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [PATCH 2/3] Move duplicated code to SeasideListItemBase.
Hi Robin,
Thanks for taking a look. I haven't tested this under much load yet, and
based on your comments below, it looks like my understanding of the
async APIs was incorrect.
On 03/17/2011 06:21 AM, Robin Burchell wrote:
Hi Kaitlin,
On 17/03/11 00:22, Kaitlin Rupert wrote:
I've pushed the changes to a remote branch if you want to take a look:
http://meego.gitorious.org/meego-handset-ux/libseaside/commits/async.
I've taken a look through, and while the aim is good, I do see one
problem with this design.
you appear to be storing single instances of many different requests
(QContactSaveRequest instances for updateAvatar, updateContact, etc)
inside SeasideSyncModel. I'm not sure what your reasons are, but at
the least, this won't work as you expect with many requests being
processed at once.
this is because setContact while a request is still running is
probably not a good idea, and at best, start() on an already-running
request is going to return false. So when you have high contention
with multiple running saves, bad things will happen.
I had some concerns about this, but hadn't tested the current code
thoroughly to make sure this wasn't an issue. I should have implemented
something to safe guard against this in the first place though. Agreed
- the approach I have won't work with requests coming in from multiple
applications.
A better option is to abstract your saving of details of contacts to
have an explicit 'commit' functionality somehow, which might look
something like this for saving contacts:-
void SeasideSyncModel::savePendingContacts()
{
QContactLocalId id = priv->uuidToId[uuid];
QContact *contact = priv->idToContact[id];
if (!contact)
return;
QContactSaveRequest *saveRequest = new QContactSaveRequest(this);
connect(saveRequest,
SIGNAL(stateChanged(QContactAbstractRequest::State),
SLOT(onSaveStateChanged(QContactAbstractRequest::State));
saveRequest->setContacts(priv->unsavedContacts);
priv->unsavedContacts.clear();
if (!saveRequest->start()) {
qDebug() << Q_FUNC_INFO << "Save request failed to start";
delete saveRequest;
}
}
void
SeasideSyncModel::onSaveStateChanged(QContactAbstractRequest::State
state)
{
// delete request if it's finished
// log error if it failed for some reason
}
This sounds like an excellent approach. It would also provide a way to
expose errors to the applications. libseaside currently lacks error
handlers for when saveContact() / removeContact() fails.
... and then, presuming that savePendingContacts is a slot, you could
invoke it on a timer set to persist, say, 50-100ms after the last
alteration of data. In addition, this approach also allows you to
easily thread the save request to really prevent UI blocking, should
you wish.
And this would give the application a way to retry in case an error occurs.
If you'd like, I can work on a patch prototyping this approach
sometime in the next day or two.
I won't be able to take a look at libseaside until sometime next week.
So if you have bandwidth to work on this, that would be fantastic. I
can assist with testing.
Thanks!
-Kaitlin
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] MeeGo Conferece: non-commercial proposals are also welcome!
CROSSPOSTING ON PURPOSE - please reply only to meego-events. Loud and clear: 100% community - non-profit - hobbyist submissions are also welcome at the MeeGo Conference http://sf2011.meego.com/program/call-session-proposals Just like in Dublin. Hurry up! I'm sending this because I just realized at #meego IRC channel that many people thought the San Francisco conference was *exclusively* for commercial parties and topics like e.g. apps.meego.com or the community OBS were not wanted. Good that I asked and we found the problem. I'm not part of the content committee but I believe everybody in the conference organization assumes that any relevant community activity related to the MeeGo project is worth a submission proposal. -- Quim ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Post-installation security fix & question for Intel MeeGo Tablet developers release
On Tue, Mar 8, 2011 at 1:30 PM, Martin Grimme wrote: > I found out how to use the mute button on the Lenovo S10-3t for the > Super/Home Key on the Intel Tablet UX. The other two buttons are ACPI > buttons and generate no keycodes with this kernel. > > Run > > setkeycodes e020 125 > > as root. Thank you!! Works great on the Netbook UX as well, bringing up the popup bar at the top. This is normally difficult to bring up in "tablet" mode because you have to jam your pinky up against the bezel near the top of the display so as to get close to the pixels at the very top of the screen. Or use a capacitive "stylus" that is small enough to get at the screen right near the bezel. I'm more likely to reach under and find the "windows" key... but now I don't have to. I also updated http://forum.meego.com/showthread.php?p=19269 with this info. Niels http://nielsmayer.com ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] Getting touchscreen recognized by mtev
Do I need to add an xorg.conf.d file to xorg-x11-drv-mtev to get my touchscreen to work with MeeGo 1.2 ? I'm backporting a touchscreen driver[1] from 2.6.38. However, it didn't even work as a mouse until I forced it to use the mtev driver (xorg.conf). (This is a 1.1.90.x Handset pineview build). The MeeGo package for xorg-x11-drv-mtev includes the files 60-cando-mtev.conf and 70-sitronix-mtev.conf to do the same thing. Is this the Right Way, or is there something wrong with the driver? Thanks, Gabriel [1] The hid-multitouch driver (BMC # 10887) ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [PATCH 2/3] Move duplicated code to SeasideListItemBase.
Hi Kaitlin,
On 17/03/11 00:22, Kaitlin Rupert wrote:
I've pushed the changes to a remote branch if you want to take a look:
http://meego.gitorious.org/meego-handset-ux/libseaside/commits/async.
I've taken a look through, and while the aim is good, I do see one
problem with this design.
you appear to be storing single instances of many different requests
(QContactSaveRequest instances for updateAvatar, updateContact, etc)
inside SeasideSyncModel. I'm not sure what your reasons are, but at the
least, this won't work as you expect with many requests being processed
at once.
this is because setContact while a request is still running is probably
not a good idea, and at best, start() on an already-running request is
going to return false. So when you have high contention with multiple
running saves, bad things will happen.
A better option is to abstract your saving of details of contacts to
have an explicit 'commit' functionality somehow, which might look
something like this for saving contacts:-
void SeasideSyncModel::savePendingContacts()
{
QContactLocalId id = priv->uuidToId[uuid];
QContact *contact = priv->idToContact[id];
if (!contact)
return;
QContactSaveRequest *saveRequest = new QContactSaveRequest(this);
connect(saveRequest,
SIGNAL(stateChanged(QContactAbstractRequest::State),
SLOT(onSaveStateChanged(QContactAbstractRequest::State));
saveRequest->setContacts(priv->unsavedContacts);
priv->unsavedContacts.clear();
if (!saveRequest->start()) {
qDebug() << Q_FUNC_INFO << "Save request failed to start";
delete saveRequest;
}
}
void SeasideSyncModel::onSaveStateChanged(QContactAbstractRequest::State
state)
{
// delete request if it's finished
// log error if it failed for some reason
}
... and then, presuming that savePendingContacts is a slot, you could
invoke it on a timer set to persist, say, 50-100ms after the last
alteration of data. In addition, this approach also allows you to easily
thread the save request to really prevent UI blocking, should you wish.
If you'd like, I can work on a patch prototyping this approach sometime
in the next day or two.
-Kaitlin
Best regards,
--
Robin Burchell
http://rburchell.com
___
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [MeeGo-community] GSOC 2011: Idea
On Thu, Mar 17, 2011 at 2:02 PM, Leonardo Luiz Padovani da Mata < leonar...@syst.com.br> wrote: > On Thu, Mar 17, 2011 at 9:49 AM, Daniele Maio > wrote: > > Hello, > > > > I've an idea for the Google Summer of Code 2011, and I wuold like to > discuss > > it here before updating the wiki. > > My idea is to create an application to monitoring traffic on > streets/routes. > > With this application everyone with a device (smartphone/laptop/whatever) > > with a gps can trace some route. > > While tracking, in addition to the coordinates also the istant speed and > a > > timestamp will be registered. > > This application would have a daemon that does this job (tracking), a > simple > > UI that show a map (using google maps api) > > through which you can search for a street (or a route) and it will give > you > > information about the average speed (also filtered by time). > > One more thing is the necessity to have a 'server' where the registered > data > > have to be sended. This data has to be stored in a database, > > and the server has to be capable of doing operation for calculating the > > average speed and filtering results. > > You can also consider this application as a 'social application' : > everyone > > everywhere can help tracking any street/route. > > I would like to do this application with meego since it cover a large > number > > of devices (don't forget IVI). > > So, any comments/feedback ? > > > The idea is to use server information to update the application > traffic? Some cities already have traffic information uploaded to > google maps, maybe you can just use this information instead of > creating a new track. > Yes, but as you said only *some* city have this information available. My idea is to have the traffic information, as per social application, for many other country. The information could be also searched by time and day. > > Do you think that someone wants to share their location every time? > Don't you think this is an private information that should be shared > only to those who are friends. There are some security issues related > on that. > They are not sharing their location. The app should only register the coordinates only if the user explicitly want to do this, and all the information will be sended to the server in an anonymous way. > > The sever capability is another problem, you need to specify how often > the data should be sent to the server, how much information is sent to > the server and what the server will do with the information. Depending > on the solution you want to provide you will have a NP-complex > problem. > The data should be sended whenever the user want (e.g. immediatly after stop tracking, if any connection is available or schedule when to update the data). The data will consist in a simple text file (or sqlite file). > > > > Thank you. > > > > > > > > > > Best Regards, > > Daniele Maio > > > > ___ > > MeeGo-community mailing list > > meego-commun...@meego.com > > http://lists.meego.com/listinfo/meego-community > > http://wiki.meego.com/Mailing_list_guidelines > > > > > > -- > Leonardo Luiz Padovani da Mata > > International Syst S/A > Metasys Tecnologia > Software Engineer Metasys MeeGo Team > > leonar...@metasys.com.br > +55-31-3503-9040 > > "May the force be with you, always" > "Nerd Pride... eu tenho. Voce tem?" > Best Regards, Daniele Maio. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [MeeGo-community] GSOC 2011: Idea
On Thu, Mar 17, 2011 at 9:49 AM, Daniele Maio wrote: > Hello, > > I've an idea for the Google Summer of Code 2011, and I wuold like to discuss > it here before updating the wiki. > My idea is to create an application to monitoring traffic on streets/routes. > With this application everyone with a device (smartphone/laptop/whatever) > with a gps can trace some route. > While tracking, in addition to the coordinates also the istant speed and a > timestamp will be registered. > This application would have a daemon that does this job (tracking), a simple > UI that show a map (using google maps api) > through which you can search for a street (or a route) and it will give you > information about the average speed (also filtered by time). > One more thing is the necessity to have a 'server' where the registered data > have to be sended. This data has to be stored in a database, > and the server has to be capable of doing operation for calculating the > average speed and filtering results. > You can also consider this application as a 'social application' : everyone > everywhere can help tracking any street/route. > I would like to do this application with meego since it cover a large number > of devices (don't forget IVI). > So, any comments/feedback ? The idea is to use server information to update the application traffic? Some cities already have traffic information uploaded to google maps, maybe you can just use this information instead of creating a new track. Do you think that someone wants to share their location every time? Don't you think this is an private information that should be shared only to those who are friends. There are some security issues related on that. The sever capability is another problem, you need to specify how often the data should be sent to the server, how much information is sent to the server and what the server will do with the information. Depending on the solution you want to provide you will have a NP-complex problem. > Thank you. > > > > > Best Regards, > Daniele Maio > > ___ > MeeGo-community mailing list > meego-commun...@meego.com > http://lists.meego.com/listinfo/meego-community > http://wiki.meego.com/Mailing_list_guidelines > -- Leonardo Luiz Padovani da Mata International Syst S/A Metasys Tecnologia Software Engineer Metasys MeeGo Team leonar...@metasys.com.br +55-31-3503-9040 "May the force be with you, always" "Nerd Pride... eu tenho. Voce tem?" ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] GSOC 2011: Idea
Hello, I've an idea for the Google Summer of Code 2011, and I wuold like to discuss it here before updating the wiki. My idea is to create an application to monitoring traffic on streets/routes. With this application everyone with a device (smartphone/laptop/whatever) with a gps can trace some route. While tracking, in addition to the coordinates also the istant speed and a timestamp will be registered. This application would have a daemon that does this job (tracking), a simple UI that show a map (using google maps api) through which you can search for a street (or a route) and it will give you information about the average speed (also filtered by time). One more thing is the necessity to have a 'server' where the registered data have to be sended. This data has to be stored in a database, and the server has to be capable of doing operation for calculating the average speed and filtering results. You can also consider this application as a 'social application' : everyone everywhere can help tracking any street/route. I would like to do this application with meego since it cover a large number of devices (don't forget IVI). So, any comments/feedback ? Thank you. Best Regards, Daniele Maio ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] N900 Developer Edition Release Blockers Flag
Hello MeeGons! A quick note to inform you that we just enabled a new flag in order to track the blockers related to the N900 DE release. This new flag can be proposed by any user with editbug credentials. Remember to clearly state in a bug comment the reasons why you propose it as blocker. In order to search for the flag, please use the Advanced Searching Using Boolean Charts at the bottom of the search/report bugzilla page. MeeGo_N900DE_Release_Blocker? Will show the proposed flags MeeGo_N900DE_Release_Blocker+ Will show the approved flagged bugs MeeGo_N900DE_Release_Blocker- Will show the rejected ones Approval or refusal is handled by Jukka Eklund. More people will be added in the flag granting group as we proceed. Iekku Huttunen acts as official EM for this exercise. Note that the "N900_Developer_Edition_Blocker" keyword is deprecated and has been removed. Happy bug hunting and fixing! Best regards, Eric Le Roux MeeGo EM Lead ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] Candidate specification for a generic video player from the TV list
Hi Dominig, On 16.03.2011 11:08, ext Dominig ar Foll wrote: > Hello, > > As many of you may not follow the TV mailing list. I post you an information > about a proposal which might also present interest outside of the TV world. > > when you start to play video on Linux you realise quickly that no > solution can cover the full need of playing video for a real full TV > application. If you try to create a Consumer Electronic (CE) device, you > likely use a System on Chip (SoC) which provides a concept of video > overlay which provide a great help on performance but make any > integration very specific. > > The propose specification has been written for TV but cold be valuable > to any device which either wants to be fully compliant with TV > requirement when playing videos or use SoC with hardware acceleration. > > The proposed specification aims at creating a generic service for Linux > (I will start by MeeGo TV) which could unify the play out of a video and > make transparent the support of various hardware helper provider by some > chip and in particular the support of overlay video common on SoC. > > Thanks to let me know your feedback, preferably on the MeeGo TV mailing > list.. > > File can be found here : > http://wiki.meego.com/File:Meego_Unified_MultiMedia_Service_V0.4.odt Regarding the already existing projects. Are you aware of MAFW on Maemo5 http://www.grancanariadesktopsummit.org/node/219 The implementation might not be perfect, but the concept behind is sane. The picture in "6 Position in MeeGo" looks quite arbitrary to me. Do the colors have a special semantics (meybe add a small leged below). In "7 Transparency" you need to highlight what your proposal adds to the existing features. * Transport protocol: handled e.g. by gstreamer already, standarts like DLNA specify subsets for interoperability already * Transparent Encapsulation and Multiplexing: could you please elaborate why one would need the non-automatic mode. I think it does not make sense to let the application specify what format the stream is in, if the media-framework can figure it (in almost all of the cases). In some corner cases one can e.g. use custom pipelines and specify the format (e.g. a ringtone playback service might do that if it knows the format already). * Transparent Target: Whats the role of the UMMS here? How does the URI make sense here. Are you suggesting to use something like opengl://localdisplay/0/0/854/480? MAFW was introducing renderers, where a local renderer would render well locally and one could e.g. have a UPnP DLNA renderer or a media recorder. * Transparent Resource Management: That makes a lot of sense and so far was planned to be done on QT MultimediaKit * Attended and Non Attended execution: This sounds like having a media recording service in the platform. "8 Audio Video Control" This is a media player interface. Most of the things make sense. Below those that might need more thinking * Codec Selection: please don't. This is something that we need to solve below and not push to the application or even to the user. * Buffer Strategy: same as before. Buffering strategy depends on the use-case and media. The application needs to express whether its a media-player/media-editor/.. and from that we need to derive this. "9 Restricted Access Mode" Most of those are needed as platform wide services. E.g. Parental Control would also be needed for Internet access. "11 Developer and Linux friendly" * Backwards compatible ...: My suggestion is to take inspiration in existing components, but only do any emulation if someone really needs that. It is usually possible to some extend, but whats the point? * Device and Domain independence: Again, how does UMMS improve the situation here? "12 Typical use cases" I think it would be helpful to have before and after stories here to highlight the benefits of your concept. "13 D-Bus" Be careful with generic statements like "D-Bus can be a bit slow ...". Stick with facts and avoid myths. "14 QT-Multimedia" Seriously, don't even consider to stack it on top of qt-multimedia. We're still embedded. You could propose to implement it as part of QT multimedia though (or having it at the same level). "15 GStreamer" It is GStreamer (with a upper case 'S') :) In general please spell check the section. Regarding the three weak points: * smooth fast forward is a seek_event with a rate>1.0. There might be elements not properly implementing that, but I fail to understand how you can fix that on higher layers instead of in the elements. It might make sense to define extended compliance criteria for base adaptation vendors to ensure consistent behavior and features. * DRM can be implemented outside of GStreamer. still I don't fully understand what the issue here might be. * Push/pull: gstreamer is a library. you can do lots of things with it. If you want to use it to broadcast media you can do that very well. Some known examples: rygel (upnp media server), gst-rtsp-server. J
