Silk GUI

[zodern]

I have started making a GUI in javascript named Silk. You can find the github repository here.

4 main goals:

• Fast and Lightweight
• Designed with developers in mind
• Experiment with new ideas for GUI's
• Client (window manager) can be accessed remotely

  What is Completed

I duplicated Meteor.methods since they make it very for the client and server to communicate.

The basics of window management are done. It is possible to open and minimize windows. It applies the correct z-index to windows.

It is possible to remotely access Silk by going to the url shown in the terminal.

Plans

The first version will have a very simple text editor and file explorer.

There is no security to prevent anyone from remotely accessing the computer, which needs to be fixed. We could look at logon.

Right now the window manager uses iframes to show the apps. Some websites don't allow themselves to display in iframes, including google.com, jw.org and github.com. If the expo browser is used in node os, maybe the window manager could create exoframes (I think that is what they are called) for each app.

To try it, past these commands into your terminal.

npm i -g silk-gui cd silk npm start

Screen Shots

Loading Screen

Desktop

Taskbar Hover

Notice that the taskbar background becomes solid on hover.

Current State of File Explorer

If you have a suggestion or idea, feel free to create an issue

[piranna]

I've open two issues on node-webgl and its dependence node-glfw to add support for EGL, since its underlying library glfw now support it. @netlovers, could you be able to take a look about making it to work? If so, then it would be trivial to have NodeOS as a game platform... :-D

Also, I've found one of the forks of node-webgl focused on headless rendering to be used for example for gpgpu, so it would be interesting to take it in account... :-)

[ghost]

Hmm, I'm not so sure about NodeOS being a gaming platform first... :D Anyway all of the three packages seem to depend on OpenGL which we talked about that we don't need it. But we'll see.

Yesterday I tried to build Ozone-GBM (which is actually Ozone-Dri, so I had to check a bunch of sources to see if they are really the same or not). The building of content_shell was successful, but I could only use the test platform which saves an image, but has no actual display. Then I found this Chromium-OzoneGBM. This is quite new, so maybe, just maybe this is the missing part. But Chrome builds for quite some time, so I couldn't yet check if it works.

[piranna]

Hmm, I'm not so sure about NodeOS being a gaming platform first... :D

Ey, would be cool to have some games on NPM... :-P

p> Anyway all of the three packages seem to depend on OpenGL which we talked about that we don't need it. But we'll see.

Yes, but since glfw has experimental support for EGL, maybe this is not mandatory anymore... :-)

Yesterday I tried to build Ozone-GBM (which is actually Ozone-Dri, so I had to check a bunch of sources to see if they are really the same or not). The building of content_shell was successful, but I could only use the test platform which saves an image, but has no actual display. Then I found this Chromium-OzoneGBM. This is quite new, so maybe, just maybe this is the missing part. But Chrome builds for quite some time, so I couldn't yet check if it works.

That's awesome! :-D

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix." – Linus Tordvals, creador del sistema operativo Linux

[ghost]

It took me a while, but here is some new information: 1) I was able to successfully build Chrome content_shell. 2) It runs only in 800x600 mode, although I think it is possible to change that somewhere. 3) It loads the Google home page, and I don't know how to change that, yet. 4) If I kill the process and try to run it again only black screen shows up. I have to restart the virtual machine to get it to work again, and I'm not sure what is the cause. 5) There is an invisible (but working) mouse pointer, and I was able to search for things, so keyboard works as well. 6) Only one content_shell can run, and it is full screen. How would apps work? Every app would be inside its own iframe? I think iframes won't run in separate threads. 7) Youtube videos work, but no sound because of missing drivers. Proof

[formula1]

4)

That is really interesting. I'm wondering if it tries to remember its last state.

6)

This is somewhat relevent. Its obvious chromium has desire to put iframes into their own threads but have not implemented it yet. It may be a personal preference but making the window manager editable as if it was html feels as important as the individual applications.

The following would need to get done at somepoint

