Summary: | Update 7.4 -> 7.6.1 disables DRI | ||
---|---|---|---|
Product: | Mesa | Reporter: | Lauri Kasanen <cand> |
Component: | Drivers/DRI/r300 | Assignee: | Default DRI bug account <dri-devel> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | ||
Version: | 7.6 | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
dmesg
lspci -vvnn Xorg.0.log |
Description
Lauri Kasanen
2010-01-10 11:58:31 UTC
Created attachment 32564 [details]
lspci -vvnn
Created attachment 32565 [details]
Xorg.0.log
Forgot to mention the newer Mesa also brought an update to libdrm (2.4.11 with 7.4.4, 2.4.17 with 7.6.1). Apologies if this is a libdrm bug instead. How can I find that out? Found a strange symptom: if X has been run with a working combo, the new combo works as well. The new combo fails straight from a reboot. (In reply to comment #3) > Forgot to mention the newer Mesa also brought an update to libdrm (2.4.11 with > 7.4.4, 2.4.17 with 7.6.1). > Apologies if this is a libdrm bug instead. How can I find that out? E.g. by downgrading Mesa but keeping the new libdrm. It's certainly not really possible for Mesa to prevent the X server from enabling the DRI... > Found a strange symptom: if X has been run with a working combo, the new combo > works as well. The new combo fails straight from a reboot. Sounds like maybe it's a /dev/dri/card* ownership / permissions issue. These were traditionally determined by X but more recently udev may also play a role, depending on how libdrm is built. The git master of libdrm works. Something between 2.4.17 and master fixes this. Thanks for your time. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.