Bug 10843 - Rotation clips output on intel 2.0.0 server 1.3.0
Summary: Rotation clips output on intel 2.0.0 server 1.3.0
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium blocker
Assignee: Wang Zhenyu
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-03 02:31 UTC by Barry Scott
Modified: 2007-06-07 03:45 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
x.conf at 1024x768 (1.52 KB, application/octet-stream)
2007-05-03 02:48 UTC, Barry Scott
no flags Details
1360x768 config file (1.63 KB, text/plain)
2007-05-10 03:28 UTC, Barry Scott
no flags Details
log from using 1360x768 config (52.09 KB, text/x-log)
2007-05-10 03:29 UTC, Barry Scott
no flags Details

Description Barry Scott 2007-05-03 02:31:42 UTC
kernel 2.6.21.0 (from RedHat FC7 rpm)
Xorg 7.2 build from source with updated
server 1.3.0 and intel 2.0.0 and all required
dependencies.

I'm testing rotating a 1024x768 screen. Once it is rotated
only 768x768 area of the screen can be drawn on. The rest
of the screen shows pixels from operation the screen in landscape.

# xrandr
Screen 0: minimum 320 x 200, current 768 x 1024, maximum 1024 x 768
VGA connected 768x1024+0+0 left (normal left inverted right) 408mm x 255mm
  1024x768       60.0*+
  800x600        60.3
  640x480        60.0

Looking at the xrandr output I notice that minimum and maximum
are unrotated dimensions where as current is rotated.

Is the bug that maximum is being used to reduce current?

Changing the config with:

Section "Screen"
       Virtual     1024 1024 

This works around the bug for 1024x768.
But does not work for 1440x900. 

This is reproducible on 945 and 965.

In our application this is a blocker bug. All the screens
are mounted in portrait orientation.
Comment 1 Barry Scott 2007-05-03 02:48:34 UTC
Created attachment 9847 [details]
x.conf at 1024x768
Comment 2 Barry Scott 2007-05-04 03:25:09 UTC
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.
Comment 3 Barry Scott 2007-05-09 03:42:50 UTC
As requested assign to Wang Zhenyu.
Comment 4 Wang Zhenyu 2007-05-09 18:51:21 UTC
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. 
Comment 5 Barry Scott 2007-05-10 01:46:13 UTC
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

Comment 6 Barry Scott 2007-05-10 01:50:03 UTC
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


Comment 7 Wang Zhenyu 2007-05-10 02:15:36 UTC
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. 
Comment 8 Barry Scott 2007-05-10 03:28:30 UTC
Created attachment 9913 [details]
1360x768 config file
Comment 9 Barry Scott 2007-05-10 03:29:02 UTC
Created attachment 9914 [details]
log from using 1360x768 config
Comment 10 Barry Scott 2007-05-10 03:35:19 UTC
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
Comment 11 Wang Zhenyu 2007-05-10 19:34:06 UTC
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.
Comment 12 Barry Scott 2007-05-11 08:55:45 UTC
(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.
Comment 13 Barry Scott 2007-05-11 09:58:36 UTC
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?)



Comment 14 Barry Scott 2007-05-14 04:02:19 UTC
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
Comment 15 Wang Zhenyu 2007-05-14 18:32:28 UTC
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.
Comment 16 Wang Zhenyu 2007-05-17 20:51:26 UTC
Please pull latest xserver git which has resolved rotation issue with DRI, or wait for Keith might release a xserver-1.3 update. 
Comment 17 Barry Scott 2007-05-18 07:35:22 UTC
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
Comment 18 Wang Zhenyu 2007-05-20 17:57:38 UTC
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.

Comment 19 Barry Scott 2007-05-21 03:51:04 UTC
(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?
Comment 20 Michel Dänzer 2007-05-21 04:58:20 UTC
(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.
Comment 21 Barry Scott 2007-05-21 06:01:00 UTC
(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?
Comment 22 Michel Dänzer 2007-05-21 06:21:08 UTC
(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?
Comment 23 Barry Scott 2007-05-21 07:38:22 UTC
(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).

Comment 24 Barry Scott 2007-05-25 04:26:57 UTC
(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.
Comment 25 Barry Scott 2007-05-25 04:27:26 UTC
(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.
Comment 26 Barry Scott 2007-05-25 05:48:17 UTC
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
Comment 27 Wang Zhenyu 2007-05-30 00:11:43 UTC
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.
Comment 28 Barry Scott 2007-06-01 08:45:09 UTC
(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.
Comment 29 Barry Scott 2007-06-01 08:53:10 UTC
(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.
Comment 30 Barry Scott 2007-06-07 03:45:20 UTC
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.


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.