• Override <a target='__blank'></a> to instruct the top window to open a new frame
• Override window.open() to instruct the closest manager to give a new frame and return it the windows context.

In some ways, it doesn't matter how it happens, just so long as it can be overwritten. And it can be from userscripts, better yet within javascript.

[piranna]

1) I was able to successfully build Chrome content_shell.

Code or didn't happen! (aka. Awesome! :-D)

2) It runs only in 800x600 mode, although I think it is possible to change that somewhere.

That could be an issue of the graphic driver or the CEF demo app, definitely it should be possible to use a higher resolution, and maybe also change it dinamically :-) Main problem would be with Retina displays, but let's do one step at a time :-)

3) It loads the Google home page, and I don't know how to change that, yet.

I think it was hardcoded on the CEF demo app, but there should be some command line parameter.

What would be the desired default behabiour? Load google.com as it's now? Load about:blank? Read the url from a config file? Exit with error if no command line parameter is given?

4) If I kill the process and try to run it again only black screen shows up. I have to restart the virtual machine to get it to work again, and I'm not sure what is the cause.

Since it gets fixed after the virtual machine is restarted, it seems to me is some kind of problem with the initialization of EGL. As @formula1 said, seems it's not stateless.

5) There is an invisible (but working) mouse pointer, and I was able to search for things, so keyboard works as well.

When no mouse pointers are installed, X11 show a big cross instead, but don't know what EGL does. Maybe is just a matter of installing a set of mouse pointer icons...

6) Only one content_shell can run, and it is full screen.

That's ok, and in fact the intended behaviour.

How would apps work? Every app would be inside its own iframe? I think iframes won't run in separate threads.

We have here two use cases:

• single full-screen apps (kiosk mode-like)
• desktop manager (that in fact, is a single full-screen app itself :-) )

For single full-screen apps, I would start the backend server and later from command line start CEF giving it the URL of the app GUI:

> cd tetris
> forever start ./server
GUI served at http://localhost:1234
> cef http://localhost:1234

or maybe also cef would be started automatically by the application itself. Desktop manager would an application itself, only that it host some iframes to show other applications. This can be full client-side Javascript, and also would to override window.open() to open new iframes instead of new content_shells, I think should be trivial.

7) Youtube videos work, but no sound because of missing drivers.

Sound drivers in NodeOS will be compiled in kernel, if you were using Ubuntu Core or other kernel probably they were compiled as modules and not loaded, or if so, maybe sound was muted on AlsaMixer. Definitely, the next step ;-)

Proof

Why the horizontal scrollbar? Maybe the EGL surface was smaller than the CEF drawing area (screen size vs. window size)?

P.D.: great work ;-)

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix." – Linus Tordvals, creador del sistema operativo Linux

[ghost]

Umm, this is not CEF but Chrome Content Shell. 2) The 800x600 is hardcoded somewhere (search for "800" here)

3) The desired behavior would be to load the desktop manager (so basically a local html file) itself.

6) For the server I think a global (multi process) server is the solution, and not one server for every app. The iframe solution has a big problem, the apps would be able to connect to each other (window.parent), and because it runs in a single process, if one app dies, everything dies. And there is a problem with the window.open() because no new content_shells open (at least by default). So right now pop-up windows don't work, and there are no alert windows nor context menus either.

The horizontal scrollbar is there because the Google homepage is not responsive.

I'm not yet sure how any of this can be solved. Maybe we should check out the Crosswalk-project because it seems like that they solved some of these problems.

If someone wants to play with it, here is what I did: 1) I followed these instructions: https://github.com/kalyankondapally/Chromium-OzoneGBM I forgot to apply the patches so it might not be that important.

2) I did not build the full Chrome browser, but the content_shell only, so the last part changes to:

export GYP_DEFINES="embedded=1"
build/gyp_chromium
ninja -C out/Release/ content_shell
sudo ./out/Release/content_shell --disable-setuid-sandbox --ozone-platform=dri

