Test environment: - HSW GT3e - Up to date Ubuntu 13.10 - Latest versions of libdrm and mesa built (from today's git master), with only i965 driver enabled Steps to reproduce: 1. Run glxgears with latest mesa Expected output: - i965 driver loaded & HW acceleration used Actual output: - Mesa complains that it doesn't find i915 nor swrast - glxgears runs really slowly Bisecting Mesa identified this commit as culprit: ---------------------------------- commit 7bd95ec437a5b1052fa17780a9d66677ec1fdc35 Author: Eric Anholt <eric@anholt.net> Date: Thu Jan 23 10:21:09 2014 -0800 dri2: Trust our own driver name lookup over the server's. This allows Mesa to choose to rename driver .sos (or split drivers), without needing a flag day with the corresponding 2D driver. v2: Undo the loader-only-for-dri3 change. ---------------------------------- If Mesa needs some new dependency or specific version of that to identify on which HW it's running, it should check for that in configure.
There are a couple of solutions for this [1] [2]. I would prefer the latter as I've never been a fan of black/white listing. Eric are you leaning towards either solution ? Can we get an ack or your thoughts if you are not keen on either one ? Thanks [1] http://lists.freedesktop.org/archives/mesa-dev/2014-January/052888.html [2] http://lists.freedesktop.org/archives/mesa-dev/2014-January/052981.html
The bisected commit git-7bd95ec also caused Chrome "webgl" can't be enabled(bug 75739).
I'm guessing the problem was just this: commit b959fd9674938e127a34d42d34b903e3a9ae7ad9 Author: Eric Anholt <eric@anholt.net> Date: Thu Jan 30 10:19:44 2014 -0800 dri: Require libudev-dev for building DRI on Linux.
Right, I used --disable-dri3, and libudev-dev was forced only for DRI3. Next problem with b959fd9674938e127a34d42d34b903e3a9ae7ad9 is that alhtough it checks for libudev-dev, it doesn't check that it's for right architecture. Everything builds fine, but programs can crash on same system due to assert in loader because there was libudev-dev for 64-bit, but there was no libudev for 32-bit (if you were building for 32-bit). That's easier to debug than Mesa using wrong driver/SW rendering, so verifying.
Hi, I am using the dri2 driver on a non-udev system, this commit http://cgit.freedesktop.org/mesa/mesa/commit/configure.ac?id=b959fd9674938e127a34d42d34b903e3a9ae7ad9 breaks compilation for me. This patch fixes the problem by moving the udev check to the dri3 module http://patchwork.ozlabs.org/patch/346792/ As a reply to http://lists.freedesktop.org/archives/mesa-dev/2014-January/052990.html "I'm still fairly astounded that a Linux user who cares about 3D graphics would not have udev." I am using xbmc on a uclibc-based buildroot-compiled linux system which does not ship udev, it uses busybox mdev instead because the distro is aimed at small systems (design choice by developers which I can not influence) but can also run on recent Intel SB/IB/HSW CPUs.
(In reply to comment #5) > Hi, > > I am using the dri2 driver on a non-udev system, this commit > http://cgit.freedesktop.org/mesa/mesa/commit/configure. > ac?id=b959fd9674938e127a34d42d34b903e3a9ae7ad9 > breaks compilation for me. > > This patch fixes the problem by moving the udev check to the dri3 module > http://patchwork.ozlabs.org/patch/346792/ > > As a reply to > http://lists.freedesktop.org/archives/mesa-dev/2014-January/052990.html > "I'm still fairly astounded that a Linux user who cares about 3D graphics > would not have udev." > > I am using xbmc on a uclibc-based buildroot-compiled linux system which does > not ship udev, it uses busybox mdev instead because the distro is aimed at > small systems (design choice by developers which I can not influence) but > can also run on recent Intel SB/IB/HSW CPUs. udev != libudev. The latter can be used without the presence of the former as it is a selection of helper functions that helps abstract dev manipulations. AFAICS you have a couple options here - install libudev or keep a bunch of local patches. I would encourage you go with the former.
The kernel I have to use is compiled without CONFIG_DEVTMPFS and without CONFIG_FHANDLE. http://cgit.freedesktop.org/systemd/systemd/tree/README states that at least these options are required, the later one explicitly for libudev, so using libudev seems not to be an option for me :(
(In reply to comment #7) > The kernel I have to use is compiled without CONFIG_DEVTMPFS and without > CONFIG_FHANDLE. > > http://cgit.freedesktop.org/systemd/systemd/tree/README states that at least > these options are required, the later one explicitly for libudev, so using > libudev seems not to be an option for me :( Why not file a bug with your distribution mentioning that Mesa now requires libudev (but not udev), and asking them to enable the necessary options? CONFIG_FHANDLE appears to add no additional runtime cost, and adds a single syscall that's maybe 100 lines of code. Basically nothing. We'd really like to avoid having to maintain multiple paths.
(In reply to comment #8) > Why not file a bug with your distribution mentioning that Mesa now requires > libudev (but not udev) Hi, I found a way to include libudev in the distro, so you can disregard my comment :)
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.