Fremantle porting - getting organised
 

EDIT: The work can now be followed here:

• https://maemo-leste.github.io/category/news.html https://maemo-leste.github.io/
• http://talk.maemo.org/showthread.php?t=100192

Hi!

TL;DR: Let's see if we can organise the maemo porting efforts a bit more to make
it easier for others to join and test/help-out/develop.

For some time I've been wanting to get Gentoo running on my phone, with a
mainline kernel. Now that I managed to make that work, mostly thanks to the
great work done by Pali, freemangorden and others, I realised that while a fun
target, it doesn't really help maemo a whole lot.

Others on IRC seems to think the same -- it's much better if we try to unify our
efforts move maemo forward. To make maemo live on -- after the last n900 finally
breaks (likely 20 years from now ;-).

This post aims to do just that - while there has been a lot of development
happening already recently ([1], [2]), it does seem like a good idea to
organise it a bit more, and make participation easier -- as many have indicated
that they wanted to help.

The goals right now are to take useful things from fremantle (hildon-desktop,
for example) and port them to a modern distribution, while also using the
modern/new libraries. In the current form, we're aiming for devuan (and thus
also debian, mostly), with gtk-related code being ported to gtk3.

The goal is also to get everything to work on other devices as well, so that
testing can be done on other devices than the N900:

• QEMU virtual image (perhaps we can offer a updateable devuan qcow2 image)
• Intel laptops/desktops/devices
• Cheap ARM Linux (allwinner a33?) tablets
• Development boards (like Olimex LIME boards)
• Neo900 and/or Pyra

There are a LOT of things that need to be done, and I personally also do not (by far)
oversee all that needs to be done (please reply to get things added):

• Automated builds of ported packages
• Automated deb repository where built packages go to
• Porting applications from maemo-cssu and stock repositories. (We need to
  keep a list of applications that are ported, and applications that we require
  to be ported, with some priority)
• Reverse engineering of components/packages (What ones? Link to the list or make it)
• Documentation:
  • How to join in the development(!)
  • What components do we not want to keep or port
  • What devices are known to have some sort working state, how do you set a
    device up with the ported software
  • Common porting things/problems that one might run in to
• Status: We need to keep the current status clear to prevent double work

Concluding, I think it is good if:

1) People who are interested to help out, post on this threads (perhaps also
share what you'd like to work on, or what you can work on)
2) We shape/form ideas on how we will document the process and make sure it's
doable for interested developers to join the efforts. Let's do this for a few
days and see who is interested, and then with the interested parties make some
important decisions, like where to host the documentation, and so on.
3) We figure out what our common first goals are

For now, I haven't done much programming work for this porting at all, but do
hope to do more work in the future, but we'll also need people who can do status
updates, organise lists, tasks and write documentation and keep it documentation
up to date, as well people trying to get it to work on their device.

Finally, I realise some documentation may already be out there -- please link it here, so I/we can attempt to organise it in a central place - makes it easier for others to start out.

[1] http://talk.maemo.org/showthread.php?t=91308
[2] http://talk.maemo.org/showthread.php?t=96800

Re: Fremantle porting - getting organised
 

Reserving post for documentation until moved elsewhere

• Fremantle-gtk on Github: https://github.com/fremantle-gtk3

Re: Fremantle porting - getting organised
 

So, let me start: I would like to help out!

I have a few hours per week (more in the vacation periods) that I can spend on porting, or writing documentation, and I have the following devices:

* A33 tablet with Linux 4.9 on it
* About 10 N900 phones (gathered slowly over the years)
* ARM laptops that I use all day
* Intel machines to use QEMU on, or just to test maemo on

What I can try to work on:

• Automated builds and devuan/debian repos
• Porting applications (Know C, Python, some asm, and most other languages that are relevant)
• Write documentation

Re: Fremantle porting - getting organised
 

At first, we need someone who is familiar with Devuan ecosystem ;)

Re: Fremantle porting - getting organised
 

Thanks. But why a new thread?

Re: Fremantle porting - getting organised
 

Because those 2 other threads are development related, not organizational and I share the opinion that those 2 should be separate - I'd rather not have post re debian repo setup or whatever in between the conversation on how to migrate clutter_effect_fade to clutter_animation :)