[ghost]

Ha-ha, so as it turns out, it is easier to open any webpage than I thought: sudo ./out/Release/content_shell https://github.com/ --disable-setuid-sandbox --ozone-platform=dri

[piranna]

Umm, this is not CEF but Chrome Content Shell.

Can you explain the diference, please? (I honestly don't know what is :-( )

2) The 800x600 is hardcoded somewhere (search for "800" here)

Hum... then we should read the demo app code and change the size to fetch it dinamically from EGL APIs instead.

3) The desired behavior would be to load the desktop manager (so basically a local html file) itself.

I would do it more generic, specially now that we know how to give to content_shell an URL by command line ;-) I vote for reading a config file and/or exit with error if no URL is given.

6) For the server I think a global (multi process) server is the solution, and not one server for every app.

For static content and/or full client-side apps (ChromeOS/FirefoxOS-like ones) a global server is definitelly the best option, my example was more related to an use-case where the logic of the "tetris" app was build in the Node.js server. Both designs (global and per-app servers) can coexists though, leaving it up to the developer what one to use.

The iframe solution has a big problem, the apps would be able to connect to each other (window.parent), and because it runs in a single process, if one app dies, everything dies.

FirefoxOS has the Browser API (https://developer.mozilla.org/es/docs/Web/API/Using_the_Browser_API) that's an extension if the iframes mostly intended to host their apps in an isolated way, we could take it for inspiration.

And there is a problem with the window.open() because no new content_shells open (at least by default). So right now pop-up windows don't work, and there are no alert windows nor context menus either.

This is just a matter of override window.open(), alert(), input() and prompt() methods in Javascript. Probably there are already libraries for doing this, and if not we can craft them to help to desktop manager developers.

The horizontal scrollbar is there because the Google homepage is not responsive.

Lol! X-D

I'm not yet sure how any of this can be solved. Maybe we should check out the Crosswalk-project because it seems like that they solved some of these problems.

Seems to me it's only an updated version of webview, isn't it?

If someone wants to play with it, here is what I did: 1) I followed these instructions: https://github.com/kalyankondapally/Chromium-OzoneGBM I forgot to apply the patches so it might not be that important.

2) I did not build the full Chrome browser, but the content_shell only, so the last part changes to:

export GYP_DEFINES="embedded=1" build/gyp_chromium ninja -C out/Release/ content_shell sudo ./out/Release/content_shell --disable-setuid-sandbox --ozone-platform=dri

Great! There's a lot of libraries and components involved to make it automatic, but otherwise don't seems to be too much difficult... :-)

[ghost]

There is a nice overview that talks about the differences between CEF and Content Shell: https://github.com/adobe/brackets/wiki/CEF3-vs.-Chromium-Content-Shell But CEF does not yet support EGL, so it is quite clear which one we have to use: http://www.magpcss.org/ceforum/viewtopic.php?f=6&t=11924 (I couldn't make the mentioned project to work.)

[piranna]

There is a nice overview that talks about the differences between CEF and Content Shell: https://github.com/adobe/brackets/wiki/CEF3-vs.-Chromium-Content-Shell

So if I understood it correctly, CEF is build on top of Content Shell making it easier to embed it and integrate on the target platform, for example providing support for context menu. Since we are building our own target platform instead, I think Content Shell is the good library to use :-)

[ghost]

I found the place where the 800x600 is hardcoded, and changed it, but whatever value I choose it always shows a black screen after compiling. But one thing I noticed that even if what I can see is a black screen the webpage is still loads as expected, and randomly clicking around shows that pages are loaded. So I guess if we can find a way to fix the black screen then changing the screen resolution should work, too.

[piranna]

I found the place where the 800x600 is hardcoded, and changed it, but whatever value I choose it always shows a black screen after compiling. But one thing I noticed that even if what I can see is a black screen the webpage is still loads as expected, and randomly clicking around shows that pages are loaded. So I guess if we can find a way to fix the black screen then changing the screen resolution should work, too.

