Bug 75739

Created attachment 95066 [details]
Xorg.0.log

The bisected commit also cause "Mesa selects wrong DRI driver"(Bug 75212)

Did you have libudev detected by configure.ac during your build?  Nothing GL will work if not, but my patch to fix that by requiring it to build got blocked by complaints about dependencies.

(In reply to comment #3)
> Did you have libudev detected by configure.ac during your build?  
No error when build Mesa,with libudev detected by configure.ac pass.

With the patch(git-b959fd96),the problem still exists.

In case it adds useful information: I can't reproduce the problem on my system (IVB, Intel HD Graphics 4000). Tried with with mesa's master, the reported bad commit and also with the mesa package provided by my distro (Ubuntu 13.10) and it seems to always work fine here.

Do you have libudev installed on the ChromeOS image, in addition to libudev-dev being present in build environment?

What udev reports as the GPU on ChromeOS?

(In reply to comment #6)
> Do you have libudev installed on the ChromeOS image, in addition to
> libudev-dev being present in build environment?
> 
> What udev reports as the GPU on ChromeOS?
Maybe i mislead you,that the "chrome" meams chrome browser. 
we do some analyze,detail as below:
libudev.so.0 -> libudev.so.0.13.1* (can't support webgl）
libudev.so.0 -> libudev.so.1.3.5   (support webgl)
by above the way,we can reproduce the problem.

(In reply to comment #7)
> (In reply to comment #6)
> > Do you have libudev installed on the ChromeOS image, in addition to
> > libudev-dev being present in build environment?
> > 
> > What udev reports as the GPU on ChromeOS?
> Maybe i mislead you,that the "chrome" meams chrome browser. 
> we do some analyze,detail as below:
> libudev.so.0 -> libudev.so.0.13.1* (can't support webgl）
> libudev.so.0 -> libudev.so.1.3.5   (support webgl)
> by above the way,we can reproduce the problem.

I have libudev.so.1.3.5 too.

> I have libudev.so.1.3.5 too.
BTW we can support webgl status as below:
libudev.so -> libudev.so.1.3.5*
libudev.so.0 -> libudev.so.1.3.5*
libudev.so.1 -> libudev.so.1.3.5*
Do you also like this?

Eric, can you reproduce that?

I can't reproduce this, WebGL works just fine with current Mesa master, tested with SNB and IVB machines. There is something wrong in tester's environment. Also you don't need "--enable-webgl --ignore-gpu-blacklist" flags, WebGL works fine on Intel without these.

Add the error output:
-----------------------
libudev: udev_device_new_from_syspath: not in sys :/sys/dev/char/226:0
libGL error: MESA-LOADER: could not create udev device for fd 12
ATTENTION: default value of option force_s3tc_enable overridden by environment.
[13082:13082:0521/212337:ERROR:context_group.cc(193)] ContextGroup::Initialize failed because too few texture units.
[13082:13082:0521/212337:ERROR:gles2_cmd_decoder.cc(2255)] GpuScheduler::InitializeCommon failed because group failed to initialize.
[7:7:0521/212337:ERROR:command_buffer_proxy_impl.cc(165)] Failed to initialize command buffer service.
[13082:13082:0521/212337:ERROR:context_group.cc(193)] ContextGroup::Initialize failed because too few texture units.
[13082:13082:0521/212337:ERROR:gles2_cmd_decoder.cc(2255)] GpuScheduler::InitializeCommon failed because group failed to initialize.
[7:7:0521/212337:ERROR:command_buffer_proxy_impl.cc(165)] Failed to initialize command buffer service.

(In reply to comment #8)
In our side, we can reproduce that as following:
if "ln -s libudev.so.0.13.1 libudev.so.0", the case would be fail.
if "ln -s libudev.so.1.3.5 libudev.so.0", the case would be pass.

No idea what was going on with this bug (very well might have been invalid). Regardless, Mesa doesn't link to udev anymore.