Skip to content

Raspberry Pi 4 support  #44

Closed
Closed

Description

@jvolker

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.

Activity

  1. jmwohl commented on Sep 23, 2019

    @jmwohl
    Member

    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.

  2. jvolker commented on Sep 23, 2019

    @jvolker
    CollaboratorAuthor

    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.

  3. jmwohl commented on Sep 29, 2019

    @jmwohl
    Member

    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.

  4. jvolker commented on Sep 29, 2019

    @jvolker
    CollaboratorAuthor

    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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions