[MeeGo-dev] MeeGo Security Architecture
I wanted to let everyone on this list know that the initial revision of the MeeGo Security Architecture has been published in the MeeGo wiki here: http://wiki.meego.com/Security/Architecture I know many of you will consider this long overdue. To those I apologize. I also want to publicly recognize Elena Reshetova, Janne Karhunen and Casey Schaufler for their innumerable contributions. Please direct any questions or concerns you may have to the meego-security-discuss...@meego.com list. While the security architecture touches on many different aspects of MeeGo (hence the reason for the broad distribution list), I want to ensure the discussion is centralized in one place and we aren't cross-posting across numerous lists. In the coming days I will also be expanding the wiki security page to point to other aspects of MeeGo security. Thanks, Ryan Ware MeeGo Security Lead ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Qt situation with single touch?
On 02/01/2011 04:11 PM, Clark, Joel wrote: What changed recently that exposed this evtouch issue? This driver has seemed to work OK for over a year, until around mid January. Qt now relies on XInput2 in order to support multiple contact points per device. As part of that work, Qt uses data advertised by the input device driver in order to correctly map labeled buttons to Qt buttons. Unfortunately, when the evtouch driver is used, the driver advertises that it has the data, but doesn't seem to set that data up correctly. James regards Joel -Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of James Sent: Tuesday, February 01, 2011 4:06 PM To: Carsten Munk Cc: meego-dev Subject: Re: [MeeGo-dev] Qt situation with single touch? On 01/31/2011 02:34 AM, Carsten Munk wrote: Hi, After the xinput2 patches came into qt, we have seen problems on IVI (BMC# 12777 ) and N900 (http://bugs.meego.com/show_bug.cgi?id=10147) regarding input not working. The problem seems to be that all presses are seen as constantly held down. On N900 we've even tried to see if upgrading evdev to latest upstream worked (xinput2 support included), but no remedy. Normal X applications work fine, but Qt apps don't work properly. What is the story here and what is timeframe for it being fixed? I'm a bit tired of seeing very low % QA reports in acceptance for 4 days in a row :) It appears there is a bug with the evtouch (at least) X input driver such that button labels atoms are not being set correctly in the XIButtonClassInfo structure provided by X -- which results in Qt not being able to map the button presses to ButtonLeft. Those atoms are set correctly when a USB mouse is used or the mtev input driver. To confirm the above, you can enumerate the configured button labels for input devices via xinput $ xinput list --long "Virtual core pointer" On a good system, you will see all of the button labels being displayed for the aggregate set of input devices bound to the virtual core pointer. Names like "Button Left" etc. With the evtouch driver on IVI, you will see X complain about various bad Atoms being provided when it attempts to enumerate the button labels. Within Qt, the atoms provided by X are mapped to known values to correspond to ButtonLeft, ButtonRight, etc. The code logic breaks down in Qt's src/gui/kernel/qapplication_x11.cpp's mapXI2ButtonToButtonLabel() since the label provided by X is bogus it can't be mapped to a Qt button label, resulting in no button being identified. James ___ 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] Qt situation with single touch?
What changed recently that exposed this evtouch issue? This driver has seemed to work OK for over a year, until around mid January. regards Joel -Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of James Sent: Tuesday, February 01, 2011 4:06 PM To: Carsten Munk Cc: meego-dev Subject: Re: [MeeGo-dev] Qt situation with single touch? On 01/31/2011 02:34 AM, Carsten Munk wrote: > Hi, > > After the xinput2 patches came into qt, we have seen problems on IVI > (BMC# 12777 ) and N900 (http://bugs.meego.com/show_bug.cgi?id=10147) > regarding input not working. The problem seems to be that all presses > are seen as constantly held down. On N900 we've even tried to see if > upgrading evdev to latest upstream worked (xinput2 support included), > but no remedy. > > Normal X applications work fine, but Qt apps don't work properly. > > What is the story here and what is timeframe for it being fixed? I'm a > bit tired of seeing very low % QA reports in acceptance for 4 days in > a row :) It appears there is a bug with the evtouch (at least) X input driver such that button labels atoms are not being set correctly in the XIButtonClassInfo structure provided by X -- which results in Qt not being able to map the button presses to ButtonLeft. Those atoms are set correctly when a USB mouse is used or the mtev input driver. To confirm the above, you can enumerate the configured button labels for input devices via xinput $ xinput list --long "Virtual core pointer" On a good system, you will see all of the button labels being displayed for the aggregate set of input devices bound to the virtual core pointer. Names like "Button Left" etc. With the evtouch driver on IVI, you will see X complain about various bad Atoms being provided when it attempts to enumerate the button labels. Within Qt, the atoms provided by X are mapped to known values to correspond to ButtonLeft, ButtonRight, etc. The code logic breaks down in Qt's src/gui/kernel/qapplication_x11.cpp's mapXI2ButtonToButtonLabel() since the label provided by X is bogus it can't be mapped to a Qt button label, resulting in no button being identified. James ___ 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] Qt situation with single touch?
On 01/31/2011 02:34 AM, Carsten Munk wrote: Hi, After the xinput2 patches came into qt, we have seen problems on IVI (BMC# 12777 ) and N900 (http://bugs.meego.com/show_bug.cgi?id=10147) regarding input not working. The problem seems to be that all presses are seen as constantly held down. On N900 we've even tried to see if upgrading evdev to latest upstream worked (xinput2 support included), but no remedy. Normal X applications work fine, but Qt apps don't work properly. What is the story here and what is timeframe for it being fixed? I'm a bit tired of seeing very low % QA reports in acceptance for 4 days in a row :) It appears there is a bug with the evtouch (at least) X input driver such that button labels atoms are not being set correctly in the XIButtonClassInfo structure provided by X -- which results in Qt not being able to map the button presses to ButtonLeft. Those atoms are set correctly when a USB mouse is used or the mtev input driver. To confirm the above, you can enumerate the configured button labels for input devices via xinput $ xinput list --long "Virtual core pointer" On a good system, you will see all of the button labels being displayed for the aggregate set of input devices bound to the virtual core pointer. Names like "Button Left" etc. With the evtouch driver on IVI, you will see X complain about various bad Atoms being provided when it attempts to enumerate the button labels. Within Qt, the atoms provided by X are mapped to known values to correspond to ButtonLeft, ButtonRight, etc. The code logic breaks down in Qt's src/gui/kernel/qapplication_x11.cpp's mapXI2ButtonToButtonLabel() since the label provided by X is bogus it can't be mapped to a Qt button label, resulting in no button being identified. James ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] [MeeGo-Dev] Navit in QX11EmbedContainer disappears while playing movie in QMediaPlayer
In MeeGo IVI I am embedding Navit in Qt Application using QX11EmbedContainer working fine. However once I start QMediaPlayer to play video (in other QWidget) and go back to Navit, QX11 does not show anything. Navit is still working and responding to DBus requests, but I cannot see anything. I already tried to call show(); repaint(); etc. methods of QX11, but without success. So is there anything I did not think about using embeddedcontainer with qmediaplayer in parallel? //this is how I start video QMediaPlayer *player = new QMediaPlayer; QVideoWidget *widget = new QVideoWidget(); player->setVideoOutput(widget); widget->show(); player->play(); cheers simon:) mit freundlichem Gruss / best regards / pozdrawiam / atentamente Simon P. Bolek -- Dipl. Inf. Simon P. Bolek SAP Consultant Business Mobile and IVI Solutions Cell: +49 (177) 67 36 556 mailto: simon.bo...@arcom-ivi.de http://www.arcom-ivi.de/ XING: https://www.xing.com/profile/SimonP_Bolek GULP: 84465 ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Broadcom WL on MeeGo Netbook 1.1.90.0.20110125
I understand your concerns about Broadcom's open-source policy. However, since I was successfully able to build the very same driver on the MeeGo 1.1 release form October but not with the one from 1/25 the not so far fetched conclusion is that something changed in MeeGo. Which I now know it did. Ok, this may not be the right list but one is probably more likely to get an answer about init_MUTEX on a developer list than on an end-user list. On Tue, Feb 1, 2011 at 12:58 PM, Arjan van de Ven wrote: > On 2/1/2011 12:57 PM, Rudolf Streif wrote: > >> Thank you. Yes, I did download the latest source from >> http://www.broadcom.com/support/802.11/linux_sta.php. The version number >> is 5.100.82.38 which is the version of the spec file. It's the one I am >> having issues with. >> > > not to be an ass about it, but I would suspect that Broadcom is in a much > better position to support their binary driver > than the MeeGo development list Have you tried asking Broadcom for > support instead ? > > (never mind that this is a development list not an end user help list) > > ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Broadcom WL on MeeGo Netbook 1.1.90.0.20110125
On 2/1/2011 12:57 PM, Rudolf Streif wrote: Thank you. Yes, I did download the latest source from http://www.broadcom.com/support/802.11/linux_sta.php. The version number is 5.100.82.38 which is the version of the spec file. It's the one I am having issues with. not to be an ass about it, but I would suspect that Broadcom is in a much better position to support their binary driver than the MeeGo development list Have you tried asking Broadcom for support instead ? (never mind that this is a development list not an end user help list) ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Broadcom WL on MeeGo Netbook 1.1.90.0.20110125
Thank you. Yes, I did download the latest source from http://www.broadcom.com/support/802.11/linux_sta.php. The version number is 5.100.82.38 which is the version of the spec file. It's the one I am having issues with. Rudi On Tue, Feb 1, 2011 at 12:27 PM, Sergio Schvezov wrote: > On Mon, 2011-01-31 at 22:39 -0800, Shane Bryan wrote: > > On Mon, Jan 31, 2011 at 05:37:51PM -0800, Rudolf Streif wrote: > > I am trying t build the pita Broadcom WL driver module on a MeeGo Netbook > > for which I built the image using meego-netbook-ia32-1.1.90.0.20110125.3.ks. > > When compiling the wl_linux.c it throws "implicit declaration of function > > 'init_MUTEX'". I installed the kernel headers and supposedly that macro is > > declared in semaphore.h. I built that driver on previous MeeGo Netbook > > releases but it won't compile on this one. I am not a kernel hacker, so if > > this is obvious, please forgive me. > > init_MUTEX was dropped in 2.6.37 kernel > > Grab the src.rpm from slain.org[1] and extract the Mutex and semaphore > patches from that (or, just use his rpm). > > > > You might need to update to the latest broadcom source as the one linked > there is not avail anymore. Just search broadcom for that driver name as > specified in the spec file > > > Shane... > [1] http://slaine.org/_slaine/Meego_1.1_Wifi.html > > > > ___ > 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] Broadcom WL on MeeGo Netbook 1.1.90.0.20110125
On Mon, 2011-01-31 at 22:39 -0800, Shane Bryan wrote: > On Mon, Jan 31, 2011 at 05:37:51PM -0800, Rudolf Streif wrote: > > I am trying t build the pita Broadcom WL driver module on a MeeGo Netbook > > for which I built the image using meego-netbook-ia32-1.1.90.0.20110125.3.ks. > > When compiling the wl_linux.c it throws "implicit declaration of function > > 'init_MUTEX'". I installed the kernel headers and supposedly that macro is > > declared in semaphore.h. I built that driver on previous MeeGo Netbook > > releases but it won't compile on this one. I am not a kernel hacker, so if > > this is obvious, please forgive me. > > init_MUTEX was dropped in 2.6.37 kernel > > Grab the src.rpm from slain.org[1] and extract the Mutex and semaphore > patches from that (or, just use his rpm). > You might need to update to the latest broadcom source as the one linked there is not avail anymore. Just search broadcom for that driver name as specified in the spec file > Shane... > [1] http://slaine.org/_slaine/Meego_1.1_Wifi.html ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Nintendo Meego GameBoy
Please stop feed the troll its the third thread with similar issue stop this spam right away, I am sure 99% of the developers are unintrested in some amateurs who thinks they now "some company" bests. 2011/2/1 Dave Neary > Hi, > > Thiago Macieira wrote: > > I shouldn't be feeding you but... > > Please do stop feeding the trolls, it makes them reproduce. > > Thanks! > Dave. > > -- > Email: dne...@maemo.org > Jabber: bo...@jabber.org > > ___ > 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] earphone detection question
On Tue, Feb 01, 2011 at 02:00:40PM +0200, Kalle Lampila wrote: > On Tue, Feb 1, 2011 at 09:31, Thiago Macieira wrote: > > On Monday, 31 de January de 2011 22:47:22 Shane Bryan wrote: > >> On Tue, Feb 01, 2011 at 01:58:36PM +0800, alexguitar wrote: > >> > Dear All, > >> > > >> > I want to develop a app to detect earphone with two features, including > >> > plug in and plug out earphone jack . > >> > > >> > Whether does the Qt and Qt mobility provide the API about earphone > >> > detection? > >> > >> If you get an answer off list, please let us know, as I need to monitor > >> this > >> as well. > > > > I'm not sure if the info is available elsewhere, but there's a /dev/input > > interface usually associated with that. Even my Dell laptop has it. > > > > Event: time 1296545363.867189, type 5 (EV_SW), code 2 (Headphone insert), > > value 1 > > Event: time 1296545363.867201, -- Report Sync > > Event: time 1296545370.850146, type 5 (EV_SW), code 2 (Headphone insert), > > value 0 > > Event: time 1296545370.850155, -- Report Sync > > > > There might be a daemon already listening to this event and reporting it in > > contextkit. > > Hi, > > Resouce policy framework has accessories plugin for ohmd to detect > headpohones etc. That information is used to route audio, but probably > that is not reported forward to contexkit. > > Btw. Why you need that information on application? In the dialer app, I have a multi-state button allowing the user to select the output path, and it needs to be aware of the available devices to the appropriate button state options can be presented. So I need to know, when the all of the following are connected or disconnected: - Jack headset - USB headset - BT headset I can get the BT HSP info now, but am still missing the wired jack and USB headset info. Honestly, I've not dug into it much yet, as I've had other work that is taking priority, but since the question was asked, I cast in my vote for more info too ;) -- Shane... ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Libva support on meego 1.1
On 1 February 2011 16:13, john pratss wrote: > Hi , > > Please find the pipeline below which i used for playback > gst-launch filesrc location=test.mp4 ! qtdemux ! vaapidecode ! vaapisink To be honest i've never got it to work either in Meego 1.1, then again I didnt try very hard either. I haven't tried the vaapidecode + vaapisink elements. Have you tried to use vaapi using mplayer, I believe that's the most stable FOSS vaapi implementation... As said, Moorestown support is "experimental", however that much should be obvious if you have used meego 1.1 for more than 5 seconds on a moorestown device. (although it's claimed as "supported" for meego 1.1 handset, but then again so is the N900...) Brendan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Libva support on meego 1.1
Hi , Please find the pipeline below which i used for playback gst-launch filesrc location=test.mp4 ! qtdemux ! vaapidecode ! vaapisink Cheers, John On Tue, Feb 1, 2011 at 8:35 PM, Brendan Le Foll wrote: > On 1 February 2011 15:03, john pratss wrote: > > Hi, > > > > I have tried a gstreamer pipeline to play a video, pipeline freezes while > > libva is trying to open the pvr graphics driver, so could not able play > the > > video. The pipeline is run on the mego 1.1 official release on a Intel > > moorestown platform. > > Please let me know whether libva in 1.1 release supports video playback. > > What is your pipeline exactly? > > What gstreamer elements are you using that uses libva? > > Brendan > ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Libva support on meego 1.1
On 2/1/2011 6:03 AM, john pratss wrote: Hi, I have tried a gstreamer pipeline to play a video, pipeline freezes while libva is trying to open the pvr graphics driver, so could not able play the video. The pipeline is run on the mego 1.1 official release on a Intel moorestown platform. yikes... Moorestown support in 1.1 was "experimental" at best. Please let me know whether libva in 1.1 release supports video playback. you need more than just libva; you need all the hardware specific pieces and codecs to go with it. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Libva support on meego 1.1
On 1 February 2011 15:03, john pratss wrote: > Hi, > > I have tried a gstreamer pipeline to play a video, pipeline freezes while > libva is trying to open the pvr graphics driver, so could not able play the > video. The pipeline is run on the mego 1.1 official release on a Intel > moorestown platform. > Please let me know whether libva in 1.1 release supports video playback. What is your pipeline exactly? What gstreamer elements are you using that uses libva? Brendan ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Multi-touch input driver removed for 2.6.37 kernel
On Tuesday, February 01, 2011 01:26:00 am Thiago Macieira wrote: > On Monday, 31 de January de 2011 22:50:34 Gabriel M. Beddingfield wrote: > > However, wasn't it decided that we need this driver for > > MT support in 1.2 ?? Is this a mistake or a policy > > change? > > 1.2 will use the standard kernel MT interface. It will > not use the "RX-71 hack" protocol. Good! Thank you. -gabriel ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Libva support on meego 1.1
Hi, I have tried a gstreamer pipeline to play a video, pipeline freezes while libva is trying to open the pvr graphics driver, so could not able play the video. The pipeline is run on the mego 1.1 official release on a Intel moorestown platform. Please let me know whether libva in 1.1 release supports video playback. Regards, John ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Nintendo Meego GameBoy
Hi, Thiago Macieira wrote: > I shouldn't be feeding you but... Please do stop feeding the trolls, it makes them reproduce. Thanks! Dave. -- Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] meegoimframework interfaces related to orientation change will be changed
Hi, The upcoming release of libmeegoimframework (0.19.41-1) will have some interface changes which are related to orientation change. What and why Basically, this change only affects the developer who are developing input method plugins base on libmeegoimframework. The detail of changes: - MAbstractInputMethod was changed. The method handleAppOrientationChange() was renamed as handleAppOrientationChanged(), which means target application already finish changing orientation. And there was a new method handleAppOrientationAboutToChange() says target application is about to change orientation. What will break -- The input method plugin which bases on libmeegoimframework will break. To resolve it. The plugins must update their codes according the interfaces changes. How to prepare -- * If you are developer for a input method plugin which bases on libmeegoimframework, you can pull the latest libmeegoimframework from gitorious: http://meego.gitorious.org/meegotouch/meegotouch-inputmethodframework The interfaces changes are already in the master. And update your plugin implementation base on it. When it will happen --- libmeegoimframework (0.19.41-1) will be tagged before in this week. Any question please contact me as soon as possible. BR Ning Chi ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] earphone detection question
On Tue, Feb 1, 2011 at 09:31, Thiago Macieira wrote: > On Monday, 31 de January de 2011 22:47:22 Shane Bryan wrote: >> On Tue, Feb 01, 2011 at 01:58:36PM +0800, alexguitar wrote: >> > Dear All, >> > >> > I want to develop a app to detect earphone with two features, including >> > plug in and plug out earphone jack . >> > >> > Whether does the Qt and Qt mobility provide the API about earphone >> > detection? >> >> If you get an answer off list, please let us know, as I need to monitor this >> as well. > > I'm not sure if the info is available elsewhere, but there's a /dev/input > interface usually associated with that. Even my Dell laptop has it. > > Event: time 1296545363.867189, type 5 (EV_SW), code 2 (Headphone insert), > value 1 > Event: time 1296545363.867201, -- Report Sync > Event: time 1296545370.850146, type 5 (EV_SW), code 2 (Headphone insert), > value 0 > Event: time 1296545370.850155, -- Report Sync > > There might be a daemon already listening to this event and reporting it in > contextkit. Hi, Resouce policy framework has accessories plugin for ohmd to detect headpohones etc. That information is used to route audio, but probably that is not reported forward to contexkit. Btw. Why you need that information on application? -- Kalle Lampila ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] earphone detection question
I input context-ls command, it shows result below: Alarm.Present Alarm.Trigger Battery.ChargeBars Battery.ChargePercentage Battery.IsCharging Battery.LowBattery Battery.OnBattery Battery.TimeUntilFull Battery.TimeUntilLow Bluetooth.Connected Bluetooth.Enabled Bluetooth.Visible Cellular.CellName Cellular.DataTechnology Cellular.NetworkName Cellular.RegistrationStatus Cellular.SignalStrength Cellular.Technology Environment.IsBright Environment.IsDark Internet.NetworkName Internet.NetworkState Internet.NetworkType Internet.SignalStrength Internet.TrafficIn Internet.TrafficOut Location.Coordinates Location.Heading Location.SatPositioningState Media.NowPlaying Phone.Call Phone.Muted Position.Shaky Position.Stable Presence.State Profile.Name Screen.IsCovered Screen.TopEdge Session.State System.PowerSaveMode But it doesn't have properties about headphone. How does Contextkit get value about headphone? 2011/2/1 Thiago Macieira > On Monday, 31 de January de 2011 22:47:22 Shane Bryan wrote: > > On Tue, Feb 01, 2011 at 01:58:36PM +0800, alexguitar wrote: > > > Dear All, > > > > > > I want to develop a app to detect earphone with two features, including > > > plug in and plug out earphone jack . > > > > > > Whether does the Qt and Qt mobility provide the API about earphone > > > detection? > > > > If you get an answer off list, please let us know, as I need to monitor > this > > as well. > > I'm not sure if the info is available elsewhere, but there's a /dev/input > interface usually associated with that. Even my Dell laptop has it. > > Event: time 1296545363.867189, type 5 (EV_SW), code 2 (Headphone insert), > value 1 > Event: time 1296545363.867201, -- Report Sync > Event: time 1296545370.850146, type 5 (EV_SW), code 2 (Headphone insert), > value 0 > Event: time 1296545370.850155, -- Report Sync > > There might be a daemon already listening to this event and reporting it in > contextkit. > > > -- > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org > Senior Product Manager - Nokia, Qt Development Frameworks > PGP/GPG: 0x6EF45358; fingerprint: > E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 > ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
