Closed Bug 731498 (b2g-on-linux) Opened 12 years ago Closed 6 years ago

Make b2g work on minimal ubuntu/debian linux image

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: romaxa, Assigned: romaxa)

References

Details

Attachments

(7 files, 6 obsolete files)

2.91 KB, patch
ted
: review+
Details | Diff | Splinter Review
896 bytes, patch
Details | Diff | Splinter Review
2.19 KB, patch
Details | Diff | Splinter Review
17.07 KB, patch
karlt
: review+
Details | Diff | Splinter Review
52.35 KB, patch
Details | Diff | Splinter Review
13.82 KB, patch
Details | Diff | Splinter Review
886 bytes, patch
glandium
: review+
Details | Diff | Splinter Review
Attached patch Plain linux b2g port (obsolete) — Splinter Review
I think it would be nice to make b2g working on plain linux without X, without toolkits, just base debian/ubuntu rootstock image + rendering to framebuffer

Here is the simple patch with is partially cloning android port and make it works on beagle board ubuntu image like this one:
http://elinux.org/BeagleBoardUbuntu
http://rcn-ee.net/deb/rootfs/oneiric/ubuntu-11.10-r5-minimal-armel.tar.xz

I called this port as honk, not sure if this proper name, but made it just to make simple rename from gonk port ;)

I think this port would work also on panda board. and similar
Attachment #601502 - Flags: feedback?(jones.chris.g)
Attachment #601502 - Flags: feedback?(mwu)
Interesting.

Is fontconfig available so you don't have to hardcode a fonts list?

Could EGL work?
fontconfig available
EGL works just perfect
http://elinux.org/BeagleBoardUbuntu#SGX_Video_Acceleration
Depends on: 746913
Depends on: 754506
Blocks: 760442
Attachment #601502 - Flags: feedback?(mwu)
Attached patch LinuxGL port basic version (obsolete) — Splinter Review
Here is the basic configuration + build for LinuxGL widget backend.
it does not have X11 hooks no input events handling and no fonts ajustements
Attachment #601502 - Attachment is obsolete: true
Attachment #601502 - Flags: feedback?(jones.chris.g)
Attachment #650885 - Flags: feedback?(jones.chris.g)
this patch make fonts backend working exactly same way as on android.
I have more detailed patch queue with basic config, fonts, X11 hooks, simple input event reader (detects with udev) and raspberry pi eglNativeWindow implementation in more detailed patch queue:
http://hg.mozilla.org/users/romaxa_gmail.com/embedipc_queue/file/linuxglpure/linuxgl

What would be a best strategy to review it and land it?
I can push each patch separately as well... but want to make sure that general idea looks ok for now
Attached patch Configure.Part1Splinter Review
LinuxGL configure part
Attachment #650885 - Attachment is obsolete: true
Attachment #650887 - Attachment is obsolete: true
Attachment #650885 - Flags: feedback?(jones.chris.g)
Attachment #655416 - Flags: review?(ted.mielczarek)
Initialize libevent loop for linuxGL port
Assignee: nobody → romaxa
Status: NEW → ASSIGNED
Attachment #655418 - Flags: review?(jones.chris.g)
Fix ipc plugins build with LinuxGL
Attachment #655419 - Flags: review?(jones.chris.g)
Basic copy+rename of Android platform
Attachment #655420 - Flags: review?(karlt)
Copy+Rename version of gonk->LinuxGL
Fixed running on HW single buffer framebuffer, using temporary Image surface
Removed all gonk input dispatcher code (evdev version will be added)
Attachment #655421 - Flags: feedback?(jones.chris.g)
I know this is not TRUE way to go, but at least this path is more less supported because it is in use by android builds and actually works
Attachment #655503 - Flags: review?(jfkthame)
Attachment #655420 - Flags: review?(karlt) → review+
Summary: Make b2g work on beagleboard ubuntu rootstock image → Make b2g work on minimal ubuntu/debian linux image
Attachment #656136 - Flags: review?(mh+mozilla)
Attachment #656136 - Flags: review?(mh+mozilla) → review+
(In reply to Oleg Romashin (:romaxa) from comment #11)
> Created attachment 656136 [details] [diff] [review]
> Link libxul with fontconfig libraries, part6

Oleg, do we have a working process to go from nothing to B2G running on a Linux image yet? I'm interested to try this out on a few things (panda, pi, Chromebox). If you could add them here, or send them to me via email, I'll work with the documentation team to get them on MDN.

Let me know if I'm jumping the gun and there aren't enough pieces yet to get everything working.

Rob
Comment on attachment 655416 [details] [diff] [review]
Configure.Part1

Review of attachment 655416 [details] [diff] [review]:
-----------------------------------------------------------------

::: configure.in
@@ +4392,5 @@
>          -o "$_DEFAULT_TOOLKIT" = "cairo-cocoa" \
>          -o "$_DEFAULT_TOOLKIT" = "cairo-uikit" \
>          -o "$_DEFAULT_TOOLKIT" = "cairo-android" \
> +        -o "$_DEFAULT_TOOLKIT" = "cairo-gonk" \
> +        -o "$_DEFAULT_TOOLKIT" = "cairo-linuxgl"

Do you think you could change this into a case block? This got ridiculous a while ago.

@@ +4521,5 @@
> +cairo-linuxgl)
> +    AC_DEFINE(MOZ_WIDGET_LINUXGL)
> +    AC_DEFINE(MOZ_TOUCH)
> +    MOZ_WIDGET_TOOLKIT=linuxgl
> +    MOZ_WEBGL=1

