| Summary: | Wayland compositors won't start after a recent update, downgrading lib64drm fixes the issue | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Keith Bowes <zooplah> |
| Component: | RPM Packages | Assignee: | Mageia Bug Squad <bugsquad> |
| Status: | RESOLVED OLD | QA Contact: | |
| Severity: | minor | ||
| Priority: | Normal | CC: | kernel, marja11, thierry.vignaud, tmb |
| Version: | 6 | Keywords: | UPSTREAM |
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | CVE: | ||
| Status comment: | |||
| Attachments: |
Weston error log
Sway 0.15.2 error log Sway 1.0 alpha 5 error log |
||
|
Description
Keith Bowes
2018-08-21 04:34:44 CEST
Created attachment 10323 [details]
Weston error log
Created attachment 10324 [details]
Sway 0.15.2 error log
Created attachment 10325 [details]
Sway 1.0 alpha 5 error log
I don't know which SRPM to assign this bug report to, afaics neither wayland nor weston nor libdrm nor mesa were recently updated in Mageia 6. I cannot find sway in our repositories, am I overlooking it, or don't we have it? Summary:
Wayland compositors won't start after a recent update =>
Wayland compositors won't start after a recent update, downgrading lib64drm fixes the issue (In reply to Keith Bowes from comment #0) > After a recent update, Weston, Sway, and other compositors won't start. > https://github.com/swaywm/sway/issues/2301 mentions downgrading Mesa solving > the problem, but that didn't work for me. However, it gave me a good start > to discovering the problem: lib64drm (I downgraded it and everything started > working again). That also explains why SDL2 games also refused to start > against my self-compiled SDL 2.0.8 (with kmsdrm enabled) when not being run > in a display server. > _way_ too little info... What did you update ? when? What libdrm was you running when it worked ? and when it failed ? And exactly _what_ did you downgrade ? And What hw ? Sorry for the delay in replying. I just realized that my email notifications were disabled. Anyway, I discovered the cause of the problem. I've had `export LIBGL_ALWAYS_SOFTWARE=1` in my ~/.bashrc for years to reduce Pipelight crashes, but after I removed it, Wayland compositors and other OpenGL programs started working on DRM again, and furthermore, SDL games are much faster now. I suppose I'll report this upstream, as it seems that something is wrong with their code when software rendering is enabled. Since this is a problem with the software rendering (where hardware rendering works fine), I'd assume that it has nothing to do with my hardware, but I'd be willing to give any information I can. I know my GPU is Intel Sandy Bridge; I found that out when Mageia 7 was released with Vulkan libraries and tools and was wanting to try it out (it turns out that Sandy Bridge is Intel's final GPU without Vulkan support). Is there any other hardware that would have any bearing on this bug? Severity:
normal =>
minor (In reply to Keith Bowes from comment #6) <snip> > Anyway, I discovered the cause of the problem. I've had `export > LIBGL_ALWAYS_SOFTWARE=1` in my ~/.bashrc for years to reduce Pipelight > crashes, but after I removed it, Wayland compositors and other OpenGL > programs started working on DRM again, and furthermore, SDL games are much > faster now. I suppose I'll report this upstream, as it seems that something > is wrong with their code when software rendering is enabled. > <snip> Thanks for the feedback. Next time when you report an issue here and then conclude it is an upstream issue, please give a link to your upstream ticket or bug report. Thanks in advance :-) I'm closing this report as OLD, because we stopped supporting Mageia 6 long ago and also because it isn't an issue with our packaging. Status:
NEW =>
RESOLVED |