Summary: | kwin_wayland asserts when overlapping screens | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Nicolas Fella <nicolas.fella> |
Component: | wayland-generic | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | aleixpol, aspotashev, nate, subdiff |
Priority: | NOR | ||
Version: | git master | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | faulty configuration |
Description
Nicolas Fella
2020-06-02 13:38:29 UTC
scaling *both* to 2x works fine Created attachment 128999 [details]
faulty configuration
The way the screens overlap seems to be important, so here's a screenshot I think what happens is this: The first (lower) screen is processed fine. When the second screen (upper) screen is processed the geometry of the first is subtracted. This results in two region parts. An upper one, above the second screen, and a very narrow one (1 x something pixels) to the left or right of the first screen, because by pure chance the x position of the screen was 1 instead of 0. (I can give you a mediocre drawing if that helps). Both these rects are then checked for being a top screen, which is true for both, although the narrow one arguably shouldn't be considered top. Then further down in the calculation something seems to go wrong because of the very narrow rect *** Bug 424425 has been marked as a duplicate of this bug. *** Hey, we also hit this bug in KWinFT: https://gitlab.com/kwinft/kwinft/-/issues/67#note_397290004 I have a MR for it here: https://gitlab.com/kwinft/kwinft/-/merge_requests/36 Should apply cleanly to KWin too. A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/193 Shoulda been fixed with https://invent.kde.org/plasma/kwin/-/merge_requests/193. For some reason this didn't get closed. |