Hi Greg, On 14 December 2017 at 08:21, Pekka Paalanen <ppaala...@gmail.com> wrote: > On Thu, 14 Dec 2017 03:05:59 +0300 > Greg V <greg@unrelenting.technology> wrote: >> - FreeBSD support: https://github.com/myfreeweb/weston/commit/5827840c8 >> 2b9d0a302d5c54c514ca6f4238e12de > > In theory I'd support this, but I'm sure we'll have some bikeshedding > on how to actually deal with the alternative code. I would also be > worried about testing, because most developers don't run any BSD and > changes would not be tested without a CI running something on a BSD. > And if testing would catch breakage on BSD, at least I wouldn't know > how to fix it.
Indeed, but that's not something we can do much about for a while. I do have another suggestion though: can you please change the platform checks (#ifdef __linux__ and #ifdef FreeBSD) to instead be feature checks? For example, CLOCK_MONOTONIC_RAW is behind a Linux ifdef and CLOCK_MONOTONIC_FAST is behind a FreeBSD ifdef. There's no reason either platform couldn't start providing the other's clocks. There's also the issue of musl, which likes to pretend that it's glibc whilst not actually providing all of glibc's features (nope, me neither). Anyway, just having these be feature checks based on the presence of certain definitions / header files / etc would be an improvement over platform checks, since the latter don't age too gracefully. I also suspect that we could be doing one more portable thing in various cases anyway, e.g. it seems we get PATH_MAX from <limits.h> on glibc if we at least have _USE_POSIX, which we get from _GNU_SOURCE. So just doing that should let us drop one patch from your 'portability fixes' set, and so on. That being said, I have at least pushed the $(SED) patch. >> - memfd/anonymous shm in os_create_anonymous_file: https://github.com/m >> yfreeweb/weston/commit/24bbf0d9265478c406a23d8f1642a37daf43425f > > Sounds nice. Yep, though having this split into two patches (one to use memfd where available, another to only ever use shm_open on FreeBSD because there is no tmpfs) would be nice. >> - the Rust libweston bindings themselves https://github.com/myfreeweb/w >> eston-rs — incomplete/WIP, but a simple example compositor works! (see >> weston-rs/examples folder) > > Is this something that would need to live with libweston or can it be a > separate project? I'm really excited about this, BTW! :) I'd love to do what I can to push this forward. >> - fractional DPI scaling! https://github.com/myfreeweb/weston/commit/d2 >> 16493ae33659a98b9a9cbe77d4068b9462eea8 (additional downscaling after >> integer scaling) > > I would guess users would welcome this feature, so sure, details to be > discussed. Mutter's just implemented the same, so making sure we more or less do the same would be great. Cheers, Daniel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
