[Cogl] Cogl rendering to framebuffer on Raspberry Pi
Robert Bragg
robert at sixbynine.org
Mon Jan 6 07:36:11 PST 2014
Hi Stephen,
Thanks for looking at this, and sorry for the delay with replying over
the Christmas, New Year break.
Just taking a quick look over the code I have a few comments - sorry
some of them are a bit petty...
It looks like you could remove the
_cogl_winsys_egl_add_config_attributes function and just rely on the
default implementation if cogl-winsys-egl.c since you don't appear to
be setting any rpi platform specific attributes.
The code seems to have a mixture of coding styles, not following the
same style as the rest of Cogl. We more or less follow the GNU coding
style so for an if() statement we wouldn't put the opening brace on
the same line as the condition but rather on a new line and indented
by two space. Sorry if that's a bit awkward for your editor to help
you with, but it's helpful for us maintaining the code if everything
is consistent. You can perhaps look at the 'indent' program to
automatically update the style for the whole file. If it's too much
faff we can always update this ourselves when we look at landing this.
Please see docs/CODING_STYLE for more details about this.
In cogl-renderer.c if you move the added
_cogl_winsys_egl_rpi_get_vtable within the
_cogl_winsys_vtable_getters[] array to be above
_cogl_winsys_egl_null_get_vtable then I would guess that you wouldn't
need to require applications to set any environment variables to use
this backend, it should be the first backend to successfully connect a
renderer, assuming you aren't running an X server. If you are running
an X server then I guess it makes sense for it to default to egl_xlib
or glx anyway.
It would be nice if we could support creating multiple onscreen
framebuffers for given display manager handles, but if it's too much
hassle to try and support that now that's ok we can go with the way it
is and only support a single framebuffer like the egl-null winsys. If
you were to take a stab at support multiple onscreen framebuffers you
could take a look at the glx or egl_xlib backends. To do this I would
imagine adding api like cogl_onscreen_rpi_set_dispman_handle() that
can be used to configure an onscreen framebuffer before it's allocated
- like cogl_x11_onscreen_set_foreign_window_xid(). The winsys would
define a CoglOnscreenRpi struct for associating dispman state with an
onscreen fb and instead of creating the eglWindowSurface in
_cogl_winsys_egl_context_created() the window-surfaces would be
created in _cogl_winsys_egl_onscreen_init() instead. Again not to
worry if this is too much hassle for now, we should be able to look at
this in the future without affecting compatibility.
Could you perhaps squash all of the changes you made to add the rpi
winsys into one patch for landing? We don't need to track the
intermediate work-in-progress commits which presumably don't all build
or have issues which may cause problems bisecting later.
At the top of the file you have copied the copyright statement from
another file, which is ok since you said it is based on the Android
backend, but please also feel free to add your own Copyright (C)
2013,2014 Name/Employer notice, and Authors line too if you want.
Since we are currently in the process of seeking approval from
contributors to re-license Cogl to the MIT license it would also be
great if you could give us your blessing to license your code under
the MIT license.
Thanks again for looking at this,
kind regards,
Robert
On Fri, Dec 20, 2013 at 3:54 AM, Stephen J <stephenjust at gmail.com> wrote:
> Hello again,
>
> Neil: Thanks for the clarification. I ended up basing my work on the Android
> winsys, as it was much simpler to deal with.
>
> At this point, I have managed to get enough of cogl working to run the
> cogl-hello example on the raspberry pi in full-screen with GPU acceleration
> - without X or Wayland.
> As well (and somewhat more exciting), I've managed to get several of the
> "toys" from the clutter-project github repository to run. I haven't bothered
> to check fps yet, but the animations in the clutter demos look very smooth.
>
> You can see my code so far here:
> https://github.com/stephenjust/cogl/tree/cogl-1.18
> I may have performed some operations in incorrect places within the egl-rpi
> winsys, however I managed to get it running. Use the
> --enable-rpi-egl-platform=yes with autogen.sh to enable the Raspberry Pi
> winsys.
>
> Due to some irregularities with how the Raspberry Pi's libraries are set up,
> when you compile anything using the cogl raspberry pi functionality, you
> need to add -L/op/vc/lib/ -lEGL -lGLESv2 to the linker command.
>
> In order to get this to work, I had to use a few packages newer than what is
> available in Raspbian Wheezy. I used cogl-1.18 and clutter-1.14. cogl-1.14,
> which Raspbian Wheezy provides, does not work with these modifications. (The
> clutter toys also need -lcogl-path to link because of this being split out
> of the main cogl library.)
>
> If you have any feedback regarding the code, things to try, etc, let me
> know.
>
> Thanks
>
> _______________________________________________
> Cogl mailing list
> Cogl at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/cogl
>
More information about the Cogl
mailing list