Screen rotation causes tablet pen miscalibration.

[Perkins]

Binary package hint: wacom-tools

Using xrandr and xsetwacom to rotate the screen works fine. Sometime in the last week or so it started having issues when rotated back to normal.

Specifically, there are serious display artefacts on the top half of the screen, and the pen calibration ends up moving the cursor roughly twice as far as the pen in the horizontal axis, and half as far in the vertical.

The display artefacts sometimes clear themselves after a couple of seconds. Other times the screen reverts to black with a cursor. Switching to a TTY and back to the graphical shell brings it back to normal in either case.

The pen calibration remains unaffected by subsequent rotations. The miscalibration is the same on the physical axes, regardless of the way the screen is rotated. Restarting X returns the calibration to normal. This problem had been occurring previously, but only when the system was put into standby or hibernate mode. Most of the reports I remember seeing listed it as only occurring when the system was suspended while rotated, however my personal machine would do it if the screen had been rotated at any point prior to suspend.

Basically, this is very similar to bug 295292, however it is now happening without the suspend-resume cycle in the middle of it.

ProblemType: Bug
Architecture: i386
CheckboxSubmission: 1ffc70464a61577edc395c2691103d43
CheckboxSystem: b1865df84255b8716d3bcc269ff410d1
Date: Sun Feb 28 17:01:50 2010
DistroRelease: Ubuntu 9.10
MachineType: TOSHIBA PORTEGE M700
Package: xorg 1:7.4+3ubuntu10
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
ProcCmdLine: root=UUID=d1adabde-e223-4a18-a57d-d9ddf4c9be27 ro quiet splash
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-19.56-generic
RelatedPackageVersions:
 xserver-xorg 1:7.4+3ubuntu10
 libgl1-mesa-glx 7.6.0-1ubuntu4
 libdrm2 2.4.14-1ubuntu1
 xserver-xorg-video-intel 2:2.9.0-1ubuntu2.1
 xserver-xorg-video-ati 1:6.12.99+git20090929.7968e1fb-0ubuntu1
SourcePackage: xorg
Uname: Linux 2.6.31-19-generic i686
XorgConf:
 Section "ServerFlags"
  Option "DontZap" "False"
 EndSection
dmi.bios.date: 06/30/2008
dmi.bios.vendor: TOSHIBA
dmi.bios.version: Version 1.50
dmi.board.asset.tag: 0000000000
dmi.board.name: Portable PC
dmi.board.vendor: TOSHIBA
dmi.board.version: Version A0
dmi.chassis.asset.tag: 0000000000
dmi.chassis.type: 10
dmi.chassis.vendor: TOSHIBA
dmi.chassis.version: Version 1.0
dmi.modalias: dmi:bvnTOSHIBA:bvrVersion1.50:bd06/30/2008:svnTOSHIBA:pnPORTEGEM700:pvrPPM70U-09X01H:rvnTOSHIBA:rnPortablePC:rvrVersionA0:cvnTOSHIBA:ct10:cvrVersion1.0:
dmi.product.name: PORTEGE M700
dmi.product.version: PPM70U-09X01H
dmi.sys.vendor: TOSHIBA
fglrx: Not loaded
system:
 distro: Ubuntu
 architecture: i686kernel: 2.6.31-19-generic

[Perkins (lperkins)]

Addendum: When the screen is rotated back, it throws up a bunch of garbage, and then goes black. At this point, the only thing which works is the mouse pointer, and the pen is still correctly calibrated. It is not until I switch to a console and back to reset the display that the calibration goes nuts.

[Perkins (lperkins)]

Second Addendum: I finally realised that it is not unpredictable. It does it if there is an open webbrowser which has a flash object loaded.

[Bryce Harrington (bryce)]

Thank you for reporting this issue with wacom-tools, we are migrating it to the new xf86-input-wacom package which has replaced it in the development version of Ubuntu.

This would be a good point for you to re-test this issue against the new package to see if is still occurring. If not, you can mark it as Fix Released in Launchpad. If it is still an issue in the current development release and you're the original reporter, please reply and attach a fresh Xorg.0.log.

[Perkins (lperkins)]

Well, it's different. The xf86-input-wacom does not appear to accept rotation commands via xsetwacom. Do you know the new method? I'm not having a lot of luck finding instructions.

[Perkins (lperkins)]

Ok, so I finally clicked that the new system had changed the device names. The easy triggers for the behaviour appear to have been fixed. I will test the other possibilities that have come and gone more thoroughly as time allows, but for now it appears to be resolved.