The Fremantle release contains many open components that were closed (or their equivalents) in Diablo. But no new components are planned to be opened in Diablo because of the Fremantle.

To make things easy and operative, we will listen the Mer project since they have a clear goal and have shown commitment and certain developer power to achieve it. Stskeeps & co, can you share the top 3 closed Diablo components that you would find useful to have access to the code? 3 at most, and we can look at new cases as soon as current cases are solved or well on its way.

I am confused by two things. Can you answer them please?

First, you say no Diablo components are planned to be opened, and then you ask for 3 closed Diablo components useful to Mer. Since Mer is an open project, this seems inconsistent.

Second, why is Fremantle the reason you don't want to open Diablo components? Diablo is EOL, dropped in lieu of Fremantle. Aren't Diablo components less commercially viable to Nokia than Fremantle components?

Thanks.

extended use of maemo4 over maemo5/mer equals slower move over to maemo5 as a platform.

I said, or wanted to say, that no Diablo components will be opened because of Fremantle. They may be opened because of Diablo community editions, Mer or whatever other good reasons you find.

Opening components takes time. Sometimes a lot of time. This is the main reason for being conservative.

IMO, the obvious 3 would be GPS, BME, and (now) GLES... everything else can be replaced, but those 3 are essential.

OK, so - this is my current list for N8x0. It is the top 3 things that constantly annoy a bit when dealing with these devices on a technical level.

1) Going through with https://bugs.maemo.org/show_bug.cgi?id=4874 - documentation of the CAL area.

Community has shown that it can make it's own libcal implementation and asks to have documentation to avoid breaking things. We constantly run into libcal issues when building lower level system software such as DSME and others and we would like access to write why the system lifeguard rebooted for instance without risking breaking things. Having proper information on how to read and write safely to the area is key, the deeper specifics of each element less so.

2) Open sourcing retutime - it is a major component in sense of dealing with RTC on the device and alarms and it would be good to have this tiny but important binary opened.

3) Not so much open sourcing.. but some way to get patches into gpsdriver and released a fixed binary containing fixes for:

* Requirement that user is /home/user
* Serial line handling by gpsdriver that breaks under recent kernels (there was a thread somewhere on it) - this causes issues with getting on to later kernels.

This is what bothers on a very low level regarding this specific hardware.

The rest (using binaries) I hope, in time, would be covered through http://wiki.maemo.org/Token_based_access_restriction which is getting implemented on maemo.org this month to be able to demonstrate.

This is my own list and what bothers me as maintainer of the HW repo for N8x0 for Mer. - I would like to hear what the community SSU people say as well.

Thanks. Community SSU is currently considering

https://bugs.maemo.org/show_bug.cgi?id=3199

and various other UI elements

Again, all that UI stuff can be easily replaced. Even CAL can be ignored/replaced if necessary in the end. Hardware support cannot be easily replaced without a LOT more work reverse engineering, documenting, and reimplementation.

I guess everything that prevents other OS (Android or Ubuntu) on the legacy devices has to be opened. I guess it's sound, GPS and such things.

Also I would be happy if someone could backport the N900 browser to my N810.

(N810) sound has been part of Linux-OMAP for a while at least. AFAIK, the only hardware left is GPS, BME, and GLES.