Hi,
Following this workaround : https://wiki.x2go.org/doku.php/wiki:development:glx-xlib-workaround did the trick !
The workaround also works for ubuntu 18.04. I just replaced "aptitude" by "apt".
I had to chown -R <me>:<me> mesa-18.0.5/ to be able to compile.
Now modifying nextcloud client launch sequence !
Cheers,
Thierry
Hi All,
I'm glad to introduce you a new X2Go feature - X2Go KDrive. X2Go KDrive is a new X-Server for X2Go, similar to Xephyr. It's based on the recent X.Org code and can run modern desktops and apps, like Gnome-3 and KDE-5. I uploaded some sources to our git repository. It's not a release or even testing version, just kind of review at the moment. We don't have any build system for it yet. However I wrote some instructions, which could help you to build it.
check our wiki page if you need more information:
https://wiki.x2go.org/doku.php/wiki:advanced:x2gokdrive:start
regards, Alex
Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Schleiermacherstr. 2 | Fax. : 0911 - 14870374 9 D-90491 Nürnberg | Mobil: 0163 - 49 64 461
Geschäftsführung: Dipl.-Inf. Oleksandr Shneyder
Amtsgericht München | http://www.phoca-gmbh.de HRB 196 658 | http://www.x2go.org USt-IdNr.: DE281977973
On Thu, Dec 20, 2018 at 3:40 PM Oleksandr Shneyder <o.shneyder@phoca-gmbh.de> wrote:
Hi All,
I'm glad to introduce you a new X2Go feature - X2Go KDrive. X2Go KDrive is a new X-Server for X2Go, similar to Xephyr. It's based on the recent X.Org code and can run modern desktops and apps, like Gnome-3 and KDE-5. I uploaded some sources to our git repository. It's not a release or even testing version, just kind of review at the moment. We don't have any build system for it yet. However I wrote some instructions, which could help you to build it.
check our wiki page if you need more information:
https://wiki.x2go.org/doku.php/wiki:advanced:x2gokdrive:start
Wow, I am astonished how tiny the code is compared to nxagent!
Can you tell us a bit more why you developed this? I mean, this drops the main advantages of NX vs VNC and RDP: efficient compression, low bandwidth support. Is this usable outside a LAN?
To save some development effort you could try to include the image compression/caching from nx-libs.
Uli
Hi Uli,
Am 20.12.18 um 19:54 schrieb Ulrich Sibiller:
On Thu, Dec 20, 2018 at 3:40 PM Oleksandr Shneyder <o.shneyder@phoca-gmbh.de> wrote:
Hi All,
I'm glad to introduce you a new X2Go feature - X2Go KDrive. X2Go KDrive is a new X-Server for X2Go, similar to Xephyr. It's based on the recent X.Org code and can run modern desktops and apps, like Gnome-3 and KDE-5. I uploaded some sources to our git repository. It's not a release or even testing version, just kind of review at the moment. We don't have any build system for it yet. However I wrote some instructions, which could help you to build it.
check our wiki page if you need more information:
https://wiki.x2go.org/doku.php/wiki:advanced:x2gokdrive:start
Wow, I am astonished how tiny the code is compared to nxagent!
Can you tell us a bit more why you developed this?
First target - we need to support modern desktops. At the moment, KDE-5 or GNOME-3 are not working with X2Go environment. I'm not talking about different hacks and workarounds. For the industry environments all of them are not acceptable. I had a request from my customer to implement such support for X2Go (as they already have a huge X2Go infrastructure). Main target - SLES 12SP1 and OpenSUSE Leap 42.3 with SLE-Classic desktop (GNOME3) on stations with dual FULL HD screens over LAN. They tested many existing solutions, like spice, VNC, all kinds of commercial products including new NX. None of them was suitable for their needs. This why X2Go KDrive was developed.
I mean, this drops the main advantages of NX vs VNC and RDP: efficient compression, low bandwidth support.
It's true, that the compression on the level of frame buffer can't be as efficient as a compression on the level of X-protocol for the legacy X apps. However, the trends in developing of desktop applications are clear - multi platform support and that means that they are not optimized to run under X-Server. The best example are modern browsers like Chrom(e|ium) or FF. Compression on the level of X-Protocol in this case is even less efficient than on the level of FB. And amount of such applications is growing. I was thinking about porting NX to X.Org 7, but I just see, that the NX, like X itself has no future. NX is obsolete since long time. And port to X.Org 7 will be obsolete again very soon. First, when (if) Xorg 7.8 will be released. Or when first major Linux distribution will come without X-Server. Another huge disadvantage is a need to have an X-Server on the client. It's ok if the client is running on Linux. In all other cases it's huge pain in the ass and source of any possible troubles. And it makes impossible to create HTML5 client or native clients for mobile devices. I don't think it's correct to say, that this solution will drop the main advantages of NX. NX in X2Go is just the way to transfer display over the network. X2Go itself is more than that. X2Go Kdrive is not going to kick NX out of X2Go. NX was great some time ago and is still very good in some cases. But it's not only NX, why people using X2Go. Normal users choosing it, because it's very easy to use. Companies taking it, because it's scalable and has a lot of features. Now we are going to give them one new feature more. If they want to use their fancy new desktops with X2go, they will be able to do it with the help of X2Go KDrive. If they want to connect to their home computers over slow networks or use legacy desktops and apps, they'll still be able to do it with the help of NX.
Is this usable outside a LAN?
Well, it worked fine for me when I was connecting from Ajaccio in Corsica to my KDE5 session in Nürnberg. On both sides normal "home" Internet. In Nürnberg 100MB, in Ajaccio 10MB and 2.4 GHz Wifi. i would say pretty usual setup. KDE5 worked fine, Internet browser worked better than over NX. I'll add more optimization in the future, I have some interesting ideas. But it's not my first priority at the moment.
To save some development effort you could try to include the image compression/caching from nx-libs.
I don't think so, NX-Libs are developed for X-protocol. I don't think they are suited very well for X2Go KDrive. Image compression itself is not a big deal. Caching as well. I made some researches and took a look on some protocols, like RFB. None of them made me really happy and I decided to develop frame processing from scratch.
regards, Alex
Uli
--
Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Schleiermacherstr. 2 | Fax. : 0911 - 14870374 9 D-90491 Nürnberg | Mobil: 0163 - 49 64 461
Geschäftsführung: Dipl.-Inf. Oleksandr Shneyder
Amtsgericht München | http://www.phoca-gmbh.de HRB 196 658 | http://www.x2go.org USt-IdNr.: DE281977973
Am 21.12.18 um 13:08 schrieb Oleksandr Shneyder:
They tested many existing solutions, like spice, VNC, all kinds of commercial products including new NX. None of them was suitable for their needs. This why X2Go KDrive was developed.
It would be cool if you could release this "feature comparison" chart to the public, say, in our Wiki, so we can show people which advantage they will gain compared to spice, VNC, and New-NX - or when to stay away from X2Go (KDrive or not), because it will not do what they are looking for.
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
Hi Stefan,
Yes, it would be cool, however I don't think I'll have time for it soon. Next months I'll be fully dedicated to the development and won't have a lot of time for any community projects.
regards, Alex
Am 21.12.18 um 13:17 schrieb Stefan Baur:
Am 21.12.18 um 13:08 schrieb Oleksandr Shneyder:
They tested many existing solutions, like spice, VNC, all kinds of commercial products including new NX. None of them was suitable for their needs. This why X2Go KDrive was developed.
It would be cool if you could release this "feature comparison" chart to the public, say, in our Wiki, so we can show people which advantage they will gain compared to spice, VNC, and New-NX - or when to stay away from X2Go (KDrive or not), because it will not do what they are looking for.
Kind Regards, Stefan Baur
x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
--
Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Schleiermacherstr. 2 | Fax. : 0911 - 14870374 9 D-90491 Nürnberg | Mobil: 0163 - 49 64 461
Geschäftsführung: Dipl.-Inf. Oleksandr Shneyder
Amtsgericht München | http://www.phoca-gmbh.de HRB 196 658 | http://www.x2go.org USt-IdNr.: DE281977973
Hi Alex,
You could also dump your notes as raw text in this thread, so $MAYBE $SOMEONE $EVENTUALLY will pick it up and turn it into a nice Wiki page. ;-)
-Stefan
Am 21.12.18 um 13:41 schrieb Oleksandr Shneyder:
Hi Stefan,
Yes, it would be cool, however I don't think I'll have time for it soon. Next months I'll be fully dedicated to the development and won't have a lot of time for any community projects.
regards, Alex
Am 21.12.18 um 13:17 schrieb Stefan Baur:
Am 21.12.18 um 13:08 schrieb Oleksandr Shneyder:
They tested many existing solutions, like spice, VNC, all kinds of commercial products including new NX. None of them was suitable for their needs. This why X2Go KDrive was developed.
It would be cool if you could release this "feature comparison" chart to the public, say, in our Wiki, so we can show people which advantage they will gain compared to spice, VNC, and New-NX - or when to stay away from X2Go (KDrive or not), because it will not do what they are looking for.
Kind Regards, Stefan Baur
x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
-- 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, Dec 21, 2018 at 1:13 PM Oleksandr Shneyder <o.shneyder@phoca-gmbh.de> wrote:
First target - we need to support modern desktops. At the moment, KDE-5 or GNOME-3 are not working with X2Go environment. I'm not talking about different hacks and workarounds. For the industry environments all of
This is what we want to achieve by updateing nxagetn step-by-step. Unfortunately resources are too scarce to getting this done quickly. I have an nx-libs repo that's par with xorg 1.4.2-
them are not acceptable. I had a request from my customer to implement such support for X2Go (as they already have a huge X2Go infrastructure). Main target - SLES 12SP1 and OpenSUSE Leap 42.3 with SLE-Classic desktop (GNOME3) on stations with dual FULL HD screens over LAN. They tested many existing solutions, like spice, VNC, all kinds of commercial products including new NX. None of them was suitable for their needs. This why X2Go KDrive was developed.
I don't see why X2gokdrive is preferable over Xvnc or similar solutions. Please explain.
I mean, this drops the main advantages of NX vs VNC and RDP: efficient compression, low bandwidth support.
It's true, that the compression on the level of frame buffer can't be as efficient as a compression on the level of X-protocol for the legacy X apps. However, the trends in developing of desktop applications are clear - multi platform support and that means that they are not optimized to run under X-Server. The best example are modern browsers like Chrom(e|ium) or FF. Compression on the level of X-Protocol in this case is even less efficient than on the level of FB. And amount of such applications is growing. I was thinking about porting NX to X.Org 7, but
We are on X.Org 7, currently Xorg 7.3 (which is called Xorg-xserver 1.3).
I just see, that the NX, like X itself has no future. NX is obsolete since long time. And port to X.Org 7 will be obsolete again very soon. First, when (if) Xorg 7.8 will be released. Or when first major Linux
Xorg is a 1.20 currently, what do you mean by Xorg 7.8?
distribution will come without X-Server. Another huge disadvantage is a need to have an X-Server on the client. It's ok if the client is running on Linux. In all other cases it's huge pain in the ass and source of any possible troubles. And it makes impossible to create HTML5 client or native clients for mobile devices.
No, it is not impossible. You can simply use the approach you took and run nxagent against an Xserver like Xvnc or x2gokdrive _on the server side_ that forwards the image data to some client. That client can be anything including html5.
I don't think it's correct to say, that this solution will drop the main advantages of NX. NX in X2Go is just the way to transfer display over the network. X2Go itself is more than that. X2Go Kdrive is not going to
I am not talking about x2go, I am talking about nx.
kick NX out of X2Go. NX was great some time ago and is still very good in some cases. But it's not only NX, why people using X2Go. Normal users choosing it, because it's very easy to use. Companies taking it, because it's scalable and has a lot of features. Now we are going to give them one new feature more. If they want to use their fancy new desktops with X2go, they will be able to do it with the help of X2Go KDrive. If they want to connect to their home computers over slow networks or use legacy desktops and apps, they'll still be able to do it with the help of NX.
Is this usable outside a LAN?
Well, it worked fine for me when I was connecting from Ajaccio in Corsica to my KDE5 session in Nürnberg. On both sides normal "home" Internet. In Nürnberg 100MB, in Ajaccio 10MB and 2.4 GHz Wifi. i would
NX works over a 64k ISDN line. While you are right that your tested setup is pretty much standard today it is not necessary to waste bandwidth just because you can. (Just my opinion, there are people that will disagree).
say pretty usual setup. KDE5 worked fine, Internet browser worked better than over NX. I'll add more optimization in the future, I have some interesting ideas. But it's not my first priority at the moment.
To save some development effort you could try to include the image compression/caching from nx-libs.
I don't think so, NX-Libs are developed for X-protocol. I don't think they are suited very well for X2Go KDrive. Image compression itself is not a big deal. Caching as well. I made some researches and took a look on some protocols, like RFB. None of them made me really happy and I decided to develop frame processing from scratch.
Alright, but remember a lot of thinking and testing went into the existing protocols, so why re-invent the wheel?
Uli
Am 21.12.18 um 13:46 schrieb Ulrich Sibiller:
On Fri, Dec 21, 2018 at 1:13 PM Oleksandr Shneyder <o.shneyder@phoca-gmbh.de> wrote:
First target - we need to support modern desktops. At the moment, KDE-5 or GNOME-3 are not working with X2Go environment. I'm not talking about different hacks and workarounds. For the industry environments all of
This is what we want to achieve by updateing nxagetn step-by-step. Unfortunately resources are too scarce to getting this done quickly. I have an nx-libs repo that's par with xorg 1.4.2-
It will be great when it'll be done. And I'll be happy to see it as a part of X2Go. As I told, it's not about NX against X2Go KDrive, I don't want to replace NX in X2Go. It's another solution with another purpose.
them are not acceptable. I had a request from my customer to implement such support for X2Go (as they already have a huge X2Go infrastructure). Main target - SLES 12SP1 and OpenSUSE Leap 42.3 with SLE-Classic desktop (GNOME3) on stations with dual FULL HD screens over LAN. They tested many existing solutions, like spice, VNC, all kinds of commercial products including new NX. None of them was suitable for their needs. This why X2Go KDrive was developed.
I don't see why X2gokdrive is preferable over Xvnc or similar solutions. Please explain.
See above. I described the target of my customers. They didn't achieve it with any of solutions they are tested. X2Go KDrive is made for their purposes. I'm happy that this work can be also available for community as a part of X2Go project.
I mean, this drops the main advantages of NX vs VNC and RDP: efficient compression, low bandwidth support.
It's true, that the compression on the level of frame buffer can't be as efficient as a compression on the level of X-protocol for the legacy X apps. However, the trends in developing of desktop applications are clear - multi platform support and that means that they are not optimized to run under X-Server. The best example are modern browsers like Chrom(e|ium) or FF. Compression on the level of X-Protocol in this case is even less efficient than on the level of FB. And amount of such applications is growing. I was thinking about porting NX to X.Org 7, but
We are on X.Org 7, currently Xorg 7.3 (which is called Xorg-xserver 1.3).
https://www.x.org/wiki/Releases/7.7/
I just see, that the NX, like X itself has no future. NX is obsolete since long time. And port to X.Org 7 will be obsolete again very soon. First, when (if) Xorg 7.8 will be released. Or when first major Linux
Xorg is a 1.20 currently, what do you mean by Xorg 7.8?
https://www.x.org/wiki/Releases/7.8/
distribution will come without X-Server. Another huge disadvantage is a need to have an X-Server on the client. It's ok if the client is running on Linux. In all other cases it's huge pain in the ass and source of any possible troubles. And it makes impossible to create HTML5 client or native clients for mobile devices.
No, it is not impossible. You can simply use the approach you took and run nxagent against an Xserver like Xvnc or x2gokdrive _on the server side_ that forwards the image data to some client. That client can be anything including html5.
hackish, and you won't need NX in this scenario at all, you'll lose all it advantages.
I don't think it's correct to say, that this solution will drop the main advantages of NX. NX in X2Go is just the way to transfer display over the network. X2Go itself is more than that. X2Go Kdrive is not going to
I am not talking about x2go, I am talking about nx.
I'm talking about X2Go. It has absolutely nothing to do with NX. Once again, NX is great. I love it and I'll be happy to see the new version of it. But we are talking now about another protocol for another purpose.
kick NX out of X2Go. NX was great some time ago and is still very good in some cases. But it's not only NX, why people using X2Go. Normal users choosing it, because it's very easy to use. Companies taking it, because it's scalable and has a lot of features. Now we are going to give them one new feature more. If they want to use their fancy new desktops with X2go, they will be able to do it with the help of X2Go KDrive. If they want to connect to their home computers over slow networks or use legacy desktops and apps, they'll still be able to do it with the help of NX.
Is this usable outside a LAN?
Well, it worked fine for me when I was connecting from Ajaccio in Corsica to my KDE5 session in Nürnberg. On both sides normal "home" Internet. In Nürnberg 100MB, in Ajaccio 10MB and 2.4 GHz Wifi. i would
NX works over a 64k ISDN line. While you are right that your tested setup is pretty much standard today it is not necessary to waste bandwidth just because you can. (Just my opinion, there are people that will disagree).
I absolutely agree with you. Unfortunately most of the developers don't care. Yes, NX will work on 64k ISDN line. But will you be able to start in this session Google Chrome and scroll through planet.debian.org? I can tell you, you won't be very happy with result. Even with 1Mbit DSL it doesn't work very well. The times of XRender support in FF are over. Unfortunately.
say pretty usual setup. KDE5 worked fine, Internet browser worked better than over NX. I'll add more optimization in the future, I have some interesting ideas. But it's not my first priority at the moment.
To save some development effort you could try to include the image compression/caching from nx-libs.
I don't think so, NX-Libs are developed for X-protocol. I don't think they are suited very well for X2Go KDrive. Image compression itself is not a big deal. Caching as well. I made some researches and took a look on some protocols, like RFB. None of them made me really happy and I decided to develop frame processing from scratch.
Alright, but remember a lot of thinking and testing went into the existing protocols, so why re-invent the wheel?
It's true. Also true, that existing protocols are developed long time ago for different kind of applications. It doesn't mean, that we can't import some good features in X2Go KDrive from another protocols. But I want to have a protocol which is optimized for the modern applications. For sure I could just take XVNC-Server and frb protocol. But I also could take FreeNX long time ago instead of developing X2Go.
regards Alex
Uli
--
Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Schleiermacherstr. 2 | Fax. : 0911 - 14870374 9 D-90491 Nürnberg | Mobil: 0163 - 49 64 461
Geschäftsführung: Dipl.-Inf. Oleksandr Shneyder
Amtsgericht München | http://www.phoca-gmbh.de HRB 196 658 | http://www.x2go.org USt-IdNr.: DE281977973
On Fri, Dec 21, 2018 at 3:37 PM Oleksandr Shneyder <o.shneyder@phoca-gmbh.de> wrote:
Am 21.12.18 um 13:46 schrieb Ulrich Sibiller:
On Fri, Dec 21, 2018 at 1:13 PM Oleksandr Shneyder <o.shneyder@phoca-gmbh.de> wrote:
First target - we need to support modern desktops. At the moment, KDE-5 or GNOME-3 are not working with X2Go environment. I'm not talking about different hacks and workarounds. For the industry environments all of
This is what we want to achieve by updateing nxagetn step-by-step. Unfortunately resources are too scarce to getting this done quickly. I have an nx-libs repo that's par with xorg 1.4.2-
It will be great when it'll be done. And I'll be happy to see it as a part of X2Go. As I told, it's not about NX against X2Go KDrive, I don't want to replace NX in X2Go. It's another solution with another purpose.
Understood.
We are on X.Org 7, currently Xorg 7.3 (which is called Xorg-xserver 1.3).
Ok, you are talking about the the whole xorg release which is pretty much irrelevant since all the packages have their own version number and are released independently.
distribution will come without X-Server. Another huge disadvantage is a need to have an X-Server on the client. It's ok if the client is running on Linux. In all other cases it's huge pain in the ass and source of any possible troubles. And it makes impossible to create HTML5 client or native clients for mobile devices.
No, it is not impossible. You can simply use the approach you took and run nxagent against an Xserver like Xvnc or x2gokdrive _on the server side_ that forwards the image data to some client. That client can be anything including html5.
hackish, and you won't need NX in this scenario at all, you'll lose all it advantages.
Well, you could reconnect to the nxagent from elsewhere and profit from the nx compressions but that's a very special usecase.
NX works over a 64k ISDN line. While you are right that your tested setup is pretty much standard today it is not necessary to waste bandwidth just because you can. (Just my opinion, there are people that will disagree).
I absolutely agree with you. Unfortunately most of the developers don't care. Yes, NX will work on 64k ISDN line. But will you be able to start in this session Google Chrome and scroll through planet.debian.org? I can tell you, you won't be very happy with result. Even with 1Mbit DSL it doesn't work very well. The times of XRender support in FF are over. Unfortunately.
Well, I am using FF daily and it is very usable over NX. The only things that are problematic are video and OpenGL. There are some tunables in Firefox that really help (enable xrender, disable smooth scrolling). For LAN-only you can also disable image compression in NX.
Alright, but remember a lot of thinking and testing went into the existing protocols, so why re-invent the wheel?
It's true. Also true, that existing protocols are developed long time ago for different kind of applications. It doesn't mean, that we can't import some good features in X2Go KDrive from another protocols. But I want to have a protocol which is optimized for the modern applications. For sure I could just take XVNC-Server and frb protocol. But I also could take FreeNX long time ago instead of developing X2Go.
Well, Nomachine nowadays claims to be the fastest solution, so at least you have something to compete against ;-)
Uli
Am 21.12.18 um 15:47 schrieb Ulrich Sibiller:
Well, I am using FF daily and it is very usable over NX. The only things that are problematic are video and OpenGL. There are some tunables in Firefox that really help (enable xrender, disable smooth scrolling).
With all due respect, I cannot confirm this. Even after applying all the about:config settings you suggested at the Gathering 2018, and making sure firefox was completely shut down and a new instance spawned, it was still slow as molasses compared to PaleMoon 27 with xrender enabled. To be honest, I didn't see a single speed improvement from the part of your changes that I hadn't already applied, compared to stock Firefox.
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
Hi Stefan,
it depends which version of FF Uli is using. Mozilla switched to Skia by default some time ago. The Xrender backend was available for the long time. In the recent versions this option is only their for backward compatibility, Xrender backend is not supported in FF anymore.
regards, Alex
Am 21.12.18 um 16:02 schrieb Stefan Baur:
Am 21.12.18 um 15:47 schrieb Ulrich Sibiller:
Well, I am using FF daily and it is very usable over NX. The only things that are problematic are video and OpenGL. There are some tunables in Firefox that really help (enable xrender, disable smooth scrolling).
With all due respect, I cannot confirm this. Even after applying all the about:config settings you suggested at the Gathering 2018, and making sure firefox was completely shut down and a new instance spawned, it was still slow as molasses compared to PaleMoon 27 with xrender enabled. To be honest, I didn't see a single speed improvement from the part of your changes that I hadn't already applied, compared to stock Firefox.
Kind Regards, Stefan Baur
--
Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Schleiermacherstr. 2 | Fax. : 0911 - 14870374 9 D-90491 Nürnberg | Mobil: 0163 - 49 64 461
Geschäftsführung: Dipl.-Inf. Oleksandr Shneyder
Amtsgericht München | http://www.phoca-gmbh.de HRB 196 658 | http://www.x2go.org USt-IdNr.: DE281977973
On Fri, Dec 21, 2018 at 4:16 PM Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:
Am 21.12.18 um 15:47 schrieb Ulrich Sibiller:
Well, I am using FF daily and it is very usable over NX. The only things that are problematic are video and OpenGL. There are some tunables in Firefox that really help (enable xrender, disable smooth scrolling).
With all due respect, I cannot confirm this. Even after applying all the about:config settings you suggested at the Gathering 2018, and making sure firefox was completely shut down and a new instance spawned, it was still slow as molasses compared to PaleMoon 27 with xrender enabled. To be honest, I didn't see a single speed improvement from the part of your changes that I hadn't already applied, compared to stock Firefox.
Well, what should I say? It is quick here and very usable with FF 60.3.0esr. I am writing this mail with this FF.
Uli
Am 21.12.18 um 16:29 schrieb Ulrich Sibiller:
With all due respect, I cannot confirm this. Even after applying all the about:config settings you suggested at the Gathering 2018, and making sure firefox was completely shut down and a new instance spawned, it was still slow as molasses compared to PaleMoon 27 with xrender enabled. To be honest, I didn't see a single speed improvement from the part of your changes that I hadn't already applied, compared to stock Firefox. Well, what should I say? It is quick here and very usable with FF 60.3.0esr. I am writing this mail with this FF.
Actual line speed:
user@local:~$ ls -lah /tmp/testfile -rw-rw-r-- 1 user user 512M Dez 21 16:33 /tmp/testfile user@local:~$ rsync -aPv /tmp/testfile user@remoteserv:/tmp/ Enter passphrase for key '/home/user/.ssh/id_rsa': sending incremental file list testfile 536,870,912 100% 1.58MB/s 0:05:25 (xfr#1, to-chk=0/1)
sent 537,002,083 bytes received 35 bytes 1,629,748.46 bytes/sec total size is 536,870,912 speedup is 1.00
(testfile was created from urandom)
Firefox packages on remoteserv:
ii firefox-esr 60.2.2esr-1~deb9u1 amd64 Mozilla Firefox web browser - Extended Support Release (ESR) ii firefox-esr-l10n-de 60.2.2esr-1~deb9u1 all German language package for Firefox ESR
X2Go/NX packages on remoteserv:
ii cups-x2go 3.0.1.3-2 all Virtual X2Go printer for CUPS ii libnx-x11-6:amd64 2:3.5.99.16-1.0x2go1+git20180719.2988+9.main.1 amd64 nxagent's libNX_X11 client-part library ii libx2go-log-perl 4.1.0.2-0x2go1+git20180801.1642+9.main.1 all Perl X2Go::Log package ii libx2go-server-db-perl 4.1.0.2-0x2go1+git20180801.1642+9.main.1 amd64 Perl X2Go::Server:DB package ii libx2go-server-perl 4.1.0.2-0x2go1+git20180801.1642+9.main.1 all Perl X2Go::Server package ii libxcomp3:amd64 2:3.5.99.16-1.0x2go1+git20180719.2988+9.main.1 amd64 NX compression library ii libxcompshad3:amd64 2:3.5.99.16-1.0x2go1+git20180719.2988+9.main.1 amd64 NX shadowing library ii nx-x11-common 2:3.5.99.16-1.0x2go1+git20180719.2988+9.main.1 all nx-X11 (common files) ii nxagent 2:3.5.99.16-1.0x2go1+git20180719.2988+9.main.1 amd64 Nested Xserver (aka NX Agent) supporting the NX compression protocol ii nxproxy 2:3.5.99.16-1.0x2go1+git20180719.2988+9.main.1 amd64 NX proxy ii x2go-keyring 2012.07.23+git20170305.17+9.main.1 all GnuPG keys of all X2Go developers and the X2Go archive ii x2goclient 4.1.2.1-0x2go1+git20180626.1801+9.main.1 amd64 X2Go Client application (Qt4) ii x2godesktopsharing 3.1.1.4-0x2go1+git20180205.186+9.main.1 amd64 Share X11 desktops with other users via X2Go ii x2goserver 4.1.0.2-0x2go1+git20180801.1642+9.main.1 amd64 X2Go server ii x2goserver-common 4.1.0.2-0x2go1+git20180801.1642+9.main.1 amd64 X2Go Server (common files) ii x2goserver-extensions 4.1.0.2-0x2go1+git20180801.1642+9.main.1 all X2Go Server (extension support) ii x2goserver-fmbindings 4.1.0.2-0x2go1+git20180801.1642+9.main.1 all X2Go Server (file manager bindings) ii x2goserver-printing 4.1.0.2-0x2go1+git20180801.1642+9.main.1 all X2Go server (printing support) ii x2goserver-x2goagent 4.1.0.2-0x2go1+git20180801.1642+9.main.1 amd64 X2Go Server's X2Go Agent ii x2goserver-xsession 4.1.0.2-0x2go1+git20180801.1642+9.main.1 all X2Go Server (Xsession runner)
The only thing I noticed is that I still have BIG-REQUESTS disabled because Thunderbird and possibly evince would crash with it (and the X2Go packages installed here are from X2Go stable, and dated before the Gathering 2018, so do not contain your BIG-REQUESTS fixes yet).
*Maybe* the speed-up effect you're seeing is only possible with BIG-REQUESTS enabled?
Looks like there are updates available for both firefox-esr and X2Go since, so I'll try updating and see if and what that changes.
-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
Am 21.12.18 um 16:52 schrieb Stefan Baur:
The only thing I noticed is that I still have BIG-REQUESTS disabled because Thunderbird and possibly evince would crash with it (and the X2Go packages installed here are from X2Go stable, and dated before the Gathering 2018, so do not contain your BIG-REQUESTS fixes yet).
*Maybe* the speed-up effect you're seeing is only possible with BIG-REQUESTS enabled?
Looks like there are updates available for both firefox-esr and X2Go since, so I'll try updating and see if and what that changes.
Something else: I'm using published application mode. Are you using it in a full desktop environment, as a single application, or also in published application mode?
-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
HI Stefan,
On Fr 21 Dez 2018 17:07:57 CET, Stefan Baur wrote:
Am 21.12.18 um 16:52 schrieb Stefan Baur:
The only thing I noticed is that I still have BIG-REQUESTS disabled because Thunderbird and possibly evince would crash with it (and the X2Go packages installed here are from X2Go stable, and dated before the Gathering 2018, so do not contain your BIG-REQUESTS fixes yet).
*Maybe* the speed-up effect you're seeing is only possible with BIG-REQUESTS enabled?
Looks like there are updates available for both firefox-esr and X2Go since, so I'll try updating and see if and what that changes.
Something else: I'm using published application mode. Are you using it in a full desktop environment, as a single application, or also in published application mode?
published applications mode (rootless nxagent sessions) are much
slower then full desktop sessions.
The real reason for it is not yet known AFAICT (probably some issue
with bitmaps, interaction between remote nxagent session and local
window manager, but just a wild guess).
Mike
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
On Fri, Dec 21, 2018 at 3:47 PM Ulrich Sibiller <uli42@gmx.de> wrote:
On Fri, Dec 21, 2018 at 3:37 PM Oleksandr Shneyder
We are on X.Org 7, currently Xorg 7.3 (which is called Xorg-xserver 1.3).
Ok, you are talking about the the whole xorg release which is pretty much irrelevant since all the packages have their own version number and are released independently.
Just for the records: there will be no further Xorg release bundles (called Katamari). So 7.8 will never come. See https://www.phoronix.com/scan.php?page=news_item&px=X.Org-Katamari-Dead-2019
Uli
Hi Alex,
On Do 20 Dez 2018 15:37:12 CET, Oleksandr Shneyder wrote:
Hi All,
I'm glad to introduce you a new X2Go feature - X2Go KDrive. X2Go KDrive is a new X-Server for X2Go, similar to Xephyr. It's based on the recent X.Org code and can run modern desktops and apps, like Gnome-3 and KDE-5. I uploaded some sources to our git repository. It's not a release or even testing version, just kind of review at the moment. We don't have any build system for it yet. However I wrote some instructions, which could help you to build it.
check our wiki page if you need more information:
https://wiki.x2go.org/doku.php/wiki:advanced:x2gokdrive:start
Thanks for this work.
I see, you haven't pushed anything to X2Go Server and X2Go Client. I
accept code changes for those two Git repos, too.
Please don't push those changes directly to master. Please push them
on a feature branch where the changes can then be cherry-picked from
once the x2goephyr code parts are wrapped up in packages properly.
Thanks, Mike
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
Am 21.12.18 um 07:38 schrieb Mike Gabriel:
Hi Alex,
On Do 20 Dez 2018 15:37:12 CET, Oleksandr Shneyder wrote:
Hi All,
I'm glad to introduce you a new X2Go feature - X2Go KDrive. X2Go KDrive is a new X-Server for X2Go, similar to Xephyr. It's based on the recent X.Org code and can run modern desktops and apps, like Gnome-3 and KDE-5. I uploaded some sources to our git repository. It's not a release or even testing version, just kind of review at the moment. We don't have any build system for it yet. However I wrote some instructions, which could help you to build it.
check our wiki page if you need more information:
https://wiki.x2go.org/doku.php/wiki:advanced:x2gokdrive:start
Thanks for this work.
I see, you haven't pushed anything to X2Go Server and X2Go Client. I accept code changes for those two Git repos, too.
Please don't push those changes directly to master. Please push them on a feature branch where the changes can then be cherry-picked from once the x2goephyr code parts are wrapped up in packages properly.
Hi Mike,
Yes, that was also my plan. I don't have a lot of experience in packaging, so I'll appreciate any help. I built some binaries for my customers and they are already testing the new solution. But I think there are some members of community, that would like to try it too.
regards, Alex
PS: We decided, that the X2Go Kdrive is a better name, please try not to use name "x2goephyr" to avoid the confusions.
Thanks, Mike
--
Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Schleiermacherstr. 2 | Fax. : 0911 - 14870374 9 D-90491 Nürnberg | Mobil: 0163 - 49 64 461
Geschäftsführung: Dipl.-Inf. Oleksandr Shneyder
Amtsgericht München | http://www.phoca-gmbh.de HRB 196 658 | http://www.x2go.org USt-IdNr.: DE281977973
Hi Alex,
On Fr 21 Dez 2018 13:16:50 CET, Oleksandr Shneyder wrote:
Am 21.12.18 um 07:38 schrieb Mike Gabriel:
Hi Alex,
On Do 20 Dez 2018 15:37:12 CET, Oleksandr Shneyder wrote:
Hi All,
I'm glad to introduce you a new X2Go feature - X2Go KDrive. X2Go KDrive is a new X-Server for X2Go, similar to Xephyr. It's based on the recent X.Org code and can run modern desktops and apps, like Gnome-3 and KDE-5. I uploaded some sources to our git repository. It's not a release or even testing version, just kind of review at the moment. We don't have any build system for it yet. However I wrote some instructions, which could help you to build it.
check our wiki page if you need more information:
https://wiki.x2go.org/doku.php/wiki:advanced:x2gokdrive:start
Thanks for this work.
I see, you haven't pushed anything to X2Go Server and X2Go Client. I accept code changes for those two Git repos, too.
Please don't push those changes directly to master. Please push them on a feature branch where the changes can then be cherry-picked from once the x2goephyr code parts are wrapped up in packages properly.
Yes, that was also my plan. I don't have a lot of experience in packaging, so I'll appreciate any help. I built some binaries for my customers and they are already testing the new solution. But I think there are some members of community, that would like to try it too.
Don't expect any DEB packaging work before January/February. Plus: I
am stuffed with paid customer projects, they have priority.
Plus, it would be cool to have autotools as build toolchain available
like in all other Xserver video drivers.
An example can be taken from e.g. xserver-xorg-video-nouveau [1].
PS: We decided, that the X2Go Kdrive is a better name, please try not to use name "x2goephyr" to avoid the confusions.
Noted and ack'ed.
Thanks, Mike
Greets, Mike
[1] apt-get source xserver-xorg-video-nouveau (on a Debian
buster/unstable system)
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
Am 21.12.18 um 13:23 schrieb Mike Gabriel:
Don't expect any DEB packaging work before January/February. Plus: I am stuffed with paid customer projects, they have priority.
I don't think *anyone* is seriously expecting any packaging work before that date. See <https://twitter.com/Dave_Cochran/status/1075736637257236480> for the main reason.
I can try to poke around among my customers and maybe assign Mihai to work on it on paid time, if no one picks up after February (though I'm not sure yet if he might be unavailable in February or March, we'll see).
-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
Hi Mike,
Am 21.12.18 um 13:23 schrieb Mike Gabriel:
Hi Alex,
[.....]
Don't expect any DEB packaging work before January/February. Plus: I am stuffed with paid customer projects, they have priority.
sure, I don't expect you to do it before your paid projects. I'm in the same situation here. I think the proper packages are more important for community. For my customers now are more important working binaries and for them I can just build installations packages.
Plus, it would be cool to have autotools as build toolchain available like in all other Xserver video drivers.
An example can be taken from e.g. xserver-xorg-video-nouveau [1].
It's a bit different situation. X2Go KDrive is not a driver, it's a XServer and it need to be built inside of X.Org tree. For the moment I'm using very simple and dirty way to build it. Not very nice, but works for me. I'm very busy with development now and don't have time to create a "clean" build procedure.
PS: We decided, that the X2Go Kdrive is a better name, please try not to use name "x2goephyr" to avoid the confusions.
Noted and ack'ed.
Thanks, Mike
Greets, Mike
[1] apt-get source xserver-xorg-video-nouveau (on a Debian buster/unstable system)
regards
--
Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Schleiermacherstr. 2 | Fax. : 0911 - 14870374 9 D-90491 Nürnberg | Mobil: 0163 - 49 64 461
Geschäftsführung: Dipl.-Inf. Oleksandr Shneyder
Amtsgericht München | http://www.phoca-gmbh.de HRB 196 658 | http://www.x2go.org USt-IdNr.: DE281977973
Hi,
On Fr 21 Dez 2018 13:53:52 CET, Oleksandr Shneyder wrote:
Hi Mike,
Am 21.12.18 um 13:23 schrieb Mike Gabriel:
Hi Alex,
[.....]
Don't expect any DEB packaging work before January/February. Plus: I am stuffed with paid customer projects, they have priority.
sure, I don't expect you to do it before your paid projects. I'm in the same situation here. I think the proper packages are more important for community. For my customers now are more important working binaries and for them I can just build installations packages.
Plus, it would be cool to have autotools as build toolchain available like in all other Xserver video drivers.
An example can be taken from e.g. xserver-xorg-video-nouveau [1].
It's a bit different situation. X2Go KDrive is not a driver, it's a XServer and it need to be built inside of X.Org tree. For the moment I'm using very simple and dirty way to build it. Not very nice, but works for me. I'm very busy with development now and don't have time to create a "clean" build procedure.
Ah, ok. The TigerVNC maintainers in Debian have found a way to handle that:
https://salsa.debian.org/debian-remote-team/tigervnc/tree/master/debian
Especially for TigerVNC, the xorg-server-source package [1] got
introduced (available since jessie).
We need to make sure that x2godrive builds against all those versions.
The TigerVNC people have various patches against the different
xorg-server(-source) versions to make that happen.
Greets, Mike
[1] https://packages.debian.org/sid/xorg-server-source
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
Hi again,
On Do 20 Dez 2018 15:37:12 CET, Oleksandr Shneyder wrote:
Hi All,
I'm glad to introduce you a new X2Go feature - X2Go KDrive. X2Go KDrive is a new X-Server for X2Go, similar to Xephyr. It's based on the recent X.Org code and can run modern desktops and apps, like Gnome-3 and KDE-5. I uploaded some sources to our git repository. It's not a release or even testing version, just kind of review at the moment. We don't have any build system for it yet. However I wrote some instructions, which could help you to build it.
check our wiki page if you need more information:
https://wiki.x2go.org/doku.php/wiki:advanced:x2gokdrive:start
Please also fix the non-bare Git repo for x2goephyrclient (probably
simply remove it as it seems to have been replaced by
x2gokdriveclient.git).
Mike
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby mobile: +49 (1520) 1976 148 landline: +49 (4354) 8390 139
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
My bad, I forgot to delete it. Already done. Thanks for pointing it out.
regards, Alex Am 21.12.18 um 07:52 schrieb Mike Gabriel:
Hi again,
On Do 20 Dez 2018 15:37:12 CET, Oleksandr Shneyder wrote:
Hi All,
I'm glad to introduce you a new X2Go feature - X2Go KDrive. X2Go KDrive is a new X-Server for X2Go, similar to Xephyr. It's based on the recent X.Org code and can run modern desktops and apps, like Gnome-3 and KDE-5. I uploaded some sources to our git repository. It's not a release or even testing version, just kind of review at the moment. We don't have any build system for it yet. However I wrote some instructions, which could help you to build it.
check our wiki page if you need more information:
https://wiki.x2go.org/doku.php/wiki:advanced:x2gokdrive:start
Please also fix the non-bare Git repo for x2goephyrclient (probably simply remove it as it seems to have been replaced by x2gokdriveclient.git).
Mike
--
Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Schleiermacherstr. 2 | Fax. : 0911 - 14870374 9 D-90491 Nürnberg | Mobil: 0163 - 49 64 461
Geschäftsführung: Dipl.-Inf. Oleksandr Shneyder
Amtsgericht München | http://www.phoca-gmbh.de HRB 196 658 | http://www.x2go.org USt-IdNr.: DE281977973
Hi Alex,
On Do 20 Dez 2018 15:37:12 CET, Oleksandr Shneyder wrote:
Hi All,
I'm glad to introduce you a new X2Go feature - X2Go KDrive. X2Go KDrive is a new X-Server for X2Go, similar to Xephyr. It's based on the recent X.Org code and can run modern desktops and apps, like Gnome-3 and KDE-5. I uploaded some sources to our git repository. It's not a release or even testing version, just kind of review at the moment. We don't have any build system for it yet. However I wrote some instructions, which could help you to build it.
check our wiki page if you need more information:
https://wiki.x2go.org/doku.php/wiki:advanced:x2gokdrive:start
regards, Alex
Stefan managed to get some funding for me to work on wrapping up X2Go
KDrive (Agent + Client) as DEB packages.
I have committed quite some stuff to the repos, more to come the
coming week. Please review. Especially, I prepared native builds
against the DEB package xserver-xorg-source.
I also ported the nx-libs test scripts. With X2Go Client and also with
the "on-localhost" testscript, I get this segfault:
However, I currently get this SegFault Traceback when initiating a connection:
x2gokdriveinit.c:194,ddxProcessArgument() mark argv[1]='-name'
x2gokdriveinit.c:194,ddxProcessArgument() mark argv[3]='-geometry'
x2gokdriveinit.c:194,ddxProcessArgument() mark argv[5]=':9'
x2gokdriveinit.c:233,OsVendorInit() mark
x2gokdriveinit.c:65,InitCard() mark
x2gokdriveinit.c:170,processScreenOrOutputArg() screen number:0, size:
800x600, output (null)
remote.c:2288,remote_init() running in NXAGENT MODE
remote.c:2297,remote_init() read options from /home/mike/.x2go/C-9/options
remote.c:2177,processConfigFileSetting() accept 127.0.0.1
remote.c:1709,setAgentState() Agent state STARTING
remote.c:2058,open_socket() Accepting connections from 127.0.0.1
remote.c:2061,open_socket() Listen on port 15000
remote.c:2089,open_socket() Socket is ready
x2gokdriveselection.c:640,selection_init() INITIALIZING selections
x2gokdriveselection.c:657,install_selection_callbacks() SERVER
CLIPBOARD disabled, not installing callbacks
x2gokdrive.c:98,ephyrScreenInitialize() Init screen
remote.c:2987,remote_screen_init() REMOTE SCREN INIT!!!!!!!!!!!!!!!!!!
remote.c:2990,remote_screen_init() SKIPPING CALLBACK INSTALL
remote.c:3001,remote_screen_init() host_screen=0x5645af625e60 x=0,
y=0, wxh=800x600, buffer_height=1800
remote.c:3014,remote_screen_init() TRYING TO ALLOC MAIN_IMG 1920000
remote.c:3016,remote_screen_init() TRYING TO ALLOC DOUBLE BUF 1920000
remote.c:1321,send_frame_thread() Started sending thread: #0!
remote.c:1325,send_frame_thread() waiting for TCP connection
remote.c:3021,remote_screen_init() ALL INITIALIZED
x2gokdrive.c:244,ephyrMapFramebuffer() DIRECT FB
x2gokdrive.c:834,ephyrRandRInit() RANDR INIT, HERE WE ARE DOING OUR
RANDR INITIALIZATION
x2gokdrive.c:835,ephyrRandRInit() OUTPUTS: 0, CRTCS: 0, SIZES: 0
x2gokdrive.c:781,addOutput() CREATE OUTPUT X2GoEphyr-0
x2gokdrive.c:673,setOutput() Set output 800 600 0 0
x2gokdrive.c:732,setOutput() RANDR SIZES - SCREEN 800x600 - 271x203,
OUTPUT 800x600 - 271x203
x2gokdrive.c:751,setOutput() OUPUT has now modes 1 (800x600)
remote.c:1332,send_frame_thread() Connection from (127.0.0.1)...
remote.c:1378,send_frame_thread() got 32 COOKIE BYTES from client
remote.c:1387,send_frame_thread() Cookie approved
remote.c:1709,setAgentState() Agent state RUNNING
remote.c:1918,clientReadNotify() Client want resize to 1276x454
remote.c:1934,clientReadNotify() SCREEN 0 - (1276x454) - 0,0
x2gokdrive.c:861,ephyrResizeScreen() EPHYR RESIZE SCREEN!!! af6392f0 1276 454
x2gokdrive.c:864,ephyrResizeScreen() EPHYR RESIZE SCREEN 2
x2gokdrive.c:869,ephyrResizeScreen() Virtual Screens: 0x7ffd5d23c9e0
x2gokdrive.c:438,ephyrRandRSetConfig() SET RANDR CFG
x2gokdrive.c:456,ephyrRandRSetConfig() Trying to get virtual screens
x2gokdrive.c:457,ephyrRandRSetConfig() Virtual Screens: 0x7ffd5d23c9e0
remote.c:2987,remote_screen_init() REMOTE SCREN INIT!!!!!!!!!!!!!!!!!!
remote.c:2995,remote_screen_init() REINSTALL CALLBACKS
x2gokdriveselection.c:657,install_selection_callbacks() SERVER
CLIPBOARD disabled, not installing callbacks
remote.c:3001,remote_screen_init() host_screen=0x5645af625e60 x=0,
y=0, wxh=1276x454, buffer_height=1362
remote.c:3010,remote_screen_init() FREE DBF
remote.c:3012,remote_screen_init() DONE FREE DBF
remote.c:3014,remote_screen_init() TRYING TO ALLOC MAIN_IMG 2317216
remote.c:3016,remote_screen_init() TRYING TO ALLOC DOUBLE BUF 2317216
remote.c:3021,remote_screen_init() ALL INITIALIZED
x2gokdrive.c:244,ephyrMapFramebuffer() DIRECT FB
(EE)
(EE) Backtrace:
(EE) 0: x2gokdrive (OsLookupColor+0x139) [0x5645ad81fc69]
(EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x50)
[0x7fb9bc68177f]
(EE) 2: x2gokdrive (GetScratchGC+0x31) [0x5645ad6f27c1]
(EE) 3: x2gokdrive (miPaintWindow+0x182) [0x5645ad749082]
(EE) 4: x2gokdrive (miWindowExposures+0xf2) [0x5645ad748e72]
(EE) 5: x2gokdrive (miHandleValidateExposures+0x6e) [0x5645ad75771e]
(EE) 6: x2gokdrive (SetRootClip+0x1f3) [0x5645ad70b703]
(EE) 7: x2gokdrive (SwapShorts+0x49c) [0x5645ad72624c]
(EE) 8: x2gokdrive (_start+0x70b0) [0x5645ad6e8b70]
(EE) 9: x2gokdrive (_start+0x7496) [0x5645ad6e98e6]
(EE) 10: x2gokdrive (_start+0x4faf) [0x5645ad6e4baf]
(EE) 11: x2gokdrive (OsCleanup+0x591) [0x5645ad820a61]
(EE) 12: x2gokdrive (WaitForSomething+0x1c3) [0x5645ad819883]
(EE) 13: x2gokdrive (SendErrorToClient+0x10c) [0x5645ad71d59c]
(EE) 14: x2gokdrive (InitAtoms+0x3c6) [0x5645ad6e4b46]
(EE) 15: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xeb)
[0x7fb9bc4d009b]
(EE) 16: x2gokdrive (_start+0x2a) [0x5645ad6db0fa]
(EE)
(EE) Segmentation fault at address 0x564500000008
(EE)
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE)
Does the above segfault and traceback ring a bell? If not, never mind.
I will dive into it the coming week.
Note: I also merged the feature/kdrive_support branch found on
x2goserver.git and x2goclient.git to master.
Greets, Mike
DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 486 14 27
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
Hi Mike,
Initially i started to develop X2Go KDrive based on source code of xorg-server-1.19.2. I made some patches to port it for some older versions used by SLES12SP1 and Leap42.3. I didn't try it yet with newer versions of XOrg, however I think it should not be a big deal. Looking on the log you provided, I could guess that the problem is somewhere in the XRandr handling. But I would need to take a closer look to be sure.
Regards Alex
Am 14.06.19 um 15:50 schrieb Mike Gabriel:
Hi Alex,
On Do 20 Dez 2018 15:37:12 CET, Oleksandr Shneyder wrote:
Hi All,
I'm glad to introduce you a new X2Go feature - X2Go KDrive. X2Go KDrive is a new X-Server for X2Go, similar to Xephyr. It's based on the recent X.Org code and can run modern desktops and apps, like Gnome-3 and KDE-5. I uploaded some sources to our git repository. It's not a release or even testing version, just kind of review at the moment. We don't have any build system for it yet. However I wrote some instructions, which could help you to build it.
check our wiki page if you need more information:
https://wiki.x2go.org/doku.php/wiki:advanced:x2gokdrive:start
regards, Alex
Stefan managed to get some funding for me to work on wrapping up X2Go KDrive (Agent + Client) as DEB packages.
I have committed quite some stuff to the repos, more to come the coming week. Please review. Especially, I prepared native builds against the DEB package xserver-xorg-source.
I also ported the nx-libs test scripts. With X2Go Client and also with the "on-localhost" testscript, I get this segfault:
However, I currently get this SegFault Traceback when initiating a connection:
x2gokdriveinit.c:194,ddxProcessArgument() mark argv[1]='-name' x2gokdriveinit.c:194,ddxProcessArgument() mark argv[3]='-geometry' x2gokdriveinit.c:194,ddxProcessArgument() mark argv[5]=':9' x2gokdriveinit.c:233,OsVendorInit() mark x2gokdriveinit.c:65,InitCard() mark x2gokdriveinit.c:170,processScreenOrOutputArg() screen number:0, size: 800x600, output (null) remote.c:2288,remote_init() running in NXAGENT MODE remote.c:2297,remote_init() read options from /home/mike/.x2go/C-9/options remote.c:2177,processConfigFileSetting() accept 127.0.0.1 remote.c:1709,setAgentState() Agent state STARTING remote.c:2058,open_socket() Accepting connections from 127.0.0.1 remote.c:2061,open_socket() Listen on port 15000 remote.c:2089,open_socket() Socket is ready x2gokdriveselection.c:640,selection_init() INITIALIZING selections x2gokdriveselection.c:657,install_selection_callbacks() SERVER CLIPBOARD disabled, not installing callbacks x2gokdrive.c:98,ephyrScreenInitialize() Init screen remote.c:2987,remote_screen_init() REMOTE SCREN INIT!!!!!!!!!!!!!!!!!! remote.c:2990,remote_screen_init() SKIPPING CALLBACK INSTALL remote.c:3001,remote_screen_init() host_screen=0x5645af625e60 x=0, y=0, wxh=800x600, buffer_height=1800 remote.c:3014,remote_screen_init() TRYING TO ALLOC MAIN_IMG 1920000 remote.c:3016,remote_screen_init() TRYING TO ALLOC DOUBLE BUF 1920000 remote.c:1321,send_frame_thread() Started sending thread: #0! remote.c:1325,send_frame_thread() waiting for TCP connection remote.c:3021,remote_screen_init() ALL INITIALIZED x2gokdrive.c:244,ephyrMapFramebuffer() DIRECT FB x2gokdrive.c:834,ephyrRandRInit() RANDR INIT, HERE WE ARE DOING OUR RANDR INITIALIZATION x2gokdrive.c:835,ephyrRandRInit() OUTPUTS: 0, CRTCS: 0, SIZES: 0 x2gokdrive.c:781,addOutput() CREATE OUTPUT X2GoEphyr-0 x2gokdrive.c:673,setOutput() Set output 800 600 0 0 x2gokdrive.c:732,setOutput() RANDR SIZES - SCREEN 800x600 - 271x203, OUTPUT 800x600 - 271x203 x2gokdrive.c:751,setOutput() OUPUT has now modes 1 (800x600) remote.c:1332,send_frame_thread() Connection from (127.0.0.1)... remote.c:1378,send_frame_thread() got 32 COOKIE BYTES from client remote.c:1387,send_frame_thread() Cookie approved remote.c:1709,setAgentState() Agent state RUNNING remote.c:1918,clientReadNotify() Client want resize to 1276x454 remote.c:1934,clientReadNotify() SCREEN 0 - (1276x454) - 0,0 x2gokdrive.c:861,ephyrResizeScreen() EPHYR RESIZE SCREEN!!! af6392f0 1276 454 x2gokdrive.c:864,ephyrResizeScreen() EPHYR RESIZE SCREEN 2 x2gokdrive.c:869,ephyrResizeScreen() Virtual Screens: 0x7ffd5d23c9e0 x2gokdrive.c:438,ephyrRandRSetConfig() SET RANDR CFG x2gokdrive.c:456,ephyrRandRSetConfig() Trying to get virtual screens x2gokdrive.c:457,ephyrRandRSetConfig() Virtual Screens: 0x7ffd5d23c9e0 remote.c:2987,remote_screen_init() REMOTE SCREN INIT!!!!!!!!!!!!!!!!!! remote.c:2995,remote_screen_init() REINSTALL CALLBACKS x2gokdriveselection.c:657,install_selection_callbacks() SERVER CLIPBOARD disabled, not installing callbacks remote.c:3001,remote_screen_init() host_screen=0x5645af625e60 x=0, y=0, wxh=1276x454, buffer_height=1362 remote.c:3010,remote_screen_init() FREE DBF remote.c:3012,remote_screen_init() DONE FREE DBF remote.c:3014,remote_screen_init() TRYING TO ALLOC MAIN_IMG 2317216 remote.c:3016,remote_screen_init() TRYING TO ALLOC DOUBLE BUF 2317216 remote.c:3021,remote_screen_init() ALL INITIALIZED x2gokdrive.c:244,ephyrMapFramebuffer() DIRECT FB (EE) (EE) Backtrace: (EE) 0: x2gokdrive (OsLookupColor+0x139) [0x5645ad81fc69] (EE) 1: /lib/x86_64-linux-gnu/libpthread.so.0 (funlockfile+0x50) [0x7fb9bc68177f] (EE) 2: x2gokdrive (GetScratchGC+0x31) [0x5645ad6f27c1] (EE) 3: x2gokdrive (miPaintWindow+0x182) [0x5645ad749082] (EE) 4: x2gokdrive (miWindowExposures+0xf2) [0x5645ad748e72] (EE) 5: x2gokdrive (miHandleValidateExposures+0x6e) [0x5645ad75771e] (EE) 6: x2gokdrive (SetRootClip+0x1f3) [0x5645ad70b703] (EE) 7: x2gokdrive (SwapShorts+0x49c) [0x5645ad72624c] (EE) 8: x2gokdrive (_start+0x70b0) [0x5645ad6e8b70] (EE) 9: x2gokdrive (_start+0x7496) [0x5645ad6e98e6] (EE) 10: x2gokdrive (_start+0x4faf) [0x5645ad6e4baf] (EE) 11: x2gokdrive (OsCleanup+0x591) [0x5645ad820a61] (EE) 12: x2gokdrive (WaitForSomething+0x1c3) [0x5645ad819883] (EE) 13: x2gokdrive (SendErrorToClient+0x10c) [0x5645ad71d59c] (EE) 14: x2gokdrive (InitAtoms+0x3c6) [0x5645ad6e4b46] (EE) 15: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0xeb) [0x7fb9bc4d009b] (EE) 16: x2gokdrive (_start+0x2a) [0x5645ad6db0fa] (EE) (EE) Segmentation fault at address 0x564500000008 (EE) Fatal server error: (EE) Caught signal 11 (Segmentation fault). Server aborting (EE)Does the above segfault and traceback ring a bell? If not, never mind. I will dive into it the coming week.
Note: I also merged the feature/kdrive_support branch found on x2goserver.git and x2goclient.git to master.
Greets, Mike
--
Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Schleiermacherstr. 2 | Fax. : 0911 - 14870374 9 D-90491 Nürnberg | Mobil: 0163 - 49 64 461
Geschäftsführung: Dipl.-Inf. Oleksandr Shneyder
Amtsgericht München | http://www.phoca-gmbh.de HRB 196 658 | http://www.x2go.org USt-IdNr.: DE281977973
Hi Alex,
On Mo 17 Jun 2019 09:22:48 CEST, Oleksandr Shneyder wrote:
Hi Mike,
Initially i started to develop X2Go KDrive based on source code of xorg-server-1.19.2. I made some patches to port it for some older versions used by SLES12SP1 and Leap42.3. I didn't try it yet with newer versions of XOrg, however I think it should not be a big deal. Looking on the log you provided, I could guess that the problem is somewhere in the XRandr handling. But I would need to take a closer look to be sure.
Regards Alex
I worked quite a bit on the X2Go KDrive Xserver code last week and
achieved the following:
no compiler warnings anymore -> please make sure you don't introduce new compiler warning -> build the package via debuild -uc -us to verify that no new compiler warnings are introduced
forward-port the X2Go KDrive code so that it builds against xorg-server 1.20.4
provide xorg-server code tree integration patches for all known
xorg-server versions that are found in Debian stretch, buster, bullseye/unstable and Ubuntu 16.04, 18.04, 19.04 and upcoming 19.10various coding style fixes / uniform commenting / typo fixes / etc.
integrationg of x2gokdrive and x2gokdriveclient builds in the DEB
based build infrastructures (jenkins.x2go.org, launchpad.net/~x2go)
For building against older X.Org versions, you added some patches
against x2gokdrive code into the upstream Git. These patches have now
been moved to the patches.legacy/ subfolder, see the
README.legacy-patches.md file for details on this [1]. Instead of
shipping such legacy patches, it might probably make more sense adding
the required backport changes into the x2gokdrive*.(ch) code files
using ifdef XORG_CURRENT_VERSION macros. See [2] for my work to
differentiate between xorg-server 1.19.x and 1.20.x.
While working on the code (esp. the separation of declarations and
actual code) I introduced some regressions. I think I have fixed them
all by now, but maybe not. Thus, I'd appreciate it if you could take a
close look at the changes made (unfortunately there are quite a lot of
commits between where you left of and today's master/HEAD).
Furthermore, I introduced an x2goserver-x2gokdrive wrapper package
that provides some integration support into X2Go Server.
Plus, I updated Python X2Go and PyHoca-CLI, so that they now also have
support for launching X2Go Agent and X2Go KDrive sessions alike.
Updating PyHoca-GUI accordingly is still pending. Not sure, when I
will get to that (I use pyhoca-cli from the terminal a lot these days,
but not so much pyhoca-gui, unfortunately).
How to test (on a Debian stretch or buster system or some recent
Ubuntu version):
### make sure you use the X2Go heuler (nightly built) repos
# on the X2Go Server:
sudo apt install x2goserver gnome cinnamon
# (this will pull in x2goserver-x2gokdrive, x2gokdrive and the
GNOME and the Cinnamon desktop)
# on the client (X2Go Client)
sudo apt install x2goclient
# (this will pull in x2gokdriveclient)
x2goclient -> create a GNOME or CINNAMON desktop session profile
and enable kdrive support
# or: on the client (PyHoca-CLI)
sudo apt install phyoca-cli
pyhoca-cli --server <server> --user <server-user> --command GNOME
--sound none
pyhoca-cli --server <server> --user <server-user> --command CINNAMON
Please let me know any concerns and thoughts you might have!
light+love, Mike
[1]
https://code.x2go.org/gitweb?p=x2gokdrive.git;a=blob;f=patches.legacy/README...
[2]
https://code.x2go.org/gitweb?p=x2gokdrive.git;a=commitdiff;h=3a30f5aa177e176...
DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
Hi Mike,
great job! I'm working currently on another project. I'll give it closer look when I'll have some time.
Regards Alex
Am 21.07.19 um 11:03 schrieb Mike Gabriel:
Hi Alex,
On Mo 17 Jun 2019 09:22:48 CEST, Oleksandr Shneyder wrote:
Hi Mike,
Initially i started to develop X2Go KDrive based on source code of xorg-server-1.19.2. I made some patches to port it for some older versions used by SLES12SP1 and Leap42.3. I didn't try it yet with newer versions of XOrg, however I think it should not be a big deal. Looking on the log you provided, I could guess that the problem is somewhere in the XRandr handling. But I would need to take a closer look to be sure.
Regards Alex
I worked quite a bit on the X2Go KDrive Xserver code last week and achieved the following:
* no compiler warnings anymore -> please make sure you don't introduce new compiler warning -> build the package via debuild -uc -us to verify that no new compiler warnings are introduced
* forward-port the X2Go KDrive code so that it builds against xorg-server 1.20.4
* provide xorg-server code tree integration patches for all known xorg-server versions that are found in Debian stretch, buster, bullseye/unstable and Ubuntu 16.04, 18.04, 19.04 and upcoming 19.10
* various coding style fixes / uniform commenting / typo fixes / etc.
* integrationg of x2gokdrive and x2gokdriveclient builds in the DEB based build infrastructures (jenkins.x2go.org, launchpad.net/~x2go)
For building against older X.Org versions, you added some patches against x2gokdrive code into the upstream Git. These patches have now been moved to the patches.legacy/ subfolder, see the README.legacy-patches.md file for details on this [1]. Instead of shipping such legacy patches, it might probably make more sense adding the required backport changes into the x2gokdrive*.(ch) code files using ifdef XORG_CURRENT_VERSION macros. See [2] for my work to differentiate between xorg-server 1.19.x and 1.20.x.
While working on the code (esp. the separation of declarations and actual code) I introduced some regressions. I think I have fixed them all by now, but maybe not. Thus, I'd appreciate it if you could take a close look at the changes made (unfortunately there are quite a lot of commits between where you left of and today's master/HEAD).
Furthermore, I introduced an x2goserver-x2gokdrive wrapper package that provides some integration support into X2Go Server.
Plus, I updated Python X2Go and PyHoca-CLI, so that they now also have support for launching X2Go Agent and X2Go KDrive sessions alike. Updating PyHoca-GUI accordingly is still pending. Not sure, when I will get to that (I use pyhoca-cli from the terminal a lot these days, but not so much pyhoca-gui, unfortunately).
How to test (on a Debian stretch or buster system or some recent Ubuntu version):
### make sure you use the X2Go heuler (nightly built) repos
# on the X2Go Server: sudo apt install x2goserver gnome cinnamon # (this will pull in x2goserver-x2gokdrive, x2gokdrive and the GNOME and the Cinnamon desktop)
# on the client (X2Go Client) sudo apt install x2goclient # (this will pull in x2gokdriveclient) x2goclient -> create a GNOME or CINNAMON desktop session profile and enable kdrive support
# or: on the client (PyHoca-CLI) sudo apt install phyoca-cli pyhoca-cli --server <server> --user <server-user> --command GNOME --sound none pyhoca-cli --server <server> --user <server-user> --command CINNAMON
Please let me know any concerns and thoughts you might have!
light+love, Mike
[1] https://code.x2go.org/gitweb?p=x2gokdrive.git;a=blob;f=patches.legacy/README...
[2] https://code.x2go.org/gitweb?p=x2gokdrive.git;a=commitdiff;h=3a30f5aa177e176...
--
Oleksandr Shneyder | Email: o.shneyder@phoca-gmbh.de phoca GmbH | Tel. : 0911 - 14870374 0 Schleiermacherstr. 2 | Fax. : 0911 - 14870374 9 D-90491 Nürnberg | Mobil: 0163 - 49 64 461
Geschäftsführung: Dipl.-Inf. Oleksandr Shneyder
Amtsgericht München | http://www.phoca-gmbh.de HRB 196 658 | http://www.x2go.org USt-IdNr.: DE281977973
On Di 23 Jul 2019 16:44:03 CEST, Oleksandr Shneyder wrote:
Plus, I updated Python X2Go and PyHoca-CLI, so that they now also have support for launching X2Go Agent and X2Go KDrive sessions alike. Updating PyHoca-GUI accordingly is still pending. Not sure, when I will get to that (I use pyhoca-cli from the terminal a lot these days, but not so much pyhoca-gui, unfortunately).
PyHoca-GUI has X2Go KDrive support now, too [1].
Mike
[1]
https://code.x2go.org/gitweb?p=pyhoca-gui.git;a=commitdiff;h=21f711d3c84f58d...
DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
-
Mike Gabriel -
Oleksandr Shneyder -
Stefan Baur -
Thierry Kauffmann -
Ulrich Sibiller -
Ulrich Sibiller