"open" isn't an end in itself. It's a means to an end, to facilitate fixing bugs and adding new functions (and yes, sometimes to address educational purposes, though for that you very rarely do reverse-engineer stuff).
Replacing anything by an "open" equivalent just for the "we did it" is forcing unjustified workload and risk on those who have to maintain and use stuff. Same applies for extensions that nobody really needs, basically.
Making a replacement available so, when needed, it can receive useful patching and then replaces the closed original in the productive release is quite another goal that's pretty welcome. But keep in mind that the productive release is not a stage for such unsolicited RE work, maintainers are supposed to keep productive releases as safe as possible. I'm mentioning this with CSSU in mind. Stage for RE versions would be CSSU-devel maybe, but not CSSU-Testing/Stable, unless we need some change to fix issues. In MCE there's more than one issue to fix, so we're happy to have the means now to actually do those bugfixes and improvements.
Yet another topic is portability (read: fremantle porting), where we might need to patch otherwise perfectly working closed blobs. Think `audio´. It's not exactly simple to answer if and when such changes/patches should propagate back to the original stable productive release.

cheers
jOERG

see
http://talk.maemo.org/showthread.php...08#post1408808
http://talk.maemo.org/showthread.php...10#post1408810
http://talk.maemo.org/showthread.php...33#post1408933 + next 4

and the idea is to keep 100% backward compatibility with original MCE/lp5523-kerneldriver. Not even gconf involved ;-)
[on a sidenote I have to confess it so far evaded my mind why some systems use gconf while others don't. MCE uses dbus which seems a sufficient precondition to qualify for gconf, yet MCE is using a plain config file. Then OTOH MCE is needed pretty early in system init Other systems use both config files AND gconf .oO(???)]

@joerg_rw - I'd rather wait until there is a MR on gitorious before digging deeper into that

Missed that one (in devel) - I was using shaw's patched version. Until now I was perfectly sure, that those are two same ones - that's why I got surprised you were not sure if it's going to get merged. Now I see that shaw's work is separate, so of course I applaud call for creating MG from shaw's side

Let me see about implementing keyboard fade (without lysti engine 3) and then I'll do a merge request. Adding the fade back in should maintain existing functionality...

We can't forget mce.. Any news?

http://talk.maemo.org/showpost.php?p...&postcount=313

Now that I am getting back into reverse engineering again, I want to ask if there are any cases known where the functionality of open-MCE (as reverse engineered by me and originally posted) differs from stock MCE and whether that means there are things I should re-reverse-engineer...

I am using REed mce since I pushed it in cssu-devel, don't see any difference.

I've been using it as well, for months (with 3 engine mods for LED) and don't notice anything amiss.