Re: Fremantle porting - getting organised
 

I know a few people who work directly on Devuan, and they've also said they'd help out, so I think that'll be fine.

I am trying to get it a bit more organised - to make it easier to people to start out, without having to read through 20 pages of forum threads. I like the forum, but it's not useful as a starters guide if you have to dig through lots of text, IMHO.

That said, my current goal is:

• Getting wifi/3d(mali) to work on my A33 tablet
• Get some experience building packages
• Try said packages on the tablet
• Work on the auto builder.

Is there anyone else interested in helping out one way or another? It helps if you post that in the thread, so we can try to find the right task for everyone.

Re: Fremantle porting - getting organised
 

OK, so wifi works on the tablet. I hope to get mali/3d to work tonight.

And I spoke to some devuan people about building packages automatically, and then creating a repository with said packages.

Seems like it'll be doable, and we'll have to create a (gitlab) repository per package, and they'll automatically build it. I need to get some more clarity on the repository generation, but it seems like they can aid us.

Re: Fremantle porting - getting organised
 

I went ahead with trying to build fremantle-gtk2 on devuan, here's the log i've written:

Re: Fremantle porting - getting organised
 

We're making good progress. There's now a debian repo online that can be added to a devuan system. Then one can 'apt-get install hildon-desktop'. After making a few extra symlinks, the system will boot directly to hildon-desktop!

Currently this works on amd64.

There are automated builds set up for amd64 with jenkins, and armel and armhf will follow soon.

We'll need a bit more time to clean up the current state, add more features, but then we should be able to put it out there and ask people for help and contributions.

Re: Fremantle porting - getting organised
 

i wonder if Maemo Council can help in any way?

Re: Fremantle porting - getting organised
 

Please please please ...
No matter what...
make sure there is a good noob friendly walk through ..
a foolproof idiot's guide..
a video tutorial ...
whatever...it takes.
for those who just know how to turn the "power button" on...
but want to learn more...

it will in the end pay off with increased numbers... of individuals joining the community...more people testing...more people helping...
well ...you get the domino effect from the result...

Re: Fremantle porting - getting organised
 

They are. They are providing (some) infra.

I think that will happen - but right now we need a few more weeks to get things in a better shape first. Then we'll make a detailed post/announcement and ask for help too. :)

Re: Fremantle porting - getting organised
 

I'm kind of lost with all the Fremantle revival and porting threads these days.
What exactly is the aim of this project?

• Do you guys want to run Fremantle on other devices?
• Are you porting hildon-desktop to run on other OSes?
• Or are you guys upgrading the N900 to a newer kernel?

All of these have been mentioned before and attempted with some results, so I'm not sure which one is it this time. And what's the current status?

Just out of curiosity.

Re: Fremantle porting - getting organised
 

I suppose it's a mix of first and second, since hildon-desktop and other Fremantle packages are ported to Devuan, which then can run on other devices. Check this post for status.

Re: Fremantle porting - getting organised
 

The idea is to take as much as we can from fremantle. And then make that run on a modern 'base'. In this case: devuan/debian.

That means that you should be able to run this devuan/debian on your N900 and then install the stuff ported over from fremantle. That likely will also mean we can start using a mainline kernel.

But the N900 is not the only target device. Also arm tablet(s), the arm droid4 phone, and perhaps even intel tablets of some kind.

Makes sense?

Re: Fremantle porting - getting organised
 

Yes, it makes perfect sense! Thank you!
Do you guys also plan to switch to Wayland instead of X11?

Re: Fremantle porting - getting organised
 

That will require reworking libHildon and hildon-desktop. At the moment xatom iirc is used to signal the window manager to correctly render menus. That's just for starters.

Window stacks need looking at, especially if going after stock GTK support

Re: Fremantle porting - getting organised
 

Is libhildon even necessary? I thought a lot of what it does is now available in Gtk3.

Re: Fremantle porting - getting organised
 

