Here's build commands for debian bullseye (testing track atm)

[twitchyliquid64]

Sharing in case they are useful. Feel free to put them on the readme/faq if you are inclined :)

#!/bin/bash

# Install dependencies
DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true apt-get install -y \
  build-essential make cmake autoconf git ninja-build meson scdoc pkg-config \
  zlib1g-dev libpixman-1-dev libturbojpeg0-dev libgbm-dev \
  libgnutls28-dev \
  libdrm-dev libdrm-common libxkbcommon-dev libxkbcommon-tools libxkbcommon0 \
  wayland-protocols waylandpp-dev wayland-scanner++ libwayland-dev

set -xe

# Build, copied straight from README
git clone https://github.com/any1/wayvnc.git
git clone https://github.com/any1/neatvnc.git
git clone https://github.com/any1/aml.git

mkdir wayvnc/subprojects
cd wayvnc/subprojects
ln -s ../../neatvnc .
ln -s ../../aml .
cd -

mkdir neatvnc/subprojects
cd neatvnc/subprojects
ln -s ../../aml .
cd -

cd wayvnc
meson build
ninja -C build

[any1]

Thanks. Are waylandpp-dev and wayland-scanner++ actually needed? Seems odd given that this is not a C++ project.

Edit: Also cmake seems out of place

[twitchyliquid64]

Hmmm, I'll try without, I basically just skimmed the other distro instructions + the meson file and threw in anything I thought was related. I'll try without those three packages and report back.

[Lyamc]

You're missing libpam0g-dev btw.

Edit: moved previous text to issue #86

[elsiehupp]

To get this running on Ubuntu (20.10) I had to add a few more steps:

$ sudo apt install graphviz \
                   libdrm-dev \
                   libpam0g-dev \
                   libturbojpeg-dev \
                   libxcb-xkb-dev \
                   scdoc \
                   valgrind

$ sudo dpkg --purge --force-all libxkbcommon0
$ sudo dpkg --purge --force-all libxkbcommon0:i386
$ wget http://ftp.br.debian.org/debian/pool/main/libx/libxkbcommon/libxkbcommon0_1.0.3-2_amd64.deb
$ sudo dpkg --install libxkbcommon0_1.0.3-2_amd64.deb

$ sudo dpkg --purge --force-all libxkbcommon-dev
$ sudo dpkg --purge --force-all libxkbcommon-dev:i386
$ wget http://ftp.br.debian.org/debian/pool/main/libx/libxkbcommon/libxkbcommon-dev_1.0.3-2_amd64.deb
$ sudo dpkg --install libxkbcommon-dev_1.0.3-2_amd64.deb

$ sudo dpkg --purge --force-all libsdl2-2.0-0:i386
$ wget http://ftp.br.debian.org/debian/pool/main/libs/libsdl2/libsdl2-2.0-0_2.0.14+dfsg2-3_amd64.deb
$ sudo dpkg --install libsdl2-2.0-0_2.0.14+dfsg2-3_amd64.deb

$ sudo dpkg --purge --force-all libsdl2-dev:i386
$ wget http://ftp.br.debian.org/debian/pool/main/libs/libsdl2/libsdl2-dev_2.0.14+dfsg2-3_amd64.deb
$ sudo dpkg --install libsdl2-dev_2.0.14+dfsg2-3_amd64.deb

$ sudo dpkg --purge --force-all libxkbcommon-x11-0
$ wget http://ftp.br.debian.org/debian/pool/main/libx/libxkbcommon/libxkbcommon-x11-0_1.0.3-2_amd64.deb
$ sudo dpkg --install libxkbcommon-x11-0_1.0.3-2_amd64.deb

$ sudo apt --fix-broken install
$ sudo apt autoremove

$ cd <path_to_cloned_directory>/aml
$ meson build
$ sudo ninja -C build install

$ cd <path_to_cloned_directory>/neatvnc
$ meson build
$ sudo ninja -C build install

(These steps can probably be further simplified.)

To summarize, the issues were:

1. Ubuntu seems to have slightly different names for certain apt packages.
2. Ubuntu ships with a comedically outdated version of xkbcommon, so this version of the instructions manually installs the Debian version.
3. The wayvnc install script doesn't install libaml.so.0 or libneatvnc.so.0 properly (see Meson/Ninja incorrectly installing libaml.so.0 libneatvnc.so.0 on Ubuntu #86), so you have to install them individually.

Now the issue I'm running into is that my graphics drivers don't seem to support Wayland, though it sounds like this will be fixed with NVIDIA's upcoming 470 driver release. (It seems that NVIDIA has pulled the 470 beta from distribution, though, due to the fact that it unlocked Ethereum mining on Windows.) My guess as to why I had previously gotten Wayland running on my computer is that I may have been using the open-source Nouveau driver, which comes with its own set of problems.

[Lyamc]

I’ll test this out on 21.04

[elsiehupp]

FWIW I don't know if there are any other problems caused by manually upgrading xkbcommon. Ideally the install script would be able to use a version other than the one included with the operating system. (I don't know how to do this off the top of my head.)

[elsiehupp]

Another approach might be including xkbcommon as a subproject, like so:

$ git clone https://github.com/xkbcommon/libxkbcommon.git
$ cd wayvnc/subprojects
$ ln -s ../../libxkbcommon .
$ cd -

Then replacing the following line in meson.build:

wayvnc/meson.build

Line 47 in 7a60ab7

xkbcommon = dependency('xkbcommon', version: '>=1.0.0')

with:

xkbcommon = subproject('libxkbcommon', required: true)

This would work around the problem of Ubuntu (and possibly other distributions) not including recent enough versions of xkbcommon.

[crazy-logic]

so I've been trying to get this compile under 21.04;

sudo apt install git meson ninja-build build-essential cmake libpam0g-dev libpixman-1-dev libdrm-dev libxkbcommon-dev libwayland-dev libturbojpeg gnutls-bin zlib1g-dev libgnutls28-dev libturbojpeg-dev scdoc

git clone https://github.com/any1/wayvnc.git
git clone https://github.com/any1/neatvnc.git
git clone https://github.com/any1/aml.git

mkdir wayvnc/subprojects
cd wayvnc/subprojects
ln -s ../../neatvnc .
ln -s ../../aml .
cd -

mkdir neatvnc/subprojects
cd neatvnc/subprojects
ln -s ../../aml .
cd -

cd wayvnc
meson build
ninja -C build

but when i run ./build/wayvnc

i get the following

wl_registry@2: error 0: invalid version for global wl_seat (16): have 5, wanted 7
ERROR: Virtual Pointer protocol not supported by compositor.
ERROR: Failed to initialise wayland

any ideas?

when running the menson build the only thing hat stood out was "||Header <sys/event.h> has symbol "kqueue" : NO" is this important ?

[Lyamc]

What DE are you running? Gnome doesn’t work right now and it’s not wayvnc’s fault

#86 (comment)

[crazy-logic]

yeah running Gnome - i guess that's why then... :(

[mike-yamazaki]

Hi.

I am trying to install wayvnc on a Raspberry Pi 4B running Raspberry Pi OS 64 Bullseye. My ultimate goal is to mirror a Cage session running on the RasPi as the server with any computer running VNC Viewer. I have been continually attempting to install in several different ways, but ultimately, I get the same result.

