Re: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo
Carsten, David and Robin, Thank you very much for this proposal and work already done and started. This single post alone convinces me that we have not wasted any work on MeeGo (ce), and that it in fact will have bright future ahead, no matter of the name of the project , the products based on it or possible companies involved in it. This very clearly is the best part of OSS promise, when one (business) model changes, the projects and the best people continue with the code and their learning of the old model. I sincerely hope that people understand that your Mer project is not against anything or anyone. If companies don't understand the value of your proposal in this round, for sure they will in next one. Have a happy hacking, and see you around. Br, //Harri -Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of ext Carsten Munk Sent: 3. lokakuuta 2011 9:01 To: meego-dev; meego-comm...@meego.com Subject: [MeeGo-dev] MeeGo Reconstructed - a plan of action and direction for MeeGo Hi all, MeeGo is dead ... long live Tizen !! - Haven't we heard that before? - Maemo, Moblin? We need a community that transcends the mere branding of MeeGo, Maemo, Moblin - and now Tizen. A lot of proposals have been put forward: * Move to Tizen and trust that They'll get it right this time * Merge or join some existing projects (like the Qt Project, Debian, openSUSE, etc) * Keep MeeGo alive by approaching the Linux Foundation The goal is to find a truly sustainable way for MeeGo and other interested communities to work with Tizen. Our solution is the Mer Project: How does the concept of a truly open and inclusive integration community for devices sound? After all if upstream is king - then contributions will end up the same place, no matter if it's Tizen, Maemo, MeeGo or openSUSE. Some history - many of us in MeeGo originated from a project called Mer, short for Maemo Reconstructed - where we approached doing a open mobile platform through reconstruction of the Maemo platform into a open platform. We were big on open governance, open development and open source. For a few months a group of us have been working on various scenarios of change in MeeGo [1] and now that the Tizen news is out in the open, it's time to talk about what we as a community can make happen next. To make it clear: this is not in any way an anti-Tizen or anti-Intel project, but a direction we can and will go in - we strongly want to collaborate with Tizen and Intel. We will continue to welcome contribution and participation from the hacker community - in fact we aim to make it so easy to port to a new vendor device that a single hacker could do it for their device. We decided to approach the problems and potential scenarios of change in MeeGo in the light of the reallocation of resources caused by what is now known as the Tizen work. There have not been any Trunk/1.3 releases since August and Tablet UX has totally stalled. What really works (and works quite well) is the Core. It's time to take the pieces and use them for reconstruction. We have some clear goals: * To be openly developed and openly governed as a meritocracy * That primary customers of the platform are device vendors - not end-users. * To provide a device manufacturer oriented structure, processes and tools: make life easy for them * To have a device oriented architecture * To be inclusive of technologies (such as MeeGo/Tizen/Qt/EFL/HTML5) * To innovate in the mobile OS space Now we'd like to talk a bit about what specific initiatives we propose to take: 0) Becoming MeeGo 2.0 Our work has the intended goal of being MeeGo 2.0 - and we hope that the Linux Foundation will see our work as a worthy succesor within the MeeGo spirit. We'd like to provide ability to be Tizen compliant, i.e. supporting HTML5/WAC and the application story there and feed back to that ecosystem. 1) Modularity. A set of architectural components for making devices. Rather than dictate the architecture we will support collaboration and the flexibility to easily access off-the-shelf components for device projects. Component independence permits focused feature and delivery management too. Initially the project will be developing a Core for basing products on and will split UX and hardware adaptations out into seperate projects within the community surrounding the Core. 2) Working towards an ultra-portable Linux + HTML5/QML/JS Core for building products with. We have already taken MeeGo and cut it into a set of 302 source packages that can boot into a Qt UI along with standard MeeGo stack pieces. This work can be seen already at [2] and we've made our first release and have had it booting on devices already[6]. To ease maintenance, we would like to encourage people to participate in the Core work of the Tizen project, utilizing their work where we can in Mer: why do the same work twice? Even if Tizen
Re: [MeeGo-dev] Nokia N900 hardware adaptation team meeting minutes 13/01/2011
Moro, In fact we have someone already looking into it ;) Tommi Keisala is working on it now, but naturally it will Take couple of days before we have anything concrete. But I think that Juha can work based on Gypsy or whatever is The MeeGo API atm. Our work will be below that anyway. Br, //Harri -Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of ext Carsten Munk Sent: 14. tammikuuta 2011 9:18 To: Vuolle Juha (Nokia-MS/Brisbane) Cc: meego-dev@meego.com Subject: Re: [MeeGo-dev] Nokia N900 hardware adaptation team meeting minutes 13/01/2011 2011/1/13 juha.vuo...@nokia.com: Didn't spot talks about GPS support. I've let myself believe the intention is to have it at some stage, but has anyone any better knowledge? It was discussed in the previous week's meeting. Long story short, someone needs to internally in Nokia package up libisi-liblas-..-location-daemon (closed source) and write a plugin that fits in MeeGo. And find a way to distribute them, if possible. And we don't have anyone committed to doing that yet :) /Carsten -Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of ext Carsten Munk Sent: Thursday, January 13, 2011 7:02 PM To: meego-dev Subject: [MeeGo-dev] Nokia N900 hardware adaptation team meeting minutes 13/01/2011 Next meeting next Thursday 20th at 8:00 UTC. Minutes: http://trac.tspre.org/meetbot/meego-meeting/2011/meego- meeting.2011-01-13-08.00.html Full meeting log: http://trac.tspre.org/meetbot/meego-meeting/2011/meego-meetin g.2011-01 - 13-08.00.log.html (see for details) Minutes pasted here for reading ease: Status (just write your status) (Stskeeps, 08:00:55) 1. resource policy: Policy packages are all successfully pushed to Trunk:Testing. Also, merge requests to update the package groups have been submitted. Some problems with MFLD config packages, though but those shouldn't affect N900 side. (marquiz_, 08:01:16) 2. PA: pa-modules-nokia finally updated, up to Trunk. Image creation should now succeed. (marquiz_, 08:01:22) 3. WiFi: business/legal approval of the wl1251 packages still pending. Going to sort this out tomorrow (Fri Jan 14) and hopefully push the packages to MeeGo OBS early next week. (marquiz_, 08:01:26) 4. graphics: I have been testing the latest glesfbdev drivers. Some three new patches would be needed in xserver if we want to upgrade. The issues could probably be fixed on driver side, too, though. (marquiz_, 08:01:31) 5. http://lists.meego.com/pipermail/meego-porting/2011- January/000125.html (Sage, 08:05:04) 6. Stskeeps: ARM board name autodetection, hardfp submissions and speedrpm. Hardfp build of Trunk:Testing without big issues. mfpu=neon acts weird on glibc -O3. RunFast patching of glibc. (Stskeeps, 08:09:41) 7. Planned: performance work, now that we have new SGX drivers and hardfp, we can get to the bottom of our performance issues (Stskeeps, 08:11:27) 8. Sage: armv7hl testing, package reviews, bug reports and fixes (Sage, 08:11:33) 9. Kernel (2.6.35.9) updates: DSS2, Omap SGX, patch for BT MAC address issue (ile, 08:17:43) 10. Camera #N1: [DONE] Gitorious kernel update (omap3isp-rx51, pinchartl) (theodor, 08:25:03) 11. Camera #N2: [DONE] Meego kernel update (obs, ile) (theodor, 08:25:10) 12. Camera #N3: [DROPPED, Headers included in package according Arjan's request] create temporary headers package out of experimental mediacontroller v4l2 subsystem API's and propose it to Meego Core (#1) (theodor, 08:25:19) 13. Camera #N3.1: [DONE] update gst-plugins-camera-n900 to use new headers package (theodor, 08:25:26) 14. Camera #N3.2: [ONGOING] propose to make common gst-plugins-camera out of gst-plugins-camera-n900 (theodor, 08:25:34) 15. Camera : pinchartl is again backporting fix patches for Meego kernel. He is doing it now first for .37 kernel, and only if needed for .35 (theodor, 08:25:41) 16. Camera : N3.2 we are ready to propose gst-plugins-camera for Trunk:Testing, basing on current gst-plugins-camera-n900 package in devel:devices:n900. We have conflicting gst-v4l2-camsrc in Trunk basing on same upstream already, but it is specific to Medfield ISP. It is also fairly old compared to ours which is now the latest tagged version. We should also have TSC with this, since gst-v4l2-camsrc is using V4L2 API's soon to be deprecated. I have requ (theodor, 08:25:50) 17. Camera : ... I have requested MFLD maintainers to joint forces with common gst-plugins-camera effort. (theodor, 08:26:49) 18. policy packages are now in trunk:testing (kallam, 08:27:09) 19. yamlified pa-modules-meego will be submitted today after testing. Version will be back to 0.9.19.0.11 style. (ssirkia, 08:28:34) 20. Camera: Currently qml camera example doesn't show view finder while QWidget camera example does. Looks like a bug inside qt-mobility's multimedia kit. (joonasta,
Re: [MeeGo-dev] Academic Survey for MeeGo Community Contributors
Hello all, [Disclaimer: I don't know Jarkko Moilanen or hardly anyone from uta.fi, but I do know many people from tut.fi ] From: meego-dev-boun...@meego.com [meego-dev-boun...@meego.com] on behalf of ext Julien Fourgeaud [jul...@lecatalyst.com] Sent: Tuesday, November 30, 2010 12:47 AM On Mon, Nov 29, 2010 at 10:33 PM, Auke Kok auke-jan.h@intel.commailto:auke-jan.h@intel.com wrote: In general, any form of spam or advertisement is outside regular mailing list policy. Since the post discussed is an invitation to a non-MeeGo survey, it's an advertisement. Jarkko apologized, even though it was not explicitly spam and would benefit the OSS community. Are we gonna waste even more byte for that? At least I am, because I don't like the kind of community building effort that was expressed in the comments to the original mail. As you said, as well in my opinnion there was nothing wrong with the original mail, but I feel that the comments have been mostly pure spam. I like to go as far as saying that every mail that comes from intel or Nokia domain is more advertisement than Jarkko's mail in the beginning of this thread (there is a clear ad on the from: field). So, sorry for this ad. Since when has Intel (or Nokia) turned to non-profit organisation and academic work started to be for profit ? From where are you supposed to find MeeGo developers for study if not from meego-dev ? If someone thinks that money (or salary) doesn't have anything to do with this kind of study (and that they are better researchers on the topic than the original ones), then don't participate, email to the author, or fork the study and make better one. But don't spam to the meego-dev list. This is supposed to be open community. It means that you should be able to accept all kinds of contributions, and different viewpoints than your own. Person that has backround in political studies can probably contribute also on other areas than in pure Qt quick code (notice the ad). Is it definition of open source community, that it is driven by arrogance and ingnorance ? And sorry again, this email is most likely also exhibit of worst kind of metaspam. But don't blaim me, blaim my child that woke me up. Br, //Harri ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] ARMv7 hardfp port of MeeGo discussion (Was: Re: new draft of MeeGo compliance specification)
From: Thiago Macieira [thi...@kde.org] Sent: Tuesday, October 26, 2010 12:52 AM On Monday, 25 de October de 2010 17:35:48 Arjan van de Ven wrote: this is me, one of the MeeGo architects, opposing breaking the MeeGo API this lightly. MeeGo's value proposition is about giving a consistent platform to ISVs; and this proposal completely destroys that in image, if not reality. In part this is about reputation and part is about reality; if MeeGo ends up breaking the ABIs all the time, or perceived as breaking ABIs this lightly, why bother with MeeGo at all so yes give me a break. This is why I was wondering why we're not using hardfp *now* for 1.1.0. We shouldn't be breaking binary compatibility. We shouldn't be softp either. As I said in earlier thread, this is my fault. I should have undesrtood the signifigance and start that work early enough in MeeGo so we would have had change to get it into 1.1 already. My only defence is that this is pretty new stuff, and for the record, I am not ARM expert at all .. This important e.g. for Qt Opengles, and we have that all over the place, even increasingly in the future. I don't see any other possibility that breaking the ABI now when we acn manage it, and also speak about that openly. Sotimes we make mistakes, and then we need to correct them. Br, //Harri ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] ARMv7 hardfp port of MeeGo discussion
From: Arjan van de Ven [ar...@linux.intel.com] Sent: Tuesday, October 26, 2010 10:24 PM On 10/26/2010 12:18 PM, Quim Gil wrote: On Mon, 2010-10-25 at 23:52 +0200, ext Thiago Macieira wrote: This is why I was wondering why we're not using hardfp *now* for 1.1.0. We shouldn't be breaking binary compatibility. We shouldn't be softp either. Just reminding the obvious, but as for today there is no major MeeGo products in the market, no AppUp for MeeGo, no Ovi for MeeGo, no Extras for MeeGo. Even the MeeGo SDK itself is in its first iterations. which will change once we release 1.1. I fully argee with Quim here, we have to act on this now, when the installed base does not exist. I see Arjan's point made from an architecture consistency point of view - but from a marketing point of view 1.2 and following releases will be a lot more used and scrutinized than 1.1.x releases. If this soft-hard break is unavoidable then it seems that now it will create a lot less hassle than in 6 months or later. based on the discussion here... the technology is at least several months away. and breaking compatibility in an upgrade is even worse than breaking it n a new release... really. We need to address those concerns by talking bout this openly. According to best experts this will take some time, so unfortunatelly it seems that we will have 2 ARM architecture builds towards 1.2, and we can only make final judgement when we know that hardfp will work as intended. Br, //Harri ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] glxgears performance
I have understood that glxgears is opengl program, NOT opengles. Arjan, are we supposed to have opengl as part of ivi spec ? Br, //Harri From: meego-dev-boun...@meego.com [meego-dev-boun...@meego.com] on behalf of ext Jalics, Laci [laci.jal...@delphi.com] Sent: Tuesday, October 26, 2010 3:15 PM To: meego-dev@meego.com Subject: [MeeGo-dev] glxgears performance I’m running kernel 2.6.33.5-26.1-ivi, with X Server 1.8.0 with the EMGD drivers from Intel on a Russellville GIA2 Congatec Board. When I run MeeGo I get almost 75 fps where I was getting north of 400 with Moblin 2.1. Any ideas? laci [r...@localhost faad2-2.7]# glxgears Running synchronized to the vertical refresh. The framerate should be approximately 1/1936613746 the monitor refresh rate. 372 frames in 5.0 seconds = 74.310 FPS 370 frames in 5.0 seconds = 73.887 FPS 371 frames in 5.0 seconds = 74.122 FPS ^C [r...@localhost faad2-2.7]# glxinfo name of display: 0:0.0 display: 0:0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.4 server glx extensions: GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_INTEL_swap_event client glx vendor string: Mesa Project and SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap, GLX_INTEL_swap_event GLX version: 1.4 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap, GLX_INTEL_swap_event OpenGL vendor string: Imagination Technologies OpenGL renderer string: PowerVR SGX535 OpenGL version string: 2.1 OpenGL shading language version string: 1.20 OpenGL extensions: GL_ARB_depth_texture, GL_ARB_draw_buffers, GL_ARB_fragment_program, GL_ARB_fragment_shader, GL_ARB_half_float_pixel, GL_ARB_matrix_palette, GL_ARB_multisample, GL_ARB_multitexture, GL_ARB_occlusion_query, GL_ARB_pixel_buffer_object, GL_ARB_point_parameters, GL_ARB_point_sprite, GL_ARB_shader_objects, GL_ARB_shading_language_100, GL_ARB_shadow, GL_ARB_shadow_ambient, GL_ARB_texture_border_clamp, GL_ARB_texture_compression, GL_ARB_texture_cube_map, GL_ARB_texture_env_add, GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, GL_ARB_texture_env_dot3, GL_ARB_texture_float, GL_ARB_texture_mirrored_repeat, GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, GL_NV_texture_rectangle, GL_ARB_transpose_matrix, GL_ARB_vertex_blend, GL_ARB_vertex_buffer_object, GL_ARB_vertex_program, GL_ARB_vertex_shader, GL_ARB_window_pos, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_equation_separate, GL_EXT_blend_func_separate, GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_compiled_vertex_array, GL_EXT_draw_range_elements, GL_EXT_fog_coord, GL_EXT_framebuffer_object, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_separate_specular_color, GL_EXT_shadow_funcs, GL_EXT_stencil_two_side, GL_EXT_stencil_wrap, GL_EXT_texture3D, GL_EXT_texture_compression_s3tc, GL_EXT_texture_cube_map, GL_EXT_texture_edge_clamp, GL_EXT_texture_env_add, GL_EXT_texture_env_combine, GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, GL_EXT_texture_lod_bias, GL_EXT_texture_object, GL_EXT_vertex_array, GL_IMG_texture_compression_pvrtc, GL_NV_blend_square, GL_NV_texgen_reflection, GL_S3_s3tc, GL_SGIS_generate_mipmap 24 GLX Visuals visual x bf lv rg d st colorbuffer ax dp st accumbuffer ms cav id dep cl sp sz l ci b ro r g b a bf th cl r g b a ns b eat -- 0x21 24 tc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x22 24 dc 0 32 0 r y . 8 8 8 8 0 24 8 0 0 0 0 0 0 None 0x5d 24 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0 0 0 0 None 0x5e 24 tc 0 32 0 r . . 8 8 8 8 0 0 0 0 0 0
Re: [MeeGo-dev] ARMv7 hardfp port of MeeGo discussion (Was: Re: new draft of MeeGo compliance specification)
From: Arjan van de Ven [ar...@linux.intel.com] Sent: Monday, October 25, 2010 4:59 PM On 10/25/2010 4:06 AM, jarmo.k...@nokia.com wrote: Hi, We have discussed about hardfp (and other) support in the toolchain team. Current assumption is that hardfp will be used in MeeGo 1.2. But there are still quite many other things to be agreed also - regarding different compiler options and switches, etc. Those different options are currently investigated and target is to get default settings for them, i.e. what options are used and how. breaking ABI like this goes way beyond the toolchain team. Really. I would expect the TSG to have a lively debate about such ABI breaks and make the final decision... this is not something that is done lightly, since all ISVs are completely impacted by this. Arjan, give me a break, will you. I would like to see Intel opposing that we are proposing to break ABI on ARM side .. You will likely have good laughs instead. Of course this needs to be elevated, and properly communicated as well. Hopefully already on 1.1 release material. Br, //Harri ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] new draft of MeeGo compliance specification
From: Thiago Macieira [thi...@kde.org] Sent: Saturday, October 23, 2010 6:48 PM Harri: I propose, that we don't specify softfp as the baseline for complience, but rather say that current softfp is temporary phase and we will move to hardfp as soon as possible, potentially in 1.1 update if we will have such a thing. I think that's a bad idea. We can't switch to hardfp without a full binary compatibility break. So it should be done at the new release, 1.2. That also means devices upgrading from MeeGo 1.1 to 1.2 will need a full reinstall/flashing. No applications from any repository or store will survive and need to be recompiled. I think that we are not supposed to break binary compatibility between Meego 1.1 and 1.2 , so breaking at 1.2 is not good option at all ... So, in this case I propose that we do that in MeeGo 1.1.1 (or whatever is the right number for MeeGo 1.1 update). Imho, that will be the least painfull way for everybody, especially if we decide and communicate this now. Now the amount of code/applications that needs to be recompiled is still manageable. As well as the number of affected parties. Br, //Harri ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] new draft of MeeGo compliance specification
Hello all, From: Thiago Macieira [thi...@kde.org] Sent: Wednesday, October 20, 2010 8:59 AM On Wednesday 20. October 2010 07.49.07 Carsten Munk wrote: Line 72, we really need to spell out that it is ARMv7, EABI, softfp (for 1.1) as there is emerging tendancies in industry to use hardfp too. We should really REALLY consider switching to hardfp in a later release. That means breaking binary compatibility. Yes, I agree. It was actually my mistake that we don't have hardfb already. I didn't understand early enough what kind of change that is etc from toolchain point of view. The point is that for MeeGo to be competitive enough we must use what the hw has to provide, and now it should be possible to use hardfb as well, when some work has been done with the toolchain. I propose, that we don't specify softfp as the baseline for complience, but rather say that current softfp is temporary phase and we will move to hardfp as soon as possible, potentially in 1.1 update if we will have such a thing. (And If we are not planning 1.1 update for any other reason, this is good enough reason to have it.) Anyway, for MeeGo 1.2 hardfp is must on ARM architecture side. Br, //Harri ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Minimal RAM requirements for MeeGo-Handset UX
Hello, As Auke said, N900 tech spec would practically be the lowest for usable MeeGo experience. That is not so bad, knowing that it is already one year old device and based on bit older hw. We have still some unused tricks to make it bit faster and usable, but the good reference to todays development situation can be seen on MeeGo Handset UX on a N900 (w/ TRG, gPodder UI test, HW-accelerated) http://www.youtube.com/watch?v=cWtMLs3j09U Br, //Harri From: meego-dev-boun...@meego.com [meego-dev-boun...@meego.com] On Behalf Of ext Auke Kok [auke-jan.h@intel.com] Sent: Monday, October 11, 2010 7:30 PM To: ssrk Cc: Development for the MeeGo Project (discussion list) Subject: Re: [MeeGo-dev] Minimal RAM requirements for MeeGo-Handset UX On 10/11/2010 3:24 AM, ssrk wrote: Hi, To Run MeeGo-Handset UX image on a device, what is the minimum RAM required? This is very hard to say since it depends on the hardware used, what your demands are etc. Some hardware reserves more memory for gfx, firmware etc. Apart from that, I believe the n900 only has 256mb, and there are several videos around demonstrating how well it runs. 512mb seems to be quite enough. I doubt 128mb will provide a pleasant experience... Does this answer your question? Auke ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Future of N900 as a MeeGo platform?
Dave all, Sorry that this came bit from behind trees, I was supposed to have blog post done some time before this to explain it bit. But really, like Quim said, there is nothing new on this if you take a look to what Carsten has already done for N900 and for MeeGo in general. My name has been there just to highlight that Nokia is supporting this officially and now when that should be clear anyway, it just the right thing to give the honor to the guy tht it belongs. I am just simple team leader and my role is to make sure that Carsten has all the support from our side that he needs. And as said, at least during this year N900 continues to have same role in MeeGo than before, and now we are getting to stage that things really start to work and adding features is getting easier and easier. But more about that in my upcoming post. Br, //Harri From: meego-dev-boun...@meego.com [meego-dev-boun...@meego.com] On Behalf Of ext Dave Neary [dne...@maemo.org] Sent: Tuesday, October 12, 2010 7:24 PM To: Gil Quim (Nokia-MS/MtView) Cc: meego-dev Subject: Re: [MeeGo-dev] Future of N900 as a MeeGo platform? Hi, Quim Gil wrote: On Tue, 2010-10-12 at 16:49 +0200, ext Dave Neary wrote: What does this mean for the N900 as a reference platform for MeeGo development? Please feel free asking at the TSG tomorrow, but in the meantime: As I said, unable to attend. In general, (just to repeat what I said to you on IRC) I don't think it's good to have an entry on a meeting agenda, a 2 minute discussion at a real-time meeting, and one line in minutes be the only way that fairly major changes like this get announced. I would have liked to see it proposed explained here (or on maemo-community) first. If the TSG is about ratifying things that have already been discussed, then this definitely deserved some discussion, no? Nothing new? Does it mean that Nokia are basically moving on, and leaving Carsten in place as a life-buoy for the N900 version? No, it means that the guy that is doing a great job gets the corresponding role explicitly assigned. Good to hear it. But casual observers were saying that the MeeGo meritocracy requires key roles being taken by non-Nokia and non-Intel contributors... And if that's what's happening, great. If this were associated with a reduction in resources for MeeGo on N900 on the part of Nokia, that would be a concern. If that's not happening, then great - I'm glad we cleared this up before it got to the stage of being a misunderstanding. Can those involved elaborate on what this would mean for N900 MeeGo users, please? For N900 users? Definitely nothing. N900 *MeeGo* users. Anyway, thanks for the information. Cheers, Dave. -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [meego-packaging] QtMobility has branched
Arjan all, If I remember correctly some F2F discussions on this topic (on a place close to Espoo), december deadline is not valid for those components that we are specifically developing for MeeGo 1.2, like QtMobility 1.2 in question. If it is not obvious already, this QtM release is designed for MeeGo 1.2 purposes. So what was suggested by Thiago should be OK for MeeGo 1.2. Br, //Harri From: meego-dev-boun...@meego.com [meego-dev-boun...@meego.com] On Behalf Of ext minjung.s...@nokia.com [minjung.s...@nokia.com] Sent: Wednesday, October 06, 2010 10:54 PM To: ar...@linux.intel.com; thi...@kde.org Cc: meego-dev@meego.com Subject: Re: [MeeGo-dev] [meego-packaging] QtMobility has branched Hi Arjan, The Qt Mobility 1.2 integration plan has been discussed within MeeGo Core OS program stream and feature freeze in December is new to me. Although it is a draft, the feature freeze is end of January according to the release engineering plan of MeeGo 1.2. http://wiki.meego.com/Release_Engineering/Plans/1.2 Can you tell me the source of December deadline so I can confirm? We will have to adjust Mobility release plan if needed. Regards, Min -Original Message- From: meego-dev-boun...@meego.com [mailto:meego-dev-boun...@meego.com] On Behalf Of ext Arjan van de Ven Sent: Wednesday, 6 October 2010 1:22 AM To: Thiago Macieira Cc: meego-dev@meego.com Subject: Re: [MeeGo-dev] [meego-packaging] QtMobility has branched On 10/5/2010 8:19 AM, Thiago Macieira wrote: Em Terça-feira 05 Outubro 2010, às 17:04:03, Arjan van de Ven escreveu: for QtMobility 1.2 to be an option for MeeGo 1.2, it needs to be released by the end of December. I assume the Nokia QtMobility guys are committing to this. But this means we need to get a beta version few weeks before that, and an alpha a few weeks before that. guess what it's pretty soon already so the period of instability is going to be really really short, short enough for MeeGo to just wait it out. I think the Mobility 1.2 release is January, not December. then it's not going to make MeeGo 1.2, and will make MeeGo 1.3 instead Feature freeze in December means what it means; all fundamental, core libraries and components need to be released at that point. And QtMobility certainly is such a core fundamental library. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] N900 Acting roles during July and availability of others
Hello, During Finnish holiday season (July) the following acting roles are set to secure efficient MeeGo on N900 execution: Ameay Palande is acting Team leader for N900 hardware adoption. - Carsten Munck is Acting N900 maintainer. --- Other N900 team members that are working in July are: Markus Lehtonen; upto 8 th of July, Tuukka Makinen; upto 16th of July Marko Saukko; 12th of July onwards Sami Sirkia; 12th of July onwards Teemu Tuominen; 26th of July onwards Most people will be normally available starting from 2nd of August. On N900 hw adaptation matters, please feel free to contact Ameya, Carsten or others when they are available. ps. In Finland we have long and dark winter season. Based on that, most of the people are traditionally taking long summer break on July in order to fill up vitamin D levels and to spend some time with their family. Br, //Harri ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] About building Handset UX Day1 image for N900; some notes and explanations
Hello Meegos, As you know, yesterday Handset UX developement was opened in MeeGo. As N900 is the other hanset reference device in MeeGo, we are of course actively developing all the required adaptation elements to make it possible to run MeeGo Handset UX on N900. From N900 adaptation point of view, we have had some quite nasty last minute stabilty broblems related to our Day1 builds. It looks like Wlan and connman are not working nicely together now, and we don't know yet what exactly is the problem. We have recently started to use .35rc3 kernel, but that does not seem to be the issue, it's rather something related to wlan or Connman configuration, or something above connman that we are not fully aware of. Now, when all the related source's are available, perhaps we can solve those issues as MeeGo community ! This really is Day 1 codedrop for Hanset UX rather than release, we also have bunch of other known issues and errors, like - Wlan does not work on every boot * sometimes you need to boot again.. - Sreen rotation does not work * our accelerometer sensor is not working right at the moment - On some applications closing button is hardly visible - You can use home button once per application to go to task swicther, and come back, but not more than that * this is known bug in framework - There is no phone functionality * Our new opensource drivers for modem module are not stable enough yet. And in addition we still have some issues know already earlier, like - Battery loading does not work * BME, (nokia closed) component still don't work properly.. Because of all this and some misc problems, we decided that there is no point of creating ready-made image for N900. However, there is everything available to build your own image if you are really interested to try it now. Many things are now moving all the time, and what you get with these instructions is in fact the daily image containing the latest state of MeeGo Handset UX development for N900. After all, this is code drop related to MeeGo development, and it is actually interesting first exercise to setup your build environment and start your MeeGo development by creating your first image yoursefl ! The kickstart file to enable the image creation is available at http://tablets-dev.nokia.com/meego-codedrop.php Before you can download it, you need to enter valid IMEI code of your N900 device. That is required because of our current licensensing situation for some closed components that are required to build functional Handset UX Day 1 image. We are working on this issue and I hope we can get rid of this extra step in very near future. Some instructions are available at http://wiki.meego.com/ARM/N900/Releases/Daily Theu are still under development and may contain some errors, please bear with un on this one as well. So, now you should have practically everything available, so lets make MeeGo 1.1 happen together ! Br, //Harri ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] Tomorrow, sorry .. RE: State of N900 image after Handset Day 1
Hello, There will be more information tomorrow how to get image for N900. We forgot to do one simple thing in time after some hassle, blaim me if you want to. But, please remember that this is Day 1 image, Work In Progress. So don't set your expectations too high. Openess of the image is on the same level than in the earlier ones. Br, //Harri From: meego-dev-boun...@meego.com [meego-dev-boun...@meego.com] On Behalf Of ext Sivan Greenberg [si...@omniqueue.com] Sent: Thursday, July 01, 2010 12:41 AM To: Development for the MeeGo Project (discussion list) Subject: Re: [MeeGo-dev] State of N900 image after Handset Day 1 I would dual boot it on the N900 if you don't have any other device you can fall back to if you need critical phone functionality. But, it is interesting to know the level of openness this release carries. Sivan 2010/7/1 Freyr Magnússon freyr.magnus...@gmail.com: I'm looking for some clarification regarding the current state of the N900 images. With the introduction of handset day 1 it looks like the N900 can function nicely as a phone. Can we install it now and expect decent battery life? Do we still need a special closed image for proper functionality? Where can I find the correct image and installation instructions? I really want to switch over to meego so I can start hacking on my own handset while still having a functional phone :) Freyr ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] N900 Wellcome to first open project meeting
Hello, Sorry for short notice, but we will have our first open N900 project meeting tomorrow at 9.00 EEST (8.00 CEST, 6.00 UTC, 24.00 PDT) The place is #meego-meeting IRC channel on irc.freenode.net See also http://wiki.meego.com/ARM/N900 For Agenda etc. (please notify me if you want to have additional Agenda items) Br, //Harri ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] N900: Blockers for May release ?
From: meego-dev-boun...@meego.com On Behalf Of ext Marko Saukko Sent: 17. toukokuuta 2010 10:46 * If we have some standard items on the agenda for each meeting. I think that the current blockers for the next N900 release should be discussed to ensure that each of them would be handled properly. Lets list the blockers now, we don't need to wait for Thursday. Br, //Harri ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] N900 Testing for Btrfs needed (RE: Btrfs as default file system)
Ok, Somehow I forgot this Btrfs thing, I remember that there was some discussion about it at some point. As reasoning from Arjan sounds good, we obviously now need to do some testing with N900 Btrfs as well. While filesystem is perhaps not something that must be the same between devices, it would be nice to use same. Br, //Harri From: meego-dev-boun...@meego.com [meego-dev-boun...@meego.com] On Behalf Of ext Arjan van de Ven [ar...@linux.intel.com] Sent: Tuesday, May 11, 2010 4:38 PM To: Palande Ameya (Nokia-D/Helsinki) Cc: meego-dev@meego.com Subject: Re: [MeeGo-dev] Btrfs as default file system On 5/11/2010 4:00, Ameya Palande wrote: Hi, I wanted to know why Btrfs is selected as default file system for MeeGo. we made a positive choice for btrfs for a list of reasons * It's the future of Linux filesystems. We had a case where the old guard (ext3) is getting retired, and there are two new filesystmes on the table (btrfs and ext4). We felt that if we picked ext4, we'd have all the pain of a new filesystem, and we'd then change again a year later to btrfs. * BTRFS has a strong focus on data integrity, while many other filesystems focus mostly on metadata integrity. For most cases this extra focus is free, however for database applications there is a moderate performance impact. This includes things like duplicating key metadata structures on disk twice, having data checksums, can mark files as critical and for duplication (RAID1)... but basically the whole COW design (never overwrite data) means that you never get garbage in files. * BTRFS supports on-disk compression, giving both a smaller footprint (factory preload time!) as well as higher throughput on really slow storage. * BTRFS has writable snapshots. This opens the door to features in MeeGo 1.1 like atomic package updates (already a Fedora 13 feature with btrfs) but also the Restore to factory defaults becomes easy: just blow away the snapshot and create a new one and the device is as new. You can even use it to have true multiple users in the system, both users have the whole device for themselves with a boot time switch * Performance for small files. Small files are very common, and BTRFS stores these very efficiently on disk. Whereas other filesystems generally need upto 3 IOs (and thus 3 seeks if your storage rotates) to access a file, BTRFS stores everything together and needs only 1 IO. * Built in defragmentation - performance feature for things like boot time * Storage pools: Add and remove storage on the fly. (Yes even for phones this can matter... lets say you have a small flash chip you populate in the factory; this feature allows you to then expand to a secondary storage during first use as if it's one big filesystem... no more /opt issues etc) * ... well it's a long list of things that made us chose btrfs over its competition. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] N900 RE: N900 Testing for Btrfs needed (RE: Btrfs as default file system)
From: carsten.m...@gmail.com [carsten.m...@gmail.com] On Behalf Of ext Carsten Munk [cars...@maemo.org] 2010/5/11 harri.hakuli...@nokia.com wrote: As reasoning from Arjan sounds good, we obviously now need to do some testing with N900 Btrfs as well. While filesystem is perhaps not something that must be the same between devices, it would be nice to use same. On a 2gb microSD, 200-300mb of metadata would be quite a fair bit*. Has there been any studies on how well btrfs fares on SD cards/eMMC type chips? (*) Not against the selection of btrfs - I use ZFS on my servers extensively and it has saved my data on more than one occasion, so I understand why btrfs would be useful on mobile devices. This kind of btrfs on SD/eMMC study sounds like task that someone could do for us rightaway. Any takers ? ;) Br, //Harri ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
