here's xrdp development talk room, questions here: https://gitter.im/neutrinolabs/xrdp-questions
xrdp_egfx_send_delete_surface(wm->mm->egfx, 1);
xrdp_egfx_send_reset_graphics(wm->mm->egfx, session_width, session_height, wm->client_info->monitorCount, wm->client_info->minfo_wm);
xrdp_egfx_send_create_surface(wm->mm->egfx, 1, session_width, session_width, XR_PIXEL_FORMAT_XRGB_8888);
xrdp_egfx_send_map_surface(wm->mm->egfx, 1, 0, 0);
Spoke too soon. There's still something wrong with my dynamic resize + egfx branch. For some reason, XRDP is sending too many tiles to freerdp using XR_RDPGFX_CMDID_WIRETOSURFACE_2 and I cannot seem to figure out why. A great way to reproduce it is to start at 1000x1000 and then scale to 1000x1250 (drag the height down), and then all of a sudden XRDP sends nearly 50 more tiles. I've tried resetting the encoder and it doesn't help, either.
I'll take a look at this later, probably busy for the rest of the week.
Hi Team. I had been an XRDPuser for the last month, and I love it! Thank you so much for making my life easier! I had been using XPRA for years, and it took only a few days for me to switch after getting exposed to xrdp.
I am unsure if this is the right place to post this. Please do let me know if I should post this message/request somewhere else.
I want to showcase my container image project for xrdp here for your feedback and suggestions. I hope you all like it. I would appreciate it if you could spend few minutes trying it out.
Use case:- Recently, I moved all of my VM deployments to Kubernetes by converting everything into container images. For the XRDP server VM, I looked at existing container images available in the public container repositories. However, all of them were pretty old, not maintained, and too complex to understand. I spent some time yesterday making xrdp work inside a container. I have a fully working container image for xrdp on Ubuntu. I think that this image is simple to understand as compared to other available images.
This container image is for those who do not want to set up a VM with GUI with XRDP, or all of their workloads are in containers, and they require GUI access in the remote network. I intend to continue working on this container image project and maintain it besides other images that I have built.
Based on the suggestions and feedback, I want to add some more features to it below list:
- Build container image as soon as a new stable version of xrdp is released.
- Add container images for other popular distros.
- Automated tests of newly built container image with CI pipeline (I have free infrastructure resources).
- Add more configuration options for the container image.
- Link container image tag versions to the XRDP version inside the image.
Run the container with XRDP
docker run --rm -itd -e GUEST_PASS='guest' -p 3389:3389 -v ${pwd}/data/home:/home/guest --name xrdp satishweb/xrdp
Connect to container using remote desktop on localhost:3389 and login with user guest and password as guest
Note:- This is still a work in progress. There is a lot of scope for optimization for sure.
5 replies
I'm not sure if this is heresy or awesome. I have XRDP working with all these features at the same time:
- Dynamic resolution/resize without reconnection
- GFX compression (H264)
- The wyhash optimization PR
- Nvidia acceleration
Here are the branches:
- https://github.com/Nexarian/xrdp/tree/resize_egfx_xrdp_features
- https://github.com/Nexarian/xorgxrdp/tree/resize_wyhash_egfx_nvidia_features
They're rebased off the devel branches, and I've tried to keep the branches clean such that the individual commits on top of devel correspond to their respective WIP features
Obviously there's a lot of work and testing and bug fixing before all of that can go into devel or be released, but I wanted to show that all of this can work.
Going forward I'm going to be daily driving these branches.
This answers the questions as to whether or not nvidia_hack can work with the gfx optimizations. It can!
The root cause is an update to the VM image by github and there is already an issue opened: actions/virtual-environments#2917
1 reply
No insights here I'm afraid.
On a separate topic, I've just spent quite a chunk of time commenting on an issue neutrinolabs/xrdp#1832 which there's been a Debian bug outstanding on for over two years. I've had great success interacting with the Fedora team when we've raised packaging issues with them but absolutely no luck at all with the Debian/Ubuntu packaging team. If anyone's got any ideas on how we can better communicate with these guys, I'm all ears.
8 replies
I'm new here in the group and I have a big doubt!
Today at xrdp it is possible to transfer files from one machine to another! great feature by the way.
I would like to know if it is possible ... xrdp to analyze what is on the clipboard (transfer area) and if it contains a URL with a xxx tag, open the browser on the client side with the link provided in the URL
Hi,
While fixing up a pull request there was some code that I'd like to unit test, but xrdp doesn't have a dependency on any unit testing framework that I'm aware of.
To be able to do the unit testing I'd like to add a dependency on the package check. It seems to be a popular and stable package that is available for xardp's target platforms (linux and FreeBSD), and integrates with autotools to give per test function results in the make check output.
Are there concerns with adding the check package as a dependency to xrdp's build requirements?
Are there other unit testing frameworks that are preferred? and why?
Hi all. While I know this is supposed to be mostly about XRDP, I think now and again it's OK to let the human side of our lives show a little. Recently, my company and a blog post I wrote for them were featured for Autism awareness day:
I think that most of us have some experience with autism and aspergers, especially with a product as niche as XRDP:
https://www.cnn.com/2021/04/02/health/autism-awareness-day-wellness/index.html
2 replies
Guys - I'm looking at Jay's WIP neutrinolabs/xrdp#1602 which looks at adding UNIX domain socket possibilities between xrdp and sesman.
Is there any good reason anyone can think of to keep TCP sockets between xrdp and sesman? It's not a connection we can make secure without a lot of effort, and assuming the two processes (and chansrv) are on the same box would make things a lot easier all round. Am I missing something?
3 replies
Good question - depends what you mean by proxy/gateway.
sesman is contacted over TCP currently when using pamusername=. The password is sent in plaintext.
Removing this facility makes it impossible to use a sesman on another node to authenticate, but given it's hugely insecure I don't think we should be supporting this.
The neutrinordp proxy doesn't use seman directly but can probably also make use of the link above.
tests directory from SUBDIR is the best way to enable/disable unit tests.