https://bugs.kde.org/show_bug.cgi?id=358750
Thomas Lübking changed:
What|Removed |Added
Latest Commit|
https://bugs.kde.org/show_bug.cgi?id=358750
Thomas Lübking changed:
What|Removed |Added
Flags||ReviewRequest+
---
https://bugs.kde.org/show_bug.cgi?id=358750
--- Comment #25 from Martin Gräßlin ---
The problem should only be in the EglOnXBackend, so a
qputenv("EGL_PLATFORM", "x11");
could be added, if it helps.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=358750
--- Comment #26 from Thomas Lübking ---
(In reply to Martin Gräßlin from comment #25)
> The problem should only be in the EglOnXBackend, so a
> qputenv("EGL_PLATFORM", "x11");
>
> could be added, if it helps.
+1
We might
https://bugs.kde.org/show_bug.cgi?id=358750
--- Comment #27 from Niels Ole Salscheider ---
Yes, this would be sufficient. For mesa at least, since it queries the
environment variable in eglGetDisplay.
We already use EGL_PLATFORM for the hwcomposer backend and the
https://bugs.kde.org/show_bug.cgi?id=358750
--- Comment #22 from Niels Ole Salscheider ---
Or even better, use eglGetPlatformDisplayEXT to get a display for the right
platform (if available).
--
You are receiving this mail because:
You are watching all bug
https://bugs.kde.org/show_bug.cgi?id=358750
--- Comment #20 from Niels Ole Salscheider ---
No, the current code tries all EGL drivers (which is only drm), but it only
tries one platform for each driver. This platform is either what is set by the
EGL_PLATFORM env
https://bugs.kde.org/show_bug.cgi?id=358750
--- Comment #21 from Niels Ole Salscheider ---
Maybe KWin should set EGL_PLATFORM to x11 or wayland, depending on where it
runs. This is at least what other compositors do.
--
You are receiving this mail because:
You
https://bugs.kde.org/show_bug.cgi?id=358750
--- Comment #23 from Thomas Lübking ---
The relevant code (initEGL()) is in platform agnostic in libkwineffects - we'd
either have to transfer it into the platform implementations to make us of
eglGetPlatformDisplayEXT (or
https://bugs.kde.org/show_bug.cgi?id=358750
--- Comment #24 from Niels Ole Salscheider ---
(In reply to Thomas Lübking from comment #23)
> The relevant code (initEGL()) is in platform agnostic in libkwineffects -
> we'd either have to transfer it into the
https://bugs.kde.org/show_bug.cgi?id=358750
--- Comment #3 from Thomas Lübking ---
>From the mesa troubleshooting guide:
If see this error message: radeon: Failed to get PCI ID, error number -13, make
sure you have permissions to access the device (usually
https://bugs.kde.org/show_bug.cgi?id=358750
--- Comment #11 from Niels Ole Salscheider ---
Thank you for your patience. I have sent a patch to mesa-dev that fixes the
crash.
I still see "radeon: Failed to get PCI ID, error number -13" (both with KWin
and eglinfo)
https://bugs.kde.org/show_bug.cgi?id=358750
Thomas Lübking changed:
What|Removed |Added
Component|compositing |egl
--
You are
https://bugs.kde.org/show_bug.cgi?id=358750
--- Comment #5 from Niels Ole Salscheider ---
(In reply to Thomas Lübking from comment #3)
> From the mesa troubleshooting guide:
>
> If see this error message: radeon: Failed to get PCI ID, error number -13,
> make
https://bugs.kde.org/show_bug.cgi?id=358750
--- Comment #4 from Niels Ole Salscheider ---
Created attachment 96907
--> https://bugs.kde.org/attachment.cgi?id=96907=edit
Backtrace
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=358750
--- Comment #10 from Niels Ole Salscheider ---
It segfaults in the same function. So it really seems to be a driver issue.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=358750
--- Comment #13 from Niels Ole Salscheider ---
It seems so, this is the output I get:
radeon: Failed to get PCI ID, error number -13
EGL API version: 1.4
EGL vendor string: Mesa Project
EGL version string: 1.4 (DRI2)
https://bugs.kde.org/show_bug.cgi?id=358750
--- Comment #17 from Thomas Lübking ---
This call happens very early, in particular before creating the context since
we want to know whether there's support for the buffer_age extention to flag
the preservation bit - the
https://bugs.kde.org/show_bug.cgi?id=358750
--- Comment #19 from Thomas Lübking ---
The bug is that you end up in that fuction at all - should be
dri2_initialize_surfaceless(), but I can't say why atm. resp. this one should
fail and then the next be tried (until the
https://bugs.kde.org/show_bug.cgi?id=358750
Niels Ole Salscheider changed:
What|Removed |Added
CC|
https://bugs.kde.org/show_bug.cgi?id=358750
--- Comment #2 from Thomas Lübking ---
could you please paste the backtrace?
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=358750
--- Comment #7 from Thomas Lübking ---
Does it also happen with the latest stable MESA release?
(This very much looks like a driver bug, notably since the egl call should
maybe cause an error, but certainly not segfault)
The
https://bugs.kde.org/show_bug.cgi?id=358750
Niels Ole Salscheider changed:
What|Removed |Added
Attachment #96907|0 |1
https://bugs.kde.org/show_bug.cgi?id=358750
--- Comment #8 from Niels Ole Salscheider ---
I have only tried with mesa master. I can also compile the latest stable
version but this will take a bit since I will have to downgrade llvm, clang and
maybe some other
https://bugs.kde.org/show_bug.cgi?id=358750
Thomas Lübking changed:
What|Removed |Added
Resolution|--- |UPSTREAM
https://bugs.kde.org/show_bug.cgi?id=358750
--- Comment #15 from Niels Ole Salscheider ---
The output seems to be missing?
I wonder if the problem has something to do with rendernodes.
The platform code opens /dev/dri/card0 when no display is supplied but the
https://bugs.kde.org/show_bug.cgi?id=358750
--- Comment #18 from Niels Ole Salscheider ---
> The code in question looks like it unconditionally tries /dev/dri/renderD0,
> that one's likely occupied and in return it resorts to card0
>
> What *should* (probably,
27 matches
Mail list logo