Launch Application & Lockout Desktop

We have a Product that we are developing using a Jetson Xavier NX.
I am wondering what the Proper Method would be to have my Application Run which utilizes Python, CV & PyQT5 GUI & have the “Desktop” & “System” un-accesible?
Would ideally like all “Updates” blocked as well?

Thanks,
Scott

The update question is standard for all Ubuntu. You will find this useful:
https://linuxconfig.org/disable-automatic-updates-on-ubuntu-18-04-bionic-beaver-linux

So far as the blocking of GUI goes, does your application only display, or does it also accept user input? Can you give a use case of how the end user is going to interact with this display?

Thanks for the Update Link.

It displays images from Camera & utilizes PyGame for some Thermal imaging.
They typically interact with Voice Commands.
During Setup they would plug in a Keyboard & Mouse to enter SSID & pwd

Is this to run from the same GUI as the camera app? Can I assume that SSID and password probably change a lot?

Is the voice command software directly tied to the application, such that the commands are part of the same program? Or is this a separate program which does not require GUI?

It is all in one Application that Runs as 1 Single GUI, PyGame window Pops up in front Launced by the Same Application. Voice & Voice Commands are all part of the Same Program. The GUI for it was written using PyQT5.
Basically trying to Launch it on it’s own so they Do not need to see the Ubuntu Desktop, just our GUI

Somewhere else I had this information, but am no longer sure where it is at. I’m only answering one side of this. FYI, others here may be able to tell you how to use gstreamer to display this without X at all. Below this I will tell you some information on how X is organized which you will find of use if the long length does not cause you to fall asleep :P

What most people think X does is to provide a window manager, and this is far from the way it actually works. X in no way supports more than a single application, and does not provide menus and desktop backgrounds, so on. All X does is provide a uniform API into a graphics capable buffer. The login manager and the desktop manager are very different applications and do not need to be used. X is quite capable of running just an application, and in fact that is really all that X can do.

During a normal boot of the GUI X is told to run one application. The default is a login manager. When login is authenticated, X overwrites it self, and once again runs only one application, but this time the application is a desktop manager. The desktop manager is capable of running different applications concurrently, X is not.

If you were to run X all by itself, then you’d see a primitive pointer and a bad gray background. This is all you would have.

If you start X with an X-enabled graphical application as an argument, then your one application is all that would start. This seems like what you want.

The overall boot of Linux to the point of allowing text mode launches several “getty” programs, and the one which is active depends on key bindings of “ALT-F1” through “ALT-F7” (or approximately this, different distros can use different numbers of terminals).

The overall boot of Linux into a GUI mode replaces one of those getty instances with an X server which is given the login manager as an argument, and runs as root. When in the GUI the key binding changes to “CTRL-ALT-F#”, and if you select the getty which is running X, then you go back into GUI mode.

You can in fact run X on more than one of the terminals. If for example the default of the system is to run X on CTRL-ALT-F1, and you go to CTRL-ALT-F2, then you would normally end up in text mode, but if you run X on the second getty, then in fact you will merely switch between two independent X sessions (but CTRL-ALT-F3 through Fn would remain text mode).

If you do encounter a login manager, and choose to log in, then what it does is overwrite itself and start a new X session, but with a window manager argument, and suid your user instead of as root.

The “startx” command is a human readable script. You should run “which startx”. Then read about this and experiment with it. Do not experiment from the GUI…experiment from a text terminal. You’ll find that the “X” (“Xorg”) binary itself can be run as a command line program. “startx” is a convenience wrapper to this. You could for example use this to run X with a normal desktop as whatever user runs this, or you could run X with your program name as the command line. Then you would not have a window manager, and all of those services and key bindings and “fluff” would go away. You don’t have to start with your program (since it might complicate testing), but you could for example experiment what it takes to startx with just “xterm” as the running software.

You will need to set some environment variables to do this, especially the “DISPLAY” variable. Each running X server must have its own DISPLAY, e.g., usually starting “DISPLAY=:0”, and numbering increasing, but there is no rule numbering has to be in order. You could start as “:8” for example. See:
https://www.google.com/search?source=hp&ei=DJyhX-D3GsXVtAbu45iQCA&q=how+to+use+startx+command+in+linux&oq=linux+how+to+use+startx&gs_lcp=CgZwc3ktYWIQAxgAMgkIABDJAxAWEB46DgguELEDEMcBEKMCEJMCOgUIABCxAzoCCAA6BQguELEDOgsILhCxAxDHARCjAjoICC4QsQMQgwE6CAgAELEDEIMBOggILhDHARCjAjoICAAQsQMQyQM6CAguEMcBEK8BOgUIABDJAzoGCAAQFhAeOggIIRAWEB0QHlCJCFi-HWD_MWgAcAB4AIABaogB0QuSAQQyMS4ymAEAoAEBqgEHZ3dzLXdpeg&sclient=psy-ab
(sorry for the long URL, it is just a google search)