Hi,
I managed to build x2goserver with all its dependencies and requirements from scratch (my PC runs a Linux From Scratch).
There is no problem to connect from a Windows notebook (client v4.1.2.0) to a local desktop on the Linux server (v4.1.0.3) using the integrated X-Server of the Windows client.
The pulseaudio support, however, I am a bit at a loss with.
The pulseaudio server runs on the Windows notebook and I'm able to play sound from the Linux server, but only by - locally - using something like PULSE_SERVER=192.168.0.2 (the notebook) and after manually copying the pulseaudio cookie file from notebook to PC.
My question is: How is the Windows client supposed to pass this information to the PC, so that the sound client knows how to reach the pulseaudio server? (I could go without cookie using auth-ip-acl (assuming that it works with domain/host names) but the server's config file is created by the client, so I don't know how to overwrite it, and I'd missing the pulseaudio server's address anyway.)
Ingo
I don't know how that works in detail. But the basic principle is to run an ssh server on the windows client and connect to it from the server. So maybe check if your windows firewall is the culprit.
Does file sharing in x2go work?
Uli
Ingo Brückl <ib@wupperonline.de> schrieb am Mi., 27. März 2019, 05:44:
Hi,
I managed to build x2goserver with all its dependencies and requirements from scratch (my PC runs a Linux From Scratch).
There is no problem to connect from a Windows notebook (client v4.1.2.0) to a local desktop on the Linux server (v4.1.0.3) using the integrated X-Server of the Windows client.
The pulseaudio support, however, I am a bit at a loss with.
The pulseaudio server runs on the Windows notebook and I'm able to play sound from the Linux server, but only by - locally - using something like PULSE_SERVER=192.168.0.2 (the notebook) and after manually copying the pulseaudio cookie file from notebook to PC.
My question is: How is the Windows client supposed to pass this information to the PC, so that the sound client knows how to reach the pulseaudio server? (I could go without cookie using auth-ip-acl (assuming that it works with domain/host names) but the server's config file is created by the client, so I don't know how to overwrite it, and I'd missing the pulseaudio server's address anyway.)
Ingo
x2go-user mailing list x2go-user@lists.x2go.org https://lists.x2go.org/listinfo/x2go-user
Ulrich Sibiller <ulrich.sibiller@gmail.com> wrote on Wed, 27 Mar 2019 07:43:46 +0100:
My question is: How is the Windows client supposed to pass this information to the PC, so that the sound client knows how to reach the pulseaudio server?
I don't know how that works in detail. But the basic principle is to run an ssh server on the windows client and connect to it from the server.
In order to establish a connection to the Windows client I'd need its current IP address and the pulseaudio cookie which the Windows client should report somehow through the existing connection.
So maybe check if your windows firewall is the culprit.
Not as long as I don't even know the client's address.
Does file sharing in x2go work?
I'm not using it, but a commandline scp, which works fine.
Ingo
On Wed, Mar 27, 2019 at 2:25 PM Ingo Brückl <ib@wupperonline.de> wrote:
Ulrich Sibiller <ulrich.sibiller@gmail.com> wrote on Wed, 27 Mar 2019 07:43:46 +0100:
My question is: How is the Windows client supposed to pass this information to the PC, so that the sound client knows how to reach the pulseaudio server?
I don't know how that works in detail. But the basic principle is to run an ssh server on the windows client and connect to it from the server.
In order to establish a connection to the Windows client I'd need its current IP address and the pulseaudio cookie which the Windows client should report somehow through the existing connection.
Well, I am out here. I have no deeper knowledge of how this is supposed to work.
So maybe check if your windows firewall is the culprit.
Not as long as I don't even know the client's address.
Does file sharing in x2go work?
I'm not using it, but a commandline scp, which works fine.
I was asking that since this is setup similarly to audio, IIRC.
Uli
Am 27.03.19 um 14:21 schrieb Ingo Brückl:
I don't know how that works in detail. But the basic principle is to run an ssh server on the windows client and connect to it from the server. In order to establish a connection to the Windows client I'd need its current IP address and the pulseaudio cookie which the Windows client should report somehow through the existing connection.
Please check the box to use portforwarding via a tunneled connection for audio, that will take care of everything automagically(TM).
Does file sharing in x2go work? I'm not using it, but a commandline scp, which works fine.
That was not the question.
-Stefan
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
Also, I would be very surprised if sound works for a shadowing session (AKA "connect to local desktop").
Am 27.03.19 um 15:03 schrieb Stefan Baur:
Am 27.03.19 um 14:21 schrieb Ingo Brückl:
I don't know how that works in detail. But the basic principle is to run an ssh server on the windows client and connect to it from the server. In order to establish a connection to the Windows client I'd need its current IP address and the pulseaudio cookie which the Windows client should report somehow through the existing connection.
Please check the box to use portforwarding via a tunneled connection for audio, that will take care of everything automagically(TM).
Does file sharing in x2go work? I'm not using it, but a commandline scp, which works fine.
That was not the question.
-Stefan
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
I wrote on Wed, 27 Mar 2019 04:58:50 +0100:
My question is: How is the Windows client supposed to pass this information to the PC, so that the sound client knows how to reach the pulseaudio server?
After taking a look at the client sources, the answer should have been easy: The client passes the required information to the user's ~/.x2go session directory.
Unfortunately, if shadowSession (local desktop connection, I suppose) is set (onmainwindow.cpp:5467) this code won't be executed.
So the question is: why?
AFAICS onmainwindow.cpp should not return in line 5467 and I don't see why the following code wouldn't work with local desktop connections. I'd like to test this, but I cannot compile a Windows client.
Ingo
Am 28.03.19 um 12:56 schrieb Ingo Brückl:
Unfortunately, if shadowSession (local desktop connection, I suppose) is set (onmainwindow.cpp:5467) this code won't be executed.
So the question is: why?
Because it is a *shadow* session, meant for remote support, so the assumption is that there is a local user sitting in front of the physical display, and that should be where sound goes. Else you would "hijack" the user's sound, and there's probably no way of restoring them their sound settings once you disconnect the shadow session.
What's the reason why you're so eager to use a shadow session instead of an actual X2Go session (which would not only have sound and printing/filesharing support, but which would also be faster than a shadow session)?
-Stefan
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote on Thu, 28 Mar 2019 13:24:50 +0100:
What's the reason why you're so eager to use a shadow session instead of an actual X2Go session
There are font issues with a X2Go session that I don't have with a shadow one.
The Windows client has a smaller display (1024x600) than the server (1024x768). I'm using a specially designed 10x18 font for both xterm and xdosemu that looks great (and big enough) on the server display, but on the 1024x600 fullscreen X2Go session the font is so small as if the client display would be 1280x1024 or even bigger. Moreover, and probably as a result, the small looking glyphs are not properly rendered.
With a shadow session both xterm and xdosemu have the usual big font.
Ingo
Am 28.03.19 um 17:33 schrieb Ingo Brückl:
The Windows client has a smaller display (1024x600) than the server (1024x768). I'm using a specially designed 10x18 font for both xterm and xdosemu that looks great (and big enough) on the server display, but on the 1024x600 fullscreen X2Go session the font is so small as if the client display would be 1280x1024 or even bigger. Moreover, and probably as a result, the small looking glyphs are not properly rendered.
Sounds like a DPI issue to me. Have you tried changing the DPI setting in the X2GoClient Session Configuration? And even if that doesn't help, I'm sure there are better ways to get this fixed than to (ab)use a shadow session.
Your approach sounds a bit like "The government insists I need to use glasses when I want to drive a car, so I'll just ride horse carriages instead, even if my destination is 600 miles away, because I just can't be bothered to see an opthalmologist."
Kind Regards, Stefan Baur
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote on Thu, 28 Mar 2019 18:46:41 +0100:
Sounds like a DPI issue to me. Have you tried changing the DPI setting in the X2GoClient Session Configuration?
Yes, either DPI setting (very low or very high) affects all fonts (like menu items, window titles, message boxes etc.), but neither xterm nor xdosemu. Strange!
I tried "custom desktop" and simply gave "sh /home/me/.xinitrc" as an experiment. Everything shows up like my local desktop with two exceptions. Xterm is a very small window with small font in it (as if my X resource XTerm.VT100.font: 10x18 would be ignored or 10x18 is some other font) and xdosemu.
The above holds for starting without VcXsrv's font directory. When I enable the directory and put my 10x18 font into fonts/misc, I get the same small size window, but now with my (too big) font in it. Glyphs overlay.
It seems that the wrong size font is used to calculate xterm's window size at start-up. (BTW, how could VcXsrv run when I removed its font directory as an experiment? Where do fonts come from?)
And even if that doesn't help, I'm sure there are better ways to get this fixed than to (ab)use a shadow session.
I'd love to, but I currently have no idea how to fix it.
Ingo
- On 3/28/19 10:40 PM, Ingo Brückl wrote:
I tried "custom desktop" and simply gave "sh /home/me/.xinitrc" as an experiment. Everything shows up like my local desktop with two exceptions. Xterm is a very small window with small font in it (as if my X resource XTerm.VT100.font: 10x18 would be ignored or 10x18 is some other font) and xdosemu.
The above holds for starting without VcXsrv's font directory. When I enable the directory and put my 10x18 font into fonts/misc, I get the same small size window, but now with my (too big) font in it. Glyphs overlay.
It seems that the wrong size font is used to calculate xterm's window size at start-up.
Try to copy your ~/.Xresources file to ~/.Xresources-x2go . There's a good reason why we decided not to use the "normal" ~/.Xresources file, but an X2Go-specific one. Users set weird things in ~/.Xresources (that were fine for their local X sessions, though), but ran into that when spawning X2Go sessions. Hence we're just using a custom file and don't even make use of the more general ~/.Xresources file.
There are multiple caveats, though. Firstly, this file is only read/executed/whatever for full desktop sessions. Secondly, the actual method of how this is done differs from OS to OS. On Debian (and derivates), we just set a variable that is handled by the usual X11 scripts (/etc/X11/Xsession and friends), while on RHEL (and derivates) and *SUSE (and derivates) we merge both the system file and the user file manually.
Since you're using a completely different OS... well, full desktop sessions might just fail to start up to begin with because our Xsession script will probably not find a release/version file to determine what your OS is based on.
(BTW, how could VcXsrv run when I removed its font directory as an experiment? Where do fonts come from?)
Good question. Generally VcXsrv should still run mostly correctly. Maybe some fonts will be substituted with a default, ugly, built-in font. If I don't remember correctly we don't have fonts installed by default, so users would probably have spoken up if that had caused a lot of breakage.
The whole fonts business has gotten pretty complicated anyway, since most applications (unlike older ones like xterm etc.) rasterize fonts themselves via cairo and output that as either bitmaps or other X primitives, which means that the original X fonts mechanism aren't widely used any longer.
Mihai
Mihai Moldovan <ionic@ionic.de> wrote on Fri, 29 Mar 2019 11:18:56 +0100:
Try to copy your ~/.Xresources file to ~/.Xresources-x2go .
It had nothing to do with the resources file.
(BTW, how could VcXsrv run when I removed its font directory as an experiment? Where do fonts come from?)
Good question. Generally VcXsrv should still run mostly correctly. Maybe some fonts will be substituted with a default, ugly, built-in font.
That's exactly right. VcXsrv's font path is just "built-ins" if there is nothing in the fonts directory.
The whole fonts business has gotten pretty complicated anyway,
Yes, indeed. Nevertheless, I managed to solve my problems.
First of all I copied the fonts I'm using on the Linux PC to the Windows client. I then gained access to VcXsrv's command line options by selecting "use custom X-Server" (but VcXsrv anyway) and deselecting "start X-Server on X2Go Client start" which made the options available. I added
-fp C:/Programme/x2goclient/VcXsrv/fonts/75dpi/,C:/Programme/x2goclient/VcXsrv/fonts/misc/
(my font paths) to all four command line options.
After starting a new connection I was astonished that nothing had changed.
Because "xset -q" (within the session) still said that the font path is just "built-ins", I set the path (and had to use my Linux paths):
xset fp /usr/share/fonts/75dpi/,/usr/share/fonts/misc/,built-ins
For whatever reason (maybe some rendering is done by the client and some by the server), this finally did the job!
So, Mr. Ophthalmologist I'm finally using an X2Go session and am very happy about the fullscreen mode (that could not be used with a shadow session due to a missing or invisible cursor).
And, in order to get back to the subject, pulseaudio works out of the box thanks to the set environment variable.
Ingo
Am 29.03.19 um 19:31 schrieb Ingo Brückl:
So, Mr. Ophthalmologist I'm finally using an X2Go session and am very happy about the fullscreen mode (that could not be used with a shadow session due to a missing or invisible cursor).
Yay! Please don't forget to make a new appointment in 12 months from now so we can check if you need a new prescription.
SCNR, Stefan
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
On Fri, Mar 29, 2019 at 8:23 PM Ingo Brückl <ib@wupperonline.de> wrote:
Because "xset -q" (within the session) still said that the font path is just "built-ins", I set the path (and had to use my Linux paths):
This is weird. Normally you should have more than "built-ins", see below.
If you run xset q inside the x2go session you will see the settings of x2go's X server (x2goagent/nxagent). That one is running on the Linux side, so you must use Linux paths there:
xset fp /usr/share/fonts/75dpi/,/usr/share/fonts/misc/,built-ins
To check the font settings of the Vcxsrv.exe you have two options:
- check the logfile (I am not sure if that is always created; cannot check right now)
- run xset q against the vcxsrv's display
For whatever reason (maybe some rendering is done by the client and some by the server), this finally did the job!
nxagent uses these defaults if no fontpath is specified (using -fp) on startup:
#define NXAGENT_DEFAULT_FONT_DIR "/usr/share/nx/fonts" #define NXAGENT_ALTERNATE_FONT_DIR "/usr/share/X11/fonts" #define NXAGENT_ALTERNATE_FONT_DIR_2 "/usr/share/fonts/X11" #define NXAGENT_ALTERNATE_FONT_DIR_3 "/usr/X11R6/lib/X11/fonts"
#define NXAGENT_DEFAULT_FONT_PATH
"/usr/share/nx/fonts/misc/,/usr/share/nx/fonts/Speedo/,
/usr/share/nx/fonts/Type1/,/usr/share/nx/fonts/75dpi/,
/usr/share/nx/fonts/100dpi/,/usr/share/nx/fonts/TTF/"
#define NXAGENT_ALTERNATE_FONT_PATH
"/usr/share/X11/fonts/misc/,/usr/share/X11/fonts/Speedo/,
/usr/share/X11/fonts/Type1/,/usr/share/X11/fonts/75dpi/,
/usr/share/X11/fonts/100dpi/,/usr/share/X11/fonts/TTF/"
#define NXAGENT_ALTERNATE_FONT_PATH_2
"/usr/share/fonts/X11/misc/,/usr/share/fonts/X11/Speedo/,
/usr/share/fonts/X11/Type1/,/usr/share/fonts/X11/75dpi/,
/usr/share/fonts/X11/100dpi/,/usr/share/fonts/X11/TTF/"
#define NXAGENT_ALTERNATE_FONT_PATH_3
"/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/Speedo/,
/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/75dpi/,
/usr/X11R6/lib/X11/fonts/100dpi/,/usr/X11R6/lib/X11/fonts/TTF/"
Nxagent will check if the four FONT_DIRS exist. For any existing dir it will add the corresponding path to the fontpath. Finally it will append ",.built-ins".
If you fontpath inside the session if only "built-ins" none of the mentioned dirs is existing on your server. Can you please verify?
Now the question: where's you special font located? What does xset q report if you just open a simple session with an xterm and nothing else? What does it report for a full session (before applying your fix)?.
Uli
Ulrich Sibiller <uli42@gmx.de> wrote on Sat, 30 Mar 2019 13:14:11 +0100:
Normally you should have more than "built-ins",
That's the least strange thing.
nxagent uses these defaults if no fontpath is specified (using -fp) on startup:
None of the paths apply in my case: /usr/share/fonts/{75dpi,misc}, so I don't wonder about having only "built-ins".
If you run xset q inside the x2go session you will see the settings of x2go's X server (x2goagent/nxagent).
Oh, I see. I didn't know nxagent is a nested Xserver.
To check the font settings of the Vcxsrv.exe you have two options:
- check the logfile (I am not sure if that is always created; cannot check right now)
There is one, but no information about the font settings in it.
- run xset q against the vcxsrv's display
Wouldn't I need an xset binary (and more?) for Windows to do that?
If you fontpath inside the session if only "built-ins" none of the mentioned dirs is existing on your server. Can you please verify?
Yes, I can confirm.
Now the question: where's you special font located?
Currently on both the Linux machine and a copy on Windows.
What does xset q report if you just open a simple session with an xterm and nothing else?
I don't know what you mean by "a simple session".
What does it report for a full session (before applying your fix)?.
"built-ins" only.
Ingo
On Sun, Mar 31, 2019 at 1:14 AM Ingo Brückl <ib@wupperonline.de> wrote:
nxagent uses these defaults if no fontpath is specified (using -fp) on startup:
None of the paths apply in my case: /usr/share/fonts/{75dpi,misc}, so I don't wonder about having only "built-ins".
If you run xset q inside the x2go session you will see the settings of x2go's X server (x2goagent/nxagent).
Oh, I see. I didn't know nxagent is a nested Xserver.
To check the font settings of the Vcxsrv.exe you have two options:
- check the logfile (I am not sure if that is always created; cannot check right now)
There is one, but no information about the font settings in it.
- run xset q against the vcxsrv's display
Wouldn't I need an xset binary (and more?) for Windows to do that?
This is X11, so you only need an xset anywhere and an X server (vcxsrv) that allows remote access.
I don't a have a windows installation at hand where I could test that, but in principle it works like this:
So what you do is this:
- run vcxsrv with the option -ac. This will disable access control.
- run xset -display <vcxsrv's hostname>:<vcxsrv's display number>
Maybe you have to disable the windows firewall for that.
If you fontpath inside the session if only "built-ins" none of the mentioned dirs is existing on your server. Can you please verify?
Yes, I can confirm.
Alright, the problem then is that Linux From Scratch is using fontpaths that differ from the default ones. You can pass the correct font paths by adding the appropriate -fp option to /etc/x2go/x2goagent.options.
Can you please send us the correct list (derived from the defaults I posted earlier) for your distribution? We then can add this to source code (although I think we should revise that code to determine the system's default patch automatically during build.
Now the question: where's you special font located?
Currently on both the Linux machine and a copy on Windows.
I am interested in the path. BTW: I doubt you need the fonts on the Windows side, so please re-test with the fonts removed from windows.
What does xset q report if you just open a simple session with an xterm and nothing else?
I don't know what you mean by "a simple session".
Does not matter now, as we have found the root cause: unusual font paths on your system.
A simple session is one that does not start a full desktop environment like xfce but only a single xterm. You can achieve that by selection "Application" under "Session Type" and specifying a full path to the xterm in the right input field.
Uli
Am 31.03.19 um 11:59 schrieb Ulrich Sibiller:
I don't know what you mean by "a simple session". Does not matter now, as we have found the root cause: unusual font paths on your system.
A simple session is one that does not start a full desktop environment like xfce but only a single xterm. You can achieve that by selection "Application" under "Session Type" and specifying a full path to the xterm in the right input field.
Note that some applications don't like to be started that way, resulting in an instant termination of the session. If that happens, use "Published Applications" instead (this will keep the session running) and select the desired application from the list.
-Stefan
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
Ulrich Sibiller <uli42@gmx.de> wrote on Sun, 31 Mar 2019 11:59:24 +0200:
Alright, the problem then is that Linux From Scratch is using fontpaths that differ from the default ones.
My font paths may not be pure Linux From Scratch, so don't bother changing any font path settings in your sources.
Actually, /usr/share/fonts is the default location of fonts in fontconfig and LFS sets a link for TTF fonts (ln -s $XORG_PREFIX/share/fonts/X11/TTF /usr/share/fonts/X11-TTF). I decided to put *all* my fonts directly into /usr/share/fonts. So that's actually not pure LFS.
Can you please send us the correct list (derived from the defaults I posted earlier) for your distribution?
Okay, I've started completely from defaults again. Here is what I had to do in order to make my special font (actually two of them, one for xterm and one for xdosemu) working.
Adding my non-default (non-LFS) font paths to the script that starts the session on the Linux PC (for nxagent):
xset fp /usr/share/fonts/75dpi/,/usr/share/fonts/misc/,built-ins
I totally get now why this is necessary.
Copying my /usr/share/fonts/{75dpi,misc} to the x2go Windows client to C:\Program Files\x2goclient\VcXsrv\fonts\{75dpi,misc}.
I still don't get why *this* is necessary, but it is. Without copying it doesn't work. (Actually, without copying, xterm seems to use my font, but its window is far too small and glyphs are overlapping; xdosemu wouldn't use my font at all.)
Because the Windows path in 2. is default for VcXsrv, I did *NOT* to have to change VcXsrv's default command line options (as stated previously). It is sufficient to select "use integrated X-Server" (with all its defaults).
One other thing:
Apparently, C:\Program Files\x2goclient is the default installation directory for the Windows client. On the contrary, the fixed path "C:\\program files\\vcxsrv\\vcxsrv.exe" is used three times in the client source. So when you'd change to "use custom X-Server" and don't watch out for the default executable put in there, you're screwed. The client immediately shuts down with an error at start-up then.
That should be it. Thank you for your support.
Ingo
Ingo Brückl <ib@wupperonline.de> schrieb am Do., 28. März 2019, 18:27:
Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote on Thu, 28 Mar 2019 13:24:50 +0100:
What's the reason why you're so eager to use a shadow session instead of an actual X2Go session
There are font issues with a X2Go session that I don't have with a shadow one.
The Windows client has a smaller display (1024x600) than the server (1024x768). I'm using a specially designed 10x18 font for both xterm and xdosemu that looks great (and big enough) on the server display, but on the 1024x600 fullscreen X2Go session the font is so small as if the client display would be 1280x1024 or even bigger. Moreover, and probably as a result, the small looking glyphs are not properly rendered.
With a shadow session both xterm and xdosemu have the usual big font.
Have you tried changing the dpi setting of the session?
BTW: Instead of connecting to the local desktop using a shadow session I am _always_ running an nx session, even when sitting in front of the machine in the office. When doing home office I simply connect to that session and continue where I left of.
Uli
-
Ingo Brückl -
Mihai Moldovan -
Stefan Baur -
Ulrich Sibiller -
Ulrich Sibiller