Probably, 800x600 is SVGA resolution, so probably it's defined by EGL as the default one and if trying to re-init it (the black screen after exiting the process) or by using a different resolution they would both make it crash some way, or not make the swap buffers to work correctly. Look about this, but if possible, try to get by code the EGL resolution and set it to content_shell, this way will get only one place to set resolution (EGL) since it will be always full-screen.

By the way, could you be able to give us the output of ldd on content_shell? I'm curious to know what libraries is demanding...

[ghost]

This looks interesting: https://developer.chrome.com/apps/tags/webview It looks like it needs some hacking, but this would be much better solution instead of iframes. Atom shell is using it: https://github.com/atom/atom-shell/blob/master/docs/api/web-view-tag.md

Ldd results (removed the paths and stuff):

linux-vdso.so.1
libfreetype.so.6
librt.so.1
libdl.so.2
libnss3.so
libnssutil3.so
libsmime3.so
libplc4.so
libnspr4.so
libdrm.so.2
libm.so.6
libexpat.so.1
libstdc++.so.6
libgcc_s.so.1
libpthread.so.0
libc.so.6
/lib64/ld-linux-x86-64.so.2
libz.so.1
libplds4.so

[piranna]

https://developer.chrome.com/apps/tags/webview It looks like it needs some hacking, but this would be much better solution instead of iframes. Atom shell is using it: https://github.com/atom/atom-shell/blob/master/docs/api/web-view-tag.md

Seems it has the same purpose as FirefoxOS Browser API, +1 :-)

libdl.so.2 librt.so.1 libstdc++.so.6 libm.so.6 libgcc_s.so.1 libpthread.so.0 libc.so.6 /lib64/ld-linux-x86-64.so.2

These ones are in common with Node.js

linux-vdso.so.1 libfreetype.so.6 libnss3.so libnssutil3.so libsmime3.so libplc4.so libnspr4.so libdrm.so.2 libexpat.so.1 libz.so.1 libplds4.so

These ones are not too much, don't know if content_shell load any other dynamic library that could load any other ones. If that's not the case, then it should be easy to port it to NodeOS, although I would try to compile them statically inside the content_shell executable, so it could be packaged as a NPM module without depending on third party libraries :-)

[formula1]

The most important thing to me from webview is https://developer.chrome.com/apps/tags/webview#property-contentWindow

Webview has my blessings

[piranna]

Dumb questions about content_shell and <wevbiew>:

• Is <wevbiew> standard HTML, or is only available on priviledged webapps?
• Does content_shell support <wevbiew>?
• If <wevbiew> is only available on priviledged webapps,
  • Does content_shell need some special code to enable it?
  • Are we interested/willing to have non-standard HTML (or more exactly, allow to use it to desktop manager and GUI apps developers to use it)?

And some kind of off-topic question... shouldn't this be an independent, platform-agnostic project and NPM package not directly related only with NodeOS but also usable on other OSes as a cleaner, lighter and more standards compliant framework than node-webkit? 0:-)

[ghost]

<webview> is not standard HTML tag, and content_shell does not do anything with it (I just tried that an hour ago). So we need to enable it somehow, but that's why I linked the atom-shell repo. I think we should support it, because normal iframes are not that great in this scenario, and it is needed for a web browser app anyway.

For the off-topic question: this is what CEF does.

[formula1]

My repo is pretty unstable, has requirements I know I can get rid of (or should with es6 coming around the corner [maybe next year]) and I'm currently working on something else so that web-rtc can be more plug and play for node. That being said...

• The Window is the most important aspect when speaking between applications. window.postMessage is the io that will mainly be used when speaking between window contexts. As such it technically doesn't matter too much which we use.
• A window manager creates windows. However, it is a very simple task to change from iframes to webviews.
• IFrame Context can be changed to webview context relatively easily.

