xrandr screen rotation support

[dsd]

Screen rotation seems to be currently unimplemented or unsupported on our setup. "xrandr -o left" produces a BadMatch error.

[cjb]

Looks like openchrome doesn't have support for on the fly rotation yet. (But it can rotate if you tell it to in your xorg.conf.)

Seems like this would be a good small talk to help them out with.

[laforge]

the via driver (not openchrome) implements three different ways for rotation, as there are three different units in the hardware that can do it. One is the old 2D acceleration unit, second is the CBU (no idea what the name means) rotation unit, and number three is the 3D unit.

It's probably best to do some benchmarking on that driver and then decide which of the rotation schemes should be implemented in openchrome.

[dsd]

I saw a mention on the openchrome mailing list that someone is working on randr12 support

[sayamindu]

I think this should be a high (if not a blocker). Screen rotation is crucial for our ebook work.

[Quozl]

symptom persists in os48.

[Quozl]

Symptom persists in os56 per Caryl Bigenho.

[Quozl]

In addition to not working, the left gamepad keys are remapped as if the rotation was successful. This causes the gamepad keys to confuse the user.

This is trivially fixed by reordering the call to xmodmap and xrandr, so that the call to xmodmap is not done unless the call to xrandr is successful.

[Quozl]

Raised Sugar Labs # 1667

[Quozl]

Discussion with pgf in IRC.

Correction, the only reason Sugar is getting the rotate key and mishandling it by using xmodmap is because kbdshim has let the key pass as a result of olpc-rotate failing to run xrandr.

See line 382 of http://dev.laptop.org/git/users/pgf/olpc-kbdshim/tree/olpc-kbdshim-hal.c

[pgf]

comment:8/10 fixed with olpc-kbdshim-11-1.20100120gitf4be89a.fc11.i586.rpm

[Quozl]

Reviewed change in git, looks good.

[Quozl]

Change didn't make it into os200, just verified.

[cjb]

Hi,

Replying to Quozl:

Change didn't make it into os200, just verified.

It wasn't proposed for os200, although it would have been a good candidate. It'll have to hit the next build we release instead.

[cjb]

test (input non-rotation, not screen rotation) in os109

[Quozl]

Workaround tested fine in os109, moving this ticket back to design for xrandr support in X driver.

Current situation is that the rotate key simply does not respond, as far as a user is concerned.

[Quozl]

jnettlet suggested RotationType SWRandR, which I've tried on os116 and it works adequately. The rotate button works.

Please review and merge git://dev.laptop.org/users/quozl/olpc-utils/

[pgf]

i like it. unfortunately, the screen rotates the wrong way. or, at lease, opposite to the direction that F11 rotates on XO-1, and opposite to the direction that ubuntu jaunty rotates on my eee box pc. on those machines, "xrand -o left" rotates the screen counter-clockwise. with SWRandR on XO-1.5, it rotates clockwise. this wouldn't matter, except that the touchpad rotation (controlled by /usr/bin/olpc-rotate) goes the other way. (note that early XO-1 releases also rotated clockwise with "-o left" -- but that changed later.)

is there a way to control the rotation direction for SWRandR?

[cjb]

Fixing Jon N's CC.

I suppose, worst-case, we call "xrandr -o left" if we're on an XO-1, and "xrandr -o right" if we're on an XO-1.5?

[pgf]

no. new XO-1 releases go the right way, and sugar already does the correct thing with the old releases that go the wrong way. i think the test would need to be whether we're going SWRandR or not.

if this is going to keep on being an issue, we should just put down a flag file that tells olpc-rotate which way xrandr turns, on the current build/machine.

[Quozl]

A nicely detailed bug report duplicating this ticket was found in sugarlabs.org #1866.

[Quozl]

Reviewed in team meeting. Waiting for design and coding to implement rotation in graphics driver.

[martin.langhoff]

Blocker for 10.1.2 -- happy to see it resolved with Quozl's patch enabling SWRotate.

(Then we can open a new "rotated display is slow / enable HW accel rotation" bug.)

[dsd]

We don't yet have a patch which solves the direction issue.

[dsd]

Also, it seems like that bug is in SWRandR, and fixing it there would be most appropriate...

[martin.langhoff]

We've been 15 months waiting for the "right" fix.

