[MeeGo-dev] FW: execute MTF application by command line error
Hi, I have a simple MTF application, I want to get the error message from this application, so I want to launch the application from command line, and I can easily get the error message from command line, but after I launch the MTF application, I get error message about : ERROR : No DBUS session bus found, Exiting now. Please make sure that a dbus session bus is running..., BTW if I launch the application by the desktop ICON(create the desktop icon by myself), it can be run successfully. My environment is: 1. ExoPC 2. MeeGo pre-alpha version 1.2 Best Regards. Intel Software Service Group [cid:image001.jpg@01CBF855.AB353290] B1 #205 Tun-Hwa North Rd, Taipei, Taiwan Desk +886-2-2514-4603 Mobile +886-987-369-617 E-Mail cary@intel.commailto:gorden.n...@intel.com inline: image001.jpg___ 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] FW: execute MTF application by command line error
Hi, Did you export DISPLAY=:0 and are you running the app as normal user and not root? Also it might be that you need to export DBUS variables to the environment, see bug: https://bugs.meego.com/show_bug.cgi?id=9049 Regards, Marko On 04/11/2011 10:57 AM, Pai, Cary wrote: Hi, I have a simple MTF application, I want to get the error message from this application, so I want to launch the application from command line, and I can easily get the error message from command line, but after I launch the MTF application, I get error message about : “ERROR : No DBUS session bus found, Exiting now. Please make sure that a dbus session bus is running…….”, BTW if I launch the application by the desktop ICON(create the desktop icon by myself), it can be run successfully. My environment is: 1.ExoPC 2.MeeGo pre-alpha version 1.2 Best Regards. Intel Software Service Group cid:image001.jpg@01C92560.37C6BFB0 B1 #205 Tun-Hwa North Rd, Taipei, Taiwan Desk +886-2-2514-4603 Mobile +886-987-369-617 E-Mail cary@intel.com mailto:gorden.n...@intel.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 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, On 25.03.2011 18:28, Cory T. Tusar wrote: On 03/25/2011 11:23 AM, Edward Hervey wrote: On Fri, 2011-03-25 at 10:58 -0400, Cory T. Tusar wrote: On 03/17/2011 06:57 AM, Stefan Kost wrote: snip 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). As a possible example (pulled from recent experience), automagic determination of stream parameters takes time (and CPU cycles). A non-automatic mode would be (was) helpful in instances where the application knows exactly what type of stream to expect, and there is a requirement for an absolute minimum of start-up time between the user pressing the Play button and video appearing on the screen. A lot of improvement has gone into GStreamer over the past year to speed up the pre-roll/typefinding/setup of playback pipelines. This was mainly to get gst-discoverer to be faster than exiftool to get information about media files, which it now is ... considering it also decodes the first audio/video frame(s). The only case I can think of where you would gain time would be for live mpeg-ts streams where you could provide the PAT/PMT information which you would have cached previously (in order not to have to wait for the next occurence). But that would still require you to wait for the next keyframe to appear unless you already have a few seconds live back-buffer on the machine (in which case you would also have cached PAT/PMT). Did you have another use-case in mind ? Pretty much the above, or slight variations thereof. Short version: there were product requirements regarding startup time and display of the first keyframe received over the network within N milliseconds. Explicit knowledge of stream type when constructing the decode pipeline proved helpful in meeting those requirements (this particular case was with a GStreamer pipeline on Moblin). I'm not arguing against automatic detection - it's what works and works well in a vast majority of cases - just leave the power-user option of explicitly specifying codec use / buffer sizing / etc. available for times when it's needed. Maybe we could progress by having a requirement in featurezilla? Also I wonder how much we are off the target. I believe before changing things it would be good to have a test case at hand that shows how much the target is missing and that avoiding auto-detection would meet the target (by saving enough time). * 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. Agreed, in part. As a general rule, the underlying detection and codec selection should be transparent to an application, however there are corner cases where this may not be desirable, and specific selection of a codec may be necessary. Consider a system which has an external (to the main CPU) PowerDrain-5000(tm) video processor capable of both MPEG-2 and MPEG-4 decode. If the system is in a commanded low-power state, it may be more prudent to decode standard-definition MPEG-2 content in software on the main CPU and leave the external video processor powered-down. However, when decode of MPEG-4 content is desired, soft-decode may not be feasible and the external video hardware needs to be used. In instances, as above, where the system has multiple codecs (hardware and software) capable of decoding given content, is there envisioned some method of specifying codec priority so that a given method of decode is used preferentially? Yes, with playbin2/decodebin2 you can change the order of codecs/plugins being used. By default it will use the one with the
Re: [MeeGo-dev] how to run meego-ux's meego-app-camera on MeeGo 1.2 Netbook?
On 04.04.2011 02:27, Niels Mayer wrote: After doing $ zypper ar http://download.meego.com/live/devel:/meego-ux/Trunk/devel:meego-ux.repo $ zypper zypper clean --all ; zypper --gpg-auto-import-keys refresh $ zypper in meego-app-camera meego-app-video meego-app-photos meego-app-notes meego-app-im meego-app-email meego-app-conacts meego-app-calendar meego-app-calculator meego-app-browser meego-app-clocks meego-ux-panels meego-ux-panels-photos meego-ux-panels-friends meego-ux-panels-music meego-ux-panels-mytablet meego-ux-panels-video meego-ux-panels-web meego-ux-panels-meta-tablet meego-ux-appgrid meego-ux-content meego-ux-content-socialweb which also installs dependencies: meego-handset-sound-theme meegolabs-ux-components meego-qml-launcher meego-ux-media meego-ux-media-models meego-ux-theme mkcal mlite qtgst-qmlsink telepathy-farstream I attempt to launch these apps with $ meego-qml-launcher --app appname which looks for /usr/share/appname/main.qml e.g. meego-qml-launcher --opengl --fullscreen --app meego-app-calculator meego-qml-launcher --opengl --fullscreen --app meego-app-calendar meego-qml-launcher --opengl --fullscreen --app meego-app-camera meego-qml-launcher --opengl --fullscreen --app meego-app-clocks meego-qml-launcher --opengl --fullscreen --app meego-app-contacts meego-qml-launcher --opengl --fullscreen --app meego-app-email meego-qml-launcher --fullscreen --opengl --app meego-app-im meego-qml-launcher --opengl --fullscreen --app meego-app-music meego-qml-launcher --opengl --fullscreen --app meego-app-notes meego-qml-launcher --opengl --fullscreen --app meego-app-photos meego-qml-launcher --opengl --fullscreen --app meego-app-tasks meego-qml-launcher --opengl --fullscreen --app meego-app-video meego-qml-launcher --opengl --fullscreen --app meego-ux-appgrid meego-qml-launcher --opengl --fullscreen --app meego-ux-app-photos meego-qml-launcher --opengl --fullscreen --app meego-ux-panels meego-qml-launcher --opengl --fullscreen --app meego-ux-settings Although many of the simple tablet-ux apps work on the Lenovo s10-3t running 1.2 netbook alpha, the one I really want to re-use (for http://code.google.com/p/ytd-meego/wiki/CitizenJournalismWithYoutubeDirectForMeego ) is meego-app-camera. Unfortunately, when I run it, I get the following: -- is this a bug or am I dong something wrong ? ... $ meego-qml-launcher --opengl --fullscreen --app meego-app-camera Adding Master Pointer: Virtual core pointer ( 2 ) Skipping non-Touch device: Virtual core XTEST pointer ( 4 ) Adding ATTACHED touch device: Cando Corporation Cando 10.1 Multi Touch Panel with Controller ( 11 ) Skipping non-Touch device: SynPS/2 Synaptics TouchPad ( 14 ) loaded the Generic plugin Loaded the MeeGo sensor plugin Request for interface not granted... Request for interface not granted... Warning: Object::connect: No such signal QXIMInputContext::inputMethodAreaChanged(QRect) Warning: Object::connect: No such signal LauncherApp::localeSettingsChanged() Warning: Object::connect: (sender name: 'meego-qml-launcher') Warning: Object::connect: No such signal LauncherApp::windowListUpdated(QListWindowInfo) Warning: Object::connect: (sender name: 'meego-qml-launcher') Debug: Instantiating VolumeControlPrivate Debug: Settings* Debug: Flash Mode: 0 Debug: Capture Mode: 0 Debug: /dev/video0 Lenovo EasyCamera Debug: /dev/video0 Lenovo EasyCamera Debug: Setting camera to /dev/video0 Debug: Camera caps: 64 Debug: Supported maximum optical zoom 1 Debug: Supported maximum digital zoom 10 Debug: Metadata is not available Debug: Audio input: alsa:null - Discard all samples (playback) or generate zero samples (capture) Debug: Audio input: alsa:pulse - PulseAudio Sound Server Debug: Audio input: alsa:default - Default Debug: Audio input: alsa:front:CARD=Intel,DEV=0 - HDA Intel, CONEXANT Analog Front speakers Debug: Audio input: alsa:surround40:CARD=Intel,DEV=0 - HDA Intel, CONEXANT Analog 4.0 Surround output to Front and Rear speakers Debug: Audio input: alsa:surround41:CARD=Intel,DEV=0 - HDA Intel, CONEXANT Analog 4.1 Surround output to Front, Rear and Subwoofer speakers Debug: Audio input: alsa:surround50:CARD=Intel,DEV=0 - HDA Intel, CONEXANT Analog 5.0 Surround output to Front, Center and Rear speakers Debug: Audio input: alsa:surround51:CARD=Intel,DEV=0 - HDA Intel, CONEXANT Analog 5.1 Surround output to Front, Center, Rear and Subwoofer speakers Debug: Audio input: alsa:surround71:CARD=Intel,DEV=0 - HDA Intel, CONEXANT Analog 7.1 Surround output to Front, Center, Side, Rear and Woofer speakers Debug: Audio input: pulseaudio: - PulseAudio device. Debug: Default source: alsa:null Debug: Using default resolution Debug: Using default FPS Debug: Codec: video/theora Debug: Codec: video/mpeg2 Debug: Codec: video/mpeg1 Debug: Codec: video/mjpeg Debug: Codec:
Re: [MeeGo-dev] FW: execute MTF application by command line error
Hi, Marko, Thanks for your response, I am using the root to launch the application, and the DISPLAY have already set to 0, after I tested and the result is the application can be launched successfully if you do not use the root to launch it. Best Regards. Intel Software Service Group B1 #205 Tun-Hwa North Rd, Taipei, Taiwan Desk +886-2-2514-4603 Mobile +886-987-369-617 E-Mail cary@intel.com -Original Message- From: Marko Saukko [mailto:marko.sau...@cybercom.com] Sent: Monday, April 11, 2011 4:04 PM To: meego-dev@meego.com; Pai, Cary Subject: Re: [MeeGo-dev] FW: execute MTF application by command line error Hi, Did you export DISPLAY=:0 and are you running the app as normal user and not root? Also it might be that you need to export DBUS variables to the environment, see bug: https://bugs.meego.com/show_bug.cgi?id=9049 Regards, Marko On 04/11/2011 10:57 AM, Pai, Cary wrote: Hi, I have a simple MTF application, I want to get the error message from this application, so I want to launch the application from command line, and I can easily get the error message from command line, but after I launch the MTF application, I get error message about : “ERROR : No DBUS session bus found, Exiting now. Please make sure that a dbus session bus is running…….”, BTW if I launch the application by the desktop ICON(create the desktop icon by myself), it can be run successfully. My environment is: 1.ExoPC 2.MeeGo pre-alpha version 1.2 Best Regards. Intel Software Service Group cid:image001.jpg@01C92560.37C6BFB0 B1 #205 Tun-Hwa North Rd, Taipei, Taiwan Desk +886-2-2514-4603 Mobile +886-987-369-617 E-Mail cary@intel.com mailto:gorden.n...@intel.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 mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] FW: execute MTF application by command line error
Hi, To launch MTF application as root, you need to do first as root: # export DISPLAY=:0 # source /tmp/session_bus_address.user And then you can launch your application. Best Regards, Stanislav Ionascu On Mon, 2011-04-11 at 16:56 +0800, ext Pai, Cary wrote: Hi, Marko, Thanks for your response, I am using the root to launch the application, and the DISPLAY have already set to 0, after I tested and the result is the application can be launched successfully if you do not use the root to launch it. Best Regards. Intel Software Service Group B1 #205 Tun-Hwa North Rd, Taipei, Taiwan Desk +886-2-2514-4603 Mobile +886-987-369-617 E-Mail cary@intel.com -Original Message- From: Marko Saukko [mailto:marko.sau...@cybercom.com] Sent: Monday, April 11, 2011 4:04 PM To: meego-dev@meego.com; Pai, Cary Subject: Re: [MeeGo-dev] FW: execute MTF application by command line error Hi, Did you export DISPLAY=:0 and are you running the app as normal user and not root? Also it might be that you need to export DBUS variables to the environment, see bug: https://bugs.meego.com/show_bug.cgi?id=9049 Regards, Marko On 04/11/2011 10:57 AM, Pai, Cary wrote: Hi, I have a simple MTF application, I want to get the error message from this application, so I want to launch the application from command line, and I can easily get the error message from command line, but after I launch the MTF application, I get error message about : “ERROR : No DBUS session bus found, Exiting now. Please make sure that a dbus session bus is running…….”, BTW if I launch the application by the desktop ICON(create the desktop icon by myself), it can be run successfully. My environment is: 1.ExoPC 2.MeeGo pre-alpha version 1.2 Best Regards. Intel Software Service Group cid:image001.jpg@01C92560.37C6BFB0 B1 #205 Tun-Hwa North Rd, Taipei, Taiwan Desk +886-2-2514-4603 Mobile +886-987-369-617 E-Mail cary@intel.com mailto:gorden.n...@intel.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 mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev 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] FW: execute MTF application by command line error
HI, Stanislav, I have tried your suggestion, and I can't find the file named session_bus_address.user, so I create on by myself under tmp folder, but it still shows the same error message, thanks for your response. Best Regards. Intel Software Service Group B1 #205 Tun-Hwa North Rd, Taipei, Taiwan Desk +886-2-2514-4603 Mobile +886-987-369-617 E-Mail cary@intel.com -Original Message- From: Stanislav Ionascu [mailto:stanislav.iona...@nokia.com] Sent: Monday, April 11, 2011 5:03 PM To: Pai, Cary Cc: Marko Saukko; meego-dev@meego.com Subject: Re: [MeeGo-dev] FW: execute MTF application by command line error Hi, To launch MTF application as root, you need to do first as root: # export DISPLAY=:0 # source /tmp/session_bus_address.user And then you can launch your application. Best Regards, Stanislav Ionascu On Mon, 2011-04-11 at 16:56 +0800, ext Pai, Cary wrote: Hi, Marko, Thanks for your response, I am using the root to launch the application, and the DISPLAY have already set to 0, after I tested and the result is the application can be launched successfully if you do not use the root to launch it. Best Regards. Intel Software Service Group B1 #205 Tun-Hwa North Rd, Taipei, Taiwan Desk +886-2-2514-4603 Mobile +886-987-369-617 E-Mail cary@intel.com -Original Message- From: Marko Saukko [mailto:marko.sau...@cybercom.com] Sent: Monday, April 11, 2011 4:04 PM To: meego-dev@meego.com; Pai, Cary Subject: Re: [MeeGo-dev] FW: execute MTF application by command line error Hi, Did you export DISPLAY=:0 and are you running the app as normal user and not root? Also it might be that you need to export DBUS variables to the environment, see bug: https://bugs.meego.com/show_bug.cgi?id=9049 Regards, Marko On 04/11/2011 10:57 AM, Pai, Cary wrote: Hi, I have a simple MTF application, I want to get the error message from this application, so I want to launch the application from command line, and I can easily get the error message from command line, but after I launch the MTF application, I get error message about : “ERROR : No DBUS session bus found, Exiting now. Please make sure that a dbus session bus is running…….”, BTW if I launch the application by the desktop ICON(create the desktop icon by myself), it can be run successfully. My environment is: 1.ExoPC 2.MeeGo pre-alpha version 1.2 Best Regards. Intel Software Service Group cid:image001.jpg@01C92560.37C6BFB0 B1 #205 Tun-Hwa North Rd, Taipei, Taiwan Desk +886-2-2514-4603 Mobile +886-987-369-617 E-Mail cary@intel.com mailto:gorden.n...@intel.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 mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev 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] Candidate specification for a generic video player from the TV list
On 11 April 2011 10:21, Stefan Kost enso...@hora-obscura.de wrote: My suggestion is to avoid this scenario totally. Having different pipelines depending on systems state is increasing the complexity of your system a lot. Apply the KISS pattern. Multimedia is complex enough due to the sheer amount of formats, codecs, profiles etc. At the moment you can't use GStreamer to play blu-ray. With the protection, this is probably not going to work any time soon legally in a nice autopluggable bin for GStreamer (that's currently the case for DVD playback if I understand correctly). Therefore this is an evil but at least a viable short term solution. -- Brendan Le Foll http://www.madeo.co.uk ___ 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] FW: execute MTF application by command line error
Em segunda-feira, 11 de abril de 2011, às 16:56:00, Pai, Cary escreveu: Thanks for your response, I am using the root to launch the application, and the DISPLAY have already set to 0, after I tested and the result is the application can be launched successfully if you do not use the root to launch it. Please don't run it as root. The session bus does not allow connections from different users. -- 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 signature.asc Description: This is a digitally signed message part. ___ 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] FW: execute MTF application by command line error
Hi, If the apps launch as a user, then do: $ echo $DBUS_SESSION_BUS_ADDRESS and then as root export the result: # export DBUS_SESSION_BUS_ADDRESS=result_of_echo_as_user Then you should be able to launch the app as root. Best Regards, Stanislav Ionascu. On Mon, 2011-04-11 at 17:09 +0800, ext Pai, Cary wrote: HI, Stanislav, I have tried your suggestion, and I can't find the file named session_bus_address.user, so I create on by myself under tmp folder, but it still shows the same error message, thanks for your response. Best Regards. Intel Software Service Group B1 #205 Tun-Hwa North Rd, Taipei, Taiwan Desk +886-2-2514-4603 Mobile +886-987-369-617 E-Mail cary@intel.com -Original Message- From: Stanislav Ionascu [mailto:stanislav.iona...@nokia.com] Sent: Monday, April 11, 2011 5:03 PM To: Pai, Cary Cc: Marko Saukko; meego-dev@meego.com Subject: Re: [MeeGo-dev] FW: execute MTF application by command line error Hi, To launch MTF application as root, you need to do first as root: # export DISPLAY=:0 # source /tmp/session_bus_address.user And then you can launch your application. Best Regards, Stanislav Ionascu On Mon, 2011-04-11 at 16:56 +0800, ext Pai, Cary wrote: Hi, Marko, Thanks for your response, I am using the root to launch the application, and the DISPLAY have already set to 0, after I tested and the result is the application can be launched successfully if you do not use the root to launch it. Best Regards. Intel Software Service Group B1 #205 Tun-Hwa North Rd, Taipei, Taiwan Desk +886-2-2514-4603 Mobile +886-987-369-617 E-Mail cary@intel.com -Original Message- From: Marko Saukko [mailto:marko.sau...@cybercom.com] Sent: Monday, April 11, 2011 4:04 PM To: meego-dev@meego.com; Pai, Cary Subject: Re: [MeeGo-dev] FW: execute MTF application by command line error Hi, Did you export DISPLAY=:0 and are you running the app as normal user and not root? Also it might be that you need to export DBUS variables to the environment, see bug: https://bugs.meego.com/show_bug.cgi?id=9049 Regards, Marko On 04/11/2011 10:57 AM, Pai, Cary wrote: Hi, I have a simple MTF application, I want to get the error message from this application, so I want to launch the application from command line, and I can easily get the error message from command line, but after I launch the MTF application, I get error message about : “ERROR : No DBUS session bus found, Exiting now. Please make sure that a dbus session bus is running…….”, BTW if I launch the application by the desktop ICON(create the desktop icon by myself), it can be run successfully. My environment is: 1.ExoPC 2.MeeGo pre-alpha version 1.2 Best Regards. Intel Software Service Group cid:image001.jpg@01C92560.37C6BFB0 B1 #205 Tun-Hwa North Rd, Taipei, Taiwan Desk +886-2-2514-4603 Mobile +886-987-369-617 E-Mail cary@intel.com mailto:gorden.n...@intel.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 mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev 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] FW: execute MTF application by command line error
Could you please try export $(dbus-launch) first before run the application? Regards, Jammy On Mon, Apr 11, 2011 at 5:09 PM, Pai, Cary cary@intel.com wrote: HI, Stanislav, I have tried your suggestion, and I can't find the file named session_bus_address.user, so I create on by myself under tmp folder, but it still shows the same error message, thanks for your response. Best Regards. Intel Software Service Group B1 #205 Tun-Hwa North Rd, Taipei, Taiwan Desk +886-2-2514-4603 Mobile +886-987-369-617 E-Mail cary@intel.com -Original Message- From: Stanislav Ionascu [mailto:stanislav.iona...@nokia.com] Sent: Monday, April 11, 2011 5:03 PM To: Pai, Cary Cc: Marko Saukko; meego-dev@meego.com Subject: Re: [MeeGo-dev] FW: execute MTF application by command line error Hi, To launch MTF application as root, you need to do first as root: # export DISPLAY=:0 # source /tmp/session_bus_address.user And then you can launch your application. Best Regards, Stanislav Ionascu On Mon, 2011-04-11 at 16:56 +0800, ext Pai, Cary wrote: Hi, Marko, Thanks for your response, I am using the root to launch the application, and the DISPLAY have already set to 0, after I tested and the result is the application can be launched successfully if you do not use the root to launch it. Best Regards. Intel Software Service Group B1 #205 Tun-Hwa North Rd, Taipei, Taiwan Desk +886-2-2514-4603 Mobile +886-987-369-617 E-Mail cary@intel.com -Original Message- From: Marko Saukko [mailto:marko.sau...@cybercom.com] Sent: Monday, April 11, 2011 4:04 PM To: meego-dev@meego.com; Pai, Cary Subject: Re: [MeeGo-dev] FW: execute MTF application by command line error Hi, Did you export DISPLAY=:0 and are you running the app as normal user and not root? Also it might be that you need to export DBUS variables to the environment, see bug: https://bugs.meego.com/show_bug.cgi?id=9049 Regards, Marko On 04/11/2011 10:57 AM, Pai, Cary wrote: Hi, I have a simple MTF application, I want to get the error message from this application, so I want to launch the application from command line, and I can easily get the error message from command line, but after I launch the MTF application, I get error message about : “ERROR : No DBUS session bus found, Exiting now. Please make sure that a dbus session bus is running…….”, BTW if I launch the application by the desktop ICON(create the desktop icon by myself), it can be run successfully. My environment is: 1.ExoPC 2.MeeGo pre-alpha version 1.2 Best Regards. Intel Software Service Group cid:image001.jpg@01C92560.37C6BFB0 B1 #205 Tun-Hwa North Rd, Taipei, Taiwan Desk +886-2-2514-4603 Mobile +886-987-369-617 E-Mail cary@intel.com mailto:gorden.n...@intel.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 mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev 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 ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] [SSO] Fixed Storage Dir Permissions + Authentication Core Cache Improvements
Hi, Please review a few fixes and improvements: 1. Fixed permissions for the Signon storage directory. This will allow `Restore` operation to work. https://gitorious.org/accounts-sso/signon/commit/955acb690aab318633a64d0c536f5137362e95e6 2. Allow authentication core cache to append BLOB authentication data. In case of authentication cache multiple inserts for the same cache key, any newly inserted BLOB data will be appended to the existing one, while already cached data is not deleted. https://gitorious.org/accounts-sso/signon/commit/e4aa472c350aaef8cbdf817bb749c21e08d89641 3. Removed TODO. Not allowing duplicate parameters in the auth. session data. https://gitorious.org/accounts-sso/signon/commit/adbb62c233f0fe4d2fb7850243d3e981622fb80e 4. Improved authentication data caching If the secrets db is not open, the SignonIdentity caches authentication data upon a successful storing operation. This helps signon clients to perform SSO after storing credentials, without sending username/password through the auth. session data, even when the secure storage is closed. https://gitorious.org/accounts-sso/signon/commit/fe9cc7a93270f735b24c68c9298e60315a4f14b7 Br, Aurel ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] ANNOUNCE: [ABI break] MeeGo 1.2 ARM architecture will only support hardfp ABI
Hello, the hardfp floating point ABI for ARM will be made default and mandatory for MeeGo 1.2 and later. This decision was made and approved back in December 2010 in the MeeGo TSG and the impact has been described in MeeGo wiki [1]. The hardfp scheduler is called armv8el and is up and running in MeeGo Trunk. This change introduces an ABI break with MeeGo 1.1. The hardfp ABI is not compatible with the softfp ABI and because of this the packages produced by the armv8el scheduler have the architecture name .armv7hl. They cannot be installed in an armv7l system and vice versa. If you or your company run into problems with this changeover, feel free to seek help from #meego-arm @ freenode IRC channel or from the meego-porting mailing list [2]. If you need to use closed source binaries from your hardware vendor, please contact them to get a hardfp build of those binaries. The softfp armv7el scheduler in MeeGo Trunk will be stopped at the end of April 2011. [1] http://wiki.meego.com/SDK/Toolchains/ToolchainChange [2] http://lists.meego.com/listinfo/meego-porting Cheers, Juha ___ 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] ANNOUNCE: [ABI break] MeeGo 1.2 ARM architecture will only support hardfp ABI
Em segunda-feira, 11 de abril de 2011, às 15:28:59, Juha Kallioinen escreveu: The hardfp scheduler is called armv8el and is up and running in MeeGo Trunk. Why are we calling it ARMv8? All I can find about it are future references, like: http://drdobbs.com/210800195 and talking about future processors like the Cortex-A10. There's absolutely nothing about ARMv8 in ARM's website: http://www.google.com/search?q=armv8+site%3Aarm.com Also, an ARMv8 build implies that it doesn't run on ARMv7 hardware. I think that would be extremely short-sighted. -- 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 signature.asc Description: This is a digitally signed message part. ___ 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] ANNOUNCE: [ABI break] MeeGo 1.2 ARM architecture will only support hardfp ABI
2011/4/11 Thiago Macieira thi...@kde.org: Em segunda-feira, 11 de abril de 2011, às 15:28:59, Juha Kallioinen escreveu: The hardfp scheduler is called armv8el and is up and running in MeeGo Trunk. Why are we calling it ARMv8? All I can find about it are future references, Long story short, we ran into a problem where the setup of OBS would make it difficult to have a 'armv7hl' scheduler - problems like not adding new features to a stable branch of OBS. As we couldn't get the patches into stable branch, after a month of trying to get things working organisationally, we went for the thing that made sure we got hardfp into MeeGo 1.2 in time, or we would have not been able to (and hence never). armv8el is an unfortunate side-effect of that. However, it is important to remember that 'armv7el' and 'armv8el' is just a name inside the OBS and what matters is the RPM architectures (armv7hl). You could practically have armv4 binaries inside a armv5el scheduler and so on. As we couldn't risk to mix softfp and hardfp binaries, we couldn't just reuse the armv7el scheduler name. BR Carsten Munk like: http://drdobbs.com/210800195 and talking about future processors like the Cortex-A10. There's absolutely nothing about ARMv8 in ARM's website: http://www.google.com/search?q=armv8+site%3Aarm.com Also, an ARMv8 build implies that it doesn't run on ARMv7 hardware. I think that would be extremely short-sighted. -- 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 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] ANNOUNCE: [ABI break] MeeGo 1.2 ARM architecture will only support hardfp ABI
On 04/11/2011 03:28 PM, Juha Kallioinen wrote: Hello, the hardfp floating point ABI for ARM will be made default and mandatory for MeeGo 1.2 and later. This decision was made and approved back in December 2010 in the MeeGo TSG and the impact has been described in MeeGo wiki [1]. The hardfp scheduler is called armv8el and is up and running in MeeGo Trunk. This change introduces an ABI break with MeeGo 1.1. The hardfp ABI is not compatible with the softfp ABI and because of this the packages produced by the armv8el scheduler have the architecture name .armv7hl. They cannot be installed in an armv7l system and vice versa. If you or your company run into problems with this changeover, feel free to seek help from #meego-arm @ freenode IRC channel or from the meego-porting mailing list [2]. If you need to use closed source binaries from your hardware vendor, please contact them to get a hardfp build of those binaries. The softfp armv7el scheduler in MeeGo Trunk will be stopped at the end of April 2011. [1] http://wiki.meego.com/SDK/Toolchains/ToolchainChange [2] http://lists.meego.com/listinfo/meego-porting Cheers, Juha ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines Hi, Now when the armv7el is going to be removed it is important that maintainers of devel: projects in the OBS add the armv8el scheduler to their projects. http://lists.meego.com/pipermail/meego-packaging/2011-April/247051.html Regards, Marko ___ 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] Window Manager Issues (Handset and Tablet)
On 04/09/11 16:52, ext Gabriel M. Beddingfield wrote: On the latest daily builds for Handset and Tablet there are no title bars (including app switcher button and app close button). Will there be any? Nor do apps get automatically expanded to fit the screen. Will they be? There are two kinds of application windows: fullscreen and non-fullscreen. The fullscreen ones don't have WM buttons at all and are resized to fullscreen by the WM. Currently the non-fullscreen ones get buttons and are resized so that they fill the remaining free space. Libmeegotouch windows are different: they are both fullscreen and they have buttons (which they draw themselves). This is what the git version does, I'm not sure about the MeeGo packaged mcompositor (since I don't use that). -Kimmo I.e. are there plans one way or the other? These features are important because: 1. If someone develops an app for the netbook, then they won't know that they're supposed to draw their own title bar and exit button. 2. Our company provides a lot of 3rd party, non-meego-api, Xlib apps with our devices. These apps were not written for phones, and are expecting the WM to provide the buttons to exit the application. We would rather not have to repackage mcompositor to get mdecorator back. 3. In the Tablet UX there's currently no way to close apps like chrome except to reboot. 4. These established MeeGo UI guidelines are now broken: http://meego.com/developers/ui-design-guidelines/handset/meego-basics (specifically the switcher and comments on fullscreen) Yes, I realize that mdecorator is buggy and even (at some level) a broken concept. But I'm not really even talking about mdecorator... I just need the basic WM functionality. Thank you, Gabriel ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev 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] Window Manager Issues (Handset and Tablet)
On Mon, 11 Apr 2011, Kimmo Hämäläinen wrote: The fullscreen ones don't have WM buttons at all and are resized to fullscreen by the WM. Currently the non-fullscreen ones get buttons and are resized so that they fill the remaining free space. [snip] This is what the git version does, I'm not sure about the MeeGo packaged mcompositor (since I don't use that). mdecorator has intentionally be removed from the MeeGo package. That's kind of the problem I'm having. :-) -gabriel___ 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] ANNOUNCE: [ABI break] MeeGo 1.2 ARM architecture will only support hardfp ABI
On 4/11/2011 5:28 AM, Juha Kallioinen wrote: Hello, the hardfp floating point ABI for ARM will be made default and mandatory for MeeGo 1.2 and later. This decision was made and approved back in December 2010 in the MeeGo TSG and the impact has been described in MeeGo wiki [1]. The hardfp scheduler is called armv8el and is up and running in MeeGo Trunk. This change introduces an ABI break with MeeGo 1.1. The hardfp ABI is not compatible with the softfp ABI and because of this the packages produced by the armv8el scheduler have the architecture name .armv7hl. They cannot be installed in an armv7l system and vice versa. If you or your company run into problems with this changeover, feel free to seek help from #meego-arm @ freenode IRC channel or from the meego-porting mailing list [2]. can you, for completeness, list a set of ARM SOC's that this hardfp will run on... omap3 tegra? qualcom ? asking because if it's only omap3 then I think this is a step in the wrong direction and we should revisit the TSG decision. ___ 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] Window Manager Issues (Handset and Tablet)
Hi Rusty,
On Sat, Apr 9, 2011 at 11:53 AM, Rusty Lynch rusty.ly...@intel.com wrote:
On 04/09/2011 06:52 AM, Gabriel M. Beddingfield wrote:
On the latest daily builds for Handset and Tablet there are
no title bars (including app switcher button and app close
button). Will there be any? Nor do apps get automatically
expanded to fit the screen. Will they be?
I.e. are there plans one way or the other?
First... the easy one all normal toplevel windows should be made
fullscreen by the window manager, from my observations of the version of
meegotouch-compositor in Trunk, this is happening (where the easiest example
to test is to open the terminal.) If you are not seeing this for one of
your apps then we need to file a bug on the window manager.
Thanks. This is a Good Thing. (However, I had one app that didn't
get full-screened -- so I had doubts about it. Now I know it's a Bug
To Be Filed.)
Now for the harder discussion. Looks like we have a design mismatch between
what meego-ux is attempting to accomplish (which, btw, is not tablet
specific... I just happen to be on the hook to deliver this for customers
that are making tablets), and what the original MTF style handset was
attempting to accomplish.
rant
And since MeeGo UX is the Johnny-Come-Lately that just sort of showed
up one day with no design docs and no discussion -- seems like it
should be a little more aware of the fact that it's breaking the
Handset.
/rant
For the specific example of window decoration, the meego-ux approach makes
demands on the device manufacturer that there must be hardware home button
of some form or fashion. This button must be visible to the OS, and the OS
must be able to detect the difference between press and press-n-hold (and oh
by the way... if you make that just look like a normal key then it makes it
much easier to get the device up and running.)
OK. This is mostly good, IMHO. However, shouldn't there be some way
to support devices that don't have buttons? This is a new
requirement. (However, in my case this is just a hypothetical -- my
device has a button that appears as a normal keyboard keypress.)
When the home button is pressed, you go to the homescreen. If you
press-n-hold on the homescreen, then we open a task switcher. From the task
switcher you can switch between active task, or close specific tasks.
I haven't figured out how to close a task from the device switcher.
Can anyone explain it?
So... with this approach, no applications should waste screen space on a
home button or a close button. Everyone runs edge to edge, direct rendered
(except perhaps when we are doing window to window transitions or
compositing a system level overlay like the task switcher on top of the
app), all the time.
OK, that makes sense.
I'm open to ideas, but I think it would be a mistake to compromise the
ability to make competitive devices where from day one the device
manufacture is targeting the specific design approach taken in the meego-ux.
Agreed... a little communication with the community goes a long way,
though. :-)
One example that came up on an IRC discussion is to extend the basic
Window{} implementation add things like a home button when the device theme
ask for it (without the application developer needing to do anything.)
Another idea for non-qml apps that i haven't discussed is instead of just
nuking the decorator, add a runtime config to decide if to use a decorator
Why not use the X11 window hints for this? (You know, like the
frameless window hint... or something akin to that.)
or not, and if so then which one. Then the MTF style handset could still
have it's broken decorator (at least broken on any meego image i have ever
That's the thing... they had /just/ fixed it on the images I tried --
and then it got ripped out by the MeeGo UX.
...which is why people are asking, Sine the MeeGo UX is shamelessly
breaking the Handset UX... is the Handset UX officially cancelled or
something?
3. In the Tablet UX there's currently no way to close apps
like chrome except to reboot.
The idea is that for the most part we do like android and iphone, where
users shouldn't need to 'close' an app, but a thirdparty utility could be
Yes, my wife's blackberry does this -- and a big part of the reason
why it sucks. It runs slower and more unstable over time because you
always have all these extra apps running. Do we really need to follow
suit?
4. These established MeeGo UI guidelines are now broken:
http://meego.com/developers/ui-design-guidelines/handset/meego-basics
(specifically the switcher and comments on fullscreen)
A different design philosophy. I am hopeful we can find a way to make
OK... where's the link to the MeeGo UX design philosophy? :-)
Yes, I realize that mdecorator is buggy and even (at some
level) a broken concept. But I'm not really even talking
about mdecorator... I just need the basic WM functionality.
Re: [MeeGo-dev] ANNOUNCE: [ABI break] MeeGo 1.2 ARM architecture will only support hardfp ABI
2011/4/11 Arjan van de Ven ar...@linux.intel.com: On 4/11/2011 5:28 AM, Juha Kallioinen wrote: Hello, the hardfp floating point ABI for ARM will be made default and mandatory for MeeGo 1.2 and later. This decision was made and approved back in December 2010 in the MeeGo TSG and the impact has been described in MeeGo wiki [1]. The hardfp scheduler is called armv8el and is up and running in MeeGo Trunk. This change introduces an ABI break with MeeGo 1.1. The hardfp ABI is not compatible with the softfp ABI and because of this the packages produced by the armv8el scheduler have the architecture name .armv7hl. They cannot be installed in an armv7l system and vice versa. If you or your company run into problems with this changeover, feel free to seek help from #meego-arm @ freenode IRC channel or from the meego-porting mailing list [2]. can you, for completeness, list a set of ARM SOC's that this hardfp will run on... omap3 tegra? qualcom ? The baseline is armv7hl: -mfloat-abi=hard -mfpu=vfpv3-d16 -march=armv7-a -mno-thumb This matches SoCs such as - we've tested both with the help of ARM vendors themselves and people with boards: * OMAP3, OMAP4 (tested) * nVidia Tegra2 (tested) * Qualcomm ARMv7 chips should work with it (think it was tested) * ST-Ericsson U8500 (tested) * iMX.51 (tested) * Marvell Dove and others (tested) * etc. The baseline is practically similar to that of Debian armhf, http://wiki.debian.org/ArmHardFloatPort , except that we don't mandate thumb2/permit it for the baseline for compatibility reasons - subarchitectures give proper flexibility for NEON, Thumb2. This covers the largest set of ARMv7 chipsets available, including future Cortex-A5 (VFPv3 FPU option required though of this variant and ability to use NEON exists if provided by SoC). We've actually moved from VFPv3-D32 to VFPv3-D16 which means we support nVidia tegra2 and Marvell's chips now, which armv7l didn't before. asking because if it's only omap3 then I think this is a step in the wrong direction and we should revisit the TSG decision. That would indeed be a wrong direction and we do not optimize towards a specific chipset/SoC, as seen above - the hardfp port has been happily working on many different devices and enabling even more. We don't even tune for cortex-a8 as this makes gcc exhibit NEON instructions in some situations. As it's an ABI break, it does require a rebuild on top of the MeeGo toolchain of typical closed source binaries from the hardware vendor, which they would have to anyway, given Linaro and Debian's armhf directions. BR Carsten Munk ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev 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] ANNOUNCE: [ABI break] MeeGo 1.2 ARM architecture will only support hardfp ABI
On 11/04/11 17:26, ext Arjan van de Ven wrote: can you, for completeness, list a set of ARM SOC's that this hardfp will run on... omap3 tegra? qualcom ? asking because if it's only omap3 then I think this is a step in the wrong direction and we should revisit the TSG decision. Hi, supporting the hard float abi requires a VFP coprocessor on the SoC. Debian's hardfp wiki page lists the following SoCs [1]; Freescale iMX5x, Nvidia Tegra2, Marvell Dove, TI OMAP3xxx, TI OMAP4xxx, Qualcomm Snapdragon and Samsung S5PC100. [1] http://wiki.debian.org/ArmHardFloatPort#Partial_reference_of_SoC_and_supported_ISAs Cheers, -Juha ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] Audio performance in MeeGo
Hello, I was able to reduce CPU load in audio playback in meego-ivi a few months back. This was all done by tweaking the buffer parameters of audio sink while playing with Gstreamer. How can we make sure that the user benefits from the changes? What are the players in meego-ivi that uses Gstreamer? If we want to integrate those changes from the media player's perspective, is that even possible? Best Nahid ___ 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] FW: execute MTF application by command line error
On Apr 11, 2011, at 12:57 AM, Pai, Cary wrote: Hi, I have a simple MTF application, I want to get the error message from this application, so I want to launch the application from command line, and I can easily get the error message from command line, but after I launch the MTF application, I get error message about : “ERROR : No DBUS session bus found, Exiting now. Please make sure that a dbus session bus is running…….”, BTW if I launch the application by the desktop ICON(create the desktop icon by myself), it can be run successfully. Quick reminder about mailing list policies, since this question should have been posted to meego-sdk, not meego-dev. MeeGo-Dev: Development on the MeeGo distribution - not for application development or user level questions MeeGo-sdk: MeeGo application development - using the SDK / APIs and developing applications for MeeGo. More details about our mailing lists policies: http://wiki.meego.com/Community_communication Dawn ___ 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] Audio performance in MeeGo
This really applies to all MeeGo players using gstreamer, not just the IVI ones. regards Joel From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of Alam, Nahid M Sent: Monday, April 11, 2011 9:37 AM To: meego-dev@meego.com Subject: [MeeGo-dev] Audio performance in MeeGo Hello, I was able to reduce CPU load in audio playback in meego-ivi a few months back. This was all done by tweaking the buffer parameters of audio sink while playing with Gstreamer. How can we make sure that the user benefits from the changes? What are the players in meego-ivi that uses Gstreamer? If we want to integrate those changes from the media player's perspective, is that even possible? Best Nahid ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] Fwd: [MeeGo-ivi] Bug #12777 - usbtouchscreen driver
Hi gang, Per Joel's suggestion, I Wanted to ask a quick question... The patch from the 12777 bug report seems to have fixed tsc2007 - looking at the code for usbtouchscreen.c, I don't see why a similar patch couldn't be done for it (and possbily others). Does anyone know if that is being addressed? https://bugs.meego.com/attachment.cgi?id=4935 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=drivers/input/touchscreen/usbtouchscreen.c;hb=HEAD Nasa ___ 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] Audio performance in MeeGo
did these adjustments get merged into MeeGo's gstreamer then? Auke On 04/11/11 09:58, Clark, Joel wrote: This really applies to all MeeGo players using gstreamer, not just the IVI ones. regards Joel From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of Alam, Nahid M Sent: Monday, April 11, 2011 9:37 AM To: meego-dev@meego.com Subject: [MeeGo-dev] Audio performance in MeeGo Hello, I was able to reduce CPU load in audio playback in meego-ivi a few months back. This was all done by tweaking the buffer parameters of audio sink while playing with Gstreamer. How can we make sure that the user benefits from the changes? What are the players in meego-ivi that uses Gstreamer? If we want to integrate those changes from the media player’s perspective, is that even possible? Best Nahid ___ 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-architecture] Another architecture direction mail
On 05/04/11 08:59, Antti Kaijanmäki wrote: On Fri, 2011-04-01 at 09:07 -0700, Arjan van de Ven wrote: Late last year, in the Architecture meeting, we had agreed to include timed, MCE, Sharing Framework, Non-Graphics-Feedback (NGF), Profiles, and Qt style APIs (QmSystem) identified on the http://wiki.meego.com/Architecture as new technologies into MeeGo. We had hoped that all the documentation and source code would end up well integrated into the 1.2 release of MeeGo. By Profiles you mean the device category profiles defined in compliance specification? I'm pretty sure profiles in this context means typical mobile phone profiles like Silent, Loud, In Car etc. See the wiki page (currently http://wiki.meego.com/index.php?title=Architectureoldid=35162 just in case it changes) which links to some Bugzilla entries which explain a little more. Cheers, John ___ 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] Fwd: [MeeGo-ivi] Bug #12777 - usbtouchscreen driver
2011/4/11 Nasa nas...@comcast.net: Hi gang, Per Joel's suggestion, I Wanted to ask a quick question... The patch from the 12777 bug report seems to have fixed tsc2007 - looking at the code for usbtouchscreen.c, I don't see why a similar patch couldn't be done for it (and possbily others). Does anyone know if that is being addressed? https://bugs.meego.com/attachment.cgi?id=4935 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=drivers/input/touchscreen/usbtouchscreen.c;hb=HEAD There's an alternative fix that fixes xorg-x11-drv-evdev instead in devel:x11:Trunk, we're waiting for kernel fixes on connext side (removing that hack) before we submit the updated drv-evdev. /Carsten Nasa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev 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] Fwd: [MeeGo-ivi] Bug #12777 - usbtouchscreen driver
These conneXt kernel changes? http://lists.meego.com/pipermail/meego-commits/2011-March/019591.html http://lists.meego.com/pipermail/meego-commits/2011-April/020569.html regards Joel -Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of Carsten Munk Sent: Monday, April 11, 2011 10:35 AM To: Nasa Cc: Meego-dev@meego.com Subject: Re: [MeeGo-dev] Fwd: [MeeGo-ivi] Bug #12777 - usbtouchscreen driver 2011/4/11 Nasa nas...@comcast.net: Hi gang, Per Joel's suggestion, I Wanted to ask a quick question... The patch from the 12777 bug report seems to have fixed tsc2007 - looking at the code for usbtouchscreen.c, I don't see why a similar patch couldn't be done for it (and possbily others). Does anyone know if that is being addressed? https://bugs.meego.com/attachment.cgi?id=4935 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=drivers/input/touchscreen/usbtouchscreen.c;hb=HEAD There's an alternative fix that fixes xorg-x11-drv-evdev instead in devel:x11:Trunk, we're waiting for kernel fixes on connext side (removing that hack) before we submit the updated drv-evdev. /Carsten Nasa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev 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 ___ 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] Fwd: [MeeGo-ivi] Bug #12777 - usbtouchscreen driver
- Carsten Munk cars...@maemo.org wrote: 2011/4/11 Clark, Joel joel.cl...@intel.com: These conneXt kernel changes? http://lists.meego.com/pipermail/meego-commits/2011-March/019591.html http://lists.meego.com/pipermail/meego-commits/2011-April/020569.html Yeah, just needs to be passed on to Trunk:Testing - then we can slide in the evdev fix and nothing should regress. /Carsten Thanks for the info, Sorry I missed those updated patches -- looks like a better way to approach this problem. Nasa regards Joel -Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of Carsten Munk Sent: Monday, April 11, 2011 10:35 AM To: Nasa Cc: Meego-dev@meego.com Subject: Re: [MeeGo-dev] Fwd: [MeeGo-ivi] Bug #12777 - usbtouchscreen driver 2011/4/11 Nasa nas...@comcast.net: Hi gang, Per Joel's suggestion, I Wanted to ask a quick question... The patch from the 12777 bug report seems to have fixed tsc2007 - looking at the code for usbtouchscreen.c, I don't see why a similar patch couldn't be done for it (and possbily others). Does anyone know if that is being addressed? https://bugs.meego.com/attachment.cgi?id=4935 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=drivers/input/touchscreen/usbtouchscreen.c;hb=HEAD There's an alternative fix that fixes xorg-x11-drv-evdev instead in devel:x11:Trunk, we're waiting for kernel fixes on connext side (removing that hack) before we submit the updated drv-evdev. /Carsten Nasa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev 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 ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] Can not tracker *.rm/rmvb files
Hi
I encounters a confusing problem that the *.rm/rmvb video files
can not be trackered by the following SQL
SELECT nie:url(nie:isStoredAs(?video)) WHERE{?video a nmm:Video};
I analysed the /usr/share/mime/packages/freedesktop.org.xml
that the mime type [mime-type type=application/vnd.rn-realmedia]is
defined.
Also,I found only video/* mime type is trackered in
tracker-extract-gstreamer.c,is that right?
So,does the qttracker only tracker video files which obtain mime type
[video/*]?
Can anyone give me some suggestion?
---
Confidentiality Notice: The information contained in this e-mail and any
accompanying attachment(s)
is intended only for the use of the intended recipient and may be confidential
and/or privileged of
Neusoft Corporation, its subsidiaries and/or its affiliates. If any reader of
this communication is
not the intended recipient, unauthorized use, forwarding, printing, storing,
disclosure or copying
is strictly prohibited, and may be unlawful.If you have received this
communication in error,please
immediately notify the sender by return e-mail, and delete the original message
and all copies from
your system. Thank you.
---
___
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 table screen saver
Hi I am running the meego table release. The screen saver is nice but I want to turn it off at times. I look under settings but cannot find relevant settings. Is there a way to do so? I looked under /etc/X11 but did not see anything either. Thanks Mark ___ 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 table screen saver
On 04/11/2011 08:48 PM, Mark S. Townsley wrote: Hi I am running the meego table release. The screen saver is nice but I want to turn it off at times. I look under settings but cannot find relevant settings. Is there a way to do so? I looked under /etc/X11 but did not see anything either. I am just now adding support for controlling the timeout via a gconf key, which will allow us to add a settings entry. Also... just in case you are asking as an app developer, I am about to add a merge request to meego-ux-components that adds a new Window.inhibitScreenSaver boolean property which will inhibit/enable the screen saver while the specific application is in the foreground. --rusty ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
