Bug description: On my 855 GM clutter is completely useless because its clicking detection method is based on some dark magic using pickling, this is broken on my card apparently. Clutter used to work fine here and reverting the pickling method change in clutter makes no difference, the problem seems to be in the driver. System environment: -- chipset: 855 GM -- system architecture: 32-bit -- xf86-video-intel: a92bbcc94904684e7709b3ddaad82bc04607af26 -- xserver: 2:1.6.3.901-1 -- mesa: 7.6.0~git20090817.7c422387-0ubuntu0 -- libdrm: 2.4.13-1 -- kernel: 2.6.31-rc6-686 -- Linux distribution: Debian unstable -- Machine or mobo model: Thinkpad R50e -- Display connector: LVDS Reproducing steps: 1. Build clutter 2. Run tests/interactive/test-events 3. Hover over the elements and try clicking them 4. You see how the 'focus' is removed from red-square but does not move anywhere else, warnings are printed to console Additional info: This is the log for the clutter test: Running ./test-interactive test-events 2 NOTE: For debugging purposes, you can run this single test as follows: $ libtool --mode=execute \ gdb --eval-command="b test_events_main" \ --args ./test-interactive test-events (test-events:8008): Clutter-CRITICAL **: clutter_id_pool_lookup: assertion `id < id_pool->array->len' failed [stage] STAGE STATE *source* [stage signal] activate * captured event for type 'ClutterStage' * [red box] KEY RELEASE ' ' *source* [stage] KEY RELEASE ' ' (test-events:8008): Clutter-CRITICAL **: clutter_id_pool_lookup: assertion `id < id_pool->array->len' failed (test-events:8008): Clutter-CRITICAL **: clutter_id_pool_lookup: assertion `id < id_pool->array->len' failed (test-events:8008): Clutter-CRITICAL **: clutter_id_pool_lookup: assertion `id < id_pool->array->len' failed
Fang Xun, could help testing this on 855GM I have tried latest bits on 945GME, didn't met the issue: Arch: i386 Platform: 945GME Libdrm: (master)ac71f0849928f4b2fbb69c01304ac6f9df8916a1 Mesa: (mesa_7_6_branch)84c7afd9e0f2df72d90dd82d38384c4f2f45173e Xserver: (server-1.6-branch)507e57381fea6334f7dc8da6925e53d2c76fddcb Xf86_video_intel: (master)a92bbcc94904684e7709b3ddaad82bc04607af26 Kernel: (master)74fca6a42863ffacaf7ba6f1936a9f228950f657
yes, this can be reproduced on 855GM.
usually, any bug in the event handling for Clutter is the direct result of a malfunctioning glReadPixels(). in order to identify the scene graph element that originated the event, Clutter encodes each actor's unique id into a RGB value and renders the scene graph using those colors. in this case, the warning: (test-events:8008): Clutter-CRITICAL **: clutter_id_pool_lookup: assertion `id < id_pool->array->len' failed means that the value extracted from the glReadPixels() output was not a valid id.
FWIW, I'm experiencing this with the ati and radeonhd drivers too, on this card: ATI Technologies Inc M56GL [Mobility FireGL V5200]
Does this still happen with recent Mesa bits? Note that the Intel and radeon bugs are separate since they use different paths to map pixels for readback. Vincent, please file a separate bug.
On debian sid: ii libgl1-mesa-dev 7.6-1 ii libgl1-mesa-dri 7.6-1 ii libgl1-mesa-glx 7.6-1 ii libglu1-mesa 7.6-1 ii mesa-common-dev 7.6-1 ii mesa-utils 7.6-1 ii linux-image-2.6.31-1-686 2.6.31-1 ii xserver-xorg-video-intel 2:2.9.0-1 ii libdrm-dev 2.4.14-1+b1 ii libdrm-intel1 2.4.14-1+b1 ii libdrm2 2.4.14-1+b1 ii xserver-common 2:1.6.4-2 Problem is still there. I can't test mesa from git right now.
This is fixed in Mesa 7.7 with the change in sw fallback handling.
(In reply to comment #7) > This is fixed in Mesa 7.7 with the change in sw fallback handling. > Indeed, thanks!. Curious: sw fallback means this is not implemented by my hw? that it is implemented by my hw but it broke?
For all the folks that have to stay with the old MESA libs, a small workaround: set environment variable LIBGL_ALWAYS_SOFTWARE=1, and start your (clutter-based) application. This will result in (much) slower speed, but the app will still work & it will be testable!
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.