Can we take Quozl's patch for a test to check that nothing else breaks with it? From what I see here, it'll need some frobbing in the code that calls xrandr to reverse the rotation on XO-1.5 (where's that?).

Quozl -- a while ago you had your patch, and it was decided to wait for upstream. Was there any important downsides to it that might be relevant to consider?

[martin.langhoff]

So we'd have to frob the xrandr invokation in Sugar's src/jarabe/view/keyhandler.py -- doesn't seem to be a major hassle.

[Quozl]

I disagree with raising priority to blocker since the current state is at least usable, even though the function does not work. When to release should not be made dependent on the availability of specific fixes, since that would block other fixes from being released. The amount of time the problem was known is orthogonal.

I'll retest the earlier patch in the current builds. The important downside was that the patch slowed normal unrotated usage considerably.

I've also asked jnettlet_ for a summary of the current state of development.

[Quozl]

Retested patch. Method: on 10.1.2 os852, edit /etc/X11/xorg.conf on XO-1.5 and look for the RotateType option, and add a different option:

        Option "RotationType" "SWRandR"

Then restart prefdm:

stop prefdm
start prefdm

The rotate button now functions.

Three new symptoms result:

• the rotation is in the reverse direction compared to the Geode driver on XO-1,
• the rotate button if held down for even a short time repeats rapidly, which may cause the rotation to seem random until the user learns to press the button for a very short period,
• graphics performance is much lower, about half ... using the test program from #9325 yields 28 fps, instead of 60 fps.

[pgf]

jnettlet implied recently on irc that he was very close to finishing a proper implementation of rotation.

[greenfeld]

Replying to Quozl:

Retested patch. Method: on 10.1.2 os852, edit /etc/X11/xorg.conf on XO-1.5 and look for the RotateType option, and add a different option: {{{ Option "RotationType" "SWRandR" }}} Then restart prefdm: {{{ stop prefdm start prefdm }}}

This works to enable XO 1.5 rotation, but introduces some new quirks which might be 10.1.2 bugs in themselves:

• The touchpad input rotates in the opposite direction of the XO 1.5, but in the same direction as the XO 1.0 (with no changes made to the XO 1.0's xorg.conf file). So upside-down is fine, sideways is not. Touchpad rotation does not appear to happen in the original XO 1.0 build, but does happen in 10.1.2 with both XO 1's and 1.5's.
• Gamepad rotation on 10.1.2 matches the XO 1.5, but NOT the XO 1.0 running its default rotate ability (again breaking sideways rotations). So we seem to have the reverse problem here. {Tested with the Maze activity.}
• The gamepad labeled keys (circle, square, etc.) do not rotate, yet the Maze activity treats it as a second controller. I'm not sure what the expected behavior is here, or if any apps do use said activity keys according to their hard-coded labels.

[greenfeld]

Also: XOs do not reset the mousepad, etc. orientations when Ctrl-Alt-Backspace is pressed to restart the X server.

While the screen is forced to be right-side-up, any rotations to the mousepad, etc., seem to still be in effect.

[pgf]

the goal is to make the screen, touchpad, and d-pad all rotate in the direction printed on the button when the button is pushed. if by "original XO-1 build" you mean 802, then i believe the screen goes the wrong way when the button is pushed, because of a buglet in the X11 driver. i believe this was fixed in later drivers, and /usr/bin/olpc-rotate assumes that xrandr will rotate the screen in the correct direction when given "left" and "right" directives. ("left" means ccw, "right" means "cw".) if i recall correctly, SWRandR implements this incorrectly, necessitating a change in olpc-rotate to compensate.

so, as mentioned in comments 18 and 20, we need to enhance the olpc-rotate script to do the right thing in all environments, in order to always rotate the touchpad to match the screen. this workaround may need to know whether SWRandR is in place, and/or which laptop it's running on.

i don't think we've ever expected the game keys (circle, square, ...) to rotate -- after all, they have labels on them, so rotating doesn't make sense. sounds like Maze wasn't designed with rotation in mind -- that's a different bug.

the d-pad is expected to rotate, and will always match/mismatch in the same way that the touchpad does. i can't tell from the second bullet in comment 37 whether you're saying the d-pad behaves differently (whether correctly or not) than the touchpad.

regarding the use of ctrl-alt-backspace, i believe the problem should clear up if you use the rotation button at least once, since the "next" rotation is based on the current rotation (which will be zero degrees after c-a-d). this mismatch after c-a-d is a wontfix, in my opinion.

[martin.langhoff]

My current plan is to

- olpc-session is testing for machine type, and is part of olpc-utils, which also contains the xorg.conf files. So olpc-session knows the hw and "knows" whether we're suing SWRandR. Will export an envvar (to be read by olpc-rotate :-) )

- olpc-session can also reset d-pad even after ctrl-alt-backspace :-)

[pgf]

Replying to martin.langhoff:

My current plan is to - olpc-session is testing for machine type, and is part of olpc-utils, which also contains the xorg.conf files. So olpc-session knows the hw and "knows" whether we're suing SWRandR. Will export an envvar (to be read by olpc-rotate :-) )

good plan. selfishly, i'd prefer a flag file over an envvar, simply because it makes debugging and scripting easier in cases where you're not running in a child of olpc-session (e.g., from a VT, or serial console). i assume the the data represented by the envvar or file is a boolean: whether xrandr rotates backwards or not.

- olpc-session can also reset d-pad even after ctrl-alt-backspace :-)

