kwin and NetBSD

Wed Feb 5 19:56:50 GMT 2020

On 05.02.2020 20:00, Martin Flöser wrote:
> Am 2020-02-05 17:20, schrieb Kamil Rytarowski:
>> Hello,
> Hi,
> 
>>
>> commit bbf00fdd98085a275f474fbfdffe5e140948a64b
>> Author: Martin Flöser <mgraesslin at kde.org>
>> Date:   Tue Jan 23 17:28:18 2018 +0100
>>
>>     Require libinput and udev
>>
>>     Summary:
>>     The main reason for not having it as a mandatory dependency was
>> that BSD
>>     doesn't support it. But as I learned recently it is available on
>> our CI
>>     system. So BSDs have support now.
>>
>>     Even more it showed that the code doesn't compile if the
>> dependency is
>>     missing. And there's one thing I hate: broken build configuration
>>     options.
>>
>>     So let's make UDEV and libinput a required dependency and get rid
>> of the
>>     problems.
>>
>>     Test Plan: Compiles
>>
>>     Reviewers: #kwin, #plasma
>>
>>     Subscribers: plasma-devel, kwin
>>
>>     Tags: #plasma
>>
>>     Differential Revision: https://phabricator.kde.org/D10057
>>
>>
>> Unfortunately this commit is not that correct. libinput is emulated only
>> by FreeBSD. No other BSD emulated kernel VFS (these systemd-oriented
>> libraries such as libmount, libudev etc are rather considered as poorly
>> designed not just in BSD circles..).
>>
>> There is no plan to emulate libinput in NetBSD as we have our own APIs
>> for this (wscons).
>>
>> We already implemented a support for wscons in swc:
>>
>> https://github.com/niacat/swc/blob/master/libswc/seat-ws.c
>>
>> Could you please revert this commit and make libudev nad libinput
>> optional again?
>>
>> We intend to finish porting KDE/wayland to NetBSD.
> 
> 
> I'm currently not an active developer and thus unable to revert or do
> any decision on it. Due to that I cc'ed the KWin mailing list for
> further discussion.
> 
> Please note that a revert is not possible and not sensible. As the
> commit message explains: the build flag was broken and nobody noticed.
> This would have to be implemented as a new feature and maintained(!).
> 

We have got an active maintainer of the KDE stack in pkgsrc, but I don't
know if there are cycles to interact with upstream and show signs of
life from our side. Almost all of the qt5/kde5 software works as is on
NetBSD. Until

> I must admit that I do not think that KWin is the place to hold code and
> ifdefs for such distro specific requests.

I agree with you.

In the Xorg case we centralize the whole input handling in one place,
not exporting our internals to 3rd party VMs or DEs.

However... as I discussed with the wayland developers. The Linux-only
APis and libraries are considered as 'standardized' and unchangeable.
They do not allow any modifications to the design neither APIs as they
are worried about users fragmented among multiple versions of libraries.

We have got 3 choices:

 - Reimplement chunks of linux kernel code in the NetBSD kernel and use
on top of that Linux-only libraries (libudev, libinput, libmount, ...).
 - Develop imperfect shims "emulating bugs" of Linux trying to write a
backend on top of non-Linux internals.
 - Patch every wayland compositor for NetBSD backend.

FreeBSD picked the first approach of reimplementing Linux. This has some
cons and pros... in practice there are periods of totally broken
software stack as they catch up the rabbit in imitation of other OS.

In the NetBSD case we so far prefer to switch to our native APIs. This
approach was recommended by the wayland community (but everybody hates it).

Personally I consider this wayland design that is compatible with only a
single OS as well difficult.

We are forced now to patch every compositor and we are required to do it
in kwin (same as in wlroots and others). This is bitter, but we need to
chew it now.

There was a recently a FOSDEM presentation on this topic:

https://fosdem.org/2020/schedule/event/netbsd_audio/

> A clear sign for this is that
> you raise the issue 2 years after the change was implemented and before
> it was broken for an unknown timespan.

So far we were happy with a hybrid kde4/kde5 stack. As qt4/kde4
(formally EOL few years ago, in practice still not everything non-dead
moved on to qt5) and Xorg (recently) are effectively getting purged from
distros, it's time to move on.

> I know and understand that BSDs
> are not up to the development speed of the Linux stack. But it's
> unreasonable to expect upstream to take care of it years later. My
> personal suggestion is to carry this as an out-of-tree patch in NetBSD.

I object here. As an experienced maintainer (in various places, not just
NetBSD), every single small patch is a constant cost for downstream
developers and users.

It is better to rather look for adding a NetBSD dedicated buildbot in
the project. We try to increase our testing coverage in critical
projects and we managed to deploy our patches into tricky upstreams (not
naming them here).

> For me as former KWin maintainer it was always a mantra that we do not
> have distro specific code and only features which Debian supports
> (Debian as the linux distribution having support for most packages,
> being rather slow and also supporting multiple competing integration
> solutions).
> 

BSDs are not just distros of Linux comparable to Debian, they are
distinct independent Operating Systems. It is unreasonable to expect
e.g. QNX developers to run unmodified on the Linux stack (if someone
wants Linux, it's easier to pick the original copy).

We already maintain our patches in various non-trivial software stack
(including qt5, firefox, LLVM, GCC etc).

> But of course this is up to the current development team. If a patch
> exists it can be reviewed for its merits.
> 

Actually, I reached you to get a hint how would you like to support it?

kwin looks pretty much looks like an elaborated wrapper around
libudev+libinput so a suggestions how would you like to see it
implemented are welcome.

wlroots managed to support two backends libinput and XCB:

https://github.com/swaywm/wlroots/blob/master/backend/x11/input_device.c

> Best Regards
> Martin Floeser
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kwin/attachments/20200205/2d6bd637/attachment.sig>