I want to script opening chromium in kiosk mode under Linux (openSUSE 12.3) and XWindows, while controlling which monitor chromium appear in. I also need to have this script be run outside of a standard xterm, e.g. via ssh into the machine where chromium AND the display will run (i.e. I want the application to appear on one of the displays of the machine I'm connecting to, not the machine I'm connecting from).
I can do everything I want by hand in xterm on the target machine, but I won't be running these scripts in xterm. Somehow, the xterm environment is special: it knows how to talk to the containing XWindows session, and in fact knows which actual monitor it is hosted on. For example:
When I ssh into the machine and try to run an XWindows GUI on the target machine's display, it (reasonably) complains "Can't open display". However, even when I set the DISPLAY environment variable to the same value I see in xterm, I still get the error (although it now includes the current DISPLAY value). I've also tried setting DISPLAY to a variety of permutations on ":X.Y", where X and Y are small integers, but again to no avail.
If I run chromium in --kiosk mode from xterm, it takes over the monitor that currently contains the xterm window. If I drag xterm to my other monitor then chromium will launch in that monitor. I want that control when I launch chromium from my script, but can't figure out the background magic.
For window manipulation, I've seen suggestions to use wmctrl or devilspie, but I'm a bit nervous about depending on tools that haven't been updated in years. I'd also prefer to have chromium launch in the right place right off the bat, rather than having it appear in the wrong place and then be moved. And neither app can help me launch the app remotely.
So, here are the questions. First, how does xterm tell chromium how to connect to the right XWindows session and monitor? Second, how do I simulate that from a completely separate ssh connection? (Again: it's more than just the DISPLAY variable.)
Thanks,
Dan
You can't open X client on the target machine's display because of permissions: not anyone that can ssh into a machine may "take ownership" of it's screen. These are things controlled by xset -- read up on it.
As for the display: I assume that the specific monitor is controlled by the second part of the DISPLAY environment. At least that's what I remember from reading about X. I've never actually worked in a multi-monitor X environment.
Xterm is not special. Your mouse pointer is. Chromium will appear on the monitor your mouse pointer happens to be in. This is probably the default behaviour of your window manager.
Chromium does not respect the usual window position requests. You cannot tell Chromium where to appear, you must tell your window manager where to place the Chromium window. Methods of doing that, if they exist, totally depend on what window manager you have.
If you ssh to your machine as the user that has started the X session, you should have no problem connecting to that session.
Related
OH GOD I'M SUCH A NOOB
wait let me explain this.
I am somewhat familiar with linux, and i own a raspberry pi which i use as a ssh server, but i recently got hold on a old Dell Precision M4300 Laptop, so i got a minimal debian installation on that as well.
Howerver, as i logged in directly (as using the display and keyboard on the machine) to the laptop, i discovered a strange thing:
When executing a command resulting in a new menu, for example
nano .bashrc
, and than exiting that menu, the output gets shown where previously only the list of typed in commands and outputs was. This seems somewhat logical, as the "menue" is a "command output" as well, but when sshing to the machine from my windows machine (via gygwin or putty), the "menue" closes and i see the list of prompts and command outputs again, the same happens when sshing to the raspi. Is this a speciality of Putty / Cygwin? Can i make bash on the machine clean up after nano?
Thanks for any replys, i am really out of ideas here, i don't even know the right search term...
The functionality you are talking about is implemented by smcup and rmcup which can be used by editors such as nano and other applications to save and restore the screen when they are invoked and exited. This functionality is known as alternate screen and you can find more documentation regarding it here. Some people actually are quite annoyed by it.
Unfortunately, if you're using the linux virtual console instead of X windows or even connecting into the machine via ssh from another computer, then it seems like this feature is not available, according to this other post.
This one is a pretty strange question of mine so I'll try to explain the best I can.
On a DOS Linux distribution, without having installed any graphical environment, if I start an application which is supposed to have a GUI, will I be able to interact with that window via code?
What I thought is that if KDE/GNOME's role is to graphically represent an existing GUI, I should be able to interact with it but if these graphical environments have an active role in the window creation there is nothing I can do.
You won't be able to run a graphical program without a window manager.
The reason is that the window manager is doing a lot more than just allowing the window to be shown to the user. It comes with libraries and services for constructing windows and components and interacting with them. Without these libraries and services, the program won't be able to start.
The only exception would be if a program contained all the graphical code built into it, and didn't rely on a window manager. Realistically this would only happen for a fairly simple program and in special cases; for instance, Raspbian includes OMXPlayer, which shows full screen video without relying on any window manager.
Quoting (with some adaptation) from https://raspberrypi.stackexchange.com/a/3974 which answers how to start mplayer in X11 without a window manager:
The X server is really usually called X and you can just start it. You can set the DISPLAY number as an argument along with some other things.
You might want to have some sort of session, though, and still go through xinit or such and start X with startx. You can use .xinitrc or such as a script and simply not start a window manager there. You will need a "magic client" as the last command that stays running so X doesn't terminate immediately. In a traditional "failsafe" session, that was an xterm. If you know what to launch and launch once only, it could be that program or any UI/wrapper that does the launching for you. When the last ("magic") client in the init script terminates, X terminates.
If all you want to do is play video, you might see if you can run mplayer with directfb instead and skip using X11 entirely.
I'll start off by saying I'm no Linux guru, or even close. I use it to develop embedded applications and it serves my purposes just fine as such.
I have a program which is running (I suppose the correct terminology is "running in a terminal") on a CentOS 6.3 box. For debug and statistics, I have a routine which monitors the keyboard (stdin file) and spits out items as requested by the given key-presses. That all works fine when I'm sitting in front of it.
But I'd like to be able to perform these simple functions: press a key, see some output, remotely. I can SSH into the box and execute commands, but I can't "see" this program.
I have tried searching "communicating with other terminals using ssh" and myriad variations, but I guess I'm not asking this correctly -- the search results are worthless.
What I'd like to be able to do is login to my account and then somehow "see" my program running and type keys and see its output. Is this a stdin/stdout redirection issue?
I apologize in advance if this is painfully obvious and I'm just an idiot, but I'd still like to know how to do it... :)
If you use the linux 'screen' utility, you can re-attach to the original terminal session that you used to start the program. basically you just type screen and then run your program. here is more useful info on screen:
http://www.rackaid.com/resources/linux-screen-tutorial-and-how-to
I am having some problems with launching firefox from a Linux daemon written in C.
When I launch firefox on the machine itself (via terminal) from the command shell using /usr/bin/firefox it works OK and a firefox browser window lanunches as it should.
However if I try this within my C daemon using system("/usr/bin/firefox"), firefox launches its process in the terminal but the browser window is not opened?
A similar thing happens when I try to do this using remote terminal acces. It's something to do with telling the system to open firefox in window mode rather than trying to open it in terminal mode - but I dont know how to specify this using bash commands?
I am using Lubuntu 11.10 in my Linux System.
Any help is most appreciated.
There's a reason I asked why you're attempting to do what you want. I didn't want to get into great details in my comment.
Firefox on Unix is an X-Window process (most of the Linux/Unix desktops are based upon the X11 protocol which is the heart of X-Window). What X-Window does is separate the display of the program from the process running the program. For example, I am now running Firefox from a Linux box at work, but the Linux box is actually displaying the Firefox browser window at home on my Mac.
In order to do this, I had to:
Run X11 on my Mac. The X11 program creates a default X11 client display called 0.0 which pretty much says the first screen and the first instance of X11 running (computer geeks like counting from zero). The process runs in the background on my Mac. In a certain sense, it's really a server process and not a client because it's waiting on port 6000 for a client X11 process (Firefox) to tell it what to do.
Before I run firefox, I have to tell my Mac's X11 process that I grant the X11 server running Firefox to be able to display on my X11 client process. Otherwise, you can imagine someone spamming another person by continuously popping up Windows on their display. You can use the xhost program to do this.
In order to run Firefox on the Linux box, I have tell the Firefox process what X11 client I'm running it on. I can do this by setting the DISPLAY environment variable to something like "10.0.1.33:0.0". This means the X11 client is running the the machine on IP address 10.0.1.33, and I want you to use the first screen, and the first instance of the X11 client on that screen.
Now, I can run Firefox on my Linux box, and the display will display on my Mac.
The problem you're running into is that there's simply no X11 client when you're starting FireFox as a daemon process. An X11 client is associated with a user and a display of some sort. The display could be a virtual display, but there's got to be an X11 client that's running and is addressable in some way, so the process knows where to display the output.
By the way, you said daemon which has a very, very specific meaning in Unix/Linux. A daemon is a process that runs in the background and usually has a service (and a port) associated with it. For example, there's an FTP daemon called ftpd, the mail server uses the sendmail daemon, ssh has the sshd daemon. Daemons have no display associated with them.
However, it looks like you might be using the word to mean launching Firefox via another process. Is that true? If so, you'll have to make sure that Firefox knows the X11 display to use (there's a command line setting to use to specify the display), and that your X11 client (your login session) has given permission for another process to update your display with the program window.
Can you please explain what you're trying to do in a bit more detail? If you simply want to download a file from a remote http server (which of course is running the http daemon process called httpd), you should use curl or wget which don't require a display and are way simpler to use. If you're trying to do something else, let us know exactly what it is.
Firefox needs to know which display it should open on. When you run it from within a gui, even through a terminal emulator, the DISPLAY environment variable is set to the appropriate value. When you launch from the daemon, try system("/usr/bin/firefox -display=:0").
Make sure that the DISPLAY environment variable is properly set in your daemon to refer to the X server that you want your firefox to use.
If the daemon is run as a different user account than the user account that "owns" the X server that you want to use, you will also need to use xauth(1) to configure the authentication token to grant permission to use the X server.
Often times, it is far easier to use ssh -X to tunnel X and properly configure the xauth(1) tokens in one go than try to manage xauth(1) tokens yourself. Maybe adding ssh -X into your environment would be suitable, maybe not. (I've even used ssh -X root#localhost before when I needed to run an X client as root and didn't want to bother with configuring xauth(1) manually. ssh(1) is just so much easier.)
I have got a gtk application. I want it to start automatically when I boot up the system, such that instead of getting usual login screen, my application greets the user.
My application is a sort of cash dispensing application. So user should not even see the login screen of linux. Whenever machine in boot up, after loading services and all that, my application should appear on the screen. One should not have to put any password or login in anyway to start that application.
Now so far I have tried the following but all in vain.
I put the command in my /etc/rc.local file
/home/EXE/cashier
Then rebooted machine in run level 5. But nothing happens. I get the usual login screen. Other programs that do not involve any gui or gtk, they are automatically started in this manner but not the gtk application.
Then I put
xint /home/EXE/cahier
and later
xint /home/EXE/./cashier
But they too didn't work. When I looked into details, I found out that "An Xserver is already running on screen 0, cannot open other server" or something like that.
Then I tried booting into run level 3, this time it worked.
xint /home/EXE/.cachier
But in run level 3, the font and icon sizes are smaller. Moreover some windows do not cover the whole screen.
Now I will really appreciate a way to run my application in run level 5, without showing login screen automatically.
Regards
Edit
Currently, the application is running on fedora core 2
This is more a question about linux distribution startup than it is about Gtk applications. The specifics are going to depend on your distribution, but the essence is:
Disable the gdm facility, which is normally responsible for spawning your X server.
Run xinit (not "xint") to start the server manually. This takes a client as its argument. It may work to run your Gtk application directly (it needs to be smart enough to position and size itself instead of relying on a window manager), but more likely you will want to pick a window manager to run it in. The easiest way to do this is via script that you pass to xinit.