|
the Fremantle Porting Task Force, or "how to run maemo on Neo900"
the Fremantle Porting Task Force,
or "how to run maemo on Neo900" the thread title says it all. This thread is dedicated to discussion about concepts and details of how to port maemo fremantle OS to Neo900 (Neo900 - finally a successor of N900) - or more generally to new hw platforms - , incl new volunteers introducing themselves in here, and occasional references to the Neo900 hw design and implications which the fremantle porting might have to the hw design. Next post will summarize the foundation concepts and other relevant details. Everybody who wants to contribute in porting (and during that step by step "freeing") fremantle, please don't hesitate to post in here. Or ask about Fremantle Porting Task Force and Neo900 in IRC(freenode.net):#maemo Please take any posts clearly related to Neo900-the-device (when to buy, what's the hw-features, etc pp) to the Neo900 thread linked above. Thanks! This thread is for developers only. cheers jOERG |
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
the mantra:
first we try to fix the fremantle core system foss bits to match the new hw platform. if that can't be done we try to patch the kernel device drivers so the new device looks like the the N900 one to userland if that can't be done we try to RE userland blobs or binary-patch them or write bridging-adapters from one ABI to the other if that can't be done we need to adapt the hw platform to more closely resemble the N900. Better alternative to the "closed packages" link above: http://wiki.maemo.org/Porting/Closed_Packages Also see http://wiki.maemo.org/Porting ! Our "foundation": http://omappedia.org/wiki/Maemo_Getting_Started#Beagle Highly relevant: http://elinux.org/N900 http://wiki.maemo.org/Porting Some definitions of landmarks: DM3730 is considered thumb-safe charging in Neo900 will be similar to reference implementation (TWL4030-based), so no bme blob needed [edit: this is not finally decided on yet, we might use more N900-alike charging (edit2) or even use something completely new that doesn't need any cpu support at all but isn't based on twl4030 either which is what we do now] , but we need some replacement that offers same data to HAL. Audio hardware will be 99% compatible to n900 hw, to accommodate fremantle audio blobs like alsaped and nokia proprietary PA plugins. Except for modem audio which will be a plain I2S PCM stream (just like the codec has one), instead of some obscure "network-attached" stream tunneled through ISI aka phonet0 hw interface (the notorious cntspeech). nice info: http://processors.wiki.ti.com/index....igration_Guide (for unclear reasons I get a "not allowed to acccess..." with Konqueror. FF works) About camera (about meego/sailfish, but for stuff like zerocopy and omap3camd and how stuff works it applies to fremantle as well, more or less): http://talk.maemo.org/showthread.php...55#post1397155 Some concerns about this porting project err about Neo900 err about CSSU and how it might get negatively influenced by FPTF: http://talk.maemo.org/showthread.php?t=91399 |
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
only what i can say is thank you,everybody
i realy want to buy,but not now.can i buy one after a year? |
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
Here are my thoughts on what to do with the N900 closed packages for the Neo900 (as listed in http://wiki.maemo.org/Fremantle_closed_packages)
Packages where usable open replacements/clones exist (or where the actual N900 source code has been found and is now available) and that we can modify to our needs bme-rx-51 browser-neteal osso-graphics-game-chess osso-sounds-game-chess osso-sounds-game-mahjong osso-graphics-game-mahjong mp-fremantle-generic-pr libcal-dev libcal1 initrd-progs tablet-browser-view-test calendar-home-applet libbmeipc0 libtrace-dev libtrace0 tone-generator pulseaudio-policy-enforcement ohm-plugin-prolog ohm-plugin-resolver ohm-plugins-misc libprolog0 prolog-extensions dsp-manager gstreamer0.10-dsp libdres0 libexempi-dev libexempi3 docpurge hald-addon-bme camera-firmware libmaemosec-certman-applet0 maemosec-certman-applet status-area-applet-battery status-menu-applet-profiles libprofile-dev libprofile-doc libprofile0 maemo-applet-profiles profiled profile-data profile-data-dev bluetooth-sysinfo libppu0 libwl1251 wl1251-cal policy-settings-rx51 (assuming that the output of this matches with the original prolog binary file before it was decompiled we should be able to use this package as a base in our new system) osso-systemui-tklock osso-systemui-powerkeymenu osso-systemui-alarm osso-calculator osso-calculator-ui osso-applet-notificationlight osso-applet-display connui-home-cellular maemo-applet-tvout maemo-statusmenu-fmtx libmaemosec-certman0 libmaemosec0 maemosec-certman-common-ca maemosec-certman-tools hildon-im-fkb libhildon-im-western-plugin-common3 libhildon-im-vkbrenderer3 getbootstate feedservice-plugin-fb-common clock-ui camera-ui calendar-backend calendar-backend-dev calendar-backend-doc tablet-browser-daemon Packages I think we can drop completly as non-essential for a working system: (including things that go away because we are using different hardware to the N900) amazon-installer ap-installer as-config-applet-0 as-daemon-0 as-utils status-area-applet-activesync-0 ovi-promotion-widget sharing-service-ovi sharing-service-facebook sharing-service-flickr feedservice-plugin-fb feedservice-plugin-amazon feedservice-plugin-ap facebook-installer facebook-services foreca-installer foreca-weather-applet cherry camel-as-provider-0 camelisync rtcom-accounts-plugin-facebook nokiamessaging nokia-maps-core nokia-maps-maplets nokiamaps-navigation-provider nokia-maps-ui dtg-installer modest-nokiamessaging-plugin cmt-firmware-rx51 bt-firmware wl1251-firmware nolo libgles1 libgles1-sgx-img libgles1-sgx-img-dev libgles2 libgles2-sgx-img libgles2-sgx-img-dev opengles-sgx-img-common opengles-sgx-img-common-dev libas-common-ui-0 libas-common-utils-0 libas-protocol-0 libas-storage-0 liblas1 location-daemon location-proxy libnavigation-dev libnavigation0 libmaesync maesync-backend maesync-controller modest-as-plugin-0 osso-maesync-plugin osso-maesync-ui testserver fmtx-middleware fmtx-middleware-doc funambol-cpp-api flasher sdk-fiasco-gen softupd rtcom-accounts-plugin-nokiachat Packages we can probably keep using as-is without needing to make changes: adobe-flashplayer osso-accounts-plugin-skype rtcom-abook-skype-plugin rtcom-skype-emoticons-theme skyhost-bin skyhost-vengine telepathy-spirit cellmo-headers cellmo-icpr82-headers hildon-theme-alpha hildon-theme-beta hildon-theme-devel ui-fonts chinese-font eff-content-fonts calendar calendar-ui calendar-ui-widgets-0 calendar-ui-widgets-0-dev applet-datetime google-search-widget hildon-control-panel-personalisation clockd-settings-mr0 hildon-desktop-applet-settings-mr0 hildon-desktop-application-shortcuts-mr0 maemo-ringtones-mr0 tablet-browser-bookmarks-mr0 theme-default-settings-mr0 imageviewer mediaplayer mediaplayerhomeapplet mediaplayer-restore maemo-input-sounds osso-sounds-rtc osso-sounds-ui osso-filemanager osso-filemanager-ui osso-graphics-game-lmarbles connui-statusbar-bluetooth connui-btsettings location-control location-status location-ui location-home-applet location-settings-default location-test-gui locale-resolver-data libi18n-dev libi18n-locale-resolver0 libi18n0 libjpeg62 libjpeg62-dev libjpeg62-dbg connui-conndlgs connui-conndlgs-bluetooth osso-sketch osso-notes osso-icons-default osso-icons-devel libspeex-dev libspeexdsp-dev libspeexdsp1 libspeexdsp1-dbg libspeex1 libspeex1-dbg maemo-applet-fmtx maemo-installer-utils maemointernal-keyring maemo-statusmenu-headset maemo-statusmenu-volume statusbar-alarm speex-doc ezitext-czech ezitext-danish ezitext-dutch ezitext-english-gb ezitext-english-us ezitext-essential-plugins ezitext-finnish ezitext-french-ca ezitext-french-fr ezitext-german ezitext-greek ezitext-italian ezitext-norwegian ezitext-polish ezitext-portuguese-pt ezitext-russian ezitext-spanish-es ezitext-spanish-us ezitext-swedish imengines-ezitext libezitext libcityinfo-dev libcityinfo-doc libcityinfo0-0 osso-applet-languageregional osso-applet-memory osso-applet-textinput nokia-apps nokia-binaries libimengines-wp4 libimengines4 libimlayouts0 libhildon-time-zone-chooser0-0 libcodelockui1 libcodelockui1-dev feedservice feedservice-utils osso-rss-feed-reader-list osso-applet-device osso-applet-devicelock osso-abook-home-applet osso-addressbook libosso-abook libosso-abook-dev libosso-abook-doc rtcom-accounts-plugin-gtalk rtcom-accounts-plugin-jabber rtcom-accounts-plugin-sip rtcom-accounts-ui rtcom-accounts-voip-support rtcom-notification-ui rtcom-presence-ui wappushd wappushd-dev xml2wbxml osso-startup-wizard modest-home-applet modest-providers-data mafw-iradio-source-bookmarks-default osso-systemui osso-systemui-devlock osso-systemui-splashscreen osso-systemui-conf librtcom-accounts-ui-client-dev librtcom-accounts-ui-client0 librtcom-accounts-ui-dev librtcom-accounts-widgets-dev librtcom-accounts-widgets0 libsharing-plugin-dev libsharing-plugin-doc libsharing0 sharing-account-manager sharing-dialog sharing-dialog-dev sharing-dialog-doc sharing-manager sharing-rtcom signond-dev signond0 signond-utils libsignon-glib-dev libsignon-glib0 libssoautologin liblomesa0 libnips0 libosal0 libgpx0 libdevlock-bin libdevlock1 hildon-im-common-virtual-settings hildon-im-keyboard-assistant hildon-im-keyboard-assistant-scv hildon-im-plugin-base-settings hildon-im-virtual-keyboard-layouts hildon-input-method-configurator hildon-input-method-plugins-western hildon-input-method-widgets hildon-application-manager-settings-standard hildon-plugins-notify-sv hildon-startup-progress hildon-welcome-default-logo libaccounts-dev libaccounts-doc libaccounts-glade libaccounts0 libconbtui0 libclockcore-dev libclockcore0-0 libtime-dev libtime-doc libtime0 gst-nokia-wm gstreamer0.10-hantro gstreamer0.10-wma libcumulus0 libtopos0 immvibe libimmvibe0 libimmvibe0-dev libcail-common libcail-dev Packages where we need to decide what to do: tutorial-home-applet (need to figure out whether to write new tutorial, keep existing tutorial or drop altogether) hildon-status-bar-usb (probably need to clone this and make changes to account for plans for USB improvements in Neo900) osso-backup (do we drop this completly, write a new backup app that does its own thing, write a backup app that is functionally compatible/output compatible with the N900 app or keep using the existing N900 app as-is) mce (are we able to use the Fremantle MCE as-is, do we base something off the released Meego/Harmattan MCE source, do we reverse engineer the Fremantle MCE or do we write something totally new to do this job) clockd (may need to clone and modify this if the way clock works changes e.g. cellular network provided clock) clockd-doc (may need to clone and modify this if the way clock works changes e.g. cellular network provided clock) gstreamer0.10-nokia-speech (not sure whether we need this or not and if we do, what to do about it) alsa-policy-enforcement (not sure if audio stack will change and what to do with this) libiphb-dev (not sure if we still need iphb going forward and if so whether we need to clone it or whether we can use it as-is) libiphb0 (not sure if we still need iphb going forward and if so whether we need to clone it or whether we can use it as-is) iphbd (not sure if we still need iphb going forward and if so whether we need to clone it or whether we can use it as-is) policy-application-detector (dont know what to do with this) libplayback-1-dev (not sure if libplayback will need to change due to changes in audio stuff or whether we can keep using it as-is) libplayback-1-doc (not sure if libplayback will need to change due to changes in audio stuff or whether we can keep using it as-is) libplayback-1-0 (not sure if libplayback will need to change due to changes in audio stuff or whether we can keep using it as-is) osso-systemui-actingdead (not sure if this is still needed going forward or not) osso-systemui-modechange (not sure if this is still needed going forward or not) For the cellular modem we need to decide whether to A.Reverse engineer the cellular services daemon and its plugins and modify ofono or fsogsmd to export the same interfaces, B.Reverse engineer the things that talk to the cellular modem and replace them with new bits that do the same thing but talk to existing ofono/fsogsmd interfaces C.Some combination of A and B or D.Go lower level and parse the ISI data that's sent to the modem and convert them into whatever we need in order to talk to the modem in the Neo900. For some bits (e.g. status bar widgets or the ICD GPRS plugin) it may be easier to rewrite. For others (e.g. dialer) rewriting is not an option and we need to make the new low level bits do what those upper level bits need: Cellular modem low-level bits: csd-base csd-call csd-gprs csd-info csd-sat csd-sms csd-ss libcscall2 libcsnet-dev libcsnet0 libisi-glib0 libisi1 libsimpb0 libsim0 libsms-utils0 libsms0 libss1 libtelcommon0 phonet-at phonet-utils ssc-daemon sms-manager libphinfo0 Cellular UI bits that talk to the low level bits: connui-cellular-settings rtcom-call-ui rtcom-messaging-ui connui-conndlgs-cellular connui-statusbar-cellular telepathy-ring evolution-data-server-addressbook-backend-sim gprs-provisioning libconnui-cellular librtcom-call-ui0 osso-mission-control operator-wizard-settings ota-settings osso-systemui-emergency For the internet connectivity daemon and wlan bits and such we need to figure out whether to keep using the binary blobs below or to replace them (and which ones to replace): connui-conndlgs-internet connui-conndlgs-wlan connui-iapsettings connui-iapsettings-gprs connui-iapsettings-wlan connui-statusbar-internet osso-wlan-security icd2 icd2-dev icd2-network-wlan-config icd2-settings-default libicd-network-dummy libicd-network-eap libicd-network-gprs libicd-network-ipv4 libicd-network-wlan libicd-network-wlan-dev libicd-network-wps libicd2 libconnui For GPS, the way to go is to replace the below packages with drop-in replacements that talk to the GPS chip in the Neo900 liblocation-dev liblocation0 liblocation0-doc For pulseaudio packages below, since our hardware is different, we probably dont need to use these, if we do, what do we do about them? Use whatever the various alternate OSs on the N900 are doing? (i.e. whatever the MeeGo-on-N900 work has morphed into these days) Reverse engineer these? Replace them completly? pulseaudio-module-nokia-common pulseaudio-module-nokia-music pulseaudio-module-nokia-record pulseaudio-module-nokia-voice pasr For browser UI and bits, do we A.Keep existing closed UI as-is B.Clone some or all of closed UI and modify it C.Write totally new UI that replaces existing UI but keeps same open backend (browserd etc) or D.Use totally different browser for N900 and ditch microb completly? Browser bits are as below: osso-bookmark-engine osso-bookmark-engine-dev osso-browser tablet-bookmark-manager tablet-browser-controls tablet-browser-default-plugin tablet-browser-dialogs tablet-browser-mediaplayer-plugin tablet-browser-ui tablet-browser-view tablet-browser-view-dev tablet-browser-widgets For camera, not sure if we need to keep using the below packages, clone them and change for whatever new hardware we have or write something new: libomap3cam omap3camd libhllc0 For the sysinfo libraries we probably need to create drop-in replacements that do the same job but fit our stack: libsysinfo0 osso-product-info libossoproductinfo0 sysinfo-common sysinfod sysinfo-tool For the DSP stuff, we may need new bits for whatever chip we have, we may need to replace these things, we may need to drop them completly, I dont know. libipp-nokia gstreamer0.10-ipp-nokia omap3430-dsp-baseimage-ti omap3430-dsp-libraries-ti libbridge2 libomxil-ti-components libomxil-ti0 |
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
awesome work! incredibly valuable. I boggled from it. Should this go onto a wiki page so we can edit/comment as needed?
|
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
Dropping SGX usermode bits doesn't look like something we can do IMO. Otherwise there will be no GLES, which means no games and no HW accelerated gecko (for example).
I think we should swallow those blobs :) On a side note - my understanding is that our ultimate goal is to have one (or 2, but very close) distribution to be used on both N900 and Neo900. I won't agree on dropping N900 support in favor of Neo900. Just saying :) |
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
My point about the SGX blobs is that whatever chip ends up in the Neo900 will have a GPU that is different enough that the existing N900 blobs wont work (at least that's an assumption) and therefore we will use different blobs that go with the GPU in the Neo900.
|
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
Quote:
|
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
I think it would be better to stick to one distribution, so long as it doesn't impede performance of either device. I'm thinking if one device can get better performance using a specific compiler option for a specific package or have a feature disabled on N900 due to lack of memory.
Hardware specific packages should be pretty straight forward, using metapackages. Been trying to work out how to word my suggestion but got in a mess with package this and package that. Decided it was easier to illustrate. N900-Adaptation
Neo900-Adaptation
Obviously, this may need some modification to existing packages on N900. microb (and related) wise, maybe see where Alopex is heading. I think we would need to do something even if it is just to increase security and compatibility. Finally, I would like to see the Facebook rtcom plugin stay. |
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
Quote:
Neo900 will have the same Option module as GTA04 does. I think we can use work done by FSO (http://freesmartphone.org/) and take fsogsmd as a middleware that's going to talk directly with the modem, as it already has good GTA04 suppor. API docs: http://docs.freesmartphone.org/ (we might consider oFono as well, but I would strongly recommend fsogsmd) We will have to reimplement CSD dbus API. For that some reverse engineering will be needed, as there is very small amount of documentation for those: http://wiki.maemo.org/N900_dbus DBus API documentation will also come handy for working with different parts of the OS, so I suppose collecting it has pretty high priority. Some insightful discussion happened today on #maemo-cssu regarding replacing closed blobs, especially GSM daemon. The most interesting part starts at 15:02: http://mg.pov.lt/maemo-ssu-irclog/%2...09-07.log.html |
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
Too bad we dont have documentation for other dbus interfaces in the way that we do for com.nokia.csd.gprs and com.nokia.phone.net :(
|
i guess if any of you have the gta04 board, how much would it take to be able to atleast flash the original firmware on the board? changed emmc?
|
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
Quote:
Quote:
|
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
I have just begun a thread intended to document the architecture and as much as possible of the details of the Cellular Services Daemon in Maemo. Posting as a separate thread since people other than just Neo900 guys might be interested in the information.
The thread is here http://talk.maemo.org/showthread.php?t=91313 |
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
I know the hardware side is tight dollar wise.. but will any portion of sales from neo900 be donated to maemo.org?
I mean it will be running maemo? |
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
first of all, it doesn't seem to be related to porting Maemo to Neo900 - Neo900 thread itself sound like better place to ask such question.
Now, I don't really see such thing necessary. Consider price range of Neo900, we can expect that majority of people buying it are already much involved into Maemo community (or going to be involved soon ;) ), be it as volunteer work for keeping Maemo infra up, cash donations, or working hard on Maemo-related projects. I don't think that rising price just to *force* every Neo900 buyer to make a donation is good idea. /Estel |
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
Quote:
PS, I don't agree. maemo was pimped out to jolla (ie support/advertising/facebook etc for what return? nothing!).. and now this... i don't agree. I don't know how the finance side is going on maemo.org but if it's not supported financially then there's a chance we'll have no forum/repos for N900/neo900. I was thinking even a tockenistic gesture.. ie 10USD or 1% .. i think it's a small price to pay to show support, give credit for our HW and SW (maemo.org). Anyway |
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
don't worry, maemo.org infra is rather stable at the moment. :-) What we need for infra are volunteers, raw manpower, not donations tbh.
And for this porting effort we need even more /j |
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
Quote:
Now, Jolla is purely "mainstream" commercial effort with (probably) UI closed by design harmattan way, mostly closed hardware, etc. I say "probably" and "mostly" as, like all self-respecting mainstream commerce (irony intended), they're presenting us with constant marketing BS, instead of hard facts about device, interfaces, software licenses... With Neo900, we know what we're going for even before actual work from "Maemo side" started (it can only get better if possible, not worse, than was presented). Last but not least, unlike failure with putting adverts for Jolla - where no one asked if it's really what Community want to do, for free - I don't see anything like that happening for Neo900. There are 2 threads for it, and there is task force forming, interested to port Maemo to Neo900 - all volunteer work, no one from Maemo "forced" anyone to work on this. Maemo isn't corporation, where "leaders" can re-assign manpower - only people interested themselves (and able to) are going to work on Maemo implementation for Neo900, and they're going to do it by own, independent decision. --- summing it up, I just don't see any comparison. If someone want to port Debian to any random platform he is creating, he should be obliged to donate part of his income to Debian project? Absurd! He *may* want to do so, alongside further users of his hardware, but forcing to do so would be almost M$ way. what you're proposing is de facto licensing use of Fremantle (which isn't even our copyright, BTW). /Estel |
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
I have made a wiki page here
http://wiki.maemo.org/Porting/Closed_Packages which is intended to be a place to collect a list of the closed packages on the N900 and figure out what to do with them (keep them as-is, drop them altogether, clone them, whatever) |
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
Quote:
Little rant from me :P It would be nice if you made links to wiki pages (like there are for many packages on the other page) with more detailed descriptions of each closed package ;) I would do that myself, but my free time is too limited till the end of September :( edit: Just seen you actually started from that page, sorry ;) Leaving my litte rant nonetheless ;) |
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
Yes, everything on Fremantle Closed Packages is on my list.
|
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
Added thoughts here
http://wiki.maemo.org/Porting/GPS on how to handle the GPS in the ports. The way I describe means all the programs that use GPS (including nokia-maps) will continue to work as they do now without changes. |
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
Added thoughts here
http://wiki.maemo.org/Porting/Cellular_Modem on how to handle the Cellular stack. Should enable the dialer, messaging app and other cellular bits to continue working without changes. |
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
been wondering the last few days if it is worth doing another task whilst porting.
For the n900, armel packages are obviously available and armhf drivers via MeegoCE and MER. Is it worth taking this into consideration here for the Neo900. As the process is going to involve replacing some of the remaining closed packages, it should in the future, say a maemo5.5 (can't really use 6), allow us to build entire base for armhf for a possible performance increase. |
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
This might be OT sensu stricto but it is relevant to the neo900 enterprise. Given jonwil's lists, how many part-time devs would it take to get a working fremantle on the neo900 in 6 months? I appreciate that this may be guesswork but the issue has me wondering....
|
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
Quote:
|
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
Quote:
[2013-09-14 11:31:20] <jonwil> The hardest part will be the cellular modem stuff [2013-09-14 13:37:07] <DocScrutinizer05> ((<jonwil> ... # of packages that will need stuff done...not as big. The hardest part will be the cellular modem stuff)) I'm really happy to see you are 100% in line with my own estimation regarding this :-) \o/ [2013-09-14 13:53:59] <jonwil> DocScrutinuizer05: The GPS will be the other hard part :) [2013-09-14 13:54:14] <jonwil> And a few smaller parts like MCE [2013-09-14 13:54:24] <DocScrutinizer05> yep, exactly [2013-09-14 13:55:00] <DocScrutinizer05> GPS is low prio, MCE is a MUST HAVE [2013-09-14 13:56:52] <DocScrutinizer05> IOW GPS we can make all FOSS apps work, even when switching to completely different API [2013-09-14 13:57:21] <DocScrutinizer05> (though that's not really the idea behind FP) [2013-09-14 13:59:25] <jonwil> btw it is my view that we should set the goal of doing things such that we dont need to touch telepathy-ring, rtcom-call-ui or rtcom-messaging-ui at all. [2013-09-14 13:59:41] <DocScrutinizer05> but we can jerry-build sth that kinda works, even with a thin compatibility layer above gypsy [2013-09-14 14:00:10] <DocScrutinizer05> yes, absolutely [edit] such GPS compatibility layer would make all GPS applications work - more or less - as usual, but first approach it leaves the Nokia bits broken: system status GPS icon and system menu resp settings "GPS" For GSM/modem we can worst case use a dialer from SHR based on FSO, until the csd* bits are ported. Such stuff exists for GTA04 already, working - of course zero integration into maemo, like call log, contacts, whatnot else. Likewise for GPRS data maemo already works with arbitrary internet access via e.g. USB tethering to PC. Same would of course work with arbitrary built-in modem as long as driver (from FSO) does the network access. Just maemo integration into automatic connection switching between WLAN and GPRS will again not be that simple. With csd* bits adaption this will change. from: http://mg.pov.lt/maemo-ssu-irclog/%2...09-14T14:37:07 |
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
Quote:
|
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
When it happens, I suggest6 to put a link to "legal discussion topic" in first post. After 30 pages or so, I bet you will get concerns like that from other people, or maybe even question from devs, sometime.
Also, it wouldn't leave the impression, that you're trying to "hide" some concerns from may-be-interested devs. while I agree with your argumentation and don't believe any *successful* legal threating could happen against anything related to Neo900, there is always probability of some corporate idiot getting mad ideas, and some lawyer wanting to profit on them. So, devs interested in working on this should be aware that *some* people are afraid of legal troubles (as well as your answer on those concerns). Thus, while separate thread is OK, I think putting link to it in OP (with note that this thread here is *not* place for such discussions) would be elegant think to do, to say at least. /Estel |
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
Just added some stuff related to audio and how that is going to impact this project http://wiki.maemo.org/Porting/Audio
|
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
Hi jonwil,
thank you for all your efforts. I just looked at your version of the source code for mce. Some time ago, I tried to get meego-mce version working for Fremantle, too. Some modules are working (led, display, keypad) Some parts are partly working (powerkey, even with powerkeymenu option, which was removed from meego-mce powerkey options). And some aren't working or I did not tried them (inactivity, filter-brightness.). How did you made your source version, it differs from meego-mce version, just cut away the non fremantle parts? And how did you get the source for the vibra-module (I didn't test this, yet.)? I could not find anything in meego-mce or nemos mce source (btw does anyone know if the vibra work in nemo mobile?) Can you do the same for the other missing modules, accelerometer and homekey(whereas I don't know for what homekey is good for)? |
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
Have you thought about not restricting the hardware adaptation to Neo900, but supporting N9(50) too?
There are a lot of us with Harmattan devices laying around waiting for some fun project. I personally won't buy Neo900 as I find N900 casing too bulky. But I would chip in some time to get Fremantle on N950. |
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
I cant remember anything useful about my MCE work, it was so long ago.
But I think it should be possible with a bit of reverse engineering from someone who knows what they are doing to produce a Maemo compatible MCE from the Meego code. |
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
Quote:
First to, to use APE centric audio[1] model that was used in N900 you need to implement the libcmtspeech interface[2] for the new modem. The second problem is the alsa mixers. If the used codec is not exactly the same then there is a need to emulate the necessary parts of the N900 alsa mixers and fake the rest. Other option is just to drop the old stack and use pulseaudio as it is today, but then you loose audio policy. Back porting Harmattan audio stack for Fremantle sounds like a viable, but very cumbersome option. [1] In APE (application engine) centric audio the cellular call is routed via phone operating system audio stack (in N900 case trough pulseaudio). [2] The libcmtspeech implements the interface for routing the cellular call audio to linux userspace. AFAIK the original code is opensource, but I have no idea when to find the Fremantle level sources. |
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
yeah I covered the various options in my wiki post :)
|
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
Quote:
Quote:
|
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
I don't know if this is the right place to ask, but why the resistive screen? This looks great, but that's just low tech
Like, the last thing I've seen with a resistive screen was a horrible budget android tablet at Walgreens and the Nintendo DSes, neither of I particularly want to use |
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
Neither of those have the quality of the N900 resistive screen. Even subsequent Nokia phones didn't have very good resistives. Which makes me wonder if those aftermarket ones that will be bought for Neo900 will be up to par.
|
Re: the Fremantle Porting Task Force, or "how to run maemo on Neo900"
Quote:
(capacitive touchscreens were developed in the early 70ties...) Anyway, the resistive screen on the N900 and therefore Neo900, since it is exactly the same screen that you already are holding in your hand, is way more sensitive than an iphone for example, where you have to lick your fingers everytime before you touch the screen for it to react. |
| All times are GMT. The time now is 03:15. |
vBulletin® Version 3.8.8