weston issueshttps://gitlab.freedesktop.org/wayland/weston/-/issues2023-11-24T09:35:47Zhttps://gitlab.freedesktop.org/wayland/weston/-/issues/560Crash on rdp-backend from/by using Windows 10 rdp client2023-11-24T09:35:47ZVyacheslav YurkovCrash on rdp-backend from/by using Windows 10 rdp clientI have pretty recent build of weston from main branch, which I start with rdp backend:
`/usr/bin/weston --backend=rdp-backend.so --rdp-tls-cert tls.crt --rdp-tls-key tls.key` on arm64 board.
I connect to it with Remote Desktop from a Wi...I have pretty recent build of weston from main branch, which I start with rdp backend:
`/usr/bin/weston --backend=rdp-backend.so --rdp-tls-cert tls.crt --rdp-tls-key tls.key` on arm64 board.
I connect to it with Remote Desktop from a Win10 machine. The first connection usually succeeds. But when I close the connection _and_ do not close the Remote Desktop application, but try to reconnect right away I get one of the following:
- either it's https://gitlab.freedesktop.org/wayland/weston/-/issues/509 and connection can't be established;
- or weston crashes. I've got a stacktrace for the crash
```
#0 0x0000ffff812935c4 in notify_motion_absolute (seat=0x0, time=time@entry=0xffffca045d00, x=x@entry=1070, y=y@entry=597) at ../git/libweston/input.c:1837
#1 0x0000ffff80a4ccc0 in xf_mouseEvent (input=<optimized out>, flags=<optimized out>, x=<optimized out>, y=597) at ../git/libweston/backend-rdp/rdp.c:1039
#2 0x0000ffff80937e3c in ?? () from /usr/lib/libweston-10/../libfreerdp2.so.2
#3 0x0000ffff8094af04 in ?? () from /usr/lib/libweston-10/../libfreerdp2.so.2
#4 0x0000ffff8094b7e0 in ?? () from /usr/lib/libweston-10/../libfreerdp2.so.2
#5 0x0000ffff8093afe0 in ?? () from /usr/lib/libweston-10/../libfreerdp2.so.2
#6 0x0000ffff809325e4 in ?? () from /usr/lib/libweston-10/../libfreerdp2.so.2
#7 0x0000ffff8094a524 in ?? () from /usr/lib/libweston-10/../libfreerdp2.so.2
#8 0x0000ffff80a4ce1c in rdp_client_activity (fd=<optimized out>, mask=<optimized out>, data=0xaaaac2f76ff0) at ../git/libweston/backend-rdp/rdp.c:734
#9 0x0000ffff81230e18 in wl_event_loop_dispatch () from /usr/lib/libwayland-server.so.0
#10 0x0000ffff8122e73c in wl_display_run () from /usr/lib/libwayland-server.so.0
#11 0x0000ffff8144290c in wet_main (argc=<optimized out>, argv=0xffffca046958, test_data=<optimized out>) at ../git/compositor/main.c:3506
#12 0x0000ffff812e6994 in __libc_start_main () from /lib/libc.so.6
#13 0x0000aaaabbb1a738 in _start () at ../sysdeps/aarch64/start.S:91
```
It seems to be a null pointer dereference. If you have any ideas what could be the reason, I could look into it further and fix it probably.https://gitlab.freedesktop.org/wayland/weston/-/issues/742Incorrect mapping of Windows keyboard layout "KBD_CZECH_PROGRAMMERS"2023-04-18T09:02:10Zcarlos-h-hIncorrect mapping of Windows keyboard layout "KBD_CZECH_PROGRAMMERS"In `libweston/backend-rdp/rdp.c`, the Windows keyboard layout `KBD_CZECH_PROGRAMMERS` is mapped to `cz(bksl)`.
This is incorrect, since the Czech Programmers layout is the US layout with accessing the Czech symbols by pressing Right-Alt...In `libweston/backend-rdp/rdp.c`, the Windows keyboard layout `KBD_CZECH_PROGRAMMERS` is mapped to `cz(bksl)`.
This is incorrect, since the Czech Programmers layout is the US layout with accessing the Czech symbols by pressing Right-Alt.
The correct XKB equivalent for it is: layout: `us,cz`, no variants, option: `grp:switch`.https://gitlab.freedesktop.org/wayland/weston/-/issues/711Clipboard doesn't appear to working when using in-tandem with the screen-shar...2023-02-06T15:01:33ZMarius VladClipboard doesn't appear to working when using in-tandem with the screen-share modulePresumably we get two clipboards, one for the client and one for the RDP back-end. While copy/paste works
with the RDP back-end, when doing screen-share that doesn't appear to be case.
Using a different client (rather than fullscreen-s...Presumably we get two clipboards, one for the client and one for the RDP back-end. While copy/paste works
with the RDP back-end, when doing screen-share that doesn't appear to be case.
Using a different client (rather than fullscreen-shell) would also need implementing clipboard or have a way
to have multiple back-end and pass data from one head to another *without* any intermediary client?https://gitlab.freedesktop.org/wayland/weston/-/issues/705Document how to create a AF_VSOCK and pass it to weston rdp2023-01-13T10:32:04ZGianluca S.Document how to create a AF_VSOCK and pass it to weston rdpA PR added allowed to specifying a listener fd on the command line https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/839, but documentation is missing.
I suggest to add a short documentation on this topic:
- Is it possible ...A PR added allowed to specifying a listener fd on the command line https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/839, but documentation is missing.
I suggest to add a short documentation on this topic:
- Is it possible to create a socket with socat and pass it to weston?
- OR Do we have to create the socket in a parent process (in C) as [Microsoft WSL does](https://github.com/microsoft/wslg/blob/main/WSLGd/main.cpp#L292)?
- How to connect from Windows rdphttps://gitlab.freedesktop.org/wayland/weston/-/issues/337RDP-backend needs access control2021-11-01T10:41:20ZPekka Paalanenppaalanen@gmail.comRDP-backend needs access controlI haven't seen any access control on who is allowed to connect to the RDP server. If you can access the listening port, then you gain immediate access to the desktop, no questions asked. This makes running the RDP server even on just loc...I haven't seen any access control on who is allowed to connect to the RDP server. If you can access the listening port, then you gain immediate access to the desktop, no questions asked. This makes running the RDP server even on just localhost a problem, because any local user could connect to it and take over the desktop. Obviously exposing that port to the internet would be just insane.
I would like to see at least password based authentication (preferably integrated with PAM such that the user's login password could be used by default without adding it into any `weston.ini` or such).
A good addition would be public key based authentication with the same idea as SSH does it.
Does the RDP protocol itself already support these and all that is left is to hook it up in RDP-backend?https://gitlab.freedesktop.org/wayland/weston/-/issues/276RDP-backend is too slow / uses too much network bandwidth2020-09-17T09:14:51ZPekka Paalanenppaalanen@gmail.comRDP-backend is too slow / uses too much network bandwidthWeston/RDP could be ideal for a personal use case of mine, running a headless remote desktop server on my workstation that I could then access from home, over an SSH tunnel. (It is very important to use an SSH tunnel and restrict access ...Weston/RDP could be ideal for a personal use case of mine, running a headless remote desktop server on my workstation that I could then access from home, over an SSH tunnel. (It is very important to use an SSH tunnel and restrict access to the RDP server ports, because there does not seem to be any client authentication.)
When I tried it, it was unusably slow even with a relatively small desktop over a 1.0/0.5 MB/s link. Dragging a window results in a slow motion movie where the window goes through all the intermediate positions instead of skipping to the final position, for instance.
I hear the RDP-backend implementation is kind of naive. It could be a lot smarter in making the most out of the available network bandwidth.
@rdp.effort, could you list here some things to implement in the RDP-backend that would improve the performance?
How much does the RDP client software affect this, what would you recommend? I tried with Remmina, and I recall Vinagre was even worse.
I cannot work on this myself, but I'd like people to know that the slowness is not inherent to Wayland or even to pixel-based remoting schemes, and that there are things one could do to make it better.https://gitlab.freedesktop.org/wayland/weston/-/issues/329RDP backend, pointer image dangles when mouse leaves RDP client window2020-09-17T09:14:48ZKen CRDP backend, pointer image dangles when mouse leaves RDP client windowWhen the mouse pointer leaves a RDP client application window, Weston leaves the last known image/glyph state of the pointer on-screen. In my case I am using `xfreerdp` as the client. This is with Weston off master.
Screencap below. I c...When the mouse pointer leaves a RDP client application window, Weston leaves the last known image/glyph state of the pointer on-screen. In my case I am using `xfreerdp` as the client. This is with Weston off master.
Screencap below. I can do a motion gif, but hopefully it captures the gist. The mouse has just exited off the right side of the window. Where the image ends up depends on how fast you move the mouse. What I would like is the pointer to disapear, and re-appear in the correct state when the pointer again enters the RDP client window.
If anyone has any ideas on how to get an event out of FreeRDP indicating the mouse has left the building, I can attempt a PR. I've tried naively wiring up `input->FocusInEvent` in `rdp_peer_init`, but sadly it never fires. I'm not actually sure what that event does, but it looked plausible. Oddly I do find through experimentation that a `SynchronizeEvent` reliably fires when the pointer leaves the client, but there isn't enough information in `flags` to tell the difference between the pointer leaving and (say) a caps-lock toggle off.
Any suggestions on how to tackle this appreciated.
![image](/uploads/9f1d250709ce2b299ebb5bbbbc6ba293/image.png)https://gitlab.freedesktop.org/wayland/weston/-/issues/323RDP-backend to-do from review2020-01-03T23:12:32ZPekka Paalanenppaalanen@gmail.comRDP-backend to-do from reviewWishing for the RDP-backend to improve, I read through its code. These are my notes. I did not bother to open a new issue for each single one, but feel free to open Issues or MRs as you see fit, mention them here and I will update this d...Wishing for the RDP-backend to improve, I read through its code. These are my notes. I did not bother to open a new issue for each single one, but feel free to open Issues or MRs as you see fit, mention them here and I will update this description with a link.
- [ ] seat release, needs safe wl_global removal in libweston core from #322
- [ ] call `weston_head_set_monitor_strings()` when creating the head
- [ ] `weston_head_set_physical_size()` parameters from remote screen physical size? #324
- [ ] drop manually created shadow buffer, seems unused
- [ ] prevent mode list from growing unlimited in `ensure_matching_mode()`
- [ ] `rdp_output_repaint()`: implement frame-dropping or throttle to transmission framerate to avoid slow-motion updates in the remote?
- `rdp_peer_refresh_raw()`:
- [ ] `marker.frameID++` uninitialized?
- [ ] what if `heightIncrement` starts zero due to a very wide rect?
- `rdp_peer_refresh_nsc()`:
- [ ] suspicious `#ifdef`-skipping of `memset()` to zero; would be better to use unconditional initialization
- [ ] why does it use damage extents instead of rects?
- `rdp_peer_refresh_rfx()`:
- [ ] suspicious `#ifdef`-skipping of `memset()` to zero; would be better to use unconditional initialization
- [ ] why offset `ptr` by extents `x1`, `y1`?
- [ ] log RDP remote actions with a new debug scope, e.g. `rdp_peer_refresh_*()`, input events, connects and disconnects
- [ ] clean up `#ifdef`s for old freerdp versions according to what the build requires today