10 ms·

Are we reading the same thing? Those issues show that it materialized years ago: >FreeBSD and NetBSD have epoll-shim which implements epoll through *BSD-specif

Are we reading the same thing? Those issues show that it materialized years ago: >FreeBSD and NetBSD have epoll-shim which implements epoll through *BSD-specific kqueue The shim works fine already, why fix what isn't broken? And it's not that those other systems lack Linux-specific interfaces, it's that the ones missing those APIs lack any interfaces for these things at all! There's no way to be portable here, there's nothing to port to! If they decide to implement this eventually, why not copy the Linux API that's already open source and we already know it works, instead of reinventing the wheel? Alternately, Wayland implementations could add (limited) support for userspace drivers but why bother with this when we already know it's an inferior solution that should eventually be replaced with a kernel API anyway? And BSDs have already implemented parts of those APIs separately so we know they don't actually have a problem with them!

wahern 4y ago
> The shim works fine already, why fix what isn't broken? If it works fine, why not import it into the project? > Alternately, Wayland implementations could add (limited) support for userspace drivers but why bother with this when we already know it's an inferior solution that should eventually be replaced with a kernel API anyway? FreeBSD and OpenBSD are slowly doing exactly that. But DRM, GEM, etc, aren't just any generic API, they're a constantly evolving blob of Linux-oriented calls and data structures. Though at the end of the day this is probably the most defensible aspect of it. And an important distinction here is that the drivers issue pertains to Weston, whereas the kqueue issue applies to libwayland, the ostensibly environment agnostic library which implements the Wayland protocol (libwayland and the Wayland protocol are basically one and the same as the protocol is basically an old-school RPC mechanism inextricable from the implementation as a practical matter). But none of this need be debated if we just dropped the pretense that Wayland or the Wayland community cared about anything other than Linux. Wayland is simpler than X less because it's better designed and more because it redefined the problem. Network transparency? Not Wayland's problem. Portable across OS and driver environments? Not Wayland's problem. Input device management? Not Wayland's prob^W^W^W....
- QUrprUd1nCeicw 4y ago
  >If it works fine, why not import it into the project? Why? The shim is generic, it's for porting any Linux programs. >And an important distinction here is that the drivers issue pertains to Weston It would also affect the other Wayland implementations, which would need to adopt the same driver system. Those drivers would have to duplicate a lot of code from DRM and Mesa, it's just not worth it to put all that code into another library and then make Weston use it. >But none of this need be debated if we just dropped the pretense that Wayland or the Wayland community cared about anything other than Linux. Again, what is there to port to? Those other systems are behind in supporting the APIs needed for modern hardware. There's no alternative to DRM, GEM, KMS, etc. >Wayland is simpler than X less because it's better designed and more because it redefined the problem. Network transparency? Not Wayland's problem. Portable across OS and driver environments? Not Wayland's problem. Input device management? Not Wayland's prob^W^W^W.... I think you know that X11 wasn't exactly good at any of that. I would think BSD users appreciate all of that because they all have different opinions on how all those things should be done.

wahern 4y ago

> The shim works fine already, why fix what isn't broken? If it works fine, why not import it into the project? > Alternately, Wayland implementations could add (limited) support for userspace drivers but why bother with this when we already know it's an inferior solution that should eventually be replaced with a kernel API anyway? FreeBSD and OpenBSD are slowly doing exactly that. But DRM, GEM, etc, aren't just any generic API, they're a constantly evolving blob of Linux-oriented calls and data structures. Though at the end of the day this is probably the most defensible aspect of it. And an important distinction here is that the drivers issue pertains to Weston, whereas the kqueue issue applies to libwayland, the ostensibly environment agnostic library which implements the Wayland protocol (libwayland and the Wayland protocol are basically one and the same as the protocol is basically an old-school RPC mechanism inextricable from the implementation as a practical matter). But none of this need be debated if we just dropped the pretense that Wayland or the Wayland community cared about anything other than Linux. Wayland is simpler than X less because it's better designed and more because it redefined the problem. Network transparency? Not Wayland's problem. Portable across OS and driver environments? Not Wayland's problem. Input device management? Not Wayland's prob^W^W^W....

QUrprUd1nCeicw 4y ago
>If it works fine, why not import it into the project? Why? The shim is generic, it's for porting any Linux programs. >And an important distinction here is that the drivers issue pertains to Weston It would also affect the other Wayland implementations, which would need to adopt the same driver system. Those drivers would have to duplicate a lot of code from DRM and Mesa, it's just not worth it to put all that code into another library and then make Weston use it. >But none of this need be debated if we just dropped the pretense that Wayland or the Wayland community cared about anything other than Linux. Again, what is there to port to? Those other systems are behind in supporting the APIs needed for modern hardware. There's no alternative to DRM, GEM, KMS, etc. >Wayland is simpler than X less because it's better designed and more because it redefined the problem. Network transparency? Not Wayland's problem. Portable across OS and driver environments? Not Wayland's problem. Input device management? Not Wayland's prob^W^W^W.... I think you know that X11 wasn't exactly good at any of that. I would think BSD users appreciate all of that because they all have different opinions on how all those things should be done.