good point. this should probably be done as a new invocation argument to olpc-rotate ("olpc-rotate -r") in order to keep most of the communication with kbdshim in one place.

[dsd]

Fixing swrandr to go the right way is probably less effort than working around it.

But we still have the problem that as soon as you enable swrandr, most graphics acceleration features get switched off, even when you aren't rotated. Or has that changed?

[martin.langhoff]

We have

• Patch to olpc-kbdshim so that olpc-rotate obeys a workaround flag, and learns a '-r'(reset) option. Paul -- can you review/comment/merge?
• Patch to olpc-utils so that it sets the workaround flag when appropriate. Dan, can you review/comment/merge? Patch applies cleanly to v1.0 and to master branches.

With these, I find that screen and TP work pretty well. There seems to be a bug in olpc-kbdshim where the dpad rotation is messed up. Now at least it's messed up the same in XO-1 and XO-1.5. A good test is using the dpad in Terminal (navigating history, navigating/editing the cmdline. Filed as #10380 .

Daniel - filed #10381 for the xorg/SWRandR reversed rotation bug. I agree with you it's probably a trivial bug, but am not familiar with Xorg sources. A few hours of digging didn't lead to likely suspects, and could not find any bugreports or list discussion of symptoms similar to ours. Bird in hand...

Perhaps this is already fixed right in the F14 builds for example. Would be good to know.

Opened #10382 to track a HW-accelerated solution for this.

[dsd]

What about the accel issue? IIRC swrandr was briefly carried once before, but was dropped because the mere enabling of the option disabled all kinds of acceleration.

[martin.langhoff]

Initially, I understood it would disable accel only when rotated. Re-reading of the openchrome src makes me thing that my first reading was wrong.

So just to have it enabled, we have to lose acceleration? Do we have a good test for accel that shows a clear difference?

[dsd]

Just using 2 laptops side-by-side before was enough to show it. I imagine it'll be very obvious playing an ogg. And we have one measure of performance in #9325

[martin.langhoff]

Not obvious enough to me in normal usage (even with Record). But using test2.py from #9325 does shows 28~29fps (no accel) vs 62fps.

[Quozl]

Matches test from three weeks ago Quozl:

* graphics performance is much lower, about half ... using the test program from #9325 yields 28 fps, instead of 60 fps.

The performance change seems obvious to me in normal usage. Whether it is acceptable depends on how important rotate is.

[jnettlet]

Here is an experimental version of the driver that supports Randr 1.2 so screen rotation will work, although very slowly because it is being software composited. Normal 0 degrees is accelerated via XAA and should run normal. XVideo is also not working during rotation. This driver needs to be thoroughly tested because I really had to change quite a bit in the driver to get this to work. I will do my best to address issues as fast as possible.

http://dev.laptop.org/~jnettlet/f11/xorg-x11-drv-openchrome-0.2.990-1.fc11.i586.rpm

Make sure and add a Virtual 1200 900 line to each SubSection "Display" entry in your xorg.conf or XAA acceleration gets disabled because the memory isn't managed properly.

[martin.langhoff]

with jnettlet test driver - fails to rotate

[martin.langhoff]

I didn't follow the instructions correctly -- hence the failure.

To make it work, you need to have the rpm and add a Virtual line. The end of your /etc/X11/xorg-x1.5-dcon.conf file must look like

Modes "1200x900" Virtual 1200 900

EndSubSection

EndSection

With this change, and a restart of Xorg, it works! When running in 'normal' orientation, it preserves the HW acceleration, so it's as fast as usual (the test2.py script shows >55FPS).

