XRandR Rotation with -intel doesn't work with compiz [x3100]

[Andrew Stromme]

Binary package hint: xorg

I think this is the fault of the -intel driver, although it was present in -810 as well with my old tablet PC. I can't seem to rotate my screen while compiz is running. If I do, my screen seems to rotate (all of the panels correctly place) and my mouse will move but I can't interact with my desktop. If I do something like open a program using gnome-do and then revert my screen to the normal orientation (using a ssh terminal) I find that
the program I opened actually did open, the screen just didn't update. It doesn't happen to me when compiz is disabled. I am using an X3100 intel chip with the intel drivers and a fully updated hardy gnome install.

This also happened using both the -intel (in Gutsy) and the -810 (in Feisty) drivers using a Toshiba satellite R10 Tablet PC. I don't have this machine ready for testing anymore, but I'm pretty sure it was running intel 845 or i915 graphics.

Attached is Xorg.0.log
I will also attach the ouput of lspci --vvnn

[Andrew Stromme (astromme)]

I'd like to add that the ouput of lspci is interesting, as it labels my card as a 965. Further investigation reveals this:

GMA X3100

The GMA X3100 is the mobile version of the GMA X3000 used in the Intel GL960 and GM965 chipsets.

From http://en.wikipedia.org/wiki/Intel_GMA

So I do have the X3100 which has Hardware T&L among other things. However, as I mentioned before, this same problem happened on an older i915/865 (I don't remember which it was....). Why does intel have to name their cards so confusingly?

[Bryce Harrington (bryce)]

I notice in the Xorg.0.log, this warning:

(WW) intel(0): ESR is 0x00000011, page table error
(WW) intel(0): PGTBL_ER is 0x00040000, overlay tiling
(WW) intel(0): Existing errors found in hardware state.

i965 refers to the 'architecture family' whereas X3100 is a designator for a specific chip. However I can agree the naming gets confusing. Generally I pay attention to the architecture (i965, etc.) at a high level, and for the low level look at the PCI ID (visible in lspci -vvnn).

[Bryce Harrington (bryce)]

Andrew, first, could you please install these debs of a newer -intel driver and try recreating the problem? If the issue still occurs, we can forward this bug upstream. Otherwise there may be a patch upstream we can go looking for.

 http://people.ubuntu.com/~bryce/bisect/xserver-xorg-video-intel_2.2.0+git20080318.ac763634-1_i386.deb
 http://people.ubuntu.com/~bryce/bisect/xserver-xorg-video-intel-dbg_2.2.0+git20080318.ac763634-1_i386.deb

Second, if the issue still occurs, can you please try obtaining a full backtrace? Directions for doing this are available at:

 https://wiki.ubuntu.com/X/Backtracing

Thanks ahead of time

[Bryce Harrington (bryce)]

Another thing to try, is if after rotating and locking up, if you can ssh in and kill compiz processes, does it come back properly? If so, it may be a compiz issue rather than X.

[Andrew Stromme (astromme)]

Sorry, the debs don't seem to change anything. I looked at the linked page,
but I'm having trouble getting a good backtrace. Every time I try to attach
with gdb (even from a VT in ctrl-alt-f1) my Xorg window freezes. and I must
reboot using the sysrq combinations. I can try with a network attached pc
later, but until tomorrow I can't be of much more help. Any idea about the
hard lockups?

Andrew

On Fri, Apr 18, 2008 at 9:09 PM, Bryce Harrington <email address hidden>
wrote:

> Another thing to try, is if after rotating and locking up, if you can
> ssh in and kill compiz processes, does it come back properly? If so, it
> may be a compiz issue rather than X.
>
> --
> XRandR Rotation with -intel doesn't work with compiz [x3100]
> https://bugs.launchpad.net/bugs/218000
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Andrew Stromme (astromme)]