Depends on compatibility. If you want to be able to port existing apps with little amount of changes, you need a patched GTK3. If you want to stick to vanilla/stock GTK3, libhildon shrinks making it easier to maintain but existing apps need more porting or for compatibility you could add some wrappers or defines.
HildonStackedWindow is part of libHildon. AFAIK there is no equivalent class in GTK3. Closest I've found is GtkStack but as noted elsewhere it's not complete solution to the issue. Aside from some errors encountered popping items incorrectly setting top (pop twice, top is now 0 regardless of items unless now fixed) which I solved by keeping a separate list, the is the issue of the window manager close/back icon.

Re: Fremantle porting - getting organised
 

Do you plan to keep hildon-desktop (making it Wayland compositor) or move to something else? The problem is that Weston, while being a reference compositor, is more like a Wayland demo and not very useful, while desktop environments like GNOME/KDE have their own compositors (Mutter/KWin). There are also some other compositors which could be used as base, such as sway (they also implement WIP library - https://github.com/SirCmpwn/wlroots) or lipstick (UI is written in QML, used in SailfishOS/Nemo Mobile).

Re: Fremantle porting - getting organised
 

At the moment I'm just trying out ideas. I did think about extending the Weston desktop shell. I have also looked at how budgie was interacting with mutter. As mentioned elsewhere I think the easiest option at the moment is to use fmg's Fremantle-GTK2 and create a GTK3 library to enable some preliminary transition work, with just enough content to make apps fit in. Long term a decision/opinion of community would determine Wayland path. I'm just providing results of experiments at the moment.

Re: Fremantle porting - getting organised
 

Initial announcement of the pre-alpha images can be found here: http://talk.maemo.org/showthread.php?t=100192

Re: Fremantle porting - getting organised
 

What's your vision of browser support on the ported Fremantle? microb is unusably outdated and closed-source.

Re: Fremantle porting - getting organised
 

As it is a debian based system, you should be able to run all current opensource browsers.

E.g.
Chromium & Firefox, which may be to much for the little RAM
but also Dillo, Konqueror and others which will allow you to access current websites.

Re: Fremantle porting - getting organised
 

I have some Serial UART IC could this be used for the N900 kernel development?
When this will do the job I have a spare one and would give it to someone of the fremantle porting team for free or somebody else if he is willing to do kernel development for the N900.

Re: Fremantle porting - getting organised
 

I could do the same on the N900. The main problem was that the UI was unusable. Many application can be used without UI rewrite. A browser app is not one of them, at least not the ones I tried on N900.

Re: Fremantle porting - getting organised
 

Did not give a lot of thought, but enough to realise that it might indeed be a problem.

One idea is to use a custom version of surf [1] and ensure that scrolling and such works the way we want it to.

Another option is to do some crazy fudge on the touchscreen input and emulate both right click and scroll. (Hold <1s; left click, hold <2s; right; hold <3; enter "scroll mode")

We'll have to see how it's done in osso-xterm and the older browser, I guess. Probably someone already knows.

[1] https://surf.suckless.org/

Re: Fremantle porting - getting organised
 

Might be useful - not for me personally, kernel is stable enough I don't need a serial to test small changes. But maybe for someone else it might be. See also: http://n900.elektranox.org/serial-adapter.html

Re: Fremantle porting - getting organised
 

The problem is that modern websites use features that require a web browser of memory usage that exceeds the 256MB of RAM of the N900. Your choices here are simple:

• Use a modern web browser which doesn't support JavaScript (Dillo, Lynx, etc.) and accept that many websites won't work.
• Continue to use MicroB which has no HTML5 support, old ECMAScript support, old Flash support and accept that many websites won't work.
• Use a modern lightweight browser from Devuan like Midori or Surf which is more feature complete than MicroB and accept that it will run slowly on the N900. Nevertheless it is way more useable than Firefox or Chromium.
• Run Firefox or Chromium on a server and connect to that from your N900 via VNC.
• Forget about your N900 and run Maemo Leste on a device with more RAM.

Don't think you are ever going to get anything better on the N900.

Re: Fremantle porting - getting organised
 

Yes, indeed. I much doubt anyone hopes to have 'perfect' browsing on N900. But slow might be tolerable, depending on individual use/needs

Re: Fremantle porting - getting organised
 

One side note is that "zram" might help a little: https://www.kernel.org/doc/Documenta...ckdev/zram.txt

Might get us to 400-500MB:

There is little point creating a zram of greater than twice the size of memory
since we expect a 2:1 compression ratio. Note that zram uses about 0.1% of the
size of the disk when not in use so a huge zram is wasteful.

Re: Fremantle porting - getting organised
 

Firefox wise, they have dropped GTK2 so without maintaining a fork of browser related code (Firefox/embedlite and gtkmozembed)) a Microb inspired browser is out.