Here's the text of the exact error that I'm getting when I run $ ninja -C build
ninja: Entering directory build'
[43/76] Compiling C object subprojects/neatvnc/libneatvnc.so.0.0.0.p/src_h264-encoder.c.o
../subprojects/neatvnc/src/h264-encoder.c: In function ‘fb_to_avframe’:
../subprojects/neatvnc/src/h264-encoder.c:136:25: warning: implicit declaration of function ‘gbm_bo_get_fd_for_plane’; did you mean ‘gbm_bo_get_handle_for_plane’? [-Wimplicit-function-declaration]
136 | desc->objects[i].fd = gbm_bo_get_fd_for_plane(bo, i);
| ^~~~~~~~~~~~~~~~~~~~~~~
| gbm_bo_get_handle_for_plane
[67/76] Linking target subprojects/neatvnc/libneatvnc.so.0.0.0
FAILED: subprojects/neatvnc/libneatvnc.so.0.0.0
cc -o subprojects/neatvnc/libneatvnc.so.0.0.0 subprojects/neatvnc/libneatvnc.so.0.0.0.p/src_server.c.o subprojects/neatvnc/libneatvnc.so.0.0.0.p/src_vec.c.o subprojects/neatvnc/libneatvnc.so.0.0.0.p/src_zrle.c.o subprojects/neatvnc/libneatvnc.so.0.0.0.p/src_raw-encoding.c.o subprojects/neatvnc/libneatvnc.so.0.0.0.p/src_pixels.c.o subprojects/neatvnc/libneatvnc.so.0.0.0.p/src_fb.c.o subprojects/neatvnc/libneatvnc.so.0.0.0.p/src_fb_pool.c.o subprojects/neatvnc/libneatvnc.so.0.0.0.p/src_rcbuf.c.o subprojects/neatvnc/libneatvnc.so.0.0.0.p/src_stream.c.o subprojects/neatvnc/libneatvnc.so.0.0.0.p/src_display.c.o subprojects/neatvnc/libneatvnc.so.0.0.0.p/src_tight.c.o subprojects/neatvnc/libneatvnc.so.0.0.0.p/src_enc-util.c.o subprojects/neatvnc/libneatvnc.so.0.0.0.p/src_qnum-to-evdev.c.o subprojects/neatvnc/libneatvnc.so.0.0.0.p/src_resampler.c.o subprojects/neatvnc/libneatvnc.so.0.0.0.p/src_transform-util.c.o subprojects/neatvnc/libneatvnc.so.0.0.0.p/src_damage-refinery.c.o subprojects/neatvnc/libneatvnc.so.0.0.0.p/src_murmurhash.c.o subprojects/neatvnc/libneatvnc.so.0.0.0.p/src_encoder.c.o subprojects/neatvnc/libneatvnc.so.0.0.0.p/src_cursor.c.o subprojects/neatvnc/libneatvnc.so.0.0.0.p/src_logging.c.o subprojects/neatvnc/libneatvnc.so.0.0.0.p/src_h264-encoder.c.o subprojects/neatvnc/libneatvnc.so.0.0.0.p/src_open-h264.c.o -Wl,--as-needed -Wl,--no-undefined -shared -fPIC -Wl,--start-group -Wl,-soname,libneatvnc.so.0 '-Wl,-rpath,$ORIGIN/../aml' -Wl,-rpath-link,/home/sakilabo/wayvnc/build/subprojects/aml subprojects/aml/libaml.so.0.0.0 -lm /usr/lib/aarch64-linux-gnu/libpixman-1.so /usr/lib/aarch64-linux-gnu/libz.so /usr/lib/aarch64-linux-gnu/libturbojpeg.so /usr/lib/aarch64-linux-gnu/libgnutls.so /usr/lib/aarch64-linux-gnu/libgbm.so /usr/lib/aarch64-linux-gnu/libdrm.so /usr/lib/aarch64-linux-gnu/libavcodec.so /usr/lib/aarch64-linux-gnu/libavfilter.so /usr/lib/aarch64-linux-gnu/libavutil.so -Wl,--end-group
/usr/bin/ld: subprojects/neatvnc/libneatvnc.so.0.0.0.p/src_h264-encoder.c.o: in function fb_to_avframe': /home/sakilabo/wayvnc/build/../subprojects/neatvnc/src/h264-encoder.c:136: undefined reference to gbm_bo_get_fd_for_plane'
collect2: error: ld returned 1 exit status
[72/76] Compiling C object wayvnc.p/src_buffer.c.o
ninja: build stopped: subcommand failed.`

My original thought is that it has something to do with a failure when meson building aml.

aml| Project name: aml aml| Project version: 0.2.2 aml| C compiler for the host machine: cc (gcc 10.2.1 "cc (Debian 10.2.1-6) 10.2.1 20210110") aml| C linker for the host machine: cc ld.bfd 2.35.2 aml| Program git found: YES (/usr/bin/git) aml| Library rt found: YES aml| Run-time dependency threads found: YES aml| Header "sys/epoll.h" has symbol "epoll_create" : YES aml| Header "sys/event.h" has symbol "kqueue" : NO aml| Message: epoll backend chosen aml| Build targets in project: 1 aml| Subproject aml finished.

kqueue seems to be missing from sys/event.h . It doesn't end the meson build and perhaps there's no correlation.

I have tried several approaches to installation. Firs, from the instructions on the front page of the git. Then, individually (starting with neatvnc and then aml, finally wayvnc). Then, I copied-and-pasted the script at the top of this thread and let that run. I kept throwing the same errors.

A search has not yielded any results that helped. I am kind of at a loss for how to get around this. Unless this is an incompatibility issue with RasPi OS, or with the hardware itself, it's certain that I am missing something vital. I just can't figure out where.

Any assistance or pointing in the direction where this same issue may have been solved will be humbly appreciated.

[any1]

meson build -Dneatvnc:h264=disabled is the correct way to do it. Otherwise, things will just break when a client that supports h264 connects.

[mike-yamazaki]

I did a reinstall with the correct way to bypass h264. Now I am exploring how to get it to work with a Cage session. There are some insights on other threads so I will look there. Thank you for your help.

[mike-yamazaki]

Aaaaaaand, I'm still stuck (lol). I've tried multiple angles and I can't seem to get this to work. I'm running on 2 year-old software being peddled as the "latest" version. I seem to recall someone getting this to work on a Raspberry Pi, but all that was commented was, "It works" with no details (apparently, a trade secret?).

I could really use some help. Every time I run it on the host computer, I get "1001: Failed to initialise wayland."

I read somewhere that it has to be called within the compositor. If I Cage Foot and run wayvnc there, I get the following errors:
Virtual Pointer protocol not supported by compositor ← This seems to be patched but said patch is not compatible with the Raspberry Pi at this time. Upon patch application, a rebuild generated almost a hundred errors which seems to lend credence to the compatibility issue.
wayvnc may still work if started with --disable-input
Failed to initialise wayland

When I run $./build/wayvnc --disable-input, I get
Failed to bind to address

If I run the same in a regular terminal, I get the initialization failure again.

I can't seem to find a solid resolution anywhere. What am I missing?

I apologize if there is an elementary step I'm missing.

[any1]

"Failed to bind to address" means that the server could not create a TCP socket for listening to incoming connections. Maybe something else is listening on 127.0.0.1:5900?

Wayvnc is a wayland client, so it needs to know where to contact the wayland compositor (server). This is what the WAYLAND_DISPLAY environment variable does. It tells the client where to connect to. If you're running inside the compositor, the compositor sets this environment variable for you. If you're running outside the compositor, you need to find out what it is and set it to that value. The unix socket is usually located at wayland-1, but you can run something like find /var/run/user/$UID/ -name "wayland-[0-9]" to see where it actually is.

To set the environment variable, you must run wayvnc like this:

WAYLAND_DISPLAY=wayland-1 wayvnc

or this

export WAYLAND_DISPLAY=wayland-1
wayvnc

There are other ways to set an environment variable, but these are two ways of doing it that are definitely correct.

There is the option of ditching rpi os and just running archlinux instead, for fresh software.

I don't know what you're using this for, but I don't think that you are bound to running cage. You could also just use sway with a minimal config file. That's what I do for embedded systems anyway.

[mike-yamazaki]

The project the company is working on is still in an evaluation stage. As of right now, the idea is to use hardware familiar to the company, which is the rpi. We will be experimenting with other hardware, but as of right now, the primary thing is to operate a system around the rpi. I can't really get into the hard specifics due to the nature of the project, but the central hardware requirements require the rpi (which the other proprietary hardware communicates with). So I'm looking to be able to remotely connect remotely, in real time (not a separate ssh channel/socket) for maintenance purposes.

The base requirements of the project work perfectly with Cage, which is why I am insisting on running Cage. I'm playing with Sway right now and the project can work with Sway, which does seem to be the better option for remote connections. If there wasn't a remote maintenance need, I'd just wrap things up with Cage and call it a day.

I have a few other ideas but your help has been very insightful. I may annoy you with more questions later. For now, I'll check out the TCP socket and see what's up. Thank you again!