What's next? What's the progress so far? Considering the words of Christian Schaller, "The reality is that X.org is basically maintained by us and thus once we stop paying attention to it there is unlikely to be any major new releases coming out and there might even be some bitrot setting in over time. We will keep an eye on it as we will want to ensure X.org stays supportable until the end of the RHEL8 lifecycle at a minimum, but let this be a friendly notice for everyone who rely the work we do maintaining the Linux graphics stack, get onto Wayland, that is where the future is." https://blogs.gnome.org/uraeus/2019/06/24/on-the-road-to-fedora-workstation-31/ I would like to know what's the roadmap for the *BSDs and NetBSD in particular?

I can't say that I know much about plans for Wayland in *BSDs (or much about it in general) but I have read that the X window system in general is very complicated technically and probably hard to maintain in the long run. So a replacement is probably the way to go. I imagine it will be hard to introduce and at the same time keep compability with older, less maintained software.

I'm not really expecting an answer here to be honest. Just got the feeling its something that is not being discuss so widely, probably because people got tired of it. After all, wayland has been "coming soon" for too long :)

Last I heard FreeBSD is working on it https://www.phoronix.com/scan.php?page=news_item&px=Wayland-BSD-Improving-2019

And for NetBSD there's WIP package http://pkgsrc.se/wip/wayland

@"Jay"#p560 yes, had seen it. My thoughts are more about implementation... There's an old thread on the mailing lists, but it ended up in some sort of philosophic discussion.

@"pin"#p561 check this https://www.reddit.com/r/BSD/comments/csecv2/first_wayland_application_run_on_netbsd/

@"Jay"#p570 Thx Jay! She has commited the initial packages to pkgsrc now. See, http://pkgsrc.se/devel/wayland and http://pkgsrc.se/devel/wayland-protocols ;)

...yet another step, http://pkgsrc.se/x11/modular-xorg-xwayland

The supposed motivation behind Wayland is a simpler implementation, yes. It's much more assuming of a Linuxy system, too, being developed mostly by Red Hat people. One of the main active Xorg developers being a member of Oracle's Solaris team should show where things are going, really. Whether it actively achieves simplicity in practice is another question. Over time, more and more things have been moved out of Xorg, e.g. font handling (fontconfig, freetype), rendering (Mesa, cairo), display management (libdrm), UI toolkits (GTK, Qt, SDL), rendering many parts of the X stack redundant. Wayland mainly only deals with the transfer of input, window management, and graphics buffers between the server (compositor/window manager) and clients (windows). Various NetBSD developers are interested in Wayland, but I've been doing most of the direct work so far (that isn't prerequisite yaks). I have a semi-usable set of GTK3 applications working and stable on intel via Wayland. They work but aren't stable on radeon. I hope to have most of the client-side wayland bits fully integrated and enabled by default (alongside X) in pkgsrc in time for 2019Q3. The truth is that all that's missing for functioning Wayland-ish compositing on NetBSD is polish. All the bits are there and just need more work before it's usable as an X replacement. What doesn't work? * Compositors that target Linux (I'm working on our own stuff, though). * Keyboard layouts (it currently defaults to US) - requires translation of wscons keycodes * HiDPI support - probably requires some missing compositor bits. * Multi monitor support - maybe requires some changes to our DRM stack * Fast rendering - optimizations optimizations optimizations... * Non-DRM rendering (dumb framebuffers) - needed for some of the legacy and unaccelerated machines NetBSD supports. * Cursor themes - I suspect a bug. * Qt5 - Haven't tried getting it to work yet, because it's quite a beast and I'm not very familiar with C++. My intention is to push it forward to a usable state. Whether I manage is another question. X will be around for another decade or so, at least. It's worth noting that NetBSD also contains another, ancienter X server, specifically to support 68K machines!

@"nia"#p574 Wow... Wonderful that you took the time to write here. Thx!

X.org/Wayland - The future?!

nia Just taking it slowly to avoid significant burnout.

Oh no, take it easy.

nia debugging the protocol code is not fun...

I bet its a PITA.
Thx for doing this!
Let's see if I manage to build cargo 😱

EDIT: cargo is actually integrated in the rust package, so no need to build it 🙂
Way-cooler is under heavy development. It now depends on wlroots and will eventually become a sort of awesome for wayland, maybe...

Tried to build leftwm as its also written in rust just to see if cargo-builds worked fine, but apparently it requires a newer version of lang/rust as I'm getting a lot of deprecated warnings. I'll try again when way-cooler hits stable, maybe...

nia
Saw your recent work and decided its time to give it a try 🙂
Unfortunately, I'm getting this,

===> Building for swc-0.0.0.20191211
  CCLD    launch/swc-launch
  CC      libswc/dmabuf.o
  CC      libswc/drm.o
  CCLD    cursor/convert_font
  CC      libswc/xdg_shell.o
  CC      protocol/swc-protocol.o
  CC      protocol/wayland-drm-protocol.o
libswc/dmabuf.c: In function 'bind_dmabuf':
libswc/dmabuf.c:182:22: error: 'DRM_FORMAT_MOD_INVALID' undeclared (first use in this function)
  uint64_t modifier = DRM_FORMAT_MOD_INVALID;
                      ^
libswc/dmabuf.c:182:22: note: each undeclared identifier is reported only once for each function it appears in
gmake: *** [common.mk:15: libswc/dmabuf.o] Error 1
gmake: *** Waiting for unfinished jobs....
libswc/drm.c:227:2: error: unknown field 'page_flip_handler2' specified in initializer
  .page_flip_handler2 = handle_page_flip,
  ^
libswc/drm.c:227:24: warning: initialization from incompatible pointer type [-Wincompatible-pointer-types]
  .page_flip_handler2 = handle_page_flip,
                        ^
libswc/drm.c:227:24: note: (near initialization for 'event_context.page_flip_handler')
gmake: *** [common.mk:15: libswc/drm.o] Error 1
*** Error code 2

Stop.
make[1]: stopped in /usr/pkgsrc/wm/swc
*** Error code 1

Stop.
make: stopped in /usr/pkgsrc/wm/swc

when trying to build swc
Any ideas to fix it?!

EDIT: NetBSD-8.1 amd64

nia

I haven't tested anything on 8 because none of my machines have accelerated graphics on 8. Probably need PREFER_PKGSRC+=libdrm but even then I don't know if that will work.

Will try on 9 as soon as I have the time, thanks!

nia

Flipping some wayland switches in packages to default-on for NetBSD 9, and Linux now that freeze is over and I'm not traveling without a reliable internet connection.

nia Awesome.

Jay

Thanks nia
https://mail-index.netbsd.org/pkgsrc-users/2020/01/05/msg030124.html

@nia
In case you'd be interested, https://github.com/awesomeWM/awesome/issues/159#issuecomment-519215624

@nia
I've decided to take this for a spin and installed velox and qt5-qtwayland, the other needed packages were already installed.
I created ~/velox.conf and the script bellow to make it easier 🙂

#!/bin/sh
#
# ~/wayland-velox.sh
export QT_QPA_PLATFORM=wayland-egl
export QT_QPA_PLATFORMTHEME=qt5ct

export GDK_BACKEND=wayland
gsettings set org.gnome.desktop.interface gtk-theme 'Shades-of-gray-Harvest'
gsettings set org.gnome.desktop.interface icon-theme 'Orange-Aurora'
gsettings set org.gnome.desktop.interface font-name 'Liberation Sans 10'
gsettings set org.gnome.desktop.interface monospace-font-name 'Liberation Mono 11'

export MOZ_ENABLE_WAYLAND=1

mkdir /tmp/pin-runtime
export XDG_RUNTIME_DIR=/tmp/pin-runtime && swc-launch velox

Then, just to be sure, I've changed wscons to us and rebooted.

$ ./wayland-velox.sh launches the WM just fine and I can switch between workspaces.
Although, launching firefox68, featherpad or qterminal all produce core-dumps.
I was able to launch galculator and gnumeric from dmenu-wld but, then the display server crashed and I was back at console with the message BROKEN PIPE.

Has the wayland-session been stable for you?

@nia Thank you! 😄
Amazing stuff 🤗

nia

OK, so, I lost my password for this forum 🙂

Mozilla applications are known to be broken. You'll notice Firefox instantly crashes during my FOSDEM talk. It needs work(tm). I've been using vimb/luakit/midori/netsurf happily, though.

Qt5 applications being broken is a regression. I've just fixed it in pkgsrc. Also here: https://github.com/michaelforney/swc/pull/57

After this I can run qterminal but it doesn't like being closed much. I should fix this. I'd like to use it because it still supports bitmap fonts but sakura doesn't any more.

I consider stability to be an uh, TODO item.

nia I'll try again soon, thx!

nia

Another PKGREVISION bump for swc and qterminal is now happy being closed. I did notice that Qt is picky about the permissions of XDG_RUNTIME_DIR, it wants it to be chmod 7700.

nia I had to set it to 0700 under X11 to keep it happy 😉

Mounsier

Well, people from Enlightenment project think so

The project is currently transitioning from X11 to Wayland. We are fully committed to moving to Wayland eventually, as its the future of graphical display layers on Linux.

We still primarily support Linux for Enlightenment, but there is some effort (based on help and support from users and some developers) to support BSD too.
https://www.enlightenment.org/

By the way, pin and nia, are you both girls using BSD systems, if yes then i am in love with you

Mounsier 🤔 what does gender have to do with it? We are both human!
But, ...if you need to know, I'm not a girl.

We still primarily support Linux for Enlightenment, but there is some effort (based on help and support from users and some developers) to support BSD too.

Right, duh!? Why does it need --disable-systemd config flag? 🤨
Is providing this option their way of showing love to non-systemd OSs?

@nia 🤣

Ok, I still had to default to us in wscons.conf but, to be honest I didn't look into it.
grim, the screenshot tool I've packaged in wip, is not working and right clicking qterminal to adjust settings make it crash but, its sooooo cool 🕶️ to be running wayland natively on NetBSD.
Thx!

zoomzoom

nia Non-DRM rendering (dumb framebuffers) - needed for some of the legacy and unaccelerated machines NetBSD supports.

What would need to be done to fix this?
One of my concerns with Wayland (although probably not shared by the majority) is if it's going to end up excluding older graphics cards.

Assassink

https://github.com/openbsd/ports/blob/master/wayland/TODO-Wayland.md
They have got wayland port which is minimal as of now

Assassink yes, and there's basic support on NetBSD also.

FreeBSD is a different story.

« Previous Page Next Page »