You might want to consider adding some extra checks around the --disable-webgl option, since your toolkit will not build in that configuration. Perhaps add a new variable, MOZ_WEBGL_REQUIRED, and if that's set, and --disable-webgl is specified, error out in configure.
Attachment #655416 - Flags: review?(ted.mielczarek) → review+
> > +    MOZ_WEBGL=1
> 
> You might want to consider adding some extra checks around the
> --disable-webgl option, since your toolkit will not build in that
> configuration. Perhaps add a new variable, MOZ_WEBGL_REQUIRED, and if that's
> set, and --disable-webgl is specified, error out in configure.

hmm, it compiles fine with disable-webgl option and works too, same as any other toolkit
I'll interested in running Firefox OS on uClinux, running with mdev and a very minimal tool/library set. Is that realistic? AFAIK the PandaBoard and Raspberry Pi run ordinary linux, right?
> very minimal tool/library set. Is that realistic? AFAIK the PandaBoard and
> Raspberry Pi run ordinary linux, right?

Panda board has port of android-base b2g, but this port also work on ordinary linux for panda
Comment on attachment 655421 [details] [diff] [review]
LinuxGL Widget Part5

Idea of this widget implementation is to provide basic rendering without any native toolkit dependencies, and allow to run it on Linux with minimal framework stack.
b2g - base implementation very good for it, because it has minimum dependency on external libraries.
it would be also useful to add basic implementation for:
1) evdev - events reader key/mouse/touch, could be implemented as external component/extension or in subdir of linuxgl widget.
2) X11 wrapper for OpenGL window surface, because some Linux platforms have only X11 DRI support.
All extra API's implementations such like phone/bluetooth, sensors et.c would be also keep up to OEM's implementation (if such).
Attachment #695923 - Flags: feedback+
Attachment #695924 - Flags: feedback+
couple of comments:
1) seems you've attached 2 patches and they are the same
2) don't set feedback or r+ on yours patches... you supposed to request it from someone.
3)

+   //PRABU TTC - In LinuxGL (EGL nonX11) widget, always need to be fullscreen only

        ^ space here, also don't set name and other things... it should be like TODO, FIXME... or just comment like in this case.
