0

I have, thanks to some help, managed to get the program below to compile and run but although it keeps on chugging away I cannot see anything drawn on the Pi's screen.

I don't think that it is a problem unique to the use of openvg and ajstarks code as, during the problem I had compiling the test progam, I tried a different way of writing images (sorry, all I remember was that it was low level and didn't need the includes for openvg). It took a bit of searching and re-writing to get it to compile and when it did the same thing happened.

I persevered for a while, but got no where. There were some references to some sort of limitation with Raspberry Pi and X Windows leading to the same problem. You draw something but it doesn't display. Given that there were several comments suggesting that openvg worked, I went back to that and (thanks to a guy called Ross) eventually worked out why I couldn't compile the code.

So now I am at a point where I can compile code that others have got to run successfully, but it doesn't draw anything on the screen. I know that the code runs - it chews CPU cycles (well the official demo does, mine less so although it's still definitly going) and the code can be quit with

Another method of working with graphics has come across the same no-output-display problem, so I think the problem is somewhere on my Pi but I have drawn a blank on how to address the X Windows (or it might have been X11, wish I had kept the tabs open!) not wanting to draw issue.

Any help greatly appreciated, thanks in advance!

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>

extern "C" {
#include "VG/openvg.h"
#include "VG/vgu.h"
#include "fontinfo.h"
#include "shapes.h"
}

using namespace std;

int main (void) {

int width, height;
        VGfloat w2, h2, w;
    char s[3];

    init(&width, &height);                                      // Graphics initialization

    w2 = (VGfloat)(width/2);
    h2 = (VGfloat)(height/2);
    w  = (VGfloat)w;

    Start(width, height);                                       // Start the picture
    Background(0, 0, 0);                                        // Black background
    Fill(44, 77, 232, 1);                                       // Big blue marble
    Circle(w2, 0, w);                                           // The "world"
    Fill(255, 255, 255, 1);                                     // White text
    TextMid(w2, h2, "hello, world", SerifTypeface, width/10);   // Greetings
    End();                                                      // End the picture
    fgets(s, 2, stdin);                                         // Pause until RETURN]
    finish();                                                   // Graphics cleanup
    exit(0);
}
pdw
  • 8,359
  • 2
  • 29
  • 41
user867358
  • 75
  • 11
  • 1
    I searched around for a bit and found this '...there is a small hurdle in the way at the moment for casual coders. The traditional way (on Linux) is to use the X window system to provide a surface on which the OpenGL/OpenGL ES surface can be rendered. At this moment, the implementation of X for the Raspberry Pi is unable to do this, and so you can’t use X to provide your surface.' While I am not trying these libraries, I think the problem is linked. – user867358 Aug 11 '14 at 08:53
  • I have also tried [this code](http://raspberrycompote.blogspot.co.uk/2013/03/low-level-graphics-on-raspberry-pi-part.html) not related to OpenVG and the same thing happens - prog runs with console output but there is no screen display where there should be... – user867358 Aug 11 '14 at 08:55
  • If you want to draw simple shapes, perhaps you should try [PyGame](http://www.pygame.org/) which ships with Raspian already. If you want to stick to c++ I recommend trying [OpenFrameworks](http://openframeworks.cc/setup/raspberrypi/) since it deals with OpenGLES rendering behind the scenes and you can easily draw [circles](http://openframeworks.cc/documentation/graphics/ofGraphics.html#!show_ofCircle) or other shapes – George Profenza Aug 11 '14 at 17:07

1 Answers1

0

Ok...

Thanks to a stroke of luck I have found the answer and it's odd. To me anyway...

In case anyone else encouters the problem, here is the (partial) solution which leads to another question to be posted shortly.

I am trying to run a programming club in my school and it's not practical to physically connect the Pi's to kb, mouse and monitor so they all auto-run VNC and we connect to the machines using Ultra-VNC. The programs are written in a shared directory and Eclipse C++ runs on the host; therefore all program output is viewed via VNC.

I had been continuing to try to solve the problem and at one point connected a keyboard and mouse and noticed that they seemed to be recognised (laser came on, Caps Lock toggled, etc.) but they didn't do anything when moved/typed on.

Eventually the penny began to teater on the edge as I got increasingly confused as to why no one else was having this problem. Is seemed odd that no one else had the issue and then I began to wonder more about the kb/mouse issue.

I tried plugging the HDMI output into a monitor at home (shool ones are still analogue d-sub!) and lo and behold, the physical kb and mouse worked. Then it got really strange!

Somehow I have 2 desktops running at the same time. The physical keyboard and mouse control one and VNC controls the other. Interestingly, VNC has the title Pi's X Desktop suggesting that the graphics problem might be something to do with X, but I am not sure for the reason below.

If I start a terminal window on 'Physical' desktop, it doesn't show up on 'VNC' desktop and vice versa - they seem to be independent, although that's not quite true.

When I run the test file on 'Physical' desktop, it works fine and can be controlled only using the physical kb. When I run it on 'VNC' desktop, it can be controlled only with the VNC kb but the output displays on the physical screen.

I really don't get this!

So, this answers the original question as the program does run on the Pi.

Off to post (hopefully a final) question on how to either get VNC to show the 'Physical' desktop or how to target the graphics output to the 'correct' desktop.

user867358
  • 75
  • 11
  • X-Windows configuration files have separate mappings for display and input devices. It sounds like the VNC config is correctly using the VNC input devices, but is attaching to the physical screen. Another possibility is that you're using an OpenGL driver that connects directly to the Broadcom VideoCore processor, ignoring the X display settings. – Ben Voigt Aug 11 '14 at 17:31