When rotated, however, performance is very slow 2.8 FPS (compared with "straight" SWRandR at around 25FPS).

I observed no glitches on normal or rotated modes (but my testing was limited).

[erikos]

Replying to martin.langhoff:

I didn't follow the instructions correctly -- hence the failure. To make it work, you need to have the rpm and add a Virtual line. The end of your /etc/X11/xorg-x1.5-dcon.conf file must look like Modes "1200x900" Virtual 1200 900 EndSubSection EndSection With this change, and a restart of Xorg, it works! When running in 'normal' orientation, it preserves the HW acceleration, so it's as fast as usual (the test2.py script shows >55FPS). When rotated, however, performance is very slow 2.8 FPS (compared with "straight" SWRandR at around 25FPS). I observed no glitches on normal or rotated modes (but my testing was limited).

Ok, I got the same results in regards to your posted numbers. Which of your patches from above are needed as well to the full experience?

[pgf]

i've released olpc-kbdshim-15 which fixed d-pad rotation (#10380), ignores repeats of the rotate button (i.e. one rotation per press), and incorporates martin's patch to olpc-rotate to honor the /var/run/olpc-rotate-reverse flag file, if present (which indicates xrandr goes backwards).

i've done nothing with martin's other patch, to olpc-configure, olpc-session, and xorg.conf since i don't yet see consensus on moving forward. btw, i agree with dsd, above, that fixing SWRandR would be preferable to working around it. is that possible?

[jnettlet]

I think we need some clarification on terminology and functionality.

1) Current shipped openchrome driver is not RandR 1.2 compliant. The SWRandR is a poorly termed feature that disables Hardware Acceleration on the card and instead creates a framebuffer in system memory that is rendered by the cpu. This is generally a work around for cards that don't have good 2d acceleration support, and is very cpu intensive. This feature rotates the screen incorrectly, and yes it can be worked around easily enough in the driver. 2) The new "testing" openchrome driver implements full Randr 1.2 functionality which has the added functionality of getting rotation implemented for "free". This system uses XAA and XV acceleration in the "normal" 0 rotated position and uses software compositing for rotated positions. It is really slow because the software compositing fallback is horrible and nobody really wants to fix it. To speed this up we would need to implement an updated drm module that can talk to the 3d engine in the Chrome9 hardware properly. It was decided that any new features are going in 2.6.35 and newer so this won't be happening. This feature set rotates the screen properly. 3) Someone can dig further into the code and hardware to figure out why the 2d hardware functionality of the VX855 fails with a resolution of 1200x900. It appears to be due to the alignment of that resolution, but "adjusting" the resolution to align properly causes the dcon to fail to raster the image.

I hope this helps in making a decision to be made on the proper path forward.

[erikos]

Replying to pgf:

i've released olpc-kbdshim-15 which fixed d-pad rotation (#10380), ignores repeats of the rotate button (i.e. one rotation per press), and incorporates martin's patch to olpc-rotate to honor the /var/run/olpc-rotate-reverse flag file, if present (which indicates xrandr goes backwards). i've done nothing with martin's other patch, to olpc-configure, olpc-session, and xorg.conf since i don't yet see consensus on moving forward. btw, i agree with dsd, above, that fixing SWRandR would be preferable to working around it. is that possible?

If someone wants to test it, Paul keeps his rpms in his public home. http://dev.laptop.org/~pgf/rpms/olpc-kbdshim-15-1.fc11.i586.rpm

[greenfeld]

It has been said that the software rotation solution will cause a noticeable, measurable drop in battery life (although I seem to have missed that email/comment). This is because it currently disables all hardware video acceleration.

I have been asked to test this with a pure battery life test, as opposed to rigging in a DMM to measure the current flow. Does anyone have any preferred solutions to test this? I would imagine that most video intensive solutions for an XO would also be CPU intensive, so we may find the video battery life loss drowned out by the XO doing other things.

One would hope that if the screen was kept unchanged that there would be no difference in battery life between the accelerated/unaccelerated modes, as there would be nothing new to draw.

[Quozl]

Yes, power consumption should rise, and a test may be warranted to consider the impact of software rotate on a typical deployment. I expect the CPU will be used more, and the delay before lowering clock frequency should be longer. The hardware that performs the acceleration remains powered, and is thus a dead weight. I've no idea of the impact order of magnitude.

