core: fix hyplock on proprietary nvidia drivers

[PointerDilemma]

Goal: Make it work with proprietary nvidia drivers

• Removed timerThr and pollThr in favour of polling directly in the event loop
• Never call wl_display_dispatch directly

TODO:

• Fix background:path=screenshot

[PointerDilemma]

Initially i though our problem was described by this comment: NVIDIA/egl-wayland#98 (comment)

So i made sure we always prepare_read to sync our reads,
but that does not seam to work.

Not blocking in poll immediately resolves all stutters. (for example adding POLLOUT to the pollfd of the wayland display). But this makes it a busy loop :(.

It seems like sometimes we are not getting a POLLIN wl event for a frameCallback. Weirdly enough this takes a few frames to become a problem.

[PointerDilemma]

I also tried using the presentation_time protocol instead of frame callbacks, but that has the exact same problems.

[PointerDilemma]

This is problematic because egl-wayland creates a background thread that also reads from the Wayland socket.

To me it seems like this is either a problem that we can't fix when we want to use poll for the purpose of waking on wayland events, or there is some weird interaction with some egl stuff that we do.

Maybe we can set the poll timeout to 0 for as long as we expect a frame callback to arrive.

[PointerDilemma]

Yeah actually something like that seems to work

bool expectingFrameCallback = std::find_if(m_vOutputs.begin(), m_vOutputs.end(),
                                           [](const auto& o) { return o->sessionLockSurface && o->sessionLockSurface->expectingFrameCallback(); }) != m_vOutputs.end();

int  ret = poll(pollfds, fdcount, (expectingFrameCallback) ? 0 : timeout);

[PointerDilemma]

Yeah i mean... stutters are gone and still idles properly.

[PointerDilemma]

@vaxerski anything against removing timerThr and pollThr?

[PointerDilemma]

Idk how to handle that though.
Maybe an extra pollFd for waking internally??

[PointerDilemma]

Also works smoothly on my old laptop with 3rd gen intel integrated graphics

[PointerDilemma]

this is a bad try to work around the problem. cpu is busy when are not idle.
gonna check again if i can find the reason why it blocks.
there are many other applications that poll on the display fd in their event loop and don't seem to have any problems

[PointerDilemma]

Ok so i found that doing wl_display_prepare_read -> poll -> wl_display_read fixes it.
There is probably some nvidia egl thread reading from the display when we call poll and for some reason that causes a deadlock.
Preparing before poll makes sure that does not happen.

To allow for that I moved all of the wayland event reading to the poll thread. Dispatch obviously still only in the event loop thread. Seems to work nicely.

[PointerDilemma]

Happy with it now. Gonna close this in favour of 2 seperate patches.