Interesting. If I kill compiz while rotated, my screen will come back (it's
a bit glitchy, but when I start metacity the entire screen refreshes and
it's all good). If I try and start compiz, I get the same problem. I don't
see any weird notifications from compiz while it is starting in this method.

Let me try with kwin and its compositor.

On Sat, Apr 19, 2008 at 11:46 PM, Andrew Stromme <email address hidden>
wrote:

> Sorry, the debs don't seem to change anything. I looked at the linked
> page, but I'm having trouble getting a good backtrace. Every time I try to
> attach with gdb (even from a VT in ctrl-alt-f1) my Xorg window freezes. and
> I must reboot using the sysrq combinations. I can try with a network
> attached pc later, but until tomorrow I can't be of much more help. Any idea
> about the hard lockups?
>
> Andrew
>
>
> On Fri, Apr 18, 2008 at 9:09 PM, Bryce Harrington <
> <email address hidden>> wrote:
>
> > Another thing to try, is if after rotating and locking up, if you can
> > ssh in and kill compiz processes, does it come back properly? If so, it
> > may be a compiz issue rather than X.
> >
> > --
> > XRandR Rotation with -intel doesn't work with compiz [x3100]
> > https://bugs.launchpad.net/bugs/218000
> > You received this bug notification because you are a direct subscriber
> > of the bug.
> >
>
>

[Andrew Stromme (astromme)]

One more thing before I go to bed. The exact same thing happens using kwin
(from kde 4.0.3) when 3d effects (so also the compositing functions) are
enabled.

On Sat, Apr 19, 2008 at 11:53 PM, Andrew Stromme <email address hidden>
wrote:

> Interesting. If I kill compiz while rotated, my screen will come back
> (it's a bit glitchy, but when I start metacity the entire screen refreshes
> and it's all good). If I try and start compiz, I get the same problem. I
> don't see any weird notifications from compiz while it is starting in this
> method.
>
> Let me try with kwin and its compositor.
>
> On Sat, Apr 19, 2008 at 11:46 PM, Andrew Stromme <email address hidden>
> wrote:
>
> > Sorry, the debs don't seem to change anything. I looked at the linked
> > page, but I'm having trouble getting a good backtrace. Every time I try to
> > attach with gdb (even from a VT in ctrl-alt-f1) my Xorg window freezes. and
> > I must reboot using the sysrq combinations. I can try with a network
> > attached pc later, but until tomorrow I can't be of much more help. Any idea
> > about the hard lockups?
> >
> > Andrew
> >
> >
> > On Fri, Apr 18, 2008 at 9:09 PM, Bryce Harrington <
> > <email address hidden>> wrote:
> >
> > > Another thing to try, is if after rotating and locking up, if you can
> > > ssh in and kill compiz processes, does it come back properly? If so,
> > > it
> > > may be a compiz issue rather than X.
> > >
> > > --
> > > XRandR Rotation with -intel doesn't work with compiz [x3100]
> > > https://bugs.launchpad.net/bugs/218000
> > > You received this bug notification because you are a direct subscriber
> > > of the bug.
> > >
> >
> >
>

[Andrew Stromme (astromme)]

I'm not sure if this is exactly what you meant by a backtrace, but here we
go.

I was able to follow the instructions when logged in remotely, so yay!

I did the following:

Logged into a gnome session.
Started gdb and attached it to my running Xorg process
continued the thread (cont)
rotated the screen with 'xrandr -o left'
At this point my mouse can move around the screen (still being updated) and
I can 'interact' with windows. However, nothing changes on my screen (except
for that mouse) and I do not see any of my windows moving for example if I
drag them around the screen.
I do a ctrl-c in gdb, then running backtrace full
This is the result: (the SIGINT is my ctrl-c I think)

(gdb) cont
Continuing.

Program received signal SIGINT, Interrupt.
[Switching to Thread 0xb7bdba30 (LWP 5976)]
0xb7f06410 in __kernel_vsyscall ()
(gdb) backtrace full
#0 0xb7f06410 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb7d4984d in select () from /lib/tls/i686/cmov/libc.so.6
No symbol table info available.
#2 0x081b2275 in WaitForSomething (pClientsReady=0xbff15eb0)
    at ../../os/WaitFor.c:236
    i = <value optimized out>
    waittime = {tv_sec = 0, tv_usec = 400000}
    wt = (struct timeval *) 0xbff15e70
    timeout = <value optimized out>
    clientsReadable = {fds_bits = {0 <repeats 32 times>}}
    clientsWritable = {fds_bits = {1, 138314432, -1074700904, 134833857,
    -1074700888, 1, -1074700764, -1210805528, -1074700764, 43, -1074700776,
    136163204, 1, 32, -1074700856, 136039262, 43, -1074700764, 1, 0,
    138314432, 136163204, -1074700824, 136034255, 147094224, -1074700764, 1,

    -1073741823, 1, 136713632, -1074700728, 136013494}}
    curclient = <value optimized out>
    selecterr = 0
    nready = <value optimized out>
    devicesReadable = {fds_bits = {140797068, 138314432, -1074700936,
    134819325, 138314432, 32, 140797068, 0, 0, 0, 138314432, 0, 0, 0, 0, 0,
    138277848, 103, 136713632, 136163204, 136694464, 136427336, -1074700936,

    134814362, 136340232, 0, -1074700896, 0, 0, 0, -16121856, 136163204}}
    now = 12092217
    someReady = 0
#3 0x0808d69d in Dispatch () at ../../dix/dispatch.c:425
    result = <value optimized out>
    client = (ClientPtr) 0x83df3d8
    nready = -1
    start_tick = 58640
#4 0x0807471b in main (argc=10, argv=0xbff163e4, envp=0x0)
    at ../../dix/main.c:452
    i = 1
    error = 136163204
    xauthfile = <value optimized out>
    alwaysCheckForInput = {0, 1}
(gdb)

I hope this helps. Interestingly, I tested with an external monitor (17
inch, 1280x1024) and had the exact same thing happen. So I feel that this
has to somehow be related to how the driver handles composite mode. (or the
card itself, but that seems more unlikely)

Andrew Stromme

On Sat, Apr 19, 2008 at 11:56 PM, Andrew Stromme <email address hidden>
wrote:

> One more thing before I go to bed. The exact same thing happens using kwin
> (from kde 4.0.3) when 3d effects (so also the compositing functions) are
> enabled.
>
>
> On Sat, Apr 19, 2008 at 11:53 PM, Andrew Stromme <email address hidden>
> wrote:
>
> > Interesting. If I kill compiz while rotated, my screen will come back
> > (it's a bit glitchy, but when I s...

[Bryce Harrington (bryce)]

Good work with the backtrace! It looks like the xserver is stuck in a wait loop, though, which doesn't reveal the exact problem, but we can now forward this upstream for them to look at.

[Andrew Stromme (astromme)]

Great, I'm glad I could help =).

On Wed, Apr 23, 2008 at 2:52 AM, Bryce Harrington <email address hidden>
wrote:

> Good work with the backtrace! It looks like the xserver is stuck in a
> wait loop, though, which doesn't reveal the exact problem, but we can
> now forward this upstream for them to look at.
>
> ** Changed in: xserver-xorg-video-intel (Ubuntu)
> Status: Incomplete => Triaged
>
> --
> XRandR Rotation with -intel doesn't work with compiz [x3100]
> https://bugs.launchpad.net/bugs/218000
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Kieran Fleming (kieran-fleming)]

I've had the same problem, and decided it was a compiz bug. If you can manage to get a terminal up, try running:
compiz --replace
and see if that fixes your problem. If it does, then I would suggest reassigning this bug to compiz.

[Andrew Stromme (astromme)]

I don't think this is the case. I have the same problem running
kwin-kde4 with the graphical effects turned on. It's possible that
there could be a bug in both, but I get the exact same behavior and
that makes me again think to the driver.

With that said, a workaround might be to rotate the screen with compiz
instead of with xrandr, but that has a lot of overhead.

On 5/25/08, Kieran Fleming <email address hidden> wrote:
> I've had the same problem, and decided it was a compiz bug. If you can
> manage to get a terminal up, try running:
> compiz --replace
> and see if that fixes your problem. If it does, then I would suggest
> reassigning this bug to compiz.
>
> --
> XRandR Rotation with -intel doesn't work with compiz [x3100]
> https://bugs.launchpad.net/bugs/218000
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Tom Jaeger (thjaeger)]

Current word from the compiz developers is that this requires at least mesa git plus a patch, though I haven't seen any confirmation yet that this fixes the issue. Until the bleeding-edge stuff hits the distribution, the easiest route is to apply the workaround patch mentioned in the other bug report.