I don't think a DMM is required. Current in microamps, and voltage in microvolts, is available from /sys when operating on battery, see /sys/devices/platform/olpc-battery.0/power_supply/olpc-battery/{current,voltage}_now ... and power could be calculated from that. /home/olpc/power-logs might also help. The Physics activity, with no objects on screen, with power management disabled, causes continuous X server activity (25%), and so it might be a suitable test activity.

I agree that a static screen should cost no different, but wouldn't be surprised if there was something else going on that I didn't know about. If power remains important, test it.

[greenfeld]

I did two tests with the standard (non-altered per this bug) video driver included in 10.1.2 and the same XO 1.5 laptop/battery. olpc-logbat was used to log battery usage over time.

With SWRandR disabled, the Physics activity could be kept running with no objects shown for 2 hours 18 minutes from a 100% full battery before the laptop shut off itself. The laptop then was allowed to recharge overnight. I then turned on SWRandR and ran the Physics activity for 1 hour 57 minutes before the laptop shut itself off.

If my calculations are correct, the average power draw without rotation disabled was 7.6 watts; the average with SWRandR rotation enabled (even though we were in the normal orientation) was 9.2 watts.

In other news, os351 does not quite have rotation support fully enabled. If we are going to go the hardware rotation route, the "Virtual 1200 900" line mentioned above needs to be added {which can (should?) be on its own line instead of the Mode one}. Without this attempting to rotate the screen scrunches it without repainting the boundaries.

[martin.langhoff]

olpc-utils-1.0.30-1.fc11.i586.rpm should land in the next build.

[erikos]

Please test in os352.

[greenfeld]

1. Apparently the hardware accelerated XO-1.5 rotation driver has a "feature" in os352 where if the laptop is woken up from CPU idle sleep, the display flips to the normal orientation without resetting the resolution used, resulting in an unusable screen. {Similar behavior can be seen if the "Virtual 1200 900" line is forgotten in xorg.conf and you try to rotate the screen sideways.}

2. The line of code needed to reset the touchpad and d-pad to normal orientation when X windows is restarted (via Ctrl-Alt-Bksp or similar) is missing from the 10.1.3 os352 build, and needs to be added to git/built in the RPM/etc. (The XO 1.0 has a similar problem, so such code may not be to be special cased.)

[martin.langhoff]

Registers: Normal orientation after boot

[martin.langhoff]

Left orientation

[martin.langhoff]

Left orientation - broken after resume

[martin.langhoff]

After breakage, continue to rotate fixes it

[martin.langhoff]

Left orientation - broken after resume for second time

[martin.langhoff]

Various register dumps

• Boot, switch to VT (to fetch & compile register.c), switch back to X console
• Capture normal.reg from a terminal
• Rotate left, capture left.reg
• Idle until aggressive suspend, wait a few secs, awaken. Display has a normal orientation, with a clipped 900x1200 desktop. Capture left-br.reg
• Press the rotate button 4 times to get back to left orientation -- works correctly. Capture left-1.reg
• Idle until aggressive suspend, wait a few secs, awaken. Problem reappears. Capture left-1-br.reg

When it wakes up with this strange screen mode, xrandr -o left does not resolve the problem. xrandr into any other orientation, and then back to 'left' fixes it.

[erikos]

What is the status here. Is there already a plan how to fix the symptom described above?

[erikos]

I did try to read a PDF on 353 and I must that scrolling is really a pain. I don't mind the slowness when rotating the screen, since one does that only very few times. But when you scroll in the PDF the updates are far from being close to continuous. Are there any possibilities to improve that?

[martin.langhoff]

Status summary

• openchrome-0.2.903
  • Bad: No rotation.
  • Good: Normal orientation is XAA-accelerated. Known to be stable.
• openchrome-0.2.903, using SWRandR.
  • Bad: Slower than XAA accel (50% slower) -- may be acceptable. Burns battery 10% higher. Needs olpc-kbdshim workaround for wrong direction.
  • Good: Rotation works. Equally slow on all orientations.
• openchrome-0.2.990 from jnettlet
  • Bad: Rotated modes are extremely slow. Gimp locks up system. May have other bugs / corner cases.
  • Good: Rotation works. Accelerated normal orientation.
• chrome-??? from jnettlet
  • Bad: is not here yet. May have bugs and corner cases.
  • Good: Accelerated rotation using EXA (?). Multiple Xv surfaces(depends on kernel patch?). 3D accel(?).

[dsd]

Please take future maintenance into consideration too. An important Bad: for the last 2 on the list above is that they are not upstream.

[martin.langhoff]

Right -- status update

