XO-1.75 etoys graphical corruption when launching after rotating

[dsd]

As reported by the NZ testing group and reproduced by me: rotating the screen 4 times and then starting etoys causes graphical oddities.

> Etoys on XO-1.75 seems to be very angry about rotation. If you rotate
> the screen 4 times to return to normal upright and then start etoys,
> insanity ensues. Parts of the screen are replaced by whatever was on the
> screen prior to the last rotation. Hiding part of the screen with the
> frame and then showing it again causes more of the screen to be replaced
> with the rotated version of the previous activity. This is not a problem
> on XO-1. Switching back to the ring and then back to etoys yields a
> perfect copy of the previously rotated display. Rotating while inside
> etoys seems to fix things.

Similar problems occur in other activities. Rotate 4 times then launch Paint: all of the toolbar items appear as white squares.

[jnettlet]

This was caused by the reserved memory being mapped with ioremap_nocache which sets the memory type as MT_DEVICE rather than MT_MEMORY_NONCACHED. This has been fixed in the galcore driver commit [arm-3.0-wip dfde663]

[Quozl]

Tested os14 as is, and with kernel dfde663. The symptom reproduces on os14. Part of the symptom reproduces on kernel dfde663; the old rotated screen data appears, and while the animation progresses the foreground painted by Etoys is replaced gradually by the old rotated screen data.

[Quozl]

Also reproduced in os14 plus kernel 63ab5b1 plus xorg-x11-drv-dove-0.1.0-8.olpc.armv5tel.rpm

[bert]

Appears to work fine on os15.

Regarding jnettlet's question on IRC: Squeak renders everything on its own. It only opens a simple X11 window and pushes bitmaps to it (using xshm if available). For large cursors it uses XRender. OpenGL support is compiled into the Squeak VM but not used by Etoys (on XO-1 OpenGL was disabled as build option but apparently the Fedora build does not disable it). The X11 module source (there are others, like fbdev and Quartz) is at http://squeakvm.org/svn/squeak/trunk/platforms/unix/vm-display-X11/sqUnixX11.c

[Quozl]

See #11519 for photograph of failure on os16 taken by factory. This looks no different to what I saw earlier on this ticket.

[bert]

Ah, I saw it now, too.

There is a Squeak problem that looks a bit similar: http://tracker.squeakland.org/browse/SQ-400

[dsd]

This was later fixed by adding a patch to the X server, and now we have a more suitable fix (in the graphics driver) done in #12542.