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.
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.
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.