acpi power state changes result in corrupted display [Toshiba Portege R100]

[Roy Badami]

[Problem]
Toshiba Portege R100 hardware has broken ACPI for handling power state changes (e.g. brightness settings), resulting in a corrupted display. It requires changes to kernel parameters to make the issue go away, as described in this article:
http://ubuntuforums.org/archive/index.php/t-533793.html

[Original Report]
On my Toshiba Portege R100 laptop, with trident driver, any attempt to change the display brightness results in an incorrect resolution. The screen image is displayed too large by a factor of approximately 2, with only the top left quadrant of the desktop being visible. This is with Feisty Beta.

This is particularly troublesome because by default the screen brightness is set after logging in... And also when switching between battery and AC.

As virtual consoles aren't working either, the only workaround when this happens is to kill X with Ctrl-Alt-Backspace and log in again.

Repeat by:

Boot up and log in,

or,

echo 'brightness: 6' > /proc/acpi/toshiba/lcd # assuming brighness not already at 6

[Brian Murray (brian-murray)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. You reported this bug a while ago and there hasn't been any activity in recently. We were wondering if this is still and issue for you? Thanks in advance.

[Erock (eric.hoffman)]

I have recently run into this same problem as well with a fresh install of Ubuntu 7.10 on a Toshiba R100 as well. After some reading I've found a few other people with the same problem, namely the first link below which is another launchpad bug. As it has been mentioned before, any changes to the display backlight brightness either user initiated with the hot keys or automatically as in letting the computer go idle and dimming the display or switching from AC to battery power causes the strange resolution to be displayed where only the top left quarter of the screen is expanded to full screen on the lcd.

As mentioned above, the proper resolution can be brought back by restarting X or by switching to a virtual terminal with ctrl-alt-F1 and back, ctrl-alt-F7. Some think that ACPI is to blame however when forcing Ubuntu to use the VESA driver, brightness changes work perfectly which makes me think the problem is in the Trident XP4 driver itself.

References of others with similar problems
https://bugs.launchpad.net/ubuntu/+bug/76120
http://ubuntuforums.org/archive/index.php/t-533793.html
http://ubuntuforums.org/showthread.php?p=4305081#post4305081

Any help on this issue would be greatly appreciated.

[Brian Murray (brian-murray)]

The issue that you reported is one that should be reproducable with the live environment of the Desktop CD of the development release - Hardy Heron. It would help us greatly if you could test with it so we can work on getting it fixed in the actively developed kernel. You can find out more about the development release at http://www.ubuntu.com/testing/ . Thanks again and we appreciate your help.

[Erock (eric.hoffman)]

Well the bug is a bit better with Hardy Alpha 5 in that it gets the correct resolution on startup. However when I manually changed the brightness of the screen (the brightness function + F6,F7 keys, unplugging AC power, or letting the computer go idle dont actually change the brightness of the LCD) I see the same resolution change bug.

To change the brightness I did:
echo 40 | sudo dd of=/proc/acpi/video/VGA/LCD/brightness

It almost seems that the reason this bug isnt shown on startup is because brightness can no longer be changed. Hope that helps, let me know if you need any more information.

[emerging (anyreg)]

The bug is still present in Hardy Alpha 6. A workaround is to use the fbdev driver in xorg.conf - this way X uses the framebuffer, which knows how to handle this video chip correctly, at the expense of acceleration. This was reported way back when at http://ubuntuforums.org/showthread.php?t=301082. Hope it helps.

[emerging (anyreg)]

This bug is present in Hardy Beta as well. Additionally, the screen gets garbled intermittently, see attached screenshots. I am yet to figure out what causes that.

What's worse, X now forces a reconfiguration at every reboot and switches back to the broken trident driver if I set fbdev through displayconfig-gtk. A broken driver I can live with. The system overwriting my config changes and forcing its misguided, although well-intentioned, auto configuration settings on me is way too microsoft-like and a real show stopper.

[emerging (anyreg)]

Autoconfig redeemed. I stopped gdm, killing X, and edited xorg.conf by hand. X -probeonly reported no /dev/fb0 - it never occurred to me to look. The generic kernel no longer has the framebuffer enabled, so using fbdev is no longer possible in the default config. There was a way to force loading framebuffer from grub, wasn't there? Hope this info helps, and I would greatly appreciate any suggestions as to how to work around the original video issue.

[Bryce Harrington (bryce)]

Please attach your /var/log/Xorg.0.log

[a.h() (a.h)]

I also can report this problem under Kubuntu 8.04 (hardy).

When I first installed the system, the monitor couldn't be automatically detected, I had to fix this using xfailsafedialog.

Originally, on a screen brightness change, the top-left quarter of the screen was magnified to fill the whole screen, you could restore the desktop either by changing virtual terminal, or changing to another mode in X, and back to the wanted mode. I then added the option "CyberStretch" to the graphic card section of xorg.conf - after this instead of magnifying the screen, the display was corrupted (In recent testing I noticed that a part of the screen near the left is magnified by about 1.5 times, and then shown corrupted on the monitor - any text etc. is not recogniseable as such. - The corruption is much worse than what was shown above.), however you could restore the desktop as before.

When the screen is locked (In my setup the screen just goes black, a small unlock dialog is shown in the centre of the screen), and the brightness is changed (as happens when closing the laptop lid), then the screen shows only black. This can be fixed in the same way again.

Also: If the screen brightness is set to the same brightness it currently is, i.e. by using
echo 'brightness: X' > /proc/acpi/toshiba/lcd
then nothing happens. (I doubt this is important, since the acpi software probably checks if the wanted brightness equals the current brightness before doing anything else.)

Taking a screenshot internally (i.e. using Ksnapshot, run using the PrintScreen button), results in an image of what should be shown (the uncorrupted image).

[Bryce Harrington (bryce)]

We need /var/log/Xorg.0.log, not xorg.conf (although thanks for including it too). Leaving as Incomplete since we still don't have the info needed to conduct troubleshooting.

[nossac (ubuntu-bleaksky)]

This issue is now fixable:
http://ubuntuforums.org/archive/index.php/t-533793.html

[betzi (s-betzinger)]

That posted Link doesnt't work. Can you repost it in correct way?
Thanks!

[Bryce Harrington (bryce)]

The link works okay for me.

So it sounds like this is an ACPI / Kernel issue rather than an Xorg issue. I'll refile accordingly.

[a.h() (a.h)]

I wouldn't think this is an ACPI / Kernel issue, since it only occurs when using the Trident driver (as part of Xorg), but has been reported not to occur when using the framebuffer provided through the kernel. (I will test this in detail once I have time.) The above solution in http://ubuntuforums.org/archive/index.php/t-533793.html does not work: The problem persists.

[Tim Gardner (timg-tpi)]

Can you try the Jaunty LiveCD to see if the issue still persists?

[Erock (eric.hoffman)]

I confirmed that this is still an issue on 9.04. Once I got it to the native resolution (it wasn't auto detected properly on install), removing AC power which dims the backlight causes screen image corruption. Ctrl+alt+f1, ctrl+alt+f7 fixes the corruption.

[Luc1972 (l-ingerson)]

I too experience this. The only reason it occurs on ACPI events is the system automatically dims the display to conserve battery life; if the dim option is turned off then it doesn't happen. Thus this is not an ACPI event problem rather a problem with how the system dims the display.

[Luc1972 (l-ingerson)]

Just to confirm that if under Power Management options on Battery Power section you untick "Reduce Backlight Brightness" and "dim display when idle" and also for on AC Power section untick "dim display when idle" this does not happen at all unless you manually dim the display; even if you remove AC power it will not change resolution.

[a.h() (a.h)]

For me the problem the just disappeared (I'm still on 8.04, no updates had been done within the time-frame that this happened): I was playing with my xorg.conf trying to set up an external display, and broke it, after which I created a new xorg.conf using the automatic tools, and modified it. I don't know what actually caused it, but now I can change display brightness without corrupting or resizing the screen.

[RivalComp (rival)]

Karmic Koala 9.10 has this issue on my Toshiba Portege R100. I don't know how to link two bug reports together, but there is an other report here with ACPI bug:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/471934

I think this must be a same issue.

[Thomas Hotz (thotz-deactivatedaccount)]

Can you reproduce this error with Ubuntu 12.04 LTS?

[Roy Badami (roy-gnomon)]

Unfortunately I no longer have a working R100 so I can't test.

[Luc1972 (l-ingerson)]

Neither do I. My darling children managed to smash the screen.

On 8 Nov 2012, at 12:25, Roy Badami wrote:

> Unfortunately I no longer have a working R100 so I can't test.

[Thomas Hotz (thotz-deactivatedaccount)]

Then closing this bug. Thank you for your quick response!