However, I fully understand and support the idea of remaining browser freindly. For me, that can be as simple as a switch that checks whether or not webview is available. However, there are potential problems when letting an application within the main thread asyncronously. Whether with malicious intent or a poorly written loop, ensuring it has its own context to be as terrible as it wants will keep NodeOs away from being windows 95 (crashes and freezes galore) and retaining the beauty of why we've fallen in love with javascript in the first place.

This is a personal opinion of course. And I'm fully aware of domains but that doesn't allow for permission restrictions in a cleaner manner or ensuring an infinite loop is avoided.

[piranna]

is not standard HTML tag, and content_shell does not do anything with it (I just tried that an hour ago). So we need to enable it somehow, but that's why I linked the atom-shell repo. I think we should support it, because normal iframes are not that great in this scenario, and it is needed for a web browser app anyway.

My main concern is about not being able to use the desktop manager on a standar browser, besides that +1 to webview. Anyway, I think desktop manager developers would find some solutions for this, like using real browser windows instead to be able to use a process per-window and get integrated with the user desktop in a VmWare Fusion way :-)

For the off-topic question: this is what CEF does.

Yeah, but there's no NPM package for a vanilla CEF executable, I've only found an installer for node-webkit to set it as dependency of your proyects... :-(

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix." – Linus Tordvals, creador del sistema operativo Linux

[ghost]

I think these are the least important questions right now. First we have to make sure that the content_shell works all the time, and the resolution can be changed. Then the next step is figuring out if iframe or webview is the best for us. And the last step is deciding if we can make it work for other platforms as well. Unfortunately we are stuck at the first step at the moment, and it took quite long time to get there.

[piranna]

I think these are the least important questions right now.

You are right, but they are interesting to talk about, though :-) But you are right it's not in the roadmap for the alpha release and we shouldn't expend too much time on it by now.

And the last step is deciding if we can make it work for other platforms as well.

At least for Linux platforms it should work without problems, so we should have this in mind and don't close this door. Anyway, you are doing your tests on Ubuntu Core, not on NodeOS itself... ;-)

Unfortunately we are stuck at the first step at the moment, and it took quite long time to get there.

Yep, and I'm stuck with the automated cross-compiler, that's another show stopper... :-/

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix." – Linus Tordvals, creador del sistema operativo Linux

[piranna]

This Chrome issue could be of interest:

https://code.google.com/p/chromium/issues/detail?id=330307&colspec=ID%20Pri%20M%20Week%20ReleaseBlock%20Cr%20Status%20Owner%20Summary%20OS%20Modified

[ghost]

That issue was interesting, but this is just sad: https://chromium.googlesource.com/chromium/src.git/+/ae7b974fed695f24d0229f7dbd17eab358f05500 There was a command line switch to enable it, and it is no more...

Anyway, I figured some new stuff out. Previously I said that Ozone GBM is Ozone Dri, that is actually false. There is a way to use Ozone GBM, but the information about this is so scarce on the internet that it is no wonder I missed it. So I'm trying to build a content shell version with the GBM enabled, so far no good results. But I have one or two ideas that I haven't tried yet.

[piranna]

Anyway, I figured some new stuff out. Previously I said that Ozone GBM is Ozone Dri, that is actually false. There is a way to use Ozone GBM, but the information about this is so scarce on the internet that it is no wonder I missed it. So I'm trying to build a content shell version with the GBM enabled, so far no good results. But I have one or two ideas that I haven't tried yet.

Do you think this could be the reason of the black screen?

[ghost]

It looks like GBM is built on top of Dri, and I still get black screen, but at least some more meaningful error messages show up, too. But I have to play around with this a bit more. The worst part is that is takes quite long time to compile everything, so I can't try out every possible solution.

[piranna]

It looks like GBM is built on top of Dri, and I still get black screen, but at least some more meaningful error messages show up, too.

Getting better error messages is an improvement :-) We can take a look in the future to use Ozone DRI to remove some extra layers and get a better performance. One step at a time :-)

