Launch OpenGL app straight from a windowless Linux Terminal - c

How exactly would one go about getting an OpenGL app to run fullscreen straight from the terminal (Ubuntu Server 9.04)? I've developed an application for visual diagnostics on my server, but, I'm not totally sure the best way to get it to run in a windowless environment.
Ideally, I would run my program:
./visualdiagnostics
and have that launch the OpenGL app. Then, via a simple Ctrl+X key binding, I'll kill the app and go back to the terminal.
Do I need to install X11 and then somehow launch it from within the program? What would be the best way to detect if it's already running and, start/stop it if necessary?
And FYI: No, I'm not trying to get this to run over Putty or anything... I have a monitor hooked straight up to the server. The server has proper video drivers installed.

There are several parts to your task. Keep in mind that some of this can be very distro-specific; but since you said Ubuntu we'll talk Ubuntu!
Also you tagged this question C however I am starting off with a common Linux pattern: a native application with a Bash shell script wrapper. Perhaps once you get things working well you might fold that functionality into C if you have to.
Detecting whether X is running
Being root can help a lot. Some things that work.
pgrep Xorg
Check whether /var/lib/gdm/:0.Xauth exists. This will be there even if nobody has logged in but GDM is running.
ls -l /home/*/.Xauthority (Even if you're not root you can at least confirm whether you are running X.
Piggybacking an existing X session
You did not specifically mention it but if you are root at the console, or if you want to run the app as the same user who is already logged in, it's pretty easy.
You have to get the DISPLAY and XAUTHORITY environment variables right, and once you do you can use the existing X display.
For DISPLAY you might just assume :0 or you could find an existing X program (x-session-manager is the GNOME standard) and read its environment from /proc/PID/environ. Variables are in key=value format delimited by a null byte. For example, if its PID is 12345:
cat /proc/12345/environ \
| ruby -ne 'puts $_.split("\0").select {|e| e.starts_with? "DISPLAY=" }'
For XAUTHORITY you could get it the same way. Or if you prefer guessing, it's almost always /home/whoever/.Xauthority
Once you have those two variables, running X code is easy, for example:
env DISPLAY=:0 XAUTHORITY=/home/brian/.Xauthority ./visualdiagnostics
Stopping X
This one is easy if you're root: /etc/init.d/gdm stop. killall Xorg will work too.
If you are a user, kill your own Xorg or x-session-manager process. (I'd welcome input from others for the canonical way to do this. Maybe some dbus-send message?)
Starting X
I would recommend xinit whose goal in life is to fire X and run exactly one program.
For example: xinit ./visualdiagnostics
You can also tell xinit what resolution to run X at which may or may not be important to you. (This becomes important in the full-screen section below.)
The problem with this is you will have no window manager— no maximize and minimize buttons. It's not just cosmetic. Usually an app is useless because a popup window cannot be moved or you cannot focus on the right input field. However if you have a special app it could be sufficient (see full-screen below).
The next step would be my answer to everything: another shell script wrapper! Something simple that starts the window manager and then becomes your program should work.
#!/bin/bash
#
# Start visualdiagnostics once xinit calls me.
/usr/bin/metacity& # Or ratpoison, or fluxbox, or compiz, etc.
exec ./visualdiagnostics
It's important to exec (become) the main program because once that first program exits, X will shut down.
Running fullscreen
I am not 100% certain on this. Some ideas:
Try the standard X -geometry parameters to set 0,0 as the upper-left corner and +x+y for your horizontal and vertical size. How do you know the size? Either you hard-coded it when you launched xinit or you could ask the X server. xwininfo -root will tell you and there is an xlib API call that would do that too—check the xwininfo source I guess.
Your app itself can request maximization and/or resizing to fill the screen. I'm not familiar but it is definitely in the X API.
Some of the more configurable window managers can be pre-configured to run you maximized already. This is probably what I personally would check first. Your wrapper script could create a $HOME/.fluxboxrc just by echoing some hard-coded configs > the file.
Summary
The others are right. X is not strictly necessary sine OpenGL can run against a framebuffer. However considering how ubiquitous X is and how much work has gone into automating it for distributions, I would probably invest my effort into the X route as it might be easier long-term even though it's a little convoluted.
(By the way, I sincerely hope when you say "terminal" you mean you are at the text console, not gnome-terminal that would be awful! :)

Well I am clearly not sure my answer might help you out.
Long ago when I was student, I manage to do so (launching an openGL app from a terminal only linux installation) by installing frame buffer. As long as I remember I needed to recompile my kernel (as framebuffer was/is a kernel module).
This was maybe 5 years ago on a debian distrib, and I don't know how does it work now for up-to-date debian distrib as Ubuntu. Maybe framebuffer is compiled statically in the binary kernel provided by default with Ubuntu. May be not. Maybe framebuffer is irrelevant now... Or I may be totally wrong and not remembering every details of my own adventure 5 years ago now ..
Have a look on Google ! ;-)
Hope it will help...
**
Update:
**
What is frame buffer ?
How to install it? Here or there

As yves pointed out, you can avoid running the X server if you use the framebuffer. Actually, the framebuffer modules are often yet available (for example, they are used to have the tux logo during the kernel start or a text terminal with fancy images in the background), this anyway depends on the distribution and the settings you are using.
The kernel side is quite primitive so I'd suggest to use some higher level library such as DirectFB. The framebuffer is usable without problems but don't expect the same maturity level than a full blown X server.

Are you trying to have the video be on the monitor connected directly to the computer?
Is X running on the server?
If X is running, you can do
export DISPLAY=:0.0
which tells X apps to connect to the X server at localhost, rather than where' you're coming from.
If you're actually logging in locally (from a direct terminal) ... yes, you need X installed and running.

Related

Is it possible to use a GUI based text editor (e.g. Eclipse) from the terminal?

I'd like to use terminal for all of my normal git and compiling and running processes (my school has a server that is linked to my repo on bitbucket), but I really don't like terminal-based text editing software such as Emacs and Vim. Is it possible to open and edit files from the terminal using a GUI based text editor? The reason I'm asking is because the terminal is the only way I can access the server files. Thanks in advance!
Aw, but vim is the best! :) Well, you can use nano, which is friendlier. Or, if you insist: if you are using SSH to connect to the server (and the server has an X server running !) then you can look into the ssh -X option to view X windows on your remote machine.
Oh and you could look into scp command as well (behaves almost just like regular cp, but the destination is on another host). That way you could edit on your machine, then copy it via SSH (although you'd want to be careful when copying files directly to the server filesystem)
Edit: Also, if you really don't like using the terminal (why though? (-: ), some file managers allow you to get the same functionality of the previous commands purely via GUI (for example).
You've left out some important information that someone would need to know to answer your questions. The other posters have made some assumptions.
You've mentioned this "terminal", but it's not clear exactly what that is, or how you're getting to it. What kind of computer do you have in front of you? What shell is running in that terminal? Is the shell running on your local computer, or have you remotely connected to a server and running that shell on the remote computer?
Based on what you said, I have a feeling you're making a remote connection to a server, perhaps using ssh. You likely have either a Windows or Mac PC in front of you. In those circumstances, running a GUI editor like Eclipse is possible, but likely not practical. You would have to have Eclipse installed on that remote computer, and you would be displaying the Eclipse window on your local computer using the X11 protocol. That takes a lot of bandwidth.
If my assumptions are correct, my recommendations depend on how long you expect you're going to want to stay familiar with this environment. If you intend to do this sort of work forever, then you should learn vi and Emacs to the best of your ability. As someone who's been using Emacs likely longer than you've been alive, I'd recommend you learn it, but vi is also a critical skill.
UNIXY systems provide open or gopen, depending on your OS, that should get the job done. From the man page:
By default, gopen will open filename with the application currently assigned to the file's extension. But by specifing the -a flag on the command line you can tell gopen to open the file with another application.
This means that you can use it to open files in your preferred editor
with a line like
gopen -a Eclipse file

XLIB C - get window by PID

I begin with xlib and I would like to know if it is possible with xlib in C to "catch" a window with its PID for be able to move the window, resize it...?
For example ask my program the width and height of firefox's window. I do not know if my question is clearer.
Thank you
I guess you mean the process-id of the (Linux or POSIX) client owning the window.
But your question has no real sense: the X client could be on some operating system without process-ids, or it could be running on a remote machine (different of the one running the X11 server), e.g. with ssh -X (and then you cannot do much with that pid). Be sure to understand more about the X Window System (and the roles of client, server, window manager).
However, you could study (with pain and care) X11 Window protocols and architecture (include X11 core protocol), the EWMH specifications (and also ICCCM). Look into _NET_WM_PID & XGetWMClientMachine
(Xlib & all the X protocols are really complex; you would need to read thousands of pages to understand all of them; in 2017 that effort might be obsolete, e.g. because of Wayland; it is preferable to use some higher-level toolkit like Qt or GTK).
If you want to write some X window manager (they are complex beasts, because conventions related to X have become very complex), consider studying the source code of some existing one and adapt it to your needs....
You could iterate through all windows and search for the program that you want by it's name. Afterwards you could use XMoveResizeWindow to move and resize as you please.

Starting a graphical application using sfml on Raspberry Pi boot

I would like to make a Graphical interface for a home-made program using SFML on Raspberry Pi2. I am using Raspbian. I recompiled the graphical lib
It works fine unsing startx first, then using my application, which wors perfectly fine.
But I can't figure if it is possible or how to launch my application directly after boot without launching startx (just to optimise the cpu of the Raspberry).
Starting my program direcly after boot, I get the following error:
Failed to open X11 display: make sure the DISPLAY environnement variable is set correctly.
Aborted.
I already tested the classic export DISPLAY=:0.0 but without sucess.
I interested myself in x and xinit, but I am not sure that would even do it.
Where should I start looking? I don't need a complete solution, even a hint or an idea would be nice!
I checked to see if it was possible to open a graphical app without the X desktop environment and as that answer states, with Firefox at least, you need the X server which SFML also probably needs in order to create a window.
The answer states:
Basically something like:
$ X
Then you just start Firefox in this X server:
$ DISPLAY=:0 firefox
You can switch from the X server and the framebuffer by using
CTRL+ALT+F1 and CTRL+ALT+F7.
You could try that and see if it helps.
Also, still searching, I found a forum post on the sfml website about what you're trying to accomplish stating somewhere:
SFML requires OpenGL, so as far as I know you need at least X running,
but you probably don't need gnome, KDE or a similar Desktop
Environment on top.
The forum guy asking for help seems to have managed to get X11 and a SFML basic render window to work on Ubuntu server after someone posted a link to xinitrc. I guess, that's the route to go from here.

How to turn a Linux application in C/C++ into a Desktop Environment for a Linux distro?

Is it possible to write an program in C/C++ and then turn that into a Linux Desktop Environment?
I want to take an program, and then be able to boot into my Linux distro and just see that.
Say I have a Linux program which is a window containing "Hello World" on a white background.
How can I make that program into a Linux Desktop Environment for a distro, where you boot and just see: Hello World, on a white background.
Any ideas? Let me know if that made no sense.
Edit: I am not talking about cross-compiling.
You don't want to be modifying rc files. Use your distro's existing mechanism for controlling lightdm/gdm/other and starting X. You want to create a new X session type by writing an Xsession file, so that your DE shows up as another DE alongside KDE and GNOME. Put your script in /usr/share/xsessions (and see the existing examples there).
You either want to
create a boot loader, or
you want to replace the 'shell'.
This would be governed by per-user or global xinit and Xsession files.
Your requirement: Run your own GUI application automatically, after system starts up. Am I right?
Here is what I have done with such requirement (I succefully made it working under Slackware):
Allow auto-login after system boot
Make a customizable Window Manager to be default WM lauchedby startx (I use FVWM)
Configure WM to launch your application after it starts up, and disable unneeded shortcut keys
Edit user's startup script (such as .bashrc or .bash_profile) to startx
Now, you can reboot to see whether it works.

Prevent Mac Laptop from sleeping when closed?

I'm writing a program in C and want it to have an option that will keep a mac laptop awake even if the lid is closed so processes can continue. There seems to be very little information available on this topic so I really don't know where to begin. If anyone knows how to accomplish this or where I can find more information I would really appreciate (i.e. will I need to work with the BIOS for this or are there built in functions?). Also, if it's easier to do it in another language that is fine as I'm not stubbornly set on using C.
You need to write a kernel extension for this. The OS doesn't support it by default because the laptops aren't designed to properly cool themselves with the lid closed and internal display enabled. SleepLess is a $10 utility that'll do what you want, too. If you warp the display or something, it's your own fault. :-).
If you want to write something yourself, LidSleep.kext looks like a good start (it does the opposite, i.e. sleeping on lid close) and comes with source code.
(It is possible and supported to wake up some Mac laptops with the screen closed by using an external input device.)
You can do this using the I/O Kit framework, see QA1340 listing 2 for sample code using IOPMAssertionCreateWithName to temporarily prevent sleep.
The link to LidSleep.kext listed above is not working, so I can inform that the author of NoSleep has made the source code available here, so you can see for yourself how it can be done:
https://code.google.com/p/macosx-nosleep-extension/
If your laptop is a reasonably recent model, you don't need to add anything. If you are running Lion, it simply works. If you're running an older OS you have to wake up the laptop by sending it a keystroke or mouse click from an external keyboard or mouse. See http://support.apple.com/kb/ht3131

Resources