https://bugs.kde.org/show_bug.cgi?id=408594
--- Comment #5 from Fredrik Höglund ---
There is a way to check that at runtime by calling
glGetFramebufferAttachmentParameteriv() with pname set to
GL_FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING.
--
You are receiving this mail because:
You are watching
https://bugs.kde.org/show_bug.cgi?id=408594
--- Comment #12 from Fredrik Höglund ---
(In reply to Michail Vourlakos from comment #9)
> (In reply to Fredrik Höglund from comment #5)
> > There is a way to check that at runtime by calling
> > glGetFramebufferAttachmentParameteriv()
https://bugs.kde.org/show_bug.cgi?id=408594
--- Comment #21 from Fredrik Höglund ---
Git commit 3d384f3c90205f35fea445446903661c7c046514 by Fredrik Höglund.
Committed on 29/06/2019 at 11:09.
Pushed by fredrik into branch 'Plasma/5.16'.
glx: Prefer an sRGB capable fbconfig
Pref
https://bugs.kde.org/show_bug.cgi?id=408594
--- Comment #26 from Fredrik Höglund ---
(In reply to Roman Gilg from comment #22)
> The patch lead to a regression in cirrus (default video device of openQA)
> and possibly needs to be reverted.
Reverting this patch means having to disable
https://bugs.kde.org/show_bug.cgi?id=408594
Fredrik Höglund changed:
What|Removed |Added
Latest Commit||https://commits.kde.org/kwi
https://bugs.kde.org/show_bug.cgi?id=408594
--- Comment #30 from Fredrik Höglund ---
(In reply to Fabian Vogt from comment #27)
> > So I'm going to solve this by blacklisting sRGB configs on LLVMPipe instead.
>
> That sounds like a bit too much, everything except cirrus wi
https://bugs.kde.org/show_bug.cgi?id=408594
--- Comment #32 from Fredrik Höglund ---
(In reply to Fabian Vogt from comment #31)
> (In reply to Fredrik Höglund from comment #30)
> > (In reply to Fabian Vogt from comment #27)
> > > > So I'm going to solve this by bl
https://bugs.kde.org/show_bug.cgi?id=390698
Fredrik Höglund changed:
What|Removed |Added
CC||fred...@kde.org
--- Comment #12 from Fredrik
https://bugs.kde.org/show_bug.cgi?id=390698
--- Comment #14 from Fredrik Höglund ---
MSAA doesn't blur anything. It works by computing a pixel coverage value in the
range [0..1] for each rasterized fragment, and multiplying that value with the
alpha value prior to blending.
You may be conf
https://bugs.kde.org/show_bug.cgi?id=393241
--- Comment #2 from Fredrik Höglund ---
Please provide the output from glxinfo as well.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=390457
Fredrik Höglund changed:
What|Removed |Added
Latest Commit||https://commits.kde.org/pla
https://bugs.kde.org/show_bug.cgi?id=390698
--- Comment #22 from Fredrik Höglund ---
(In reply to Vlad Zagorodniy from comment #16)
> Fredrik, what do you mean by "a complex transformation"?
Any transformation that does not just translate and/or scale the window.
Although sca
https://bugs.kde.org/show_bug.cgi?id=344326
Fredrik Höglund changed:
What|Removed |Added
CC|fred...@kde.org |
--
You are receiving this mail because
https://bugs.kde.org/show_bug.cgi?id=344326
Fredrik Höglund changed:
What|Removed |Added
URL|https://git.reviewboard.kde |https://phabricator.kde.org
https://bugs.kde.org/show_bug.cgi?id=328122
--- Comment #20 from Fredrik Höglund ---
(In reply to Thomas Lübking from comment #18)
> KWin has never fixed and actually cannot fix this (we'd need to track the VT
> and that requires root permissions), the behavior is completely in the
&
15 matches
Mail list logo