But I have to play around with this a bit more. The worst part is that is takes quite long time to compile everything, so I can't try out every possible solution.

Yeah, I know. NodeOS-barebones is spending one hour to compile, and yesterday I tried LinuxFromScript (an automated Linux From Scratch) and it spend three hours to compile everything :-/ At least it did it flawlessly, so I will be able to use it as basis for the cross-compiler! :-D

This things are really time wasting, but when they works, the compensate the effort ;-)

[serapath]

Maybe it's a stupid question, but would it be possible to merge or blend the shell/terminal with the desktop UI? several approaches exist:

• https://github.com/substack/bashful
• https://github.com/substack/exterminate
• https://github.com/substack/browser-terminal
• https://github.com/petethepig/devtools-terminal
• http://acko.net/blog/on-termkit/
• https://github.com/unconed/TermKit + https://github.com/FireyFly/TermKit
• https://github.com/shepik/wkterm
• https://github.com/featurist/shellsubstitute
• https://github.com/arturadib/shelljs
• http://www.htmlfivewow.com/demos/terminal/terminal.html
• http://www.masswerk.at/jsuix/
• http://www.masswerk.at/termlib/
• https://code.google.com/p/shellinabox/
• https://github.com/mitotic/graphterm
• https://github.com/hoeck/schirm
• https://github.com/liftoff/GateOne + http://liftoffsoftware.com/ + http://liftoffsoftware.com/Products/GateOne
• http://wterm.saverpigeeks.com/

[piranna]

@serapath, I don't see the point of your links, the only interesting one I've found is wkterm. Could you be able to explain what are you trying to achieve?

[serapath]

It was just meant for inspiration. The NodeOS project excites me, but my technical knowledge is to shallow to contribute something more useful. I was playing around with some of those projects i linked to above and like them. So in case these projects were unknown here - I was hoping to contribute some inspiration at least. I'll keep quiet now - sorry for bothering.

[piranna]

Don't worry, you didn't bothered, only I didn't get the point of them :-) NodeOS is mostly a server OS, and we try to promote that GUI apps being build as clients that connect to a headless NodeOS instance using standard protocols to increase portability. The links that you posted are OK, but they can work on their own. They don't have anything to do with NodeOS, but definitely they can work with it :-)

[formula1]

@serapath If you want to help out with terminal or a UI, check out Silk. Theres always more to do there and not all of it is particularly technical.

However, when it comes to actually creating a gui, almost everything is based off a chrome/browser implementation and its far easier to build a terminal interface and make sure that the operating system internals are working fine then integrating a chrome shell. @netlovers has made a certian amount of progress, however at the end of the day he's doing a very difficult job. On top of that, he's doing it for free which means he should be under no obligation and only be celebrated for what success he does gain.

That being said, having a workable terminal, filesystem, process system and etc is truly what a javascript OS is, the gui is extra on top that will make people want to use it more.

[ghost]

I made some more progress since then. As it turns out I can't use the Ozone-GBM platform inside a VMware vm, because the graphic driver there does not support it. I'm not sure if any vm supports GBM at the moment. But Dri uses software renderer so it might be enough for some simple stuff. Although my last attempt to build a Chrome version with the Dri platform failed. I'm far away from my laptop for a few more days, so no progress will be made by me until I get back home.

I'm thinking about using real hardware instead of just a vm, because it looks like that a vm has some serious limitations, and I can't be sure if something won't work because it runs inside the vm, or if I'm facing a real bug. And to be honest, compiling Chrome inside a vm is just too painfully slow, but I'm not ready to buy a new build server just for this task.

[jesselawson]

I've been working on a NodeOS Shell project that bypasses the need to use a browser in order to render a terminal. My goal is to have a command line similar to our traditional terminals but inside you can run a command like edit soandso.js and it will call edit.js in some /usr/share folder and pass along the arguments to it.

Ultimately, I'm trying to do two things:

1. Create a nano clone for NodeOS that will be a simple CLI text editor.
2. Create a vim clone for NodeOS so I can work exclusively inside NodeOS.
3. Package a nano clone, a vim clone, and Slap together as the trifecta of NodeOS CLI editors.

All of this requires the ability to produce a terminal-like system, which itself requires us to be able to manipulate the console which requires (I think) more integration on NodeOS's part with the actual mo'chine.

On Linux, you can enter a Node environment by typing node and hitting enter. Boom. Now you're basically inside an interactive console application. But we don't need a JavaScript console; we need something like Nash (just made that up), which is a Bash/terminal specifically for NodeOS. I think this is the key to a proper CLI interface for NodeOS.

</ramble>

[ghost]

@lawsonry Check this out https://github.com/groundwater/node-bin-nsh

[piranna]

I'm thinking about using real hardware instead of just a vm, because it looks like that a vm has some serious limitations, and I can't be sure if something won't work because it runs inside the vm, or if I'm facing a real bug. And to be honest, compiling Chrome inside a vm is just too painfully slow, but I'm not ready to buy a new build server just for this task.

What about a chroot system, like debootstrap? This way you have a somewhat "pristine minimal" system that don't depend on your system installed libraries but run on top of your native hardware... This way you could compile them faster, and theorically it could also allow you to test them... :-)

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix." – Linus Tordvals, creador del sistema operativo Linux

[piranna]

@lawsonry, do you have your shell code published somewhere?

[ghost]

@piranna I'm using a Windows laptop with uefi, and fastboot, so normal linux distros won't really work out of box (https://help.ubuntu.com/community/UEFI). And I hate the current Linux desktops, so installing one is not an easy decision to make. :D

[piranna]

@piranna I'm using a Windows laptop with uefi, and fastboot, so normal linux distros won't really work out of box (https://help.ubuntu.com/community/UEFI).

Oh, though you were using Linux already...

And I hate the current Linux desktops, so installing one is not an easy decision to make. :D

Ubuntu Mate is your friend ;-) https://ubuntu-mate.org/

"Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix." – Linus Tordvals, creador del sistema operativo Linux

[piranna]

Ok, so the emulated Cirrus of QEmus has DRM support... :-P

[ghost]

It's okay, but I can't really test it, because Qemu on Windows is slow as h*ll.

[piranna]

Well, enabling CONFIG_FB_CIRRUS to have framebuffer support gets it to be slower that disabling KVM and didn't get the Unicode characters to work nor a bigger console area, only to show the penguin at boot... :-P

(Obviously, I've reverted it...)

[piranna]

@netlovers, I have just found the compilation flags of Mesa EGL. Probably you have seen earlier, but I've seen that it supports fbdev as EGL platform, and seems we have it by free (yes, CONFIG_FB_CIRRUS is slow as h*ll, but default one using vesafb runs awesome in QEmu :-D ) maybe it would be used to start moving one step at a time :-) If we can be able to run EGL at least software rendered we could be able to exec some of the node-egl demos I put earlier in this thread and later try to compile OpenVG and adapt node-canvas-openvg to have 2D and later 3D graphics on the console framebuffer, and later try to use DRI. This would be a longer path to have the things working, but probably it will be easier and also all this steps are minor milestones in the path to get CEF to get running, what do you think? :-)

[ghost]

Why fbdev is necessary? I think Mesa should work fine with the flags that I used in my previous gist. The problem I have is with Chrome. I even thought about using X until the DRI platform is stable enough, but I know you are against X.

[piranna]

Why fbdev is necessary? I think Mesa should work fine with the flags that I used in my previous gist. The problem I have is with Chrome.

Oh sorry, I though you were having problems using DRI with Mesa + EGL, that's why I proposed to use fbdev instead as a short term solution, but if you have got advances on this field then fbdev is out of place in benefict of DRI :-D Don't know if we could get big text resolutions without using fbdev (I need to test to use pure text-mode resolutions on the boot params) nor if it would be required to initialize graphic card to draw using DRI + EGL, but if not, then framebuffer could be fully removed.

Do you have somewhere your current buid scripts? This way I could check out how feasable would be to make node-openvg-canvas to work that could be a good sandbox until CEF is available (SVG fonts on the terminal! Good bye to the Unicode problem! :-P)

I even thought about using X until the DRI platform is stable enough, but I know you are against X.

I'm not "against X" but in the fact that it add more layers that complicate the system and use more RAM + CPU resources that degrade system performance, but I have to admit it does a good job. Wayland has the same philosofy about using less layers to improve performance, the same way that DirectFB did (that's also more baremetal than Wayland), only problem is that didn't get mainstream support as Wayland has get. That's why I say about using raw DRI + EGL, because we don't need any of the extra features (windowing, transparency, network support...) but only be able to draw full-screen, and later left CEF to do the rest of the job :-)

P.D.: I'm also against fbdev because DRI + EGL can offer a better performance in a somewhat standar way, and to do the same with fbdev it's necesary to use DirectFB that internally it's using DRI so here DirectFB becames "the extra layer", but since fbdev was offered by free since it was needed to have high resolution text modes and seems it's not using too much resources and it's on the standard vanilla x86 kernel, that's why I proposed to use it as a temporal fix... ;-)

