Bug 10843

Created attachment 9847 [details]
x.conf at 1024x768

On refection I think this is more likely to be a intel driver problem.

Using the git version as of:

commit 3b769af53e0ef6ef9b56afd679446c73a0e63ea5
Author: Eric Anholt <eric@anholt.net>
Date:   Thu May 3 13:44:12 2007 -0700

I am not seeing the work around with virtual work.

As requested assign to Wang Zhenyu.

You should set fb size for the origin screen picture size, as server handles rotation by taking damage from that, then draw to scaning buffer per crtc. 
Try "--fb" option with xrandr. 

You will need to be explicit about the command that I must issue.
I tried this and get an error:

# xrandr -o left --fb 768x1360
xrandr: screen cannot be larger than 1360x768 (desired size 768x1360)

and try this and it does not fix anything:

# xrandr -o left --fb 1360x768

I'm trying to track down why rotation on the i965 is broken.
The screen that is drawn is always a square with demension
of the height. e.g for 1370x768 only 768x768 is drawn correctly
the rest of the screen is what ever was in memory.

When exaTryDriverComposite() is entered:

(gdb) p *pSrc->pDrawable
$39 = {type = 0 '\0', class = 1 '\001', depth = 24 '\030', bitsPerPixel = 32 ' ', id = 98, x = 0, y = 0, width = 768,
 height = 1360, pScreen = 0x8c4a958, serialNumber = 60}
(gdb) p *pDst->pDrawable
$40 = {type = 1 '\001', class = 0 '\0', depth = 24 '\030', bitsPerPixel = 32 ' ', id = 0, x = 0, y = 0, width = 1360,
 height = 768, pScreen = 0x8c4a958, serialNumber = 11}
(gdb)

This makes sense the pSrc->pDrawable is 768x1360 the pDst is 1360x768.

However after these calls:

339         pSrcPix = exaGetDrawablePixmap(pSrc->pDrawable);
340         pDstPix = exaGetDrawablePixmap(pDst->pDrawable);

We have:

(gdb) p *pSrcPix
$41 = {drawable = {type = 1 '\001', class = 0 '\0', depth = 24 '\030', bitsPerPixel = 32 ' ', id = 0, x = 0, y = 0,
   width = 1360, height = 768, pScreen = 0x8c4a958, serialNumber = 2}, refcnt = 1, devKind = 5632, devPrivate = {
   ptr = 0xa7e88000, val = -1477935104, uval = 2817032192, fptr = 0xa7e88000}, devPrivates = 0x8c5fbac, screen_x = 0,
 screen_y = 0}
(gdb) p *pDstPix
$42 = {drawable = {type = 1 '\001', class = 0 '\0', depth = 24 '\030', bitsPerPixel = 32 ' ', id = 0, x = 0, y = 0,
   width = 1360, height = 768, pScreen = 0x8c4a958, serialNumber = 11}, refcnt = 2, devKind = 5632, devPrivate = {
   ptr = 0xa85d6000, val = -1470275584, uval = 2824691712, fptr = 0xa85d6000}, devPrivates = 0x8c68ab4, screen_x = 0,
 screen_y = 0}
(gdb) p pDstPix
$43 = 0x8c68a88
(gdb) p pDst->pDrawable
$44 = 0x8c68a88
(gdb)

pDst->pDrawable is the same as pDstPix

pSrcPix is 1360x768 not what I'd expect which is 768x1360.

Is this the root cause of the failure to rotate the whole screen?

Barry

Could you attach the x log? And do you use the latest xrandr tool?

On my G965 with 1024x768 resolution, xrandr will show the max width/height
to be 1024x1024, which can hold rotated screen. Then I do
xrandr --output VGA --rotate left --fb 1024x1024, that fill the whole screen right.

You can still use "Virtual" to set the max size. 

Created attachment 9913 [details]
1360x768 config file

Created attachment 9914 [details]
log from using 1360x768 config

I've attached the config and log file from using 1360x768.

I have xrandr 1.2.0.

Users never use xrandr in my application. I configure the
mode and rotation using the x.conf file.

I do use xrandr to help debug this problem. Are you saying that
there are bugs in the xrandr that was release and I need the
GIT version to avoid these bugs in xrandr?

testing a 1024x768 I do see only 768x768 of drawn screen.
The rest is random frame buffer pixels.

What version of DRM do I need for correct operation?
I have linux 2.6.21 with:

[drm] Initialized drm 1.1.0 20060810
[drm] Initialized i915 1.6.0 20060119 on minor 0

Barry

So you may say 'Virtual 2048 2048' in xorg.conf, and use 
xrandr --output VGA --rotate left --fb 2048x2048, to make sure whole screen got
updated. 

The broken issue on G965 should be relate to some hw context conflicts between
DRI client and X server. You may diable DRI by Option "DRI" "FALSE" in Device
section and try. I'm still debugging this, and it looks there's problem also
applied to other chips on rotated case.

(In reply to comment #11)
> So you may say 'Virtual 2048 2048' in xorg.conf, 

This on its own does not fix the problems.

> and use 
> xrandr --output VGA --rotate left --fb 2048x2048, to make sure whole screen got
> updated. 

This does fix the drawing to the screen. All the screen is drawn. But the
Xorg process is taking 100%. Also all my apps that calculate the size of the
screen by using:

    width = DisplayWidth( m_display, m_screen );
    height = DisplayHeight( m_display, m_screen );

are broken now. They are getting 2048x2048 and not the required
actual size of the screen.

I'll go on to test with DRI disabled and add another comment.

Option "DRI" "false" with the git driver
causes the xorg server to SEGV.
I can put gdb on the server to get the details if thats
useful (or is it only a distraction from the core bug?)

With DRI False, XAA and 2048x2048 virtual screen I get this:

Program received signal SIGSEGV, Segmentation fault.
xf86AllocateOffscreenLinear (pScreen=0x0, length=1843200, gran=1024, moveCB=0, removeCB=0, privData=0x0)
    at xf86fbman.c:127
127     xf86fbman.c: No such file or directory.
        in xf86fbman.c
(gdb) bt
#0  xf86AllocateOffscreenLinear (pScreen=0x0, length=1843200, gran=1024, moveCB=0, removeCB=0, privData=0x0)
    at xf86fbman.c:127
#1  0x00f161dd in i830_xf86AllocateOffscreenLinear (pScreen=0x0, length=1843200, granularity=1024, moveCB=0,
    removeCB=0, privData=0x0) at i830_memory.c:1645
#2  0x00f0c71b in i830_crtc_shadow_allocate (crtc=0x1c2000, width=1440, height=900) at i830_display.c:1083
#3  0x080ec5c6 in xf86CrtcRotate (crtc=0x8696db0, mode=0x8696e68, rotation=2) at xf86Rotate.c:422
#4  0x080e56f7 in xf86CrtcSetMode (crtc=0x8696db0, mode=0x8696e68, rotation=2, x=0, y=0) at xf86Crtc.c:281
#5  0x080e65e1 in xf86SetDesiredModes (scrn=0x8694240) at xf86Crtc.c:1749
#6  0x00f10bec in I830EnterVT (scrnIndex=0, flags=0) at i830_driver.c:2927
#7  0x00f11e8c in I830ScreenInit (scrnIndex=0, pScreen=0x86bf958, argc=15, argv=0xbff75104) at i830_driver.c:2678
#8  0x08070409 in AddScreen (pfnInit=0xf10e40 <I830ScreenInit>, argc=15, argv=0xbff75104) at main.c:773
#9  0x0809d02a in InitOutput (pScreenInfo=0x81dd300, argc=15, argv=0xbff75104) at xf86Init.c:924
#10 0x0806fd23 in main (argc=15, argv=0xbff75104, envp=0xbff75144) at main.c:370

This happens when you set startup rotation in xorg.conf right? wmm..I can't produce this, don't know if relate to my current new code. I can rotate when startup using xaa or exa, and I've fixed DRI issue within driver now (not pushed).
The course of the failure is that xserver does rotation render without taking
DRI lock, which was unlocked in DRI's block handler. So we should add dri lock grabbing in xserver rotate code. With this I can do rotation with dri just fine on a UP machine, but on SMP it still will deadlock, I'm tracking what's wrong with it now.

Please pull latest xserver git which has resolved rotation issue with DRI, or wait for Keith might release a xserver-1.3 update. 

I have taken git xf68-intel-video and patch xorg-server 1.3.0.0 with commit
076d070e186afeb416976ae74fbfd50c86db10c5 (I'm assuming that I do not need any
of the other commits).

The orginal problem still exists. Only a 768x768 block of pixels is drawn.
The rest of the screen to the right is never written.

The command:

xrandr --output VGA --rotate right --fb 2048x2048

Allows all the pixels to be drawn but Xorg server uses 100% of the CPU on one core. Which is total unusable when playing a movie.

You have commented that rotate works for you.
If so how are you configured?
What versions of software are you using?
What tests do you run to show that rotate works?

Barry

I use xserver and video driver git tip. I have a 1024x768 screen, xrandr tells me maximum is 1024x1024, which could fit in rotation case. I don't have Virtual size set in xorg.conf.

I run "xrandr --output VGA --rotate left --fb 1024x1024", gnome desk rotates with full screen, that's fine. And run some 3d apps like glxgears and play movies by Xv, they all run fine. Then run "xrandr --output VGA --rotate normal --fb 1024x1024" to be back. 

Is your problem relate with initial rotation? I have seen initial rotation setting in Monitor section might not set the correct fb size.

(In reply to comment #18)
> I use xserver and video driver git tip. I have a 1024x768 screen, xrandr tells
> me maximum is 1024x1024, which could fit in rotation case. I don't have Virtual
> size set in xorg.conf.

O.k. It will take a couple of days until I can get the dependencies all
worked out to build with git xserver tip. I'll do that and report back.

> I run "xrandr --output VGA --rotate left --fb 1024x1024", gnome desk rotates
> with full screen, that's fine. And run some 3d apps like glxgears and play
> movies by Xv, they all run fine. Then run "xrandr --output VGA --rotate normal
> --fb 1024x1024" to be back. 
>
> Is your problem relate with initial rotation? I have seen initial rotation
> setting in Monitor section might not set the correct fb size.
> 

yes. I want this to work at startup from the config settings.

Why does the FB have to be square? Is it limit in the implementation?

(In reply to comment #19)
> Why does the FB have to be square?

I don't think it does, it just has to be large enough for the rotated view.

(In reply to comment #20)
> (In reply to comment #19)
> > Why does the FB have to be square?
> 
> I don't think it does, it just has to be large enough for the rotated view.
> 

Let me be more precise. If I'm using 1024x768 why isn't the FB either
1024x768 or 768x1024? Why is its minimum dimensions 1024x1024?

(In reply to comment #21)
> 
> If I'm using 1024x768 why isn't the FB either 1024x768 or 768x1024?

It should work if you set it to 768x1024, doesn't it?

(In reply to comment #22)
> (In reply to comment #21)
> > 
> > If I'm using 1024x768 why isn't the FB either 1024x768 or 768x1024?
> 
> It should work if you set it to 768x1024, doesn't it?
> 

Wang has been telling me to use 2048x2048. I assumed because this
is needed to either work around a bug or something. Once I have xserver git tip
built and installed I'll test with 768x1024 and report back (up till now I it
does not work).

(In reply to comment #18)
> I use xserver and video driver git tip. I have a 1024x768 screen, xrandr tells
> me maximum is 1024x1024, which could fit in rotation case. I don't have Virtual
> size set in xorg.conf.
> 
> I run "xrandr --output VGA --rotate left --fb 1024x1024", gnome desk rotates
> with full screen, that's fine. And run some 3d apps like glxgears and play
> movies by Xv, they all run fine. Then run "xrandr --output VGA --rotate normal
> --fb 1024x1024" to be back. 
> 

I have git tip running and can confirm that the rotation works as you describe
if I use a config that starts in normal and then uses xrandr to rotate.

> Is your problem relate with initial rotation? I have seen initial rotation
> setting in Monitor section might not set the correct fb size.
> 

Yes this is broken still. I cannot set rotate to right and have it work.
only right of the screen is not written to.

(In reply to comment #22)
> (In reply to comment #21)
> > 
> > If I'm using 1024x768 why isn't the FB either 1024x768 or 768x1024?
> 
> It should work if you set it to 768x1024, doesn't it?
> 

No this does not work.

I'm testing git tip on 945 hardware and its using 99.6% of the CPU time running
Xorg server. The hardware is an HP 7600U with a 2.8GHz P4.
I'm running mozilla and xine playing movies.

This works with low CPU time on the 965 hardware.

Barry

Latest git tip has my fix for i965 draw rect, which makes initial rotation work fine on my 965GM. 

On my 915G desktop, in rotation running mplayer with xv vo and mozilla cost about 40~50% cpu. I'm not sure what eats up your cpu time.

(In reply to comment #27)
> Latest git tip has my fix for i965 draw rect, which makes initial rotation work
> fine on my 965GM. 

This is a lot better. But its not taking the rotation into account
when picking up the virtual size limits. If I rotate left or right
the width and height of the virtual size must be swapped before you
start rejecting modes.

For example 1440x900 rotate right needs:
 virtual 900 1440

But mode 1440x900 is rejected with the current code.

(In reply to comment #27)

> On my 915G desktop, in rotation running mplayer with xv vo and mozilla cost
> about 40~50% cpu. I'm not sure what eats up your cpu time.
> 

Latest git still uses 99% CPU in rotate right to play a movie. I'm using xine
and texture video.

I've opened 11185 to cover the virtual size bug
and 11186 to cover the 945 performance bug.

I'm happy that the clipping bug is fixed for both
965 and 945. Thanks for all your work on this problem,
I very much appreciate it.