Opened 3 years ago

Closed 18 months ago

#11344 closed defect (fixed)

XO-1.75 etoys graphical corruption when launching after rotating

Reported by: dsd Owned by: jnettlet
Priority: normal Milestone: 11.3.0
Component: x window system Version: not specified
Keywords: Cc: bert
Blocked By: Blocking:
Deployments affected: Action Needed: diagnose
Verified: no

Description

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.

Change History (9)

comment:1 Changed 3 years ago by jnettlet

  • Action Needed changed from never set to add to build

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]

comment:2 Changed 3 years ago by Quozl

  • Action Needed changed from add to build to diagnose

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.

comment:3 Changed 3 years ago by martin.langhoff

  • Action Needed changed from diagnose to test in build

comment:4 Changed 3 years ago by Quozl

  • Action Needed changed from test in build to diagnose

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

comment:5 Changed 3 years ago by 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

comment:6 Changed 3 years ago by Quozl

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

comment:7 Changed 3 years ago by bert

Ah, I saw it now, too.

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

comment:8 Changed 3 years ago by bert

  • Cc bert added

comment:9 Changed 18 months ago by dsd

  • Resolution set to fixed
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets.