Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Raspberry Pi 4 support #44

Closed
jvolker opened this issue Sep 22, 2019 · 4 comments
Closed

Raspberry Pi 4 support #44

jvolker opened this issue Sep 22, 2019 · 4 comments

Comments

@jvolker
Copy link
Collaborator

jvolker commented Sep 22, 2019

I've just tested Openframe on the Raspberry Pi 4 running 2019-07-10-raspbian-buster.

Video

okay

Website

okay, after running sudo apt-get install xserver-xorg-legacy

Images

Error: * failed to add service - already in use?

Shader

Error: * failed to add service - already in use?

The image and shader extensions are based on glslViewer which has been reported not to support Raspberry Pi 4 currently. patriciogonzalezvivo/glslViewer#141 (comment)

This will need a some deep work. The solution will imply transitioning to this > https://github.com/eyelash/tutorials/blob/master/drm-gbm.c

That said, installing GLFW and compiling it for X11 windows manager works

I've also successfully tested WebGL on the Raspi 4, which means shaders could run in Chromium.

What is the best way to go from here? Two basic options:

  • wait until glslViewer supports Raspi 4
  • find alternatives for the image and shader extensions that work on the Raspi 4 and update the extensions. This could, for example, be based on GLFW or Chromium. Would it be worth checking if GLFW works on all Pis or would it be better to run glslViewer if supported and Chromium otherwise?

It sounds like it's going to be a while until a fix for glslViewer is available. I think it is important to fix the extensions and choose alternatives to be independent of glslViewer. Chromium seems like an easy fix as a there is a working codebase for it in the website extension. I could imagine this might also fix the issue people are having with TFT/SPI/GPIO screens. I could give it a shot.

Taking this even further, basically, all default formats (image, video, shader, website) could run in Chromium. This would also make it easy to display captions with author and title as an overlay. Also, it might offer the possibility to create smooth transitions between artworks. Not sure if using Chromium is generally a good idea for performance reasons on slower Pis, but it seems like it could have other advantages.

@jmwohl
Copy link
Member

jmwohl commented Sep 23, 2019

Good to have an issue open on this. I've played around with the Pi 4 and have been in touch with the author of glslViewer, and yeah — it's not looking like there will be a good fix in the short term.

For some background, the original POC of openframe did actually do everything in a browser! At the time it wasn't possible to get WebGL running on the pi, so no shaders. Once we started working on the more fully-realized version of openframe, we implemented our current model of having format extensions which define their requirements and how they should run artworks, and glslViewer was a great fit as it was super fast and lightweight and we had the support of the author who integrated openframe into his shader web editing tool — this led to a lot of great initial contributions.

I'm hesitant to move the core format extensions to chromium mostly because of performance concerns — historically, chromium was the least performant aspect of openframe. That said, I'm not entirely opposed to the idea, especially as performance continues to improve...

@jvolker I'd suggest you create an image and/or shader extension of your own that uses chromium, and play around with it. If you're satisfied with the performance, publish it so that others can play around with it too.

@jvolker
Copy link
Collaborator Author

jvolker commented Sep 23, 2019

I'm hesitant to move the core format extensions to chromium mostly because of performance concerns — historically, chromium was the least performant aspect of openframe. That said, I'm not entirely opposed to the idea, especially as performance continues to improve...

What if we use Chromium as a temporary fix only for the Pi 4 until there is a different solution? I reckon the image extension is the most important of all extensions, it is broken at the moment and I'm afraid this leads to frustration of new users. I can work on a fork of this that implements this.

@jmwohl
Copy link
Member

jmwohl commented Sep 29, 2019

Good news! The author of glslViewer managed to get it working successfully on the pi4! I've updated the image and shader extensions to have a specific install for the pi4, as it requires a different set of GL drivers.

As such, I'm going to close this issue. Since the core of the idea behind Openframe is that an artwork format extension can define exactly how artworks are displayed, I'd like to avoid using Chromium for formats that don't specifically require it. I understand the additional desire to have attribution displayed, but for now I think that requirement is secondary and doesn't warrant reliance on Chromium.

@jmwohl jmwohl closed this as completed Sep 29, 2019
@jvolker
Copy link
Collaborator Author

jvolker commented Sep 29, 2019

Good news! The author of glslViewer managed to get it working successfully on the pi4! I've updated the image and shader extensions to have a specific install for the pi4, as it requires a different set of GL drivers.

That is amazing! 🎉

As such, I'm going to close this issue. Since the core of the idea behind Openframe is that an artwork format extension can define exactly how artworks are displayed, I'd like to avoid using Chromium for formats that don't specifically require it. I understand the additional desire to have attribution displayed, but for now I think that requirement is secondary and doesn't warrant reliance on Chromium.

I'm going to start new threads to continue this conversation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants