On Sat, Jun 29, 2019 at 12:29:40PM -0700, Chris Cappuccio wrote: > Leonid Bobrov [mazoc...@disroot.org] wrote: > > On Fri, Jun 28, 2019 at 01:56:43PM -0400, Christopher Turkel wrote: > > > > First, I'd like to blame Xenocara for this pain porting Wayland to > > OpenBSD (because building Mesa from ports would be an opportunity), > > right now to build Mesa with Wayland support we need to import > > Wayland in Xenocara and all its dependencies (including libxml) in base. > > > > Why not simply have a Wayland-appropriate Mesa option in the ports tree? >
That's appropriate only if we build a module which then gets dlopen()'ed by Mesa in Xenocara. > > Fifth, almost nobody in OpenBSD cares about Wayland and personally I > > don't see an opportunity in protocol which requires XML. > > > > Sounds like something that belongs in the ports tree > Not really, we accepted worse crap than XML: DRM code from Linux, especially AMDGPU; X.org; LLVM. So libxml in base won't be that harmful to us, so maybe even radically removing X.org and having a sane Wayland compositor in base will only benefit us in terms of security by default? Still too bad there are no other alternatives, it's just XML is a bloat, so basically we replace elephant X with horse Wayland. > > The epoll() problem is solved at FreeBSD and NetBSD by using epoll-shim, > > it's epoll() emulation via kqueue(), DragonFly BSD still prefers not > > using epoll-shim and writting kqueue() code instead, but Peter Must > > (the current maintainer of Wayland in DragonFly) is going to use > > epoll-shim for libinput while still maintaining kqueue() code in > > reference Wayland library. > > So basically, the problems are already mostly solved. That makes for lots > of options for someone who wants to port Wayland to OpenBSD. > The Wayland library itself is already ported (check OpenBSD WIP repo, I opened PR there but it updates to a previous Wayland release, I didn't bother to port a new release yet because I am worried about input handling in wscons which doesn't have documentation on that), but it's useless without actual compositors. While wscons is not documented you can't hope that someone will port Wayland compositors unless you are going to import evdev just like FreeBSD and DragonFly BSD did it because nobody is willing to work with undocumented syscons. Surprisingly wscons suits Wayland even better than evdev because it's possible to do keylogging with evdev while it's impossible to do keylogging with wscons if you open /dev/wskbd* and /dev/wsmouse* with O_NONBLOCK flag, that means only compositor will have direct access to input no matter what user runs it.