The chrome track got stuck on various issues, so I asked jnettlet a few days ago to focus on openchrome-0.2.990 -- fix the gimp crash (which we indicated would be easy) and we may just have to live w slow perf when rotated.

The resulting rpm openchrome-0.2.990-2 works, fixes gimp crash... and has allowed us to uncover various glitches around suspend/resume + rotation:

• on resume we need to restore more registers on the resume codepath -- jnettlet is cleaning up a viafb patch for that (the rough patch works well)
• with that viafb fix, the dcon gets unfrozen too early - before the registers are reset - showing a nasty orientation glitch. After many wrong turns, we found that it's happening in OFW. James Cameron built a roughly patched OFW that doesn't unfreeze the dcon, and it fixes the problem. Now we need a proper patch & release of OFW.
• during the above investigations, we commented out a dcon unfreeze that happens in the kernel driver olpc-dcon -- unclear whether we need it
• testing in rotated modes has uncovered that dpi when rotated left or right is bogus -- the right fix is probably in xorg or xrandr but we can workaround in olpc-rotate. Sam Greenfeld had spotted this dpi problem before #10453

So late last night Jon had a working rotation, no glitches!

To get this into the build we need to

• confirm whether the olpc-dcon driver patch removing the unfreeze is needed - and whether it may need to be conditional
• cleanup viafb patch, review, merge, build kernel rpm
• check with Mitch whether the (trivial) OFW change is kosher - does it break other OSs? - release & build
• prepare a workaround patch for olpc-rotate, or a root-cause fix in xorg/xrandr for #10453

[martin.langhoff]

(In #10453) In the course of #9350 investigation, we found that this issue affects all programs / activities opened with a rotated screen.

The root problem is that when rotated, the resolution is being flipped but the screen dimensions are staying the same -- so the dpi calculations yield bogus numbers.

At this time, we have not narrowed down the code that handles this (possibly in xorg, xrandr) but we have confirmed a workaround in olpc-rotate works.

Note that this happens on both XO-1 and XO-1.5 so if it's on the xorg driver, we have it twice. A quick test on a netbook running F14 + intel chipset does not repro.

I'll craft the olpc-rotate workaround -- if the right fix materializes I'm happy to get the right fix in instead.

[pgf]

Replying to martin.langhoff:

* with that viafb fix, the dcon gets unfrozen too early - before the registers are reset - showing a nasty orientation glitch. After many wrong turns, we found that it's happening in OFW. James Cameron built a roughly patched OFW that doesn't unfreeze the dcon, and it fixes the problem. Now we need a proper patch & release of OFW.

this is probably the root cause behind #9631 as well.

* during the above investigations, we commented out a dcon unfreeze that happens in the kernel driver olpc-dcon -- unclear whether we need it

i believe the dcon driver is the right place for this unfreeze. or, at least, it's always been there, and other than the glitch, it works fine. no unfreeze is done at user-level, so without the one in olpc-dcon, we'd have to invent something new.

[martin.langhoff]

Status

• Confirm whether the olpc-dcon driver patch removing the unfreeze is needed - and whether it may need to be conditional => Confirmed, not needed
• cleanup viafb patch, review, merge, build kernel rpm => Done, kernel builder should spit out an RPM soon
• check with Mitch whether the (trivial) OFW change is kosher - does it break other OSs? - release & build => we're on track to test this
• prepare a workaround patch for olpc-rotate, or a root-cause fix in xorg/xrandr for #10453 => jnettlet is attempting a root-cause fix

[martin.langhoff]

Further updates

• OFW change seems to be kosher - various people testing q3a61c.rom; Quanta reports it does not break that other OS
• jnettlet has found a promising fix for #10453 -

[Quozl]

Change committed to SVN -r2082, published as q3a61c.rom, tested it myself on OLPC OS 10.1.2, Quanta reports Windows resume does not freeze display, no other test reports received.

[Quozl]

Sorry, correction to my previous reply, -r2082 was published as q3a61d.rom by me. I don't know what was in q3a61c published by Mitch that Martin referred to.

[erikos]

Replying to martin.langhoff:

Further updates * OFW change seems to be kosher - various people testing q3a61c.rom; Quanta reports it does not break that other OS

Issue #10547 is still present in that one, or?

[dsd]

Trying to clean up this confusing bug-tangle... The work outlined here (add rotation support) seems complete, and the remaining issues (if they still remain) are well documented in other tickets referenced above. Closing this one.