openGL without X11 windows manager

I am just starting to use my Jetson TK1 and would rather run in the console. Is it possible to run OpenGL applications that may link to the X11 libraries but not require the X11 window manager? I don’t need windows at all.

It may not be X11 you really want to get rid of. Perhaps it is really the window manager and desktop software you don’t need. Many people don’t realize that X11 is just a gray background and a mouse pointer (and the pointer is plain and ugly). All of those menus and the ability to run different things at the same time are products of the window manager. When X runs it takes a single program as its argument…that program is the window manager, and the window manager can be replaced with something else. Well, technically the default desktop starts via the login manager, but the login manager is still only one program and is designed to replace itself with the window manager once a desktop and login user name are picked.

The nVidia hardware accelerated video driver has an interface which is tied to a given X11 ABI version. Unless you have a replacement for X which uses that ABI you can’t keep the nVidia hardware acceleration…there are alternatives, but they are slow and remove access to the GPU.

So knowing more about what it is your use case might help. Because part of the login process under a windowing system is security it would also help to know if the process can run as root or needs user login (in which case the login manager could still be used, but the program it overwrites itself with would not be a window manager).

1 Like

My goal is to build a single embedded like application that starts as a daemon from an init.d script. Other daemons will run, just not the X window manager. The application will fill the entire screen. I suspect the application will need to run as root because when the application is closed a call to something similar to “shutdown -h now” will be used. I don’t know much more because I don’t know all that is necessary to make this work correctly.

While the application is running I need to be able to make calls to openGL to render a UI and it would be important to use the cuda cores on the board.

X is separate from the window manager (the windowing stuff is a child process of the X parent process). Getting rid of X gets rid of graphics capability, including OpenGL and CUDA…getting rid of the window manager gets rid of just the windowing support…X is the parent of a graphics program regardless of whether windowing is used or not (and in a standard case the window manager is in turn parent to individual applications…making that application a grandchild process of X).

Daemons are not affected by this. Removing the window manager but not X means you can have that single application with nothing else running there (you’re just replacing the window manager and its children with your custom OpenGL app). Running such an application as root simplifies things…so long as it runs as root the default behavior already does what you want.

Normally the application associated with a terminal is designed so that when you exit the process respawns waiting for a new login regardless of whether it is a text console or graphical. This is because of the parent process monitoring that child process, and not because of the child process itself (to run OpenGL your process must directly or indirectly be a child of X). The parent detects the end of a child and spawns a new login terminal (or in the case of graphics, X would start). What you are describing is simply placing a shutdown command in your custom program upon exit or destructor. Then spawning the program on system startup would occur normally, and there would be no need to modify anything in init to alter initial startup of X. The exit destructor would intercept respawn before it occurs. The only weakness would be if there were a crash of your program and the destructor was never reached…if that is an issue perhaps a wrapper could be created (a launcher of sorts which shuts down upon end of the OpenGL app regardless of the app ending normally or via exception…this would be fairly simple and avoid having to modify the OpenGL program itself…this would make the wrapper generic and interchangeable with other apps).

I took your advice and looked into replacing the window manager. I tried the matchbox-window-manager and it looked ok but didn’t get any keyboard input. I am going to look at tinywm to see if will work, it will llow me to play around and see what I really need. Any input here would be good. I need to be sure I am going to be able to use the openGL tools in an application.

You don’t actually need any window manager at all…name your program as if it were a window manager within the proper init files (I’m not positive where, but likely one of the xorg.conf type files in “/etc/X11”).

If your setup with a window manager is able to use the keyboard then it means the XInput extension is working and passing on input events. If the same xorg configuration exists with your application running in place of a window manager, then those events should also succeed in reaching your application. If you had a window manager (such as matchbox) running, then this could filter out and catch input events and make it appear there is no keyboard. If there is no window manager at all, then all events get passed to the OpenGL app unmodified with no filtering.

If you look at “/var/log/Xorg.0.log”, see if you see any comments about failing XInput or input devices.

I have not tested this, but if you look at “/etc/X11” you should notice a file “default-display-manager”. That lists the full path to the windowing software, “/usr/sbin/lightdm”. You might try making sure that lightdm works normally in an unmodified configuration…and then as an experiment when you know lightdm is working, replace “/usr/sbin/lightdm” with your application’s full path (it is possible other edits would also be needed based on environment).