instead of resizing to full screen bounds I guess we should fix fullscreen implementation and setup in shell.xul fullscreen size.. it even has some options for that
http://mxr.mozilla.org/mozilla-central/source/b2g/chrome/content/shell.xul#9 - platform specific
http://mxr.mozilla.org/mozilla-central/source/b2g/chrome/content/screen.js#80 - runtime options
Sorry, attached correct patch for accessibility configure check.
Attachment #695923 - Attachment is obsolete: true
For the fullscreen runtime setup, I already tried passing --screen=full to b2g (./b2g --screen=full) and it does not take effect. Will investigate further.
(In reply to prabindh from comment #22)
> Created attachment 695950 [details] [diff] [review]
> Patch to check for accessibility in configure

Thanks for your patch. Accessibility support is required not only for linuxgl, but for b2g as a whole. To keep this bug focused, please open a new bug report in the B2G:General category with a patch to add a configure error if accessibility is not enabled when building b2g. There you can set review? to ted@mielczarek.org. Thanks!
Oleg, care to check if these patches need a rebase, please? AFAIU, you use these patches for FxOS on RPi – do they work with the latest trunk? 

I see a few r+ but no checkin, I assume it's because no one ever set checkin-needed – that's a bummer. Do all patches work on their own, or how's the dependancy of the patches? We might want to split off some parts into different bugs to allow for a better overview and faster checkin.

Are there any tests that need to be written to ensure this doesn't break? 

Let's get this into the tree.
Flags: needinfo?(romaxa)
Flags: needinfo?(imphil)
Comment on attachment 695924 [details] [diff] [review]
Enable always fullscreen rendering in linuxgl

Please create a new Bug for this patch marked as depending on this bug.

(You cannot set feedback+ on your own patches, that just doesn't make sense. ;) )
Attachment #695924 - Flags: feedback+
Flags: needinfo?(prabu)
Attachment #695924 - Attachment is obsolete: true
Comment on attachment 695950 [details] [diff] [review]
Patch to check for accessibility in configure

New bug as well, please. Make sure you don't change the newline in the last line of the file.
Attachment #695950 - Attachment is obsolete: true
(In reply to Florian Bender from comment #25)
> Oleg, care to check if these patches need a rebase, please? AFAIU, you use
> these patches for FxOS on RPi – do they work with the latest trunk? 

In theory the should, but in practice someone has to take this approach and apply all changes to the latest tree, and try to compile it.
Most important is to split gonk widget implementation into parts which can be shared with linuxGL implementation.

> 
> I see a few r+ but no checkin, I assume it's because no one ever set
> checkin-needed – that's a bummer. Do all patches work on their own, or how's
> the dependancy of the patches? We might want to split off some parts into

No this patch queue is dependent and providing simple feature to build gecko with minimum dependencies (no toolkit). so these patches should be landed all at once.

> different bugs to allow for a better overview and faster checkin.
> Are there any tests that need to be written to ensure this doesn't break? 

Not sure if you can get any of this tested properly without tinderbox configuration which would build this backend and run tests on it.

> Let's get this into the tree.
Flags: needinfo?(romaxa)
(In reply to Florian Bender from comment #25)
> Let's get this into the tree.

This is still a lot of work. Rebased patches as of September 2013 are in my patch queue at http://www.philipp-wagner.com/hg/mc-b2g-patches/. You can also find all necessary steps to build that stuff in some of my blog posts at http://philipp-wagner.com. Unfortunately, I never found time to clean it all up and get it ready for inclusion. If you want to do that work, it's best to take the patches from my hg repository, rebase it to the current mozilla-central, and then split it and clean it up for inclusion. But be aware, this will be still quite some work.
Flags: needinfo?(imphil)
(In reply to Florian Bender from comment #27)
> Comment on attachment 695950 [details] [diff] [review]
> Patch to check for accessibility in configure
> 
> New bug as well, please. Make sure you don't change the newline in the last
> line of the file.

This is already upstream - via https://bugzilla.mozilla.org/show_bug.cgi?id=824927
Flags: needinfo?(prabu)
(In reply to Oleg Romashin (:romaxa) from comment #28)
> Most important is to split gonk widget implementation into parts which can
> be shared with linuxGL implementation.

Can/Should this be covered by a follow up bug? If so, please file a new bug.

> Not sure if you can get any of this tested properly without tinderbox
> configuration which would build this backend and run tests on it.

Can you provide the tinderbox configurations?
(In reply to Philipp Wagner [:imphil] from comment #29)
> Unfortunately, I never found time to clean it all up and get it ready 
> for inclusion. 

Since you have the overview, would be nice if you could at least provide patches for the current "unclean" work and attach them here for someone else who wants to work on it. Thanks!
(In reply to Florian Bender from comment #32)
> (In reply to Philipp Wagner [:imphil] from comment #29)
> > Unfortunately, I never found time to clean it all up and get it ready 
> > for inclusion. 
> 
> Since you have the overview, would be nice if you could at least provide
> patches for the current "unclean" work and attach them here for someone else
> who wants to work on it. Thanks!

See comment #29, it's all in http://www.philipp-wagner.com/hg/mc-b2g-patches/

Maybe it would help to break this work up into smaller pieces that people could work on?
(In reply to Dietrich Ayala (:dietrich) from comment #33)
> See comment #29, it's all in http://www.philipp-wagner.com/hg/mc-b2g-patches/

Sorry, I was unclear. I meant: Adding patches here to the bug, not just a remote repo that may or may not go away any time.

> Maybe it would help to break this work up into smaller pieces that people
> could work on?

Definitely! Though: 

(In reply to Oleg Romashin (:romaxa) from comment #28)
> No this patch queue is dependent and providing simple feature to build gecko
> with minimum dependencies (no toolkit). so these patches should be landed
> all at once.

If there is anything that can be handled in a separate bug, please file!
Comment on attachment 655418 [details] [diff] [review]
Chromium MessagePump. Part2

Sorry, I'm declaring review bankruptcy.  I don't have an opinion on these patches on their own merit.  If someone else wants to review them and land them, that's fine with me.  For the bigger-picture project of bringing up FFOS on embedded systems like Raspberry Pi and Beaglebone Black, my experience tells me that it's a much easier prospect to stand up a "stock" FFOS based on an android port for those devices.  As much as I personally dislike android, when you start looking to enable the full complement of FFOS features, the amount of work required to do a full platform port to an unsupported, custom-assembled OS is pretty staggering.  If you're just looking to run FFOS "within" a distro like Raspbian, not "on its own" as the device OS, my opinion is that targeting common and supported APIs like Wayland, gstreamer etc is the way to go.

But I've held this up long enough, however it turns out, time to step aside.
Attachment #655418 - Flags: review?(cjones.bugs)
Hi Folks, I'M gonna try to port firefox os to the OLPC XO 1.0 and 1.5 that have my students, i read all the messages but I get a bit confused, and saw that the links are for arm based architecture, the XO 1.75 have this but I don't have one in the classroom, also I hace a Gentoo image but for the students to start making and have a working environment it's a more complicated road, can someone give me some tips and clues to get this in some way done? 3 months to the end of the course and want to have this in the more advanced state that we can go, thank you.
Alias: b2g-on-linux
Firefox OS is not being worked on
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Attachment #655503 - Flags: review?(jfkthame)
You need to log in before you can comment on or make changes to this bug.