I have a program that uses OpenGL+glsl to do computation. Currently I'm using GLFW to create a context in a hidden window via:
glfwWindowHint(GLFW_VISIBLE, GL_FALSE);
window = glfwCreateWindow(1, 1,"", NULL, NULL);
This is working great for me if I run my program locally on my server at work with a fancy GPU.
When I try to log on to this server from home via SSH, I get segmentation faults. I've tried ssh -X and ssh -Y but this doesn't help. I'm also not even sure that would run the program using the server's GPU (would it?).
All I'd like to do is run the program as if I was there at the keyboard issuing it on a local terminal. There's no window or graphics to forward. Is this possible?
Would this be easier with an alternative context manager to GLFW? I actually want to use OpenGL for my problem since it is trivially re-formulated as a direct rendering task (i.e., as opposed to rewriting my program in cuda).
Related
I've followed a few tutorials on setting up Xming and putty, and also trying with cygwin but there is one particular C progam from a raspberry pi I'm having issues with over ssh to my windows machine. I've been somewhat successful as I can get Pygame and a few other small things to show up on my desktop. I'm now trying to do the same thing with the C program that uses SDL and OpenGL packages. When I try to run the program through ssh I get init_sdl() PuTTY X11 proxy: wrong authorisation protocol attempted
I also get the same error when trying to run it with MobaXterm.
at one point I did get init_sdl() without the error, but there should be two more lines that follow after that and then a GUI appear, and it isn't happening. So I think it's hanging on trying to initialize sdl? I'm not really sure. Are there any other resources I need for my windows side client?
If needed, here's the program I'm trying to run. It does work on the pi, just not over ssh. https://github.com/bear24rw/rgb_table/tree/master/code/table_drivers/beat_finder
Update: I can get init_sdl() to show every time now without the error following in cygwin, but still not getting a GUI to show or get the the full readout of
init_sdl()
init_gl()
init_fft()
init_serial() which is what should show.
EDIT2: There is a use_gui = TRUE/FALSE; option in the code, when I set this to false, I get init_fft() and init_serial() and the code works, but I would still like to have what's missing with SDL or GL to get the GUI part to work over SSH.
I have a program which can display data graphically using freeglut, which is nice but not essential. I use putty a lot to edit and compile my program on a debian server at home but when I try to run the binary from within putty I get this message:
freeglut (./a.out): failed to open display ''
Now I know that with a bit of fiddling about I could get cygwin to somehow tunnel the X server using ssh -X, but what I'd like is to simply detect if freeglut can render to the screen, and if it can't, simply to not bother.
How can I do this? I tried running a backtrace on my program in gdb but there's no stack, so I don't know if there's an exception or return value I can catch.
glutInit():
glutInit will initialize the GLUT library and negotiate a session with the window system. During this process, glutInit may cause the termination of the GLUT program with an error message to the user if GLUT cannot be properly initialized. Examples of this situation include the failure to connect to the window system, the lack of window system support for OpenGL, and invalid command line options.
So, no, you can't really handle a missing X server with GLUT. Short of some nasty hacks like a parent watchdog process or hooking exit() somehow.
I'm playing around with a simple ncurses program to move sprites around a screen. Most of the backend logic is in C++. Apparently Xcode won't with ncurses at all, so I need some other way to debug my program. I don't know C or Unix that well - is there any way I could have my program spawn another Terminal window, which would run alongside the window where ncurses is running? I'd like to be able to use cout in that window to monitor the state of my program.
Use gdb and the "attach" command to attach to your running process.
I'm wondering how to programmatically change to one of the available terminals from an embedded Qt application.
The application is invoked via application -qws. Graphically it is configured with the Linux framebuffer (support compiled into the kernel) with the tty drivers enabled.
The reason for doing this programmatically is that Ctrl+Alt+FX does not work to switch ttys.
Firstly, I tried the obvious cheating mechanism - overriding keyPressEvent I added system("chvt 2"); Unfortunately, this did not work.
Instead, I looked directly at the source of chvt.c in busybox. Essentially, that boiled down to doing:
fd = open("/dev/console", O_RDRW);
ioctl(fd, VT_ACTIVATE, vt_num);
ioctl(fd, VT_WAITACTIVE, vt_num);
Ignoring the use of xioctl and detecting the correct tty - I know /dev/console exists and I can get a RW file handle on it.
Again, no luck.
So taking my cue from chvt.c I decided to iterate over all the framebuffer devices present until I found one that was receiving keyboard input; then I ran
fd = open("/dev/fb1", O_RDRW);
ioctl(fd, VT_ACTIVATE, vt_num);
ioctl(fd, VT_WAITACTIVE, vt_num);
That caused a black screen as per any normal tty change, except that the framebuffer device returned afterwards, bringing my app back with it.
So - my question - without exiting my application, I'd like to be able to programmatically switch to a tty of my choice, and then be able to switch back using the usual ctrl+alt+fX mechanism.
Environment:
Qt 4.7.4
Linux 3.3.3
Buildroot 2011.11
Busybox 1.19
uClibc 2.21
I suspect, but am not certain, that the cause of ctrl+alt+fX not working in the first place may be the cause of the tty change not working programmatically as per chvt.
I should point out at this stage that, confusingly, the zap keys (ctrl+alt+backspace) do work as expected.
Building an app for Ubuntu using Ogre3D, CEGUI, OIS which is now all compiling and running as expected. Having got the basic app running I decided to now build a custom config file which I can store both graphics settings (ie. resolution, fullscreen, etc) as well as other configurable settings I will need in the app down the track.
As a starting point I changed from calling mRoot->showConfigDialog() at each startup to :
if(!mRoot->restoreConfig())
mRoot->showConfigDialog();
this was meant to restore the config from the 'ogre.cfg' file which exists and so it did, but got to loading a skybox texture on the first scene create and just sat there doing nothing.
Since that wasn't what I wanted anyway I tried setting things up manually like :
RenderSystem *rs = mRoot->getRenderSystemByName("OpenGL Rendering Subsystem");
mRoot->setRenderSystem(rs);
rs->setConfigOption("Full Screen","No");
rs->setConfigOption("Video Mode","1024 x 768");
Those matched the settings from 'ogre.cfg' that I was using prior from the showConfigDialog() function. I got the same issue with this manual configuration however, while loading the skybox textures it just stops.
I can't work out why these changes have any bearing at all on how the app runs and since OIS grabs the input and locks the mouse to the screen I am having trouble trying to debug it with gdb.
Regarding the mouse locking, you can run gdb on another display. It can either be a display on the same computer (including options like Xephyr that create virtual displays nested in the current display, or just a second session on a different display - if you have a working .xinitrc running two or three X sessions at a time is simple), or it can be on another machine on your network (ie. via ssh -X).