1) This is a bug reported from Ubuntu Karmic Alpha: https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/383345 2) System environment: -- chipset: 945GM -- system architecture: i686 -- xf86-video-intel version: 2.7.99.1+git20090602.ec2fde7c with Ubuntu patches, and also git b8e360bf2b77d28559d15a7c0f9c766848eb6ced -- libdrm: 2.4.11 -- kernel version: 2.6.30-7-generic -- Linux distribution: Ubuntu (Karmic Alpha) -- Machine or mobo model: Dell Latitude D820 -- Display connector: VGA 3) Reproduce steps: Have a setup with two screens and working virtual resolution (for me: Virtual 2960 1050). On Ubuntu Karmic upgrade xserver-xorg-video-intel to 2:2.7.99.1+git20090602.ec2fde7c. Reboot and notice that when gdm starts the screen gets black, you have a working mouse, but there is nothing to click on: the taskbar and the menu bar are not loaded, no icons, nothing. Reproductibility 100%. Remove virtual resolution from xorg.conf, restart gdm and notice that the menu and task bars appear and that you have mirrored monitors (same image on both). Changing resolutions (same resolution for both monitors or different resolutions - does not matter) and having different displays on each monitor works IFF the resolution combination does not need virtual resolution setup in xorg.conf. I built a .deb package out of git b8e360bf2b77d28559d15a7c0f9c766848eb6ced (current HEAD) and installed and experienced the same problems. (The .deb package can be found at https://edge.launchpad.net/~lucian.grijincu/+archive/xserver-xorg-video-intel). I can confirm that with the previous Ubuntu package xserver-xorg-video-intel=2:2.7.1-1ubuntu1 everything worked fine. You can get that package from http://archive.ubuntu.com/ubuntu/pool/main/x/xserver-xorg-video-intel/ - it contains some patches over git tag 2.7.1.
Created attachment 26414 [details] Xorg.0.log without virtual resolution on git HEAD verion of xserver-xorg-video-intel
Created attachment 26415 [details] dmesg without virtual resolution on git HEAD verion of xserver-xorg-video-intel
Created attachment 26416 [details] xrandr --verbose without virtual res on git HEAD
Created attachment 26417 [details] dmesg with virtual resolution in xorg.conf - screen is blank, mouse woking
Created attachment 26418 [details] Xorg.0.log with virtual resolution in xorg.conf - screen is blank, mouse woking
Things here seem better than bug#21190 (in which X even can't startup), with similar configuration.
*** Bug 22233 has been marked as a duplicate of this bug. ***
put the 2 monitors as top-bottom instead of left-right to fit virtual < 2048x2048 could be a workaround before this bug fixed.
I ran a git bisect between today's HEAD (b5cd2130f97591f4a387db1b98c940c30bc6404c - TV: Set correct voltage level override values) - which, by the way still has this problem, and 2.7.1. The problem appears at the commit:1b10745a2528622a32271f64c35fcdb7b7154d11 Remove XAA support. I guess you susspected that, but I wanted to make sure. If you have any ideas regarding how to fix this, I can provide my spare time and a machine to test this.
I think this is a duplicate of bug 22328 -- when resizing the frame buffer with no DRI, the screen pixmap pointer would not get reset correctly. A fix for that has been pushed to the driver, please re-open this bug if that isn't sufficient. *** This bug has been marked as a duplicate of bug 22328 ***
*** Bug 22718 has been marked as a duplicate of this bug. ***
I don't think this is a duplicate of #22328. First of all the bug descriptions are different: * #22328 - says the display will be blank with resolutions 1280x800, 1024x768 and 800x600, but it can display normal when changed to 640x480 * this bug says that everything works fine with those resolutions, but stops working when using the Virtual line in xorg.conf. I built the xserver containing the changes that fixed #22328 non-DRI FB resize failed to assign the screen pixmap devPrivate.ptr (22328) but it still does not fix my problem (and as you can read from the Launchpad bug it does not fix it for other either https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/383345). * without "Virtual" in xorg.conf everything seems to work fine (no change from before - two screens can be mirrored) * with "Virtual" in xorg.conf I tested two cases: ** Virtual 2960 1065 -- gdm would not start, and it seamed stuck in a loop trying to start the x server ** Virtual 2048 1065 -- gdm would start, but the image on the screen was destroyed (thin lines from the images dispersed over the screen), BUT the mouse pointer was displayed correctly.
*** Bug 22657 has been marked as a duplicate of this bug. ***
to extract news from launchpad: - it is not black screen in GDM. Reporter has autologin enabled. - happens only with compiz on screen 2048 wide - screen is not completely black but clipped from 2048x768 -> 1x768. One pixel column remains on left side. - kwin does not even start with compositing on that resolution, only on lower.
Things should have been changed with the fix "Allow frame buffers up to 4096x4096". Can you try xf86-video-intel 2.8.x and kernel 2.6.31-rc?
(In reply to comment #15) > Things should have been changed with the fix "Allow frame buffers up to > 4096x4096". Can you try xf86-video-intel 2.8.x and kernel 2.6.31-rc? > 2.6.31-6-generic up-to-date xorg-edgers KMS No, it'not working. larger buffer works, I'm using 2304x768 every day. But with compiz it's still the same.
I also experience the same error with compiz on 2024x1152 resolution. Interestingly there is no such bug when using metacity's compositing manager. Has somebody tried out kwin yet?
Oh and this error still exists on xorg-edgers with 2.6.33.
The original bug of not supporting a framebuffer larger than 2048x2048 for i915 class hardware has been fixed. The remaining bug that compiz does not respect the maximum renderbuffer and texture size of 2048 and gracefully fallback to metacity is a bug in compiz. i915 hardware can only support a maximum size of 2048 in the 3D pipeline, so attempting to use a GL compositor above such a size is futile.
(In reply to comment #19) > The original bug of not supporting a framebuffer larger than 2048x2048 for i915 > class hardware has been fixed. The remaining bug that compiz does not respect > the maximum renderbuffer and texture size of 2048 and gracefully fallback to > metacity is a bug in compiz. i915 hardware can only support a maximum size of > 2048 in the 3D pipeline, so attempting to use a GL compositor above such a size > is futile. This bug was about using compiz AT the maximum size - 2048 width, NOT ABOVE. At the maximum size of texture (for example 2048x768) the screen was black (blank). Compiz should drop at >2048, and all the time it did. I have the feeling you just want to close this bug, without fixing... I'll bet my shorts, that the same situation will happen at 4096 (i965) or 8192 (newer cards).
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.