Re: Fremantle porting - getting organised
 

But isn't there gtk3 mozembed and qt5 mozembed?

Re: Fremantle porting - getting organised
 

Ok, perhaps a very stupid question (?): Why can we not replace the ram with a sufficient big swap partition?

Why can we not use WebKit?

Re: Fremantle porting - getting organised
 

For your first question (honest questions are never stupid!):

Ram is built into devices for a reason, it has advantages over normal storage:
(Near) infinite reads and writes
Very fast reads and writes (orders of magnitude!)
But it looses its data when turned of.
So you use it to

1. store data which will be written to disk
2. data you only need to operate your running programs
3. data which you read so often you want to save time by storing it in RAM, where reads are much faster.

If you add swap, you tell the system to handle a bit of normal storage like ram. Obviously its fully useless for 1 and 3, because your swap is already a slow as the disk. This leaves us with usage 2. But your software expects RAM to be fast, so it changes its contents all the time. Every time something changes in your software your RAM content changes. And many things change, when, for example, your scroll a webpage.

The operation system now tries to work around this.
See that tab he has in background for 5 minutes? We can probably move it to swap, it won't change soon and the user can wait a few sec, when he activates it again. If he does, we move it to RAM and seek another inactive tab to move to swap.

This works somewhat well, till you are at a point where the fast changing contents alone use all your RAM. As modern browsers expect much RAM (and need it to render many of todays huge websites) They have big areas of RAM where contents change often.

Now these will spread to swap and things get really slow. Your firefox expects that RAM read and write to be done in 1 ms, but now its writing to swap on disk and takes 1s instead. It will still work, but the user will grow a beard till the webpage is rendered.

Re: Fremantle porting - getting organised
 

Personally, I prefer Gecko. But I am biased, because I like how XUL-based interface allows extensions to directly change web browser's look and behaviour.

WebKit has big corporations such as Google (Chrome) [granted, Google has since switched to Blink instead of WebKit], Apple (Safari), Microsoft (Entourage), Blackberry (Browser since 6.0) and Opera (uses Blink aka Google's derivative of WebKit) interested in the engine, its development, and monopolisation of market share.

Granted, there is a very fascinating project about porting WebKit to Gtk+ https://webkitgtk.org/ and an existing BSD-licensed mobile web browser based on WebKit https://en.wikipedia.org/wiki/Nokia_Browser_for_Symbian . Midori is fascinating as well.

In my personal opinion, applications running on Maemo operating system should depend only on Hildon widget toolkit, not on raw Gtk+ (just look at Navit, tiny menus are difficult to navigate), or Qt (even though it tries very hard to look like Hildon), if only for the sake of consistent behaviour (and lower memory usage - no need to have libraries for many widget toolkits around).

At the same time, web browser should have front end (GUI) entirely separate from backend (rendering engine) which means that switching between Gecko, WebKit, NetSurf, or Blink may be possible. And make porting to different desktop environments less painful.

And I would go far enough to say that apps should be interconnected to the point that web browser, instead of trying to open a Youtube page just like any other page, would allow the video to be opened by Media Player (with Youtube plug-in), thus entirely disregarding advertisements, Javascripts and other problems associated with trying to open Youtube in a web browser. But that's only possible if a third party writes suitable extension for web browser.

Whichever way you go, do take into account that there is a variety of open-source engines available, and my criteria for choosing the best one would be: 1) light weight by itself; 2) capable of dealing with heavy weight websites when RAM is tiny, memory is limited, network is slow, and CPU isn't fast either; 3) capable of rendering HTML 5 and passing ACID tests.

Thank you. Best regards.
~~~~~~~~~~~~~~~~~
Per aspera ad astra...