3

I have local machine (A) and Raspberry PI 3 (B).
B has HDMI monitor connected, and is running Raspbian OS.

I want to run X application on A - say Libre Office Impress presentation that I have on A, and have it visible (be displayed on) on screen connected to B.
I want to do that in front of A machine:

  • not by ssh -X to_A from B,
  • nor using VNC from B to get output from A

I am not looking for:

  • Running X app on B using ssh from A and having its output displayed on A (this can be done either by from_a $ ssh -X machine_B or rdp/remmina/vnc clients)
  • Running X app on B using ssh from A and having its output displayed on B (this can be done either by exporting display in ssh and proper configuration of xhost, for example from_a $ ssh machine_b from -> at_a_but_sshed_onto_b $ xhost + && export DISPLAY=:0 xeyes )
  • solution that requires direct physical access to B

What I tried, was setup (B) in order to run remote X items...if I haven't forgotten about anything - since nmap -p6000 machine_B returned that port is closed, and running (from A's commandline):

A_machine $ env DISPLAY=B_machine:0 xeyes

where B_machine is set in /etc/hosts as well as ~/.ssh/config fails.

What I suspect, is that I miss entirely step with copying X11 magic_cookies from .Xauthority...but maybe this step is not necessary and there is a simpler way?

Edit: in response to @Rostislav Kandilarov question - it would seem that lightdm starts X server, but soonest I'll be able to check that its Monday, as well as verifying if it starts with --nolisten tcp.

  • How you start X on (B) ? xdm, kdm, gdm... There is usually restriction that is binding the X only to socket or localhost. Try to disable -nolisten tcp or the equivalent... – Rostislav Kandilarov Nov 4 '16 at 19:12
2

(Edited, old answer below)

With the additional requirement that you want to do all this from A, without touching B, the problem with running an X server on B and connecting to it with an application on A is that this X server only will use input devices (keyboard, mouse) connected to B. So to use your application, you'd have to use these input devices, which you don't want.

In principle you could try to share the input devices from A, but then the construction really starts to get byzantine ...

So VNC is a lot easier in this situation.

Set up a vnc4server on A. This server will also act as X server for applications on A. Start a xvnc4viewer on A, and use it to start and control your application. Start another vncviewer on B and connect it to the server on A, it will display the application. It can be as simple as directvnc (use the framebuffer of the RaspPi directly, no additional detour over X, so less workload for the RaspPi), or if you want to keep running an existing X server on B, anoth xvnc4viewer.


The easiest way is to use a remote desktop like VNC, very likely already available as a package in your distribution. That works usually much better that X forwarding via ssh or otherwise, because it's much better compressed and doesn't use X primitives on the wire.

Of course there are also several ways to set up X forwarding, over ssh or directly. For example you can log in via ssh -X from B to A, run your application on A, and have the output displayed on B. (You ruled out the reverse direction, but didn't say anything about this one, so I'm not quite sure if you want that).

You can also configure the X server for a remote session via XDMCP. Or make a single application use a remote X server using proper xauth and DISPLAY settings.

But I'd still recommend to try VNC first.

  • Thanks, but please re-read my question. My goal is to send output/display from A to B. In solution You are proposing I would need to ssh from A to B, from B ssh -X A run app on A with display on B, just imagine how slow this would be, provided B is embedded platform. VNC solution is opposite to what I described that I am trying to do. – JustMe Nov 5 '16 at 12:24
  • I didn't say anything about "ssh from A to B", and in fact even if you'd do that, an additional "ssh -X" from B to A wouldn't work. So you have the additional condition (which you didn't mention) that you want to do all this while sitting in front of A, and not touching B? And no, VNC isn't "the opposite" to what you've described. Please read up on the X protocol and the VNC protocol, and what actual goes over the connection, and what determines the speed, given the way modern applications use X. – dirkt Nov 5 '16 at 16:12
  • Sorry if this got you confused to think that I want to do this from (B). I'm familiar with differences between X and VNC in terms sharing, yet my point wasn't to differentiate between them but simply point that if I wanted to do this from (B) i could simply use ssh -X A with forwarding, or VNC like you mentioned, and I've written in question that I want "reverse RDP", which I thought will be understandable for all, that I don't want to do normal RDP from B to A. I'll add this requirement - doing all from A, to the question. – JustMe Nov 5 '16 at 16:23
  • Answer edited for condition "don't touch B". – dirkt Nov 6 '16 at 8:05
  • 1
    You were right that only way to control such forwarded app running on A, displayed on B would be through B controls. Unless using VNC which is why i've selected this as answer. It is a little cumbersome, and for example evince crashes for some reason, but most apps have no problem. – JustMe Nov 7 '16 at 15:28
1

So if you are using Raspbian OS on (B), if you haven't done any specific customisation as you've suspected you're probably using lightdm .

For sure you need to tell lightdm to forse the X server to listen to tcp (port 6000). You do it by setting xserver-allow-tcp=true in the conf file in the global section [Seat:*]. You may also need to specify explicitly xserver-command=X -listen tcp (have a look here). It is your choice between any extra file in /etc/lightdm/lightdm.conf.d/*.conf or directly in /etc/lightdm/lightdm.conf.

Next, if you do not care too much for the security you probably will also need to run on (B) some form of xhost + command like xhost + IP_OF_(A). If you do care about LAN vulnerabilities you should not use directly X over tcp in first place, but without ssh you can give a bit hack hardness exchanging a MIT-MAGIC-COOKIE between (A) and (B) by running on (B) xauth extract - $DISPLAY | ssh (A) xauth merge - .

Then restart lightdm service lightdm restart or systemctl restart lightdm.service depending on your OS version.

Last - check on (B) if Xorg is listening on 6000 netstat -antp | grep -F 6000

  • 1
    Solution is good, and You can actually view item, single app just like i thought it should be able - but only way to control such application would be through B controls, which was not my point - thus I'll need to select VNC solution – JustMe Nov 7 '16 at 15:26
  • After getting your final idea I would have also voted for the VNC :). Although there are some tricks that you can export your (A) mouse and keyboard adding the X on (B) as kind of extra virtual monitor attached to the X on (A) using program as synergy... but as dirkt pointed out it would start to be too much :)... – Rostislav Kandilarov Nov 8 '16 at 15:19
  • But I'm happy I could test Your solution too, as it is written clearly, concisely and overall is easy to understand. If someone would want to use RPi for demo purposes, which a little different requirements than me - it would surely help. – JustMe Nov 9 '16 at 9:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.