Created attachment 14215 [details] reproducer After using dualhead for a while, switching back to single, switching to console and back and switching to dualhead again, GL apps work in a limited rectange in the top left corner of the screen. I have a HP Compaq nx7300 notebook (1280x800 display), an LCD (1280x1024) connected to its VGA output. I have xserver-xorg-core 2:1.4.1~git20080131-1 and todays (2008-02-08) git of intel driver. I'm not sure when this broke, but 2.1.1 works quite well (well, patched for the VT switch hang and brightness). I'm attaching a reproducer, which is to be run as "startx ./test.sh".
What's the mesa version you are using? Please attach xorg.conf and Xorg.0.log.
Tomas, any response?
Created attachment 15017 [details] xorg.log
Created attachment 15018 [details] xorg.conf
Created attachment 15019 [details] test output This is the output of test.sh. "DRM_I830_CMDBUFFER: -22" seems suspicious. I'm using the mesa which's in debian testing, that is OpenGL version string: 1.3 Mesa 7.0.3-rc2
Fengming, can you reproduce this on 945GM, with the first attached script?
(In reply to comment #6) > Fengming, can you reproduce this on 945GM, with the first attached script? > I using the latest git code and can not reproduce this problem.After running the script in comment #1, I still can pull or push glxgears to any place on my screen.
Tomas, can you post the xrandr output in the broken case?
ping response from bug reporter.
Without needinfo I'll have to close this as we're not able to reproduce.
Created attachment 16193 [details] xrandr output in broken case
Created attachment 16194 [details] xorg.log
I'm sorry for the late reply, but I simply didn't have time to shut down my X server and do all this testing. But I finally got to it. I attached the output you wanted, I attached new xorg.log. As of now, I was doing the tests on kernel 2.6.25, xserver 2:1.4.1~git20080131-3 (from debian), intel driver 2:2.3.0-1 (from debian), mesa 7.3.0 (libgl1-mesa-dri 7.0.3-1 from debian, for example). Still not working though. So I decided to bisect it and I ended up with the first bad commit being 4ca3550fb7d488741f8dc1ba3c8722393277c3b8 (Rework DRI buffer mappings and sarea setup to allow for moving buffers.). I hope this helps. Just a note... Most of the time, I was just getting a black window when I resized it to cover both screens. Just one times it wrote that "DRM_I830_CMDBUFFER: -22" message and logged something to dmesg: [drm:i915_emit_box] *ERROR* Bad box 383,803..683,800 [drm:i915_cmdbuffer] *ERROR* i915_dispatch_cmdbuffer failed
So the reporter says it's introduced by this commit: 4ca3550fb7d488741f8dc1ba3c8722393277c3b8 Author: Eric Anholt <eric@anholt.net> Date: Thu Oct 4 17:02:15 2007 -0700 Rework DRI buffer mappings and sarea setup to allow for moving buffers. While this has been a desired feature for some time, to allow for reallocation of the front buffer, it was made more necessary by the desire to avoid requiring a NO_MOVE buffer type in TTM because buffer objects may not be left pinned over VT switch. This is a step towards making those buffers movable and resizable.
I looked into this a little bit. pScrn->virtualY is 2048 at server init, but it is set to current screen height later. Since i830_update_dri_buffers is called only in I830EnterVT, after switching to dualhead one has to switch to console and back to X to get buffers mapped and for GL to work for whole screen. I have no idea why it works for you though. Commenting out the call to i830_update_dri_buffers in I830EnterVT seems like a great workaround for me, but I'd like you to look at why this happens. Thanks :)
Created attachment 20845 [details] [review] uDRI1: Update sarea (and other information) when CRTC configuration changes. Does this patch fix the issue? (only build tested on my end)
Could we verify if Eric's patch is valid to fix this issue?
I'll get to that in a week or so, I have no monitor here.
(In reply to comment #18) > I'll get to that in a week or so, I have no monitor here. > ping...
I really think that this patch should have fixed the problem, so closing it until we get some word that it didn't.
oops, hadn't pushed it: commit 73aa23d9150121a4e4b70a78cab910acd164abf5 Author: Eric Anholt <eric@anholt.net> Date: Fri Dec 5 13:06:05 2008 -0800 DRI1: Update sarea (and other information) when CRTC configuration changes. Bug #14423. Signed-off-by: Eric Anholt <eric@anholt.net>\
Sorry guys for not replying, I've been quite busy lately, but finally got some time to play with X again. I upgraded to 2.7.0 yesterday and this seems to be fixed, so thanks. (I feel shame for promising a reply and replying months later, but having a workaround and being busy didn't really push me to test and answer. As an apology, I spent a few hours yesterday debugging another issue (bug 21632) and I hope I've filed a great bugreport :).) Thanks again.
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.