Weston stuff: fractional HiDPI, FreeBSD, Rust

[Daniel Stone]

Hi Greg,

On 14 December 2017 at 08:21, Pekka Paalanen <ppaalanen at gmail.com> wrote:
> On Thu, 14 Dec 2017 03:05:59 +0300
> Greg V <greg at 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