[MeeGo-dev] OBS/RPM shared library dependency building problem
Hi, I have been attempting without much success to produce a working package of libliqbase. Using the C-OBS I have created my project there which happily gets as far as saying it build successfully. However, this project is missing dependencies and no matter how many tweaks I make after reading up I cannot make the build work. This has cycled round for a while and today I endeavoured to ensure it built happily but have not managed. The shared library is built but does not include any of the libraries intended for correct functioning of the library. The same makefile is used happily on Maemo and MeeGo when using make; sudo make install and includes correct dependencies for normal use. The library itself includes the dependencies for building otherwise the compile phase would not work and the same line on device is happy. Could somebody with OBS/RPM knowledge please take a look and help me to steer this in the right direction please. Thanks in advance, Gary Log fragments and investigation notes below: Build Log fragment showing Link phase: gcc -shared -Wl,-soname,libliqbase.so.1 -o libliqbase.so.1.0.1 -fPIC --build-id -ldl -lX11 -lXext -lXv -lm -lcurl `freetype-config --libs` -ljpeg -lpthread `pkg-config --libs libpng12 gstreamer-0.10 ` liqtimer.o liqcell_easyrun_multitouch.o liqrecentphotoselect.o liqapp.o liqapp_hildon.o liqapp_prefs.o liqapp_filecache.o liqcanvas_firstrun_splash.o liq_xsurface.o liqcanvas.o liqimage.o liqfont.o liqfontview.o liqsketch.o liqsketchpagefilename.o liqcliprect.o liqapp_turbo.o liqx11overlay.o liqx11_cover.o liqdialog_showtree.o liqcameraface.o liqimage_thumbnail.o liqimage_rotate.o liqlist.o liqcell_child_select.o liqx11info.o filebuf.o vgraph.o liqcell.o liqcell_arrange.o liqcell_prop.o liqcell_easyrun.o liqcell_easypaint.o liqcell_parse_filename.o liqcell_parse_liqbrain.o liqcell_easyhandler_kinetic.o liqui.o liqcell_dllcache.o md5.o textbox.o liqkeyboard.o liqaccel.o liqcell_historystore.o liqsketchedit.o liqimagescan_hotspot.o dialog_selectimage.o dialog_selectimage_grid.o dialog_selectcolor.o dialog_selectcolor_greycube.o dialog_selectcolor_colorcube.o liqcell_mk_star.o liqtag.o liqsketchfont.o liqdoc.o liqdialog.o liqcamera.o -lc Complete build log URL https://build.pub.meego.com/package/live_build_log?arch=i586package=Liqbaseproject=home%3Alcukrepository=DE_Trunk_Testing Project URL https://build.pub.meego.com/package/show?package=Liqbaseproject=home%3Alcuk OBS non functional libliqbase ldd info: [root@lcuk-desktop lcuk]# ldd /usr/lib/libliqbase.so.1.0.1 linux-gate.so.1 = (0xb781d000) libm.so.6 = /lib/libm.so.6 (0xb777c000) libc.so.6 = /lib/libc.so.6 (0xb75e1000) libpthread.so.0 = /lib/libpthread.so.0 (0xb75c5000) /lib/ld-linux.so.2 (0x00a04000) Standard working libliqbase ldd info: [root@lcuk-desktop src]# ldd libliqbase.so.1 linux-gate.so.1 = (0xb7848000) libX11.so.6 = /usr/lib/libX11.so.6 (0xb769c000) libXext.so.6 = /usr/lib/libXext.so.6 (0xb768b000) libXv.so.1 = /usr/lib/libXv.so.1 (0xb7686000) libcurl.so.4 = /usr/lib/libcurl.so.4 (0xb762e000) libfreetype.so.6 = /usr/lib/libfreetype.so.6 (0xb7595000) libjpeg.so.62 = /usr/lib/libjpeg.so.62 (0xb7572000) libpthread.so.0 = /lib/libpthread.so.0 (0xb7556000) libpng12.so.0 = /usr/lib/libpng12.so.0 (0xb752a000) libgstreamer-0.10.so.0 = /usr/lib/libgstreamer-0.10.so.0 (0xb7486000) libgobject-2.0.so.0 = /lib/libgobject-2.0.so.0 (0xb744c000) libgmodule-2.0.so.0 = /lib/libgmodule-2.0.so.0 (0xb7448000) libgthread-2.0.so.0 = /lib/libgthread-2.0.so.0 (0xb7443000) librt.so.1 = /lib/librt.so.1 (0xb7439000) libglib-2.0.so.0 = /lib/libglib-2.0.so.0 (0xb737) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0xb728) libm.so.6 = /lib/libm.so.6 (0xb7254000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0xb723a000) libc.so.6 = /lib/libc.so.6 (0xb709f000) libxcb.so.1 = /usr/lib/libxcb.so.1 (0xb7081000) libdl.so.2 = /lib/libdl.so.2 (0xb707c000) libidn.so.11 = /usr/lib/libidn.so.11 (0xb7048000) libssl.so.8 = /lib/libssl.so.8 (0xb6ffb000) libcrypto.so.8 = /lib/libcrypto.so.8 (0xb6e81000) libz.so.1 = /lib/libz.so.1 (0xb6e6c000) /lib/ld-linux.so.2 (0x00a04000) libpcre.so.0 = /lib/libpcre.so.0 (0xb6e32000) libXau.so.6 = /usr/lib/libXau.so.6
[MeeGo-dev] Defining the requirements for a MeeGo-CE
Hi, In recent months the MeeGo N900 Community Edition has been building steadily on the MeeGo ARM side of things. This is a little one sided and whilst amazing in principle is building specifically for the N900 With the recent moves from Nokia to get the N950 out, the definition of the N900-CE has expanded to include this. However this is also not without issue, between the moslo and the Qt Components compatability issues applications for MeeGo Harmattan are not compatible by default with MeeGo. The Qt Components and moslo issues can be resolved and once done will allow building and running MeeGo apps which work on the CE as well as Harmattan. This is an ideal opportunity to take this Community Edition a step further and create a proper MeeGo-CE A build of MeeGo using the available open components aimed across the spectrum at handset and tablet devices using the best of our knowledge and work. Of course, this requires extensive work in the adaption levels to allow this to occur. The aim of meego is to aim for different device categories and the 1.3 builds seem to have stalled. Most momentum is around the -arm side and moving and advancing this in to a genera ATOM and ARM arena would allow best of all we have to offer. What do you think? Gary ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] The road from bugs to patches to integration
Hi, I have been following and attempting to fix a number of bugs. There is one in particular which I have identified and fixed on my device. https://bugs.meego.com/show_bug.cgi?id=20099 [CE] Calculator crashes after pressing any button and then . This bug is trivial in effect and would serve as a good test case and way of working through bugs. Since the bug was in a QML component, there was no barrier to entry for identifying the problem. No SDK was required and no complex debugging required other than modifying the QML on device and adding some debug lines. Now, this one line patch sits there in the bugtracker. Since this bug will not be the only one of its kind, is there a simple guide which can be followed to now progress this bug? The obvious simplest method is to just offer a merge request to the gitorious repository, however the N900-CE version appears to be different to the MASTER. Since N900-ce version does not appear to be on gitorious I imagine it will require use of my community OBS. Can we get the steps to fix this book documented in a sequence from new OBS account to integration somewhere so myself and others can offer similar patches? BR Gary ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] fbdev-sgx Bug Fixing, OBS, Branching and patch guidance reqd
Hi, As part of my work, I have spent the last few days trying to get OBS up and running towards fixing an N900-CE bug: https://bugs.meego.com/show_bug.cgi?id=13084 [n900] Horizontal tearing with xvimagesink I have been following the simple OBS instructions: http://wiki.meego.com/Getting_started_with_OBS I have created an OBS project to host the patches so I can test things: https://build.pub.meego.com/project/show?project=home%3Alcuk%3AlibXv_bug13084 I have added 2 repositories to this: https://build.pub.meego.com/project/repository_state?project=home%3Alcuk%3AlibXv_bug13084repository=DE_Trunk_Testing https://build.pub.meego.com/project/repository_state?project=home%3Alcuk%3AlibXv_bug13084repository=MeeGo_Trunk_standard At this point, I thought I could import the packages required to be modified (initially I thought the bug was libXv hence the naming) But I cannot find out how to do this. Have I followed the correct steps so far, and how do I get some actual code into my repository so that I can work on fixing the bug? Stskeeps has indicated the first bug, in that the package needed is: Repository: MeeGo.com:MeeGo:1.2:non-oss Package:xorg-x11-drv-fbdev-sgx These are needed because the fbdev links against non-oss headers. I do not know how to get the latest revision of this code into my repository so that I can follow the code and attempt to fix this bug. I cannot even find where on the web interface the required packages are maintained. Can somebody help guide me so that we can document this sort of bug-fixing initiative for other packages. Gary ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] N900-DE Contacts Import from Maemo VCARD Export
Hi, Recent improvements in the N900-DE have made it viable to get further into the system and do longevity testing of much of the system. Eventually, we hope to allow more of your Maemo data to be imported and usable within the DE build. [1] As part of this testing we have been looking at how to import Contacts from Maemo into MeeGo N900-DE. The rational being that you can have more normal N900 experience by including your regular Maemo data. We are working on Mounting the main eMMC VFAT partition partition of maemo to allow this data crossover. [2] At this point however, we have a problem: How can we inside MeeGo N900-DE Import the contact cards themselves using a scripted command line tool? Thanks to discussions with the guys in IRC (Robin and Thomas especially!) we have gotten this far and they have both indicated this is possible. It would help if anybody on this list could offer this knowledge and let us know how to import these contacts. Best Regards, Gary Birkett N900-DE member. [1] http://wiki.meego.com/ARM/N900/DataManagement [2] http://wiki.meego.com/ARM/N900/DataManagement#Accessing_the_Maemo_eMMC_MyDocs_partition_for_importing_contacts ___ 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] Technical Steering Group Meeting: New Day / Time
On Sat, Apr 2, 2011 at 3:23 PM, Foster, Dawn M dawn.m.fos...@intel.comwrote: On Apr 2, 2011, at 6:53 AM, Jeremiah Foster wrote: On Fri, Apr 1, 2011 at 8:31 PM, Foster, Dawn M dawn.m.fos...@intel.com wrote: ... I sat down with a spreadsheet marked with times for US west coast, western Europe and eastern Asia, which seems to be where most of the people working on MeeGo are located, so I tried to optimize for these 3 locations. I put standard working hours in green, yellow for times 2 hours outside of working times and red for everything else. Since we've (U.S. west coast) had the meeting in the middle of our workday up to now, we thought it was only fair to give us the red time (now 11PM), western Europe was yellow / green (6am / 8am for most people) and green for Asia (2pm / 3pm for most). The other time we considered, based on the red / yellow / green chart, was 6am pacific, 2pm / 4pm western Europe and 9pm / 10pm in eastern Asia. In this scenario, Asia would again get the most inconvenient time, which did not seem fair to me. ... Regards, Dawn Dawn, could you post the spreadsheet or a screenshot of the timezones onto the meeting wiki, I think visually showing the timing differences and difficulties with planning would help. I think it would actually help with more meetings than just the TSG and allow the other WGs to actually plan meetings better too. BR Gar ___ 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] Reducing rebuilds by patching away __DATE__ and __TIME__ usage in sources?
On Wed, Dec 8, 2010 at 12:28 PM, Carsten Munk cars...@maemo.org wrote: Hi, I've spent a little too much time watching rebuilds of the basesystem lately due to the ARM hardfp work. So, a bit of background: * OBS uses the build-compare tool in order to tell if there is a difference between the newly built package and the build results in previous run * If the package is 'new', all packages that depend on it, will rebuild as well. * If not, don't signal a rebuild One common thing is that many programs/libs gratuitously include the C macros __DATE__ and/or __TIME__ in their source codes, causing every rebuild of theirs to be different, but only in those areas. This causes unneeded rebuilds. And we already have an indication of the build time of a package due to the RPM database on a system. If the scanning is being done on binaries AFTER they have been rebuilt isn't that a bit fruitless ie, build this package to compare it with the last one to see if it needs rebuilding? surely If the source is the same it should not be built in the first place? My proposal: * Identify packages using OBS build logs that include __DATE__ or __TIME__ (should be possible to grep for the usual patterns of __DATE__ and __TIME__) * Patch those usages away in spec file. or * Make build-compare able to notice a build change is 'just' because of __DATE__ and __TIME__ and otherwise similar. What do you think? BR Carsten Munk ___ 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] Is it possible to create a flashable image onto USB disk from running system?
Hey, A few days ago at the conf, we used a USB key to boot and flash the entire system replacing the OS on the ideapad. I have a need to test alternative images but I would like to maintain the changes I have made in my current system. Is it possible to prepare a flash drive capable of a complete image backup onto a new memory stick? ie, boot from a USB stick and fill the stick with the contents of my hard drive. It would allow us to store the system state right up until that point and whilst may have issues space wise would be a practical simple way to allow testing. Gary ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Is it possible to create a flashable image onto USB disk from running system?
On Thu, Nov 25, 2010 at 9:05 AM, Igor Stoppa igor.sto...@nokia.com wrote: On 11/25/2010 10:57 AM, ext Gary Birkett wrote: Hey, A few days ago at the conf, we used a USB key to boot and flash the entire system replacing the OS on the ideapad. I have a need to test alternative images but I would like to maintain the changes I have made in my current system. Is it possible to prepare a flash drive capable of a complete image backup onto a new memory stick? ie, boot from a USB stick and fill the stick with the contents of my hard drive. It would allow us to store the system state right up until that point and whilst may have issues space wise would be a practical simple way to allow testing. Gary At least on ubuntu 10.10 you can use any bootable image to create a USB stick and assign a certain amount of the remaining free space to be used for storing settings/documents. The tool is Startup disk creator. Igor, this is slightly different, the Startup image creator tool you mention combines an ISO file stored on my disk with some magic to make a USB stick. But I do not have an ISO image of the system, I have an actual real bootable live system on the meego ideapad. I have been running it and made changes and installed things and now want to push all that back onto a usb stick as a super complete image. Once I have done that, I can keep that USB disk with image and know that whatever other changes I make to the system I have a complete binary image on the usb stick that is capable of reflashing as required and get my system right back to exact point it is now. cheers, igor ___ 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] Meego Bugs Access Denied
Hey, I have encountered a number of bugs this morning as part of my work on the meego bug tracker which are giving an error: You are not authorized to access bug #[bugid] (related to something I expected to read and digest) This issue effects people in other areas too A specific example this morning was stskeeps could not access http://bugs.meego.com/show_bug.cgi?id=8474 this bug is highlighted multiple times in the acceptance report http://wiki.meego.com/Quality/HandsetTestReport/1.2_N900Acceptance20101028 Is there a general documented mechanism to follow to get access to these bugs or to generally unlock them? (going through team leaders based on requirements is normal) Gary ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] [compliance] Different view on app compliance
On Sat, Sep 18, 2010 at 6:20 PM, Carsten Munk cars...@maemo.org wrote: 2010/9/18 Andrew Flegg and...@bleb.org: On Sat, Sep 18, 2010 at 18:35, Carsten Munk cars...@maemo.org wrote: [snip] Firstly, thanks Carsten for trying to come up with a clean-sheet proposal. Much of the logic (regarding lock-downs and single RPMs delivered over HTTP) seems eminently sensible and self-consistent. #2 A MeeGo application may only depend on packages within: MeeGo Core repository (for the particular version of compliance it is targetted on) [this doesn't have to be repo.meego.com, can be a vendor mirror] and the MeeGo Profile repository it may be built for (or the particular version of compliance it is targetted on). Profile means Handset, Netbook, Tablet, etc. [same as above] And it's installation source. This avoids the dependency graph of repositories problem, but is a sensible half-way house. #3 With dependencies that originate within the installation source, these packages may only be packages that originate from the application's own source package. Reasoning: We should encourage same packaging practices as we have in MeeGo. This means packagename-devel, packagename-doc, etc. (bad examples for a package depending on other parts of itself) This bit concerns me, so either I'm not understanding it or we've found a bone of contention. Are you saying that: fooapp which depends on libbaz (both of which are in, say, MeeGo Surrounds) and libbar (in MeeGo Core) can *only* be compliant if foo.tar.gz built fooapp.rpm and libbaz.rpm? And that barapp could not be compliant if _it_ depended on libbaz? No, I'm saying that if there's any dependencies of the application that would be resolved through the installation source, these dependencies can only be from the set of binary packages being built as part of the applications' source package. It concerns me too at installation time, fooapp from AppUp should have the following simple logical installation tree available: Everything in AppUp Everything in Profile Everything in Core Dependency resolution should be simple to organise in that situation. If each library must be embedded inside applications it will cause MORE security problems than it solves. With X different packaged up libbaz versions from different applications using it, how would they be patched in a timely manner? The challenge is that if we dilute this, we risk that people dump in, let's say, SDL and it would conflict with another repository also hosting SDL. We won't see people putting same application in multiple places, I would hope.. You will have massive problems with this limitation, its nothing to do with diluting it. SDL is a dependency for many large OSS applications. Using the SDL example, if it is available in core and also Intel AppUp (for use by other AppUp applications) then the latest will be used? Just like it does now Or did dependency resolution go out of the window with the change to RPM? BR Gary Best regards, Carsten Munk ___ 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] [PATCH 0/4] cy8ctmg110 touch screen improvements
James, A question about the patch for capacitive cy8ctmg110: Added fuzz to ABS_X and ABS_Y to remove jitter I cannot determine from the patch what it does, does it reduce the resolution down to 4 unit blocks, or does it still allow single unit sensitivity whilst removing jitters from around it? If it it indeed the resolution limiting, perhaps something I did in the past to remove jitter from the very noisy accelerometer might be another alternative. At each new reading from the sensor, I would move the cursor a percentage fraction closer to that point rather than directly using it. In a jittery noisy environment this allows it to retain accuracy whilst removing the jitter. Just thoughts based on this patch and not knowing how it works inside the black box controller. If it already does this then that is great! Gary On Thu, Aug 19, 2010 at 11:21 PM, James jketr...@linux.intel.com wrote: This series fixes two bugs (jitter and calibration), provides some general cleanups, and adds multi-touch capabilities to for the cy8ctmg110 touch screen driver. James Ketrenos (4): cy8ctmg110: Removed X and Y scaling factor for send_event cy8ctmg110: Rework to be multi-touch ready cy8ctmg110: Added fuzz to ABS_X and ABS_Y to remove jitter cy8ctmg110: Add multi-touch capabilities drivers/input/touchscreen/Kconfig | 13 ++ drivers/input/touchscreen/cy8ctmg110_ts.c | 179 + 2 files changed, 142 insertions(+), 50 deletions(-) ___ 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] [PATCH 0/4] cy8ctmg110 touch screen improvements
James, that is great to know, thanks for clarifications on both parts! I did not see the details of the driver body itself in the patch hence questions :) As for a kalman filter, the equation itself looks heavy [1] and would understandably have to be recalculated every frame unless an incremental variation can be created. The version I did initially with just taking fractions of each sample was easily achieved [2] and lightweight enough to be useful without consuming battery. I bet for the use I did it wouldn't make much difference, but in scientific situations it would be good to try. Regards, Gary [1] C implementation http://www.its.washington.edu/software/kalman_fil.html [2] Maemo wiki with Accelerometer smoothing http://wiki.maemo.org/Accelerometers#Smoothed_C_interface On Tue, Aug 31, 2010 at 5:23 PM, James jketr...@linux.intel.com wrote: On 08/31/2010 05:34 AM, Gary Birkett wrote: James, A question about the patch for capacitive cy8ctmg110: Added fuzz to ABS_X and ABS_Y to remove jitter I cannot determine from the patch what it does, does it reduce the resolution down to 4 unit blocks, or does it still allow single unit sensitivity whilst removing jitters from around it? You can see drivers/input/input.c input_defuzz_abs_event() for implementation details on how fuzz is used internally within the input system. The result is that jitter around a stable point is reduced; the device still retains the same total sensitivity, but once a contact point is made, the data has a tendency to stick to that value until the threshold is crossed. If it it indeed the resolution limiting, perhaps something I did in the past to remove jitter from the very noisy accelerometer might be another alternative. At each new reading from the sensor, I would move the cursor a percentage fraction closer to that point rather than directly using it. A kalman filter (or similar predictive algorithm) is also a great way to remove noise from an accelerometer, without introducing latency into the sensor read path. James ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Dual Touchscreen Support
Jeremiah, that use case would likely cause more problems not so much with dual input technically, but with dual output logistically if both screens are active then the kids will fight over what to watch (a fun game to play, but invariably ends with Parenting_Exception being raised) Gary On Sat, Aug 21, 2010 at 12:52 AM, Jeremiah Foster jeremiah.fos...@pelagicore.com wrote: On Aug 19, 2010, at 13:25, Auke Kok wrote: On 08/19/2010 09:54 AM, Abraham Arce wrote: http://www.spinics.net/lists/linux-input/msg10503.html I'm not aware of any specific requirement for this, and it's really not that simple per se, and several packages are involved: I'm not aware of a specific requirement at the moment, but I can imagine an IVI situation where you'd want to run MeeGo on two screens in the two headrests of a car. Jeremiah ___ 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] Making meego fast - quick tests and lots of input needed
Hi, One of the big things people want nowadays with an OS is speed. They expect a nice fast solid slick experience. Last night during the discussions in IRC, performance was mentioned and how it is lacking in meego at the moment. Now, we can talk about it being an alpha and a beta and unreleased and its going to get faster all we want, but it has to get faster from all angles. There are going to be all sorts of different optimisations available and we have to start somewhere. On the n810, I used to have the capability of running in alternative resolutions. I could run my applications at full high resolution which did not always run perfectly quickly and drained the battery a bit more Or I could change to a lower resolution and carry on running exactly the same using MUCH less CPU and battery This also had the drastic effect of making it run *REALLY REALLY FAST* One of the things about Meego is that it is designed to be run on different handsets with different screen resolutions. Some of them will be lower than others and some will be higher. To gain maximum performance on the reference N900 and to test out this resolution invariance, I would like to find out how to change the resolution in Meego. Now, stskeeps told me that libmeegotouch does infact support variable resolutions: lcuk and working out how to operate in alternative resolutions *WILL* be needed when you get other devices onboard Stskeeps lcuk: libmeegotouch already runs in alternative resolutions Stskeeps check devices.conf sometime However, when I have asked about this in the past have heard that there are some issues with applications not playing too well with variations. These if true would need to be sorted, but as a quick simple test, I opened liqbase on my n900 and tried changing the resolutions and rerunning. lcuk I just did some testing in liqbase lcuk and running liqbase at *800*480 *gets a framerate doing a certain task at *45fps* lcuk running same task at *640*480 *gives me *55fps* lcuk I do not have capbility to test this [in meego] lcuk can someone PLEASE try on n900 changing the parameter stskeeps mentioned lcuk and tell me if it does change resolution lcuk and if its a valid strong improvements? Stskeeps lcuk: that isn't what sets screen resolutions, just what resolutions it's expected to work with :P lcuk so then setting that parameter is first step lcuk what else? - even accepting a black line down the side lcuk is it entirely down to the graphics driver? lcuk the yuv overlay mode can be coerced into stretch to fit (it just did it for me now) lcuk I have never managed or tried with rgb Quite drastic improvement for a 5 minute test!!! Drawing 20% less pixels gives a speedup of ~20% Now your turn Meego, how much improvement can be got by changing the resolution? how is it done? stskeeps mentioned in IRC about the parameter just being the libmeegotouch stuff so there will be more needed I bet. what problems are there? What other mechanisms can be tried??? where else can we get rid of large chunks of sluggishness? Gary ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
[MeeGo-dev] File system development pondering
Hi, This started as a discussion in #maemo yesterday, but is just as relevant here. I have looked at btrfs (https://btrfs.wiki.kernel.org/index.php/Main_Page) and whilst it incorporates a lot of features cannot determine whether the following is generically supported: It has been pondered to incorporate some smart unionfs layering onto the main filesystem of meeog/maemo. The layering should be able to know there is a smaller (256/512 MiB) fast layer, with a much larger and potentially slower storage layer ontop. I am aware btrfs supports subvolumes, but do not think this is quite what is required) Most of the devices we are currently targeting will have this kind of space/speed problem where the smaller faster layer will currently exist and outperform the large storage. The aim would be to monitor filesystem usage and as requirements change to automatically move the most used components into the fast area whilst moving the least used back to the slower area. In principle, it is fairly simple to understand, though I am told that in practice it would be a complex and challenging task to undertake. Hence, I am here asking the experts - would such a thing be feasible, has it already been done (in btrfs perhaps) and if so is it usable in meego/maemo ? This is of course just a starting point for extra discussion. thanks in advance Gary ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev
Re: [MeeGo-dev] Power Managemengards
On Tue, Jun 22, 2010 at 6:08 PM, Arjan van de Ven ar...@linux.intel.com wrote: On 6/22/2010 4:15 AM, Dave Neary wrote: Hi, Arjan van de Ven wrote: On 6/21/2010 1:27 PM, Narendranath Ghosh wrote: Is there any power management architecture doc available for user domain? Applications need to be well behaved. not wake up the cpu unneeded, not keeping resources busy etc etc (see various presentations that I and others did in the past on this topic) So, in summary, no? correct. there are, by design, no special APIs in MeeGo for applications to be power friendly. It must be sufficient for an application to be well behaving [*] for it to be power friendly in MeeGo. would it be wise to document all the best practices in one place though? also for applications to be well behaved, they should know something about their environment to that end should know where to look for the charging status for instance if the devices have a power profile available, the api to access this should be documented and clearly stated I believe that sort of information is what Narendranath Ghosh was requesting. correct me if I am wrong. BR Gary [*] so no frequent polling, closing devices it's not using etc; the stuff that we've been educating everyone on for the last few years, and that most open source software took to heart. ___ 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] Can i distribute MeeGo ?
On Sun, Jun 13, 2010 at 8:50 PM, Arjan van de Ven ar...@linux.intel.comwrote: On 6/12/2010 12:26 PM, Dome Charoenyost wrote: Dear All, I'm modify MeeGo for support nvidia , ati and include XBMC . I'm worry about copyright. so i want to know what's good way for distribute meeGo modify version. I don't want to folk. 1. Can i still use all graphic and logo in side Meego ? 2. Can i use MeeGo for name of my version? as long as your version is compliant the answer to both is yes, otherwise the answer to both is no. compliance is mostly about compatibility; if you use all our packages, and do not change the ABI in any patches you add you're fine. If you change versions of things it's a problem, or if you do things that change ABIs. the official build will be changing versions of components you best hope that can handle it easily itself too.. BG Dome C. ___ 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
Re: [MeeGo-dev] I have N900 Device can it be of any help?
On Thu, Apr 29, 2010 at 7:23 PM, Zahed Ali Taqi zahedonl...@gmail.comwrote: Hi Guys, I have N900 Device can it be of any help? I also have N810 was using the Meamo for a couple of years, got very familiar with it. So please let me know i can help in testing on my device, Cheers, Zahed I think Nokia has one or two n900 devices available for testing already! however you are more than welcome to get involved and install/discuss/patchup the released packages and even have a go at making your own. hope you enjoy the ride Gary ___ 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
