I doubt wayland will work for this purpose, but it doesn’t hurt to check, first place to check when configure is failing is the config.log file, search for wayland in there.
In normal Linuxes in theory if you configure --with-wayland and later unset DISPLAY with DISPLAY= wine notepad.exe wayland mode should work instead of X11.
Maybe i am too optimistic but i would like to see what will happen in Haiku.
But currently it refuses to recognise --with-wayland (just like most other options like sdl2,X11 even when the equivalent software is ported to Haiku so it’s headers and .so can be installed.See
haikuports/x11-libs at master · haikuports/haikuports · GitHub and haikuports/dev-libs at c7466365e687e20c5a71a17e54957b5ece41638f · haikuports/haikuports · GitHub
I suspect that after configuring more problems will arise on compilation that will need patching but one issue at a time
Well, looking at the local log here there seems to be missing something still:
configure:15983: wayland-client cflags: -I/packages/wayland-1.21.0~git-3/.self/develop/headers -I/packages/libffi-3.4.6-1/.self/develop/headers
configure:15984: wayland-client libs: -L/packages/wayland-1.21.0~git-3/.self/develop/lib -lwayland-client
configure:15992: checking for wayland-client.h
configure:15992: gcc -m64 -c -g -O2 -I/packages/wayland-1.21.0~git-3/.self/develop/headers -I/packages/libffi-3.4.6-1/.self/develop/headers conftest.c >&5
configure:15992: $? = 0
configure:15992: result: yes
configure:15995: checking for wl_display_connect in -lwayland-client
configure:16024: gcc -m64 -o conftest -g -O2 -I/packages/wayland-1.21.0~git-3/.self/develop/headers -I/packages/libffi-3.4.6-1/.self/develop/headers -lnetwork conftest.c -lwayland-client -L/packages/wayland-1.21.0~git-3/.self/develop/lib -lwayland-client >&5
configure:16024: $? = 0
configure:16036: result: yes
configure:16042: checking for wayland-scanner
configure:16065: found /bin/wayland-scanner
configure:16079: result: /bin/wayland-scanner
configure:16114: xkbcommon cflags: -I/packages/libxkbcommon-1.7.0-1/.self/develop/headers
configure:16115: xkbcommon libs: -L/packages/libxkbcommon-1.7.0-1/.self/develop/lib -lxkbcommon
configure:16123: checking for xkbcommon/xkbcommon.h
configure:16123: gcc -m64 -c -g -O2 -I/packages/libxkbcommon-1.7.0-1/.self/develop/headers conftest.c >&5
configure:16123: $? = 0
configure:16123: result: yes
configure:16130: checking for xkb_context_new in -lxkbcommon
configure:16159: gcc -m64 -o conftest -g -O2 -I/packages/libxkbcommon-1.7.0-1/.self/develop/headers -lnetwork conftest.c -lxkbcommon -L/packages/libxkbcommon-1.7.0-1/.self/develop/lib -lxkbcommon >&5
configure:16159: $? = 0
configure:16171: result: yes
configure:16201: xkbregistry cflags: -I/packages/libxkbcommon-1.7.0-1/.self/develop/headers -I/packages/libxml2-2.12.9-1/.self/develop/headers/libxml2 -I/packages/zlib-1.3.1-4/.self/develop/headers
configure:16202: xkbregistry libs: -L/packages/libxkbcommon-1.7.0-1/.self/develop/lib -lxkbregistry
configure:16210: checking for xkbcommon/xkbregistry.h
configure:16210: gcc -m64 -c -g -O2 -I/packages/libxkbcommon-1.7.0-1/.self/develop/headers -I/packages/libxml2-2.12.9-1/.self/develop/headers/libxml2 -I/packages/zlib-1.3.1-4/.self/develop/headers conftest.c >&5
configure:16210: $? = 0
configure:16210: result: yes
configure:16217: checking for rxkb_context_new in -lxkbregistry
configure:16246: gcc -m64 -o conftest -g -O2 -I/packages/libxkbcommon-1.7.0-1/.self/develop/headers -I/packages/libxml2-2.12.9-1/.self/develop/headers/libxml2 -I/packages/zlib-1.3.1-4/.self/develop/headers -lnetwork conftest.c -lxkbregistry -L/packages/libxkbcommon-1.7.0-1/.self/develop/lib -lxkbregistry >&5
configure:16246: $? = 0
configure:16258: result: yes
configure:16290: egl cflags: -DEGL_NO_X11 -I/packages/mesa-22.0.5-3/.self/develop/headers
configure:16291: egl libs: -L/packages/mesa-22.0.5-3/.self/develop/lib -lEGL
configure:16299: checking for EGL/egl.h
configure:16299: result: yes
configure:16302: checking for -lEGL
configure:16331: gcc -m64 -o conftest -g -O2 -DEGL_NO_X11 -I/packages/mesa-22.0.5-3/.self/develop/headers -lnetwork conftest.c -lEGL -L/packages/mesa-22.0.5-3/.self/develop/lib -lEGL >&5
configure:16331: $? = 0
configure:16357: result: libEGL.so.1
configure:16387: wayland-egl cflags: -I/packages/wayland-1.21.0~git-3/.self/develop/headers -I/packages/libffi-3.4.6-1/.self/develop/headers
configure:16388: wayland-egl libs: -L/packages/wayland-1.21.0~git-3/.self/develop/lib -lwayland-egl -lwayland-client
configure:16396: checking for wayland-egl.h
configure:16396: gcc -m64 -c -g -O2 -I/packages/wayland-1.21.0~git-3/.self/develop/headers -I/packages/libffi-3.4.6-1/.self/develop/headers conftest.c >&5
configure:16396: $? = 0
configure:16396: result: yes
configure:16399: checking for wl_egl_window_create in -lwayland-egl
configure:16428: gcc -m64 -o conftest -g -O2 -I/packages/wayland-1.21.0~git-3/.self/develop/headers -I/packages/libffi-3.4.6-1/.self/develop/headers -lnetwork conftest.c -lwayland-egl -L/packages/wayland-1.21.0~git-3/.self/develop/lib -lwayland-egl -lwayland-client >&5
configure:16428: $? = 0
configure:16440: result: yes
configure:16476: error: Wayland 64-bit development files not found, the Wayland driver won't be supported.
This is an error since --with-wayland was requested.
How so? it checks there for wayland_client/wayland_scanner/xkbcommon … (as seen in your screenshot)
I mean that it checks for the exact parameters you provide in the recipe and that it should not fail
I guess it’s related to the “notice_platform” that follows? Not sure.
Notice platform gets replaced with "64 bit"and the final message is “Wayland 64 bit development files not found”.
Among others i see a strange check named ac_cv_header_linux_input_h which is actually printed in #define HAVE_LINUX_INPUT_H 1…i will check the log about it…
on config.log
configure:7752: result: no
configure:7758: checking for linux/input.h
configure:7758: gcc -m64 -c -g -O2 conftest.c >&5
conftest.c:53:10: fatal error: linux/input.h: No such file or directory
53 | #include <linux/input.h>
compilation terminated.
Do you @Begasus have the same error on yours?
yeah, same error (and a few others related to “linux…”, but I don’t think those are showstoppers here.
EDIT: I guess you will see those even with wayland disabled. 
The line 16453 of configure checks or conditions for many things… The last one fails (the linux/input.h check) and prevents the --enable-wayland.
If it was missing the check would be ok on your system since you installed everything else and applied -L -I overrides.
In general the missing linux/something.h stuff breaks a lot of the available options.
As we aren’t linux, anything requiring linux/something.h will not work anyway.
Linux/input.h is used by wayland keyboard.c and pointer.c. So these will need some patching.
We already had Wine running with a native windowing backend without the Wayland stuff.
The code for it already exists,it only needs to be updated to the latest Wine version.
If Wine and Windows applications should become a first-class citizen on Haiku,not just “works somehow,but integrates bad and feels bad”,then that would be the way to go.
2 Likes
Hard agree with nipos.
Getting Wine to build on Haiku with Wayland and spending time making patches for it shouldn’t be the way to go, even if you end up with a binary at the end of it you won’t be able to use it because Wayland’s Haiku “port” lacks almost everything from standard Wayland. Same with X11.
In short, don’t make patches for Wayland, try and get the native backend from the old versions running instead, Wayland won’t work without some massive work behind it but the native backend might run fine with little effort.
4 Likes
I was hoping that newer versions of Wine would work with almost the same recipe but that was not the case (even without wayland).
I have ran both Wine 7.9 and Wine 10.6 with Winedebug=+all enabled.
(Fyi Wine 10.7 was released these days too.)
It’s not easy to spot why the latter does not load any driver.(even debug output is almost 100mb).
Furthermore it needs knowledge of both Wine codebase and winehaiku.drv for a proper display solution.
But since Wine relies on some Linux kernel features (e.g Linux/something.h headers) there will always be some broken parts elsewhere.
Wine is officially available for macOS and FreeBSD. Why would you need Linux kernel headers?
In general while running Wine configure, a lot of Linux headers are imported for various stuff.
Freebsd uses all of these
–disable-kerberos
–disable-tests
–without-capi
–without-coreaudio
–without-dbus
–without-gettext --without-gettextpo
–without-gphoto
–without-gssapi
–without-inotify
–without-krb5
–with-mingw CROSSCC=“clang”
–without-netapi
–without-opencl
–without-osmesa
–without-pcap
–without-pcsclite
–with-pthread
–without-pulse
–without-sane
–with-sdl
–without-udev
–without-unwind
–without-usb
(Most of them al seem not critical)
in order to produce a working Wine.Last but not least Freebsd has X11 development libs.
Haiku has to use winehaiku.drv and --without-x in order for someone to create a working Wine.
the strange thing is that the 10.6 non-working installation knows the correct drv name and tries to load it…
i find trace lines like this one “2921.522:0050:0054:trace:file:nt_to_unix_file_name_no_root L"windows\system32\winehaiku.drv” not found in “/boot/home/.wine/dosdevices/c:”
2921.522:0050:0054:warn:file:NtCreateFile L"\??\C:\windows\system32\winehaiku.drv" not found (c0000034)"
2 Likes
linux/input.h is needed to be copied from Linux to compile Wine with Wayland. This header contains key codes for Wayland.
Wine with Wayland can run on Haiku. winehaiku.drv need some effort to port to latest Wine version because Wine internal API changed a lot.
1 Like