Bug 10479 - No support for DRI if screen wider than 2048 px on i915
No support for DRI if screen wider than 2048 px on i915
Status: VERIFIED FIXED
Product: xorg
Classification: Unclassified
Component: Driver/intel
7.2 (2007.02)
Other Linux (All)
: medium enhancement
Assigned To: Eric Anholt
Xorg Project Team
:
: 11939 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-30 16:19 UTC by Andreas Kloeckner
Modified: 2009-12-08 07:23 UTC (History)
11 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Kloeckner 2007-03-30 16:19:41 UTC
Is there really no way to support DRI if the framebuffer is wider than 2048 pixels on the older chips? I run my laptop's panel at 1024x768 and an external LCD at 1280x1024 (not an uncommon setup I would think). 1280+1024=2304>2048. I've resolved to running the two screens stacked vertically in the framebuffer, even though in real life they are aligned horizontally. It's not a huge pain to move the mouse up instead of to the left, but it's quite unintuitive.

(And no, in reference to bug #10365, DRI isn't even working properly yet.)

Software versions:
------------------------------------------------------
X Window System Version 1.2.99.902 (1.3.0 RC 2)
Release Date: 14 March 2007
X Protocol Version 11, Revision 0, Release 1.2.99.902
Build Operating System: Linux Debian

libdrm: Debian 2.3.0-1
xserver-xorg-video-intel: Debian 2:1.9.92-1
Kernel: 2.6.21-rc4
drm: git://anongit.freedesktop.org/git/mesa/drm
agp: git://git.freedesktop.org/git/mesa/linux-agp-compat
------------------------------------------------------
Comment 1 Jeff Utter 2007-05-25 04:55:45 UTC
I would just like to say that I am concerned about this as well. I have tried stacking my displays vertically but it feels unnatural to the point of being unusable. I don't know much about the hardware or xorg limitations at play here but why is the maximum size constrainted to 2048 in any direction? why not 4194304 total pixels?
Comment 2 Michael Fu 2007-08-23 19:05:41 UTC
the work in in progress though slowly...
Comment 3 Gordon Jin 2007-10-24 20:42:00 UTC
*** Bug 11939 has been marked as a duplicate of this bug. ***
Comment 4 Eric Anholt 2008-03-28 11:40:45 UTC
It's a real hardware limitation, which was fixed in the 965 and later chipsets.  With a bunch of software we can work around it at a significant performance cost, and ajax has been working on that.
Comment 5 Gordon Jin 2009-01-04 19:49:02 UTC
ajax is working on Shatter for this: http://linux.conf.au/programme/schedule/view_talk/76?day=friday
Comment 6 Simos Xenitellis 2009-01-05 04:24:15 UTC
Regarding the 965 chipsets, 3D desktop works when the size is bigger than 2048x2048, with a caveat. I believe many users will be stuck with this and think that the 965 does not support hardware acceleration when > 2048x2048.

1. When the desktop size is bigger than 2048x2048 and you run 

$ compiz --replace &
Detected PCI ID for VGA: 
Checking for texture_from_pixmap: not present. 
Trying again with indirect rendering:
Checking for texture_from_pixmap: present. 
Checking for non power of two support: present. 
Checking for Composite extension: present. 
Comparing resolution (2304x800) to maximum 3D texture size (2048): Failed.
aborting and using fallback: /usr/bin/metacity 
$ _

Compiz does not start.

2. However, if you reduce the size (using xrandr) to something less than 2048x2048 and try again

$ compiz --replace &
Detected PCI ID for VGA: 
Checking for texture_from_pixmap: not present. 
Trying again with indirect rendering:
Checking for texture_from_pixmap: present. 
Checking for non power of two support: present. 
Checking for Composite extension: present. 
Comparing resolution (2048x768) to maximum 3D texture size (2048): Passed.
Checking for Software Rasterizer: Not present. 
Checking for nVidia: not present. 
Checking for FBConfig: present. 
Checking for Xgl: not present. 
/usr/bin/compiz.real (video) - Warn: No 8 bit GLX pixmap format, disabling YV12 image format
Starting gtk-window-decorator
$ _ 

Now, while the 3D desktop is activated, you can use xrandr to bring the resolution to the original full size (in my case, 2304x800), and the 3D desktop is still working.

Who should we bother to fix the test 'Comparing resolution (2304x800) to maximum 3D texture size (2048): Failed.' so that it does not fail with the 965?
Comment 7 perfectom 2009-03-26 13:41:46 UTC
This issue I'm  having with:
Integrated Graphics Chipset: Intel(R) Mobile Intel® GM45 Express Chipset

Is this considered pre-965? Will this fix apply to all intel chipsets then? I think quite a lot of people are interested in this being fixed, in fact for me and my colleagues I'd say it's the biggest limitation for our desktops.  Many beers for whoever can get this one taken care of :). Thanks a lot!
Comment 8 Gordon Jin 2009-03-26 18:12:18 UTC
(In reply to comment #7)
> This issue I'm  having with:
> Integrated Graphics Chipset: Intel(R) Mobile Intel® GM45 Express Chipset
> 
> Is this considered pre-965? 

No. GM45 is supposed to work without this limitation. If you have such problem, please file a separate bug.
Comment 9 Dan Gray 2009-05-22 12:39:39 UTC
Just to re-open this one for a second - surely this can be worked around.

At the moment i'm running a 1440x900 monitor and a 1024x600 monitor 'stacked'. Could the logic be added to xorg to simply wrap the mouse differently, so that the virtual screen used remains 'vertical' but the mouse jumps up between co-ordinates in reaching the side of a screen, producing the effect of a wide horizontal screen in a vertical virtual desktop?

Does anyone know where the code is that handles this? Would it be an easy add or require major changes to the way Xorg does things?

Sorry - I know this is not a feature request forum, but it does seem a logical workaround.

D.
Comment 10 Scott Zeid 2009-05-26 14:24:53 UTC
Is any real progress being made on this bug?  It's been open for two years and the only thing I've heard about it is that "ajax is working on Shatter for this".
Comment 11 Rob Mc 2009-06-23 11:48:17 UTC
As a user, I'm concerned what happens with > 2048 pixel setups in the next driver versions that rely on UXA and nothing else.  I've tried UXA before on my dual monitor configuration (1280x1024 VGA + 1024x768 laptop) and get rejected for DRI not being available.  (I'm not even trying to use Compiz - just DRI)

What will happen when I go to install Ubuntu Karmic, or use the xorg-edgers repository, and want to use dual monitors?  Fall back to VESA framebuffer drivers?

Forgive any ignorance here, please.  This is mostly an attempt by me to bring attention to (what is to me) a serious flaw in the drivers.  I'm surprised this bug hasn't garnered more attention, since a quick google will show you countless posts on forums of people who have this problem.
Comment 12 Gordon Jin 2009-06-23 19:08:52 UTC
(In reply to comment #11)
> As a user, I'm concerned what happens with > 2048 pixel setups in the next
> driver versions that rely on UXA and nothing else. 

UXA is not supposed to change this bug, though UXA now has another problem in xserver (bug#21190).
Comment 13 Gordon Jin 2009-07-31 00:40:48 UTC
This issue should have been fixed together with bug#21190 -- framebuffer has been increased to 4096 for i915/945 (with xf86-video-inte 2.8.0 and drm-intel-next kernel).
Comment 14 Ivo Anjo 2009-12-07 09:39:57 UTC
Is this really fixed? This has been marked as fixed because bug #21190 was also fixed, but I think that other bug was just related to supporting 4096x4096 *without* DRI.

For something that was hard and needed shatter, it's strange to fix it with a diff that replaces 2048 with 4096.

I am using 2.6.31.6 and Intel Driver Version 2.8.1 and I can now put a 1680x1050 monitor to the right of my netbook 1024x600 panel (combined res 2704x1050).
But the minute I do that, kwin disables compositing, and I cannot re-enable it.

If I put the monitor below or above the netbook panel (combined res 1680x1650) compositing keeps working.
Comment 15 Gordon Jin 2009-12-07 17:05:47 UTC
(In reply to comment #14)
> Is this really fixed? This has been marked as fixed because bug #21190 was also
> fixed, but I think that other bug was just related to supporting 4096x4096
> *without* DRI.

It should work (including DRI) if you use a non-compositing window manager like gnome. So I believe this old bug should be closed.
 
> I am using 2.6.31.6 and Intel Driver Version 2.8.1 and I can now put a
> 1680x1050 monitor to the right of my netbook 1024x600 panel (combined res
> 2704x1050).
> But the minute I do that, kwin disables compositing, and I cannot re-enable it.

For the compositing window manager issue, let's track at bug#23718. 

Comment 16 Ivo Anjo 2009-12-08 07:23:24 UTC
(In reply to comment #15)
> (In reply to comment #14)
> > Is this really fixed? This has been marked as fixed because bug #21190 was also
> > fixed, but I think that other bug was just related to supporting 4096x4096
> > *without* DRI.
> 
> It should work (including DRI) if you use a non-compositing window manager like
> gnome. So I believe this old bug should be closed.
> 
> > I am using 2.6.31.6 and Intel Driver Version 2.8.1 and I can now put a
> > 1680x1050 monitor to the right of my netbook 1024x600 panel (combined res
> > 2704x1050).
> > But the minute I do that, kwin disables compositing, and I cannot re-enable it.
> 
> For the compositing window manager issue, let's track at bug#23718. 
> 

You are absolutely right. I was able to set a bigger-than 2048 resolution on my desktop, and then start openarena in windowed mode, and it still ran with DRI (up to 2047x2047). 

I didn't think to test it before because I thought the compositing being disabled meant I'd lost DRI, but I was wrong.

Marking this bug as verified then.