[ghost]

I didn't change anything in my old build script: https://gist.github.com/netlovers/0bfc342f5320f35ab601 If you check the comments the Mesa build has some instructions how to build it without any X dependency. I know that X adds more layers, but until there isn't a browser engine that works out of the box with bare metal, I guess it would make many things easier. And graphics is an optional part of NodeOS anyway.

[piranna]

I didn't change anything in my old build script: https://gist.github.com/netlovers/0bfc342f5320f35ab601

Oh great, I'll try to take a look on it.

I know that X adds more layers, but until there isn't a browser engine that works out of the box with bare metal, I guess it would make many things easier.

There are some guys that have been able to run a QtWebKit based browser on the Raspberry Pi directly on top of DRI and framebuffer, I think we could take some ideas...

http://www.raspberrypi.org/forums/viewtopic.php?f=38&t=43087&sid=06f1b7d497ae48810a0e8ff02c6acfff https://github.com/Topguy/mlbrowser

Anyway, although the long term purpose is to have a web rendering engine running on top of NodeOS to bring advanced graphic functionalities, what I'm saying here is to take the lower layers and start playing with them until we get the full browser working :-)

And graphics is an optional part of NodeOS anyway.

Absolutely, and as I said in the other post, although I would love to see a desktop build in HTML and some graphic apps running on top of NodeOS, each day I think a little more if we shouldn't focus to create a pure head-less system that's only able to understand REST requests and WebSocket connections and left user interfaces (both graphic and text mode) out of scope for client apps running on external, remote devices... :-/

[piranna]

By the way, seems EGL can be statically compiled based on Gallium for a lot of platforms, that would be awesome since we would include it as a npm package... :-D

https://chromium.googlesource.com/chromium/deps/mesa/+/f2ba7591b1407a7ee9209f842c50696914dc2ded/src/gallium/targets/egl-static/Makefile

[piranna]

ChromeOS has switched to its own graphic stack Freon build directly on top of KMS/DRM to improve performance. This is also a level lower to EGL (although Ozone-* will still be available), so this are good news to us... :-)

http://www.phoronix.com/scan.php?page=news_item&px=Chrome-OS-Freon-Graphics

[piranna]

I've reviewed topcube project and seems it's mostly what we are trying to do for the GUI system, a npm package that host only a CEF-based browser and with a pure client-server architecture. It's a bit outdated and seems don't support terminal by default, but could be a great help. The needed steps would be to update its CEF version (seems it's based on Chrome 17...), compile for terminal and try to make a statically linked module.

On the other hand, Ozone-DRI backend is intented to be used directly on the framebuffer using software rendering, so it could be easier that going for pure hardware accelerated EGL... :-)