RandR does this for you.

Try setting virtual yourself like a sane human being.

(In reply to comment #1)
> RandR does this for you.

The radeon driver is able to choose different defaults depending on things like the amount of video RAM...

The defaults in radeon have no basis whatsoever, and they artificially limit what users can choose. Artificially clamping virtual to 2560x1600 is just a band-aid, and plainly wrong.

In radeonhd, in my code, i correctly check actual blitter limits when deciding FB dimensions. For some reason this was disabled in alex' Quick and Dirty code, but it is correctly used again now that CS was merged.

All the user needs to do is work around RandR stupidly deciding virtual for us, providing a square area to take into account rotation, even though rotation is not possible in this driver yet.

As I explained in discussions at the time, there's no need to check the accel limits when setting up the FB.  EXA takes the various accel limits (blitter limits, texture limits, etc.) into account and with XAA it's probably better to fail to init accel and tell the user what happened than to fail the requested setup.

(In reply to comment #4)
> As I explained in discussions at the time, there's no need to check the accel
> limits when setting up the FB.  EXA takes the various accel limits (blitter
> limits, texture limits, etc.) into account and with XAA it's probably better to
> fail to init accel and tell the user what happened than to fail the requested
> setup.

Looks like manually setting the virtual size could be avoided. As a user, one should not care about this stuff.

Comment #3 and #4 seem to be besides the point: Whether we deal with the blitter limits beforehand is irrelevant, the scanout buffer dimensions are within these limits, still there is not enough space of local memory available to allow for DRI, thus those limits are not limiting the maximum mode but part of acceleration is limit due to the space requirements for the maximum mode. 
Scanout buffer + 2d offscreen memory get reserved before DRI is initialized. It's size determines the sizes of the DRI buffers. Of course one could estimate the size of the DRI buffers beforehand and adjust things accordingly. This would however require us to implement a policy. Whatever policy is implemented it is unlikely it will meet the expectations of all users.
Please figure this out and close this bug.

I as a user have hit similar issue on in Intel card where the AGP bridge was not supported by the OS resulting in very small amount of memory available.

In this case I care about:

1) running in largest resolution possible, without accel if must be (typical desktop use)

2) possibility to start the screen rotated if the driver supports rotation so that the maximum Virtual can be allocated for the rotated mode

3) maximum accel for the chosen mode (typically the monitor native or recommended resolution)

4) allowing rotation of the max mode if supported and there is memory margin

there might be users who want preferences for

A) (also (1)) allowing larger/rotated modes over accel - this is probably handled by setting Virtual manually to some extent but it seems the modes still require ridiculously high amount of memory (~4x the size of virtual x color depth on Intel)

B) full accel over max resolution/color depth - this can be done by setting Virtual and color depth manually but the required settings are non-obvious

Is this going to be fixed?

Perhaps bandaids for specific cases would but ultimately the root of the problem is the X server's inability to change virtual as required.

For one on Intel the video overlay size seems to be limited by the virtual size (or it is just incidentally the same?) so changing the virtual to larger one when a large video playback is requested would be desirable.

Unfortunately X cannot do that.

(In reply to comment #9)
> Perhaps bandaids for specific cases would but ultimately the root of the
> problem is the X server's inability to change virtual as required.
> 
> For one on Intel the video overlay size seems to be limited by the virtual size
> (or it is just incidentally the same?) so changing the virtual to larger one
> when a large video playback is requested would be desirable.
> 
> Unfortunately X cannot do that.

It would definitely be nice to have that, but that's no excuse to have this bad behaviour.

Lots of things can be done, if the driver find outs the virtual size is too big, well then why not change the virtual size?

If you want to be puristic and avoid workarounds then disable EXA when the virtual size is too big, or fail completely and return an error.

Having the user wondering why on earth everything is so painfully is low is Not Good(tm).

(In reply to comment #10)

> It would definitely be nice to have that, but that's no excuse to have this bad
> behaviour.
> 
> Lots of things can be done, if the driver find outs the virtual size is too
> big, well then why not change the virtual size?
> 
> If you want to be puristic and avoid workarounds then disable EXA when the
> virtual size is too big, or fail completely and return an error.
> 
> Having the user wondering why on earth everything is so painfully is low is Not
> Good(tm).
> 

As explained in comment #6 X is not designed for that either.
The memory is divided among several subsystems which are initialized sequentially and do not know about the memory requirements of each other.

It would require either some guess which might cause problems in some special cases again or substantial changes to the X configuration and module initialization process.

Does this issue occur with the preferred ati driver (xf86-vide-ati)?  If so, please move this to the Driver/Radeon component.  

Development of radeonhd has pretty much halted and development focus is on the ati driver.  Please see http://www.x.org/wiki/radeonhd

If the issue does not exist in the ati driver (or if there is no response to this message), this bug will be closed as WONTFIX unless someone contributes a patch.

Closing due to lack of response.  Please reopen and move to the Driver/Radeon 
component if this issue persists with xf86-video-ati