Graphics Team Meeting notes from 2018-10-17

[Warner Losh]

On Fri, Oct 19, 2018 at 11:55 AM Greg V <greg at unrelenting.technology> wrote:

>
>
> On Fri, Oct 19, 2018 at 7:14 AM, Warner Losh <imp at bsdimp.com> wrote:
> > The graphics team has started having regular conference calls to keep
> > things moving along and to expand the knowledge base of graphics and
> > graphics issues. To that end, I'll be taking notes during these
> > meetings
> > and publishing them here. This is an experiment, so please send me
> > feedback
> > on how useful you find this.
>
> Much better than the usual silence :)
>
> > We plan on abstracting this down into the quarterly reports as well.
> >
> > Warner
> >
> > 2018-10-17:
> >       Mesa 18.2 is out and there is a patch submitted to update the
> > port
> >       (pr 230298). It’s been lightly tested by submitter, but needs
> > more
> >       extensive testing since we’ve had issue in the past with
> > incomplete
> >       testing. It’s unclear that we have to have 18.2, and it
> > represents a big
> >       risk on the 12.0R timeline. Definitely want to do it post
> > 12.0R, however.
> >       -
>
> Maybe users should be able to choose between mesa-stable and mesa-dev?
>
> I'm not sure if there's a good way to do it in the current
> ports/packages system though.
>

I'm not sure doing something people don't think will work right before a
release is a winning strategy.


> I just 'pkg add -f' my own development mesa (
>
> https://github.com/myfreeweb/freebsd-ports-dank/blob/master/graphics/mesa-dev/Makefile
> ) to let it just overwrite the mesa-libs/mesa-dri packages, but that's
> obviously terrible.
>
> Arch Linux's pacman can have a package "provide" multiple packages,
> which allows it to cleanly replace them:
> https://aur.archlinux.org/packages/mesa-git/
> I haven't found a similar feature in pkg :(


If wishes were ponies...


> >    Wayland
> >    -
> >
> >       Was updated w/o approval from the graphics team. Not worth
> > fighting
> >       to revert, but now requires EVDEV in the kernel now).
> >       -
>
> libwayland does not require evdev. libwayland, by design, does not know
> what evdev even is. libwayland is just an IPC library.
> Only the actual compositors use evdev (through libinput in pretty much
> all known implementations).
>

The bottom line is that it's practically required, so while this is a good
design, I'm not sure there's a distinction in this difference.


> About the only thing in this update was moving libwayland-egl to the
> wayland package, and thus shipping it to everyone, which massively
> alleviated the pain inflicted on other ports by the lack of it.
> No more ugly "if Mesa was built with WAYLAND" conditionals in
> *everything*.
> Worse than ugly, these conditionals required anyone who wanted to use
> Wayland to *rebuild* said everything.
> FINALLY that's not an issue, and the only things Wayland users are
> required to rebuild are kernel and Mesa.
>

I think there's broad agreement this could be cleaned up, however it's a
big undertaking. The time is short for 12.0R, so while a cleanup like this
is desirable, it's not desirable until after 12.0 ships.


> >    input stack
> >    -
> >       There are reports of regression with things like ddb> prompt
> > that
> >       need to be investigated before people will be comfortable
> > turning EVDEV on
> >       by default in GENERIC.
> >       -
>
> A fix for the keyboard deadlock has been posted back in April:
> https://reviews.freebsd.org/D15070
>
> I've been running EVDEV on two machines since EVDEV was a thing
> (without the patch) and never encountered any deadlocks or any other
> bugs.
>
> Would be a great shame if 12.0 releases without EVDEV in GENERIC.
>

True.  I'm not sure the issue has an owner or champion. That's part of the
problem here...

Warner