Waypipe issueshttps://gitlab.freedesktop.org/mstoeckl/waypipe/-/issues2024-03-14T00:30:06Zhttps://gitlab.freedesktop.org/mstoeckl/waypipe/-/issues/101Support (QtWayland 6.6) Compositor Handoffs2024-03-14T00:30:06ZMarcelina FilsSupport (QtWayland 6.6) Compositor Handoffs## Description
With Qt 6.6 application running on KWin Wayland, it's now possible to keep the application alive after compositor crashes:
- https://blog.davidedmundson.co.uk/blog/qt6_wayland_robustness/
- https://invent.kde.org/plasma/...## Description
With Qt 6.6 application running on KWin Wayland, it's now possible to keep the application alive after compositor crashes:
- https://blog.davidedmundson.co.uk/blog/qt6_wayland_robustness/
- https://invent.kde.org/plasma/kwin/-/wikis/Restarting
However, waypipe doesn't work with it, and when compositor crashes, waypipe exits and the remote Qt 6.6 application also exits.
## Steps to reproduce:
This is trivially reproducible by using KDE Plasma Wayland on local PC and Qt 6.6 application on remote PC.
#### Prepare the session
1. (Local machine) start waypipe client:
```bash
waypipe -s /tmp/waypipe-socket-local client
```
2. (Local machine) start SSH socket forwarding:
```bash
ssh -R /tmp/waypipe-socket-remote:/tmp/waypipe-socket-local -t <remote-pc>
```
Execute the command in a tmux session to prevent compositor crashing from bringing SSH connection down.
3. (Remote machine) start any Qt 6.6 application using waypipe:
```bash
export QT_WAYLAND_RECONNECT=1
waypipe \
--control /tmp/waypipe-ctrl \
--display wayland-waypipe \
-s /tmp/waypipe-socket-remote \
server -- <Application Path>
```
The environment variable `QT_WAYLAND_RECONNECT=1` is required. KDE Plasma 6 sets this automatically but not for remote applications.
[Strawberry](https://github.com/flathub/org.strawberrymusicplayer.strawberry) is a Qt 6 application that supports reconnecting.
#### Test
###### A) Drop the SSH connection and reconnect:
1. (Local machine) Press Ctrl + C on the SSH socket forwarding connection twice.
Then connect again:
```bash
ssh -R /tmp/waypipe-socket-remote:/tmp/waypipe-socket-local -t <remote-pc>
```
2. (Remote machine) Clean up the dead socket
```bash
unlink /tmp/waypipe-socket-remote
```
3. (Local machine) Establish the SSH socket forwarding connection again:
```bash
ssh -R /tmp/waypipe-socket-remote:/tmp/waypipe-socket-local -t <remote-pc>
```
4. (Remote machine) Finally, issue the reconnect command
```bash
waypipe recon /tmp/waypipe-ctrl /tmp/waypipe-socket-remote
```
###### B) Manually kill the compositor
Open System Monitor, find kwin_wayland and send signal `SIGKILL`.
## Expected results
For Test A: After issuing the reconnect command, the remote Qt application should reappear on local desktop.
For Test B: After compositor is restarted, the remote Qt application should reappear automatically.
## Actual results
For Test A: After issuing the reconnect command, the remote Qt application seems to be aware that wayland socket is down, and console output `Waiting for reconnection`. However, it never actually reconnect.
For Test B: After compositor is restarted, the remote Qt application is already killed.
## Additional informations
The remote Qt application can reconnect properly after compositor restart if the local wayland socket is directly bind-mounted to the remote system (The remote system runs within a [Incus](https://linuxcontainers.org/incus/) container. [Setup guide](https://discuss.linuxcontainers.org/t/incus-lxd-profile-for-gui-apps-wayland-x11-and-pulseaudio/18295)), without the use of waypipe.
David Edmundson (KDE maintainer) implemented most of the Wayland compositor hand-offs features. Here are some related links which might be useful:
- https://invent.kde.org/plasma/kwin/-/wikis/Restarting#adding-support-to-your-toolkit-or-standalone-application (In case you didn't see it)
- https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/283#note_1876210
- https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/4073#note_1865439https://gitlab.freedesktop.org/mstoeckl/waypipe/-/issues/100Document security implications2024-03-17T21:36:16ZSteve ZDocument security implicationsIt's well known that X11 forwarding is insecure for the client, and you should only use X11 forwarding if the server is trusted. But it's not clear if waypipe is any different. Should you only use waypipe with trusted remotes? Can the re...It's well known that X11 forwarding is insecure for the client, and you should only use X11 forwarding if the server is trusted. But it's not clear if waypipe is any different. Should you only use waypipe with trusted remotes? Can the remote server grab keyboard input when the window isn't in focus? Take screenshots? Execute commands? Access the filesystem? I think this should be documented somewhere in the readme and/or man page.https://gitlab.freedesktop.org/mstoeckl/waypipe/-/issues/99Discord + Brave Browser fail to launch via waypipe2024-03-18T03:24:03ZCRCinAUDiscord + Brave Browser fail to launch via waypipeI was recently pointed to waypipe to run apps remotely - and so far, its worked well with a number of applications I would normally use a full remote desktop for - which is a great alternative.
I've come across a couple of applications ...I was recently pointed to waypipe to run apps remotely - and so far, its worked well with a number of applications I would normally use a full remote desktop for - which is a great alternative.
I've come across a couple of applications - Discord and Brave Browser - that refuse to run.
```
# waypipe --no-gpu ssh 172.31.1.169 Discord
Discord 0.0.42
[6964:0220/183606.974189:ERROR:ozone_platform_x11.cc(239)] Missing X server or $DISPLAY
[6964:0220/183606.974232:ERROR:env.cc(255)] The platform failed to initialize. Exiting.
The futex facility returned an unexpected error code.
[0220/183606.989437:ERROR:file_io_posix.cc(144)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq: No such file or directory (2)
[0220/183606.989482:ERROR:file_io_posix.cc(144)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq: No such file or directory (2)
```
```
# waypipe --no-gpu ssh 172.31.1.169 brave-browser-stable
[7090:7090:0220/183809.952636:ERROR:ozone_platform_x11.cc(239)] Missing X server or $DISPLAY
[7090:7090:0220/183809.952654:ERROR:env.cc(257)] The platform failed to initialize. Exiting.
```
I haven't been able to find much about this via google - but perhaps this is a Chromium based thing? As Brave is forked from Chromium, and Discord is an electron app.
Any suggestions or things that could be tried to get these working?https://gitlab.freedesktop.org/mstoeckl/waypipe/-/issues/98Wishlist: Add option to set XDG_SESSION_TYPE automatically2024-02-11T16:19:12ZSergio CallegariWishlist: Add option to set XDG_SESSION_TYPE automaticallyMany applications require some environment variable to be set in order to run properly with waypipe. This is nicely mentioned in the man pages, together with some examples. However, the proposed methods to set the required environment va...Many applications require some environment variable to be set in order to run properly with waypipe. This is nicely mentioned in the man pages, together with some examples. However, the proposed methods to set the required environment variables are not always handy and in some cases may not play nice with situations in which you do not use waypipe:
1. `.ssh/environment` is a sort of environment file for *all* ssh sessions and not just for those managed by waypipe
2. Using `SendEnv` and `AcceptEnv` needs the sendenv to be passed on the command line only for sessions managed by waypipe for the same reason
3. Using `env` on the command line is the easiest thing, but is a bit wordy when you need to do it every time
Because at least `XDG_SESSION_TYPE=wayland` will almost invariably need to be set every time, would be nice to have an option on the waypipe command line to set it automatically. In the end waypipe already sets automatically the `WAYLAND_DISPLAY` variable. Namely `waypipe -W ssh server konsole` is way shorter than `waypipe ssh server "env XDG_SESSION_TYPE=wayland konsole"`. Furthermore, having an option makes it much easier to create a shell alias.https://gitlab.freedesktop.org/mstoeckl/waypipe/-/issues/97Waypipe frequently crashes when selecting a large portion of texts using mous...2024-02-09T03:34:26ZMarcelina FilsWaypipe frequently crashes when selecting a large portion of texts using mouse in Qt Creator#### Description
In Qt Creator, by holding left click button to select a large portion of texts(codes), waypipe tends to crash most of the time. This doesn't occur when selecting texts using keyboard.
#### Commands
```bash
waypipe \
...#### Description
In Qt Creator, by holding left click button to select a large portion of texts(codes), waypipe tends to crash most of the time. This doesn't occur when selecting texts using keyboard.
#### Commands
```bash
waypipe \
--compress=none \
--allow-tiled \
--video=hw,vp9 \
ssh -X <remote-address> -- <remote-program>
```
I've manually set up a wrapper script to make sure Qt Creator starts as Wayland client instead of X11 client.
#### Logs
Always the same errors when crashing:
```
C677931: 35.237735 [src/shadow.c:1514] shadow structure for RID=-107 was not available
S127073: 35.249740 [src/shadow.c:1514] shadow structure for RID=-107 was not available
wl_display@1: error 3: waypipe internal error
The Wayland connection experienced a fatal error during blocking read event: Protocol error
```
#### Versions
Same for both local and remote system:
```bash
> waypipe --version
waypipe 0.8.6
features: lz4 zstd dmabuf video vaapi
unavailable:
```
Local system has KWin (v5.27.10) as the Wayland compositor.https://gitlab.freedesktop.org/mstoeckl/waypipe/-/issues/94vkcube-wayland corrupted (server: Intel, client: AMD)2024-01-29T12:59:33ZDmitry Sharshakovvkcube-wayland corrupted (server: Intel, client: AMD)![image](/uploads/e359e59366bf4dcfd7224c2c861511c1/image.png)
Texture flashes quickly, but I certainly haven't seen a correct image there. Errors related to DMABUFs are being reported to the terminal. Textures change if I open app launc...![image](/uploads/e359e59366bf4dcfd7224c2c861511c1/image.png)
Texture flashes quickly, but I certainly haven't seen a correct image there. Errors related to DMABUFs are being reported to the terminal. Textures change if I open app launcher for example, thus they might be some uninitialized BOs on the client side
Server: Intel Jasper Lake (Celeron N5095A iGPU)
Client: AMD Renoir (Ryzen 5 4500U iGPU)
Doesn't occur if I launch Weston and connect vkcube-wayland to Weston. Please ask for other data necessary.https://gitlab.freedesktop.org/mstoeckl/waypipe/-/issues/93[Feature Request] Support systemd socket activation2024-01-25T16:15:04ZDerek Ditch[Feature Request] Support systemd socket activationI'd like to run waypipe within my local user session at login using systemd. The current code creates the socket and binds it to the configured file [here](https://gitlab.freedesktop.org/mstoeckl/waypipe/-/blob/master/src/util.c#L228-264...I'd like to run waypipe within my local user session at login using systemd. The current code creates the socket and binds it to the configured file [here](https://gitlab.freedesktop.org/mstoeckl/waypipe/-/blob/master/src/util.c#L228-264). It'd be great if waypipe had an option to check (`sd_listen_fds`)[https://www.freedesktop.org/software/systemd/man/latest/sd_listen_fds.html] for an already configured socket descriptor that is managed by [systemd.socket](https://www.freedesktop.org/software/systemd/man/latest/systemd.socket.html) activation. This would make waypipe only run when a remote server is actually connected.
For now, I've worked around this having it always run locally upon login and remotely upon login, using my `ssh_config` to configure the RemoteForward. as documented in this [gist](https://gist.github.com/dcode/912be128174c468a2dc28f263bdb7328).https://gitlab.freedesktop.org/mstoeckl/waypipe/-/issues/91Cannot get NVIDIA to intel working2023-12-17T08:57:48Zdarkblaze69Cannot get NVIDIA to intel working* GNOME 45
Cannot get NVIDIA to intel working:
```
C27002: 34.965737 [src/handlers.c:358] Display sent fatal error message zwp_linux_buffer_params_v1, code 7: failed to import supplied dmabufs: Could not bind the given EGLImage to a Co...* GNOME 45
Cannot get NVIDIA to intel working:
```
C27002: 34.965737 [src/handlers.c:358] Display sent fatal error message zwp_linux_buffer_params_v1, code 7: failed to import supplied dmabufs: Could not bind the given EGLImage to a CoglTexture2D
S93269: 34.957608 [src/handlers.c:358] Display sent fatal error message zwp_linux_buffer_params_v1, code 7: failed to import supplied dmabufs: Could not bind the given EGLImage to a CoglTexture2D
Gdk-Message: 13:53:55.187: Error 71 (Protocol error) dispatching to Wayland display.
```https://gitlab.freedesktop.org/mstoeckl/waypipe/-/issues/89application windows appears on remote machine not the local one2023-10-24T06:56:44Zbeccon4application windows appears on remote machine not the local oneOn two machines running Ubuntu 22.04 I installed waypipe from the official packages.
Calling
```
waypipe ssh user@remote-machine gnome-terminal
```
results in the terminal windows appearing at the screen of the remote machine - not ...On two machines running Ubuntu 22.04 I installed waypipe from the official packages.
Calling
```
waypipe ssh user@remote-machine gnome-terminal
```
results in the terminal windows appearing at the screen of the remote machine - not as expected on the local one.
Outputs:
```
S34456: 10.509952 [src/dmabuf.c:167] Failed to open drm fd for /dev/dri/renderD128: No such file or directory
S34456: 10.582914 [src/mainloop.c:875] application has closed
```
The same goes for any other program called remotely such as e.g. firefox.
What's wrong? This phenomenon apperars too simple to be an issue.https://gitlab.freedesktop.org/mstoeckl/waypipe/-/issues/87`--video` option does not work on a client without DMABUF support (only SHM a...2023-10-16T23:47:45ZSergei Trofimovich`--video` option does not work on a client without DMABUF support (only SHM and DRM support?)I tried to use `waypipe` from ChromeOS linux VM with their wayland implementation passed through as a client against Linux with AMD video card:
```
chromeos-nvidia $ waypipe --video=sw,h264 ssh nz
nz $ es2gears_wayland
```
The resultin...I tried to use `waypipe` from ChromeOS linux VM with their wayland implementation passed through as a client against Linux with AMD video card:
```
chromeos-nvidia $ waypipe --video=sw,h264 ssh nz
nz $ es2gears_wayland
```
The resulting performance is too low to be usable:
```
62 frames in 5.0 seconds = 12.356 FPS
66 frames in 5.0 seconds = 13.098 FPS
59 frames in 5.0 seconds = 11.697 FPS
```
The larger window I get the worse performance I see. Having added a bit of debugging into `waypipe` I think it happens because `ChromeOS` wayland implementation does not support DMABUFs:
```
$ wayland-info
interface: 'wl_compositor', version: 4, name: 1
interface: 'wl_shm', version: 1, name: 2
formats (fourcc):
0x36314752 = 'RG16'
1 = 'XR24'
0 = 'AR24'
0x34324258 = 'XB24'
0x34324241 = 'AB24'
0x3231564e = 'NV12'
interface: 'wl_drm', version: 2, name: 3
interface: 'wl_subcompositor', version: 1, name: 4
interface: 'wl_output', version: 3, name: 5
x: 0, y: 0, scale: 2,
physical_width: 280 mm, physical_height: 187 mm,
make: 'unknown', model: 'unknown',
subpixel_orientation: unknown, output_transform: normal,
mode:
width: 2560 px, height: 1706 px, refresh: 60.000 Hz,
flags: current preferred
interface: 'wl_data_device_manager', version: 3, name: 6
interface: 'wp_viewporter', version: 1, name: 7
interface: 'zwp_tablet_manager_v2', version: 1, name: 8
tablet_seat: default
tablet: Touchscreen
vendor: 0
product: 0
tablet_tool: eraser
capabilities: tilt pressure
tablet_tool: pen
capabilities: tilt pressure
interface: 'wl_seat', version: 5, name: 9
name: default
capabilities: pointer keyboard touch
keyboard repeat rate: 50
keyboard repeat delay: 200
interface: 'gtk_shell1', version: 1, name: 10
interface: 'wl_shell', version: 1, name: 11
interface: 'zwp_pointer_constraints_v1', version: 1, name: 12
interface: 'zwp_relative_pointer_manager_v1', version: 1, name: 13
interface: 'zwp_text_input_manager_v1', version: 1, name: 14
interface: 'zcr_text_input_x11_v1', version: 1, name: 15
interface: 'zcr_text_input_extension_v1', version: 11, name: 16
interface: 'xdg_wm_base', version: 3, name: 17
```
And as a result programs use SHM/DRM:
```
[3526492.422] -> wl_shm_pool@24.create_buffer(new id wl_buffer@25, 0, 348, 372, 1392, 0)
[3526492.698] -> wl_shm_pool@26.create_buffer(new id wl_buffer@27, 0, 300, 24, 1200, 1)
[3526505.692] -> wl_drm@6.create_prime_buffer(new id wl_buffer@30, fd 13, 300, 300, 875713112, 0, 1216, 0, 0, 0, 0)
[3526505.919] -> wl_shm_pool@32.create_buffer(new id wl_buffer@33, 0, 696, 744, 2784, 0)
[3526725.818] -> wl_drm@6.create_prime_buffer(new id wl_buffer@28, fd 11, 300, 300, 875713112, 0, 1216, 0, 0, 0, 0)
[3526725.876] -> wl_shm_pool@26.create_buffer(new id wl_buffer@24, 0, 600, 48, 2400, 1)
[3526799.421] -> wl_drm@6.create_prime_buffer(new id wl_buffer@32, fd 11, 300, 300, 875713112, 0, 1216, 0, 0, 0, 0)
[3526799.690] -> wl_shm_pool@31.create_buffer(new id wl_buffer@34, 0, 696, 744, 2784, 0)
[3526800.654] -> wl_shm_pool@35.create_buffer(new id wl_buffer@36, 0, 600, 48, 2400, 1)
[3526863.924] -> wl_drm@6.create_prime_buffer(new id wl_buffer@26, fd 11, 300, 300, 875713112, 0, 1216, 0, 0, 0, 0)
[3529029.601] -> wl_drm@6.create_prime_buffer(new id wl_buffer@26, fd 11, 300, 300, 875713112, 0, 1216, 0, 0, 0, 0)
[3529397.841] -> wl_shm_pool@35.create_buffer(new id wl_buffer@24, 5632, 16, 15, 64, 0)
[3529671.796] -> wl_shm_pool@27.create_buffer(new id wl_buffer@31, 5632, 16, 15, 64, 0)
[3529788.327] -> wl_shm_pool@35.create_buffer(new id wl_buffer@24, 0, 696, 744, 2784, 0)
[3529789.331] -> wl_shm_pool@25.create_buffer(new id wl_buffer@38, 0, 600, 48, 2400, 1)
[3529806.057] -> wl_shm_pool@27.create_buffer(new id wl_buffer@39, 4032, 10, 16, 40, 0)
```
Is there a chance `waypipe` could support video encoding for this case?https://gitlab.freedesktop.org/mstoeckl/waypipe/-/issues/85Support virtio-shmem with virtio-vsock2024-01-19T19:04:33ZJakob RuedigerSupport virtio-shmem with virtio-vsock`virtio-shmem` is used primarily in virtual machines, this allows the guest and the host to have shared memory and would speed up `waypipe` significantly for local connections.
Manually being able to specify an mmap location on both `wa...`virtio-shmem` is used primarily in virtual machines, this allows the guest and the host to have shared memory and would speed up `waypipe` significantly for local connections.
Manually being able to specify an mmap location on both `waypipe` server and client by path would be great like `waypipe --shmem /dev/shm/vm1`.
If you need you further details on how `virtio-shmem` is used with `qemu`, I can attach further details.https://gitlab.freedesktop.org/mstoeckl/waypipe/-/issues/83Firefox loses buffer and is unusable slow with fractional scaling2023-09-12T08:01:03ZNils TonnättFirefox loses buffer and is unusable slow with fractional scalingWhen running firefox using waypipe with fractional scaling on Gnome 44, I get following warnings. Firefox is unusable slow. The cursor warning can probably be ignored because it's still using Gtk3, but Firefox seems to regularly lose its...When running firefox using waypipe with fractional scaling on Gnome 44, I get following warnings. Firefox is unusable slow. The cursor warning can probably be ignored because it's still using Gtk3, but Firefox seems to regularly lose its buffer.
```
(firefox:296005): Gdk-WARNING **: 12:44:34.099: ../gdk/wayland/gdkcursor-wayland.c:242 cursor image size (64x64) not an integermultiple of scale (3)
(firefox:296005): Gdk-WARNING **: 12:44:34.932: ../gdk/wayland/gdkcursor-wayland.c:242 cursor image size (64x64) not an integermultiple of scale (3)
S296027: 77.180582 [../src/handlers.c:730] Attached buffer no longer exists
S296027: 81.511072 [../src/handlers.c:730] Attached buffer no longer exists
(firefox:296005): Gdk-WARNING **: 12:44:41.511: ../gdk/wayland/gdkcursor-wayland.c:242 cursor image size (64x64) not an integermultiple of scale (3)
S296027: 87.670102 [../src/handlers.c:730] Attached buffer no longer exists
(firefox:296005): Gdk-WARNING **: 12:44:47.670: ../gdk/wayland/gdkcursor-wayland.c:242 cursor image size (64x64) not an integermultiple of scale (3)
(firefox:296005): Gdk-WARNING **: 12:44:47.670: ../gdk/wayland/gdkcursor-wayland.c:242 cursor image size (64x64) not an integermultiple of scale (3)
(firefox:296005): Gdk-WARNING **: 12:44:47.670: ../gdk/wayland/gdkcursor-wayland.c:242 cursor image size (64x64) not an integermultiple of scale (3)
```https://gitlab.freedesktop.org/mstoeckl/waypipe/-/issues/81[BUG] [ARM] Running application does not display2023-07-21T08:07:56ZSelso LIBERADO[BUG] [ARM] Running application does not displayHello,
I am testing a remote display between two arm devices.
I am running this script to try to launch waypipe with application :
```
export WAYLAND_DISPLAY=wayland-0
LOCAL_PORT=/tmp/socket-local
REMOTE_PORT=/tmp/socket-remote
EXE=/...Hello,
I am testing a remote display between two arm devices.
I am running this script to try to launch waypipe with application :
```
export WAYLAND_DISPLAY=wayland-0
LOCAL_PORT=/tmp/socket-local
REMOTE_PORT=/tmp/socket-remote
EXE=/usr/bin/weston-terminal
REMOTEIP=192.168.91.191
LOGINIP=root
DISPLAY=$REMOTE_PORT
/opt/waypipe -d -s $LOCAL_PORT client &
ssh -g -R $LOCAL_PORT:localhost:$REMOTE_PORT -t $LOGINIP@$REMOTEIP QT_QPA_PLATFORM=wayland\
/opt/waypipe -d --display $DISPLAY -s $REMOTE_PORT server -- \
$EXE
kill %1
```
I had to define --display otherwise it was saying it could not place the socket.
But nothing displays. There are error messages looping :
```
c14932: 24.009919 [src/client.c:716] I'm a client listening on '/tmp' / 'socket-local'
c14932: 24.009993 [src/client.c:718] version: 0.8.6 (commit a55cd3b10c5ff7e99a2d454041687272251d2758)
c14932: 24.010118 [src/client.c:763] A wayland compositor is available. Proceeding.
ssh: Allocated port 33923 for remote forward to localhost:0
^[[32ms11128: 24.117265 [src/server.c:592] I'm a server connecting on /tmp x socket-remote, running: /usr/bin/weston-terminal^[[0m^M
^[[32ms11128: 24.117331 [src/server.c:595] version: 0.8.6 (commit a55cd3b10c5ff7e99a2d454041687272251d2758)^[[0m^M
^[[32ms11128: 24.117742 [src/server.c:408] Connection token header: 00010980^[[0m^M
^[[32ms11128: 24.139156 [src/server.c:517] New connection to server^[[0m^M
^[[32ms11128: 24.139577 [src/server.c:517] New connection to server^[[0m^M
^[[32ms11130: 24.139704 [src/mainloop.c:1180] Running main loop on application side^[[0m^M
^[[32ms11128: 24.140037 [src/server.c:517] New connection to server^[[0m^M
^[[32ms11130: 24.140059 [src/mainloop.c:900] Read 0 new file descriptors, have 0 total now^[[0m^M
^[[32ms11130: 24.140085 [src/mainloop.c:991] We are transferring a data buffer with 24 bytes^[[0m^M
^[[32ms11130: 24.140096 [src/mainloop.c:1026] Channel message start (0 blobs, 0 bytes, 1 trailing, 0 tasks)^[[0m^M
^[[32ms11130: 24.140126 [src/mainloop.c:856] Sent 28-byte message from application to channel; 28-bytes in flight^[[0m^M
^[[32ms11131: 24.140239 [src/mainloop.c:1180] Running main loop on application side^[[0m^M
^[[32ms11128: 24.140500 [src/server.c:517] New connection to server^[[0m^M
^[[32ms11133: 24.140588 [src/mainloop.c:1180] Running main loop on application side^[[0m^M
^[[32ms11131: 24.140635 [src/mainloop.c:900] Read 0 new file descriptors, have 0 total now^[[0m^M
^[[32ms11131: 24.140647 [src/parsing.c:534] Wayland messages lengths must be divisible by 4^[[0m^M
^[[32ms11133: 24.140925 [src/mainloop.c:900] Read 0 new file descriptors, have 0 total now^[[0m^M
^[[32ms11133: 24.140955 [src/parsing.c:534] Wayland messages lengths must be divisible by 4^[[0m^M
^[[32ms11128: 24.140977 [src/server.c:517] New connection to server^[[0m^M
```https://gitlab.freedesktop.org/mstoeckl/waypipe/-/issues/80[BUILD] crosscompile fail2023-07-20T02:03:51ZSelso LIBERADO[BUILD] crosscompile failI want to build for iMX8M CPU.
I wrote a crossfile for that arch following those [instructions](https://thiblahute.github.io/jpakkane.github.io/Cross-compilation.html), under ubuntu 20.04.
The toolchain was installed using a yocto genera...I want to build for iMX8M CPU.
I wrote a crossfile for that arch following those [instructions](https://thiblahute.github.io/jpakkane.github.io/Cross-compilation.html), under ubuntu 20.04.
The toolchain was installed using a yocto generated package, which provide a shell to be sourced before building.
I call this command to launch configuration :
`meson --buildtype debugoptimized --cross-file cross-file.txt --reconfigure --fatal-meson-warnings waypipe build-waypipe-imx8`
[cross-file.txt](/uploads/88c3caf7e0aebe2fa32971c0bd67728f/cross-file.txt)
[meson.log](/uploads/3c1cb00ddf0b68406bc977992b394a4e/meson.log)
I found strange that the host machine is still x86_64 but at least it is detecting a crosscompile and the crosscompiler.
Then I launch the build but it fails : it is adding an include to the build machine path.
[build.log](/uploads/dcd4db824c3912f84f4142e1f65d9042/build.log)
To me it is because of tha t-I/usr/include which will relate to the build machine FS.
That include is the result of a pkg-config call.
From the meson log I identified :
Called `/home/nautilus/Yocto/fslc-xwayland/3.3/sysroots/x86_64-fslcsdk-linux/usr/bin/pkg-config --variable=includedir libdrm` -> 0
/usr/include
Got pkgconfig variable includedir : /usr/include
I don't know why and how it found a pkg in that path. of course the path is invalid.At least is should provide the path prepended with that sysroot.
If search a little bit and this can be done by adding --define-prefix option.
since I'm not familiar with meson, with some change I coud fix it :
```
libdrm_include_dir = run_command('pkg-config', '--variable=includedir', '--define-prefix', 'libdrm').stdout().strip()
waypipe_includes += include_directories(libdrm_include_dir)
```
That change may not be the most elegant way to do that though. That is why I am not proposing a pull request.
Probably the change should be done for the other dependencies not found by pkg.
I am not sure the crossfile is useful because I had the crossbuild info positionned without it.
Best regards.https://gitlab.freedesktop.org/mstoeckl/waypipe/-/issues/79Kitty won't start without `--no-gpu` flag2023-05-30T15:29:28ZIgor TorrenteKitty won't start without `--no-gpu` flag## Description
I'm not able to run kitty ontop waypipe without the `--no-gpu` flag.
## Logs
[waypipe_kitty.log](/uploads/fa8a5d62e28e00601faf55d1b86b7f85/waypipe_kitty.log)
## Additional info
``` console
(Server and client)$ waypipe ...## Description
I'm not able to run kitty ontop waypipe without the `--no-gpu` flag.
## Logs
[waypipe_kitty.log](/uploads/fa8a5d62e28e00601faf55d1b86b7f85/waypipe_kitty.log)
## Additional info
``` console
(Server and client)$ waypipe --version
waypipe 0.8.6 (commit 033d0e7eb613f1ddfe104d07079a81b8d4e02dac)
features: lz4 zstd dmabuf video vaapi
unavailable:
```
``` console
(Server)$ gnome-shell --version
GNOME Shell 43.4
(Client)$ gnome-shell --version
GNOME Shell 43.3
```
<details><summary>$ glxinfo -B </summary>
<p>
``` console
(Server) $ glxinfo -B
name of display: :0
display: :0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: Intel (0x8086)
Device: Mesa Intel(R) Xe Graphics (TGL GT2) (0x9a49)
Version: 22.3.6
Accelerated: yes
Video memory: 15700MB
Unified memory: yes
Preferred profile: core (0x1)
Max core profile version: 4.6
Max compat profile version: 4.6
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) Xe Graphics (TGL GT2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 22.3.6
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL version string: 4.6 (Compatibility Profile) Mesa 22.3.6
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 22.3.6
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
```
``` console
(Client) $ glxinfo -B
name of display: :0
display: :0 screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
Vendor: AMD (0x1002)
Device: AMD Radeon RX 6600 (navi23, LLVM 15.0.6, DRM 3.49, 6.1.0-6-amd64) (0x73ff)
Version: 22.3.6
Accelerated: yes
Video memory: 8192MB
Unified memory: no
Preferred profile: core (0x1)
Max core profile version: 4.6
Max compat profile version: 4.6
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
Memory info (GL_ATI_meminfo):
VBO free memory - total: 7494 MB, largest block: 7494 MB
VBO free aux. memory - total: 7832 MB, largest block: 7832 MB
Texture free memory - total: 7494 MB, largest block: 7494 MB
Texture free aux. memory - total: 7832 MB, largest block: 7832 MB
Renderbuffer free memory - total: 7494 MB, largest block: 7494 MB
Renderbuffer free aux. memory - total: 7832 MB, largest block: 7832 MB
Memory info (GL_NVX_gpu_memory_info):
Dedicated video memory: 8192 MB
Total available memory: 16132 MB
Currently available dedicated video memory: 7494 MB
OpenGL vendor string: AMD
OpenGL renderer string: AMD Radeon RX 6600 (navi23, LLVM 15.0.6, DRM 3.49, 6.1.0-6-amd64)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 22.3.6
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL version string: 4.6 (Compatibility Profile) Mesa 22.3.6
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 22.3.6
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
```
</p>
</details>https://gitlab.freedesktop.org/mstoeckl/waypipe/-/issues/78--no-gpu is required with Jetson AGX Orin as server2023-05-17T06:33:32ZRussell Greene--no-gpu is required with Jetson AGX Orin as serverI understand that wayland support on the Jetson platform is experimental, so the problem may very well not be with waypipe.
When I run `waypipe ssh orin env weston-simple-egl` I get
```
S8894: 1.434117 [src/dmabuf.c:354] Failed to map...I understand that wayland support on the Jetson platform is experimental, so the problem may very well not be with waypipe.
When I run `waypipe ssh orin env weston-simple-egl` I get
```
S8894: 1.434117 [src/dmabuf.c:354] Failed to map dmabuf
Unsupported modifier, resource creation failed.
C52618: 1.441242 [src/dmabuf.c:302] Failed to make dmabuf (with format 34325241, modifier 300000000606014): Permission denied
S8894: 1.742075 [src/mainloop.c:1408] Channel hang up detected, no reconnection link, fatal
wl_display@1: error 3: waypipe internal error
```
Then it just hangs there. SIGINT closes it. It works with --no-gpu
The client process crashes:
```
#0 gbm_bo_get_stride_for_plane () at ../mesa-23.0.3/src/gbm/main/gbm.c:194
#1 0x000055d1cdbb3b10 in do_zwp_linux_buffer_params_v1_req_create
(ctx=ctx@entry=0x7fff9a6242b0, width=<optimized out>, height=<optimized out>, format=875713089, flags=<optimized out>) at ../waypipe/src/handlers.c:1466
#2 0x000055d1cdbb3e3b in do_zwp_linux_buffer_params_v1_req_create_immed
(ctx=0x7fff9a6242b0, buffer_id=0x55d1cf988160, width=<optimized out>, height=<optimized out>, format=<optimized out>, flags=<optimized out>)
at ../waypipe/src/handlers.c:1551
#3 0x000055d1cdba5a57 in handle_message
(g=g@entry=0x7fff9a624760, display_side=display_side@entry=true, from_client=from_client@entry=true, chars=chars@entry=0x7fff9a624350, fds=fds@entry=0x7fff9a624588) at ../waypipe/src/parsing.c:424
#4 0x000055d1cdba5df9 in parse_and_prune_messages
(g=g@entry=0x7fff9a624760, on_display_side=on_display_side@entry=true, from_client=from_client@entry=true, source_bytes=source_bytes@entry=0x7fff9a6243c0, dest_bytes=dest_bytes@entry=0x7fff9a624558, fds=fds@entry=0x7fff9a624588)
at ../waypipe/src/parsing.c:559
#5 0x000055d1cdba1e02 in interpret_chanmsg
(cmsg=cmsg@entry=0x7fff9a624550, cxs=cxs@entry=0x7fff9a6244d0, g=g@entry=0x7fff9a624760, display_side=display_side@entry=true, packet=0x7f80294a006c "")
at ../waypipe/src/mainloop.c:357
#6 0x000055d1cdba453e in advance_chanmsg_chanread
(g=0x7fff9a624760, display_side=true, chanfd=6, cxs=0x7fff9a6244d0, cmsg=0x7fff9a624550) at ../waypipe/src/mainloop.c:517
#7 advance_chanmsg_transfer
(any_changes=<optimized out>, progfd=7, chanfd=6, display_side=true, cxs=0x7fff9a6244d0, cmsg=0x7fff9a624550, g=0x7fff9a624760)
at ../waypipe/src/mainloop.c:604
#8 main_interface_loop
(chanfd=chanfd@entry=6, progfd=7, linkfd=<optimized out>, config=config@entry=0x7fff9a6249f0, display_side=display_side@entry=true)
at ../waypipe/src/mainloop.c:1389
#9 0x000055d1cdb9db8c in handle_new_client_connection
(conn_id=<optimized out>, disp_path=..., config=<optimized out>, connmap=0x7fff9a6249e0, chanclient=6, n_other_fds=<optimized out>, other_fds=0x7fff9a624aa0, cwd_fd=<optimized out>) at ../waypipe/src/client.c:493
#10 run_multi_client
(disp_path=..., config=0x7fff9a6254f0, eol_pid=0x7fff9a625428, channelsock=4, cwd_fd=<optimized out>) at ../waypipe/src/client.c:640
#11 run_client
(cwd_fd=cwd_fd@entry=3, sock_folder_name=sock_folder_name@entry=0x7fff9a6258c0 "/tmp/", sock_folder_fd=<optimized out>, sock_filename=sock_filename@entry=0x7fff9a625662 "waypipe-client-A61py8k7.sock", config=config@entry=0x7fff9a6254f0, oneshot=oneshot@entry=false, wayland_socket=<optimized out>, eol_pid=<optimized out>, channelsock=<optimized out>) at ../waypipe/src/client.c:760
#12 0x000055d1cdb99f02 in main (argc=3, argv=0x7fff9a625e28)
at ../waypipe/src/waypipe.c:1018
```
Setup:
Client:
* i9-11900H, hyprland Arch Linux
Server:
* Nvidia Jetson AGX Orin Devkit, Gnome Wayland 42, Jetpack 5.1.1
waypipe 033d0e7eb613f1ddfe104d07079a81b8d4e02dac on both sideshttps://gitlab.freedesktop.org/mstoeckl/waypipe/-/issues/77Support more video codecs?2023-05-20T14:11:34ZFerdinandSupport more video codecs?While supporting h264 and vp9 fits most use cases, I'd like to see support for hevc and av1. While the respective software encoders are rather slow, hardware accelerated they have their use cases when using waypipe: There are many graphi...While supporting h264 and vp9 fits most use cases, I'd like to see support for hevc and av1. While the respective software encoders are rather slow, hardware accelerated they have their use cases when using waypipe: There are many graphics cards that have a hevc encoder, but no vp9 encoder. Currently your only choice when using such a graphics card when requiring hardware acceleration is falling back to h264, which provides much worse quality for the same bitrate. (And there are graphics cards where the h264 encoder is broken and produces ugly artifacts like my RX Vega)
Additionally, I think av1 is a great codec for this when using hardware accelerated encoding and decoding, which is finally available with the current generations of AMD and Intel GPUs (Nvidia also has av1 encoding now, but [https://github.com/elFarto/nvidia-vaapi-driver/issues/116](https://github.com/elFarto/nvidia-vaapi-driver/issues/116) doesn't support encoding) as it allows users to run on much less bandwidth for a much better (and bigger) picture.
Because in Waypipe the distinguishing between the codecs to use often times works by using the `? :` operator, implementing this would require some refactoring.https://gitlab.freedesktop.org/mstoeckl/waypipe/-/issues/76Feature request: Android support2023-07-11T13:14:57ZKarel MatějovskýFeature request: Android supportHi
First of all I'd like to thank for this ambitious project, I'm using Wayland and this way I have a chance of running remote desktop over the network. Anyway my goal is to somehow send an image of one of my screens over to my phone sc...Hi
First of all I'd like to thank for this ambitious project, I'm using Wayland and this way I have a chance of running remote desktop over the network. Anyway my goal is to somehow send an image of one of my screens over to my phone screen (I want to setup a dummy monitor so that my phone acts as another screen). Is there any way to apply this model on Android as well or is it an inappropriate to do so?
Thank you again for making such and amazing project, peacehttps://gitlab.freedesktop.org/mstoeckl/waypipe/-/issues/75socket not removed in ssh example in README.md2023-04-11T06:37:44ZChris Vogelsocket not removed in ssh example in README.mdIf I do the following as described in https://gitlab.freedesktop.org/mstoeckl/waypipe/-/blob/master/README.md …
```
/usr/bin/waypipe -s /tmp/socket-local client &
ssh -R /tmp/socket-remote:/tmp/socket-local -t user@theserver \
/usr/...If I do the following as described in https://gitlab.freedesktop.org/mstoeckl/waypipe/-/blob/master/README.md …
```
/usr/bin/waypipe -s /tmp/socket-local client &
ssh -R /tmp/socket-remote:/tmp/socket-local -t user@theserver \
/usr/bin/waypipe -s /tmp/socket-remote server -- \
/usr/bin/weston-terminal
kill %1
```
… on `theserver` the socket `/tmp/socket-remote` is not removed afterwards.
Any subsequent try using the ssh-command from above leads to the following error …
```
Warning: remote port forwarding failed for listen path /tmp/socket-remote
info: main.c:356: version: 1.6.4 +ime
info: main.c:363: arch: x86_64/64-bit
info: main.c:367: locale: de_DE.UTF-8
err: config.c:2109: no configuration found, using defaults
S59522: 38.861965 [src/util.c:250] Error connecting to socket (socket-remote): Connection refused
err: wayland.c:1125: no compositor
err: wayland.c:1492: failed to flush wayland socket: Connection reset by peer
info: main.c:523: goodbye
Connection to theserver closed.
```
… because ssh didn't clean up the file `/tmp/socket-remote` on its last disconnect.https://gitlab.freedesktop.org/mstoeckl/waypipe/-/issues/73Window borders2024-01-19T19:04:34ZLuke DashjrWindow bordersIt would be nice to put a coloured border around waypipe windows, different for each client, to easily identify (eg) which machine a program is running on.
Xpra does this for X11.It would be nice to put a coloured border around waypipe windows, different for each client, to easily identify (eg) which machine a program is running on.
Xpra does this for X11.