stylus and touch input does not rotate on ThinkPad X220t

[Sebastian Henneberg]

The stylus and touch input does not rotate on my ThinkPad X220t. The screen (output) inverts absolutely fine. But all wacom devices still seem to be in the normal orientation after changing in tablet mode. I tried to get around this bug by adding a command which should be executed during switch. But it did not worked as well.
If I run the xsetwacom command manually on the command line, the rotation switch works fine.

[Favux (favux-is)]

Hi Sebastian,

In a terminal change directory to the magick-rotation folder. When in it run the following command:
    ./xrotate.py inverted
Does the screen and input tools rotate to inverted? If not what is the output after you run the command?

[Favux (favux-is)]

To rotate back to laptop change 'inverted' to 'normal' as in:
    ./xrotate.py normal

[Sebastian Henneberg (sibi)]

The output is a python stacktrace:

$ ./xrotate.py inverted
Traceback (most recent call last):
  File "./xrotate.py", line 846, in <module>
    r.rotate(direction)
  File "./xrotate.py", line 770, in rotate
    display.direction = display.rotate(direction)
AttributeError: 'NoneType' object has no attribute 'rotate'

[Favux (favux-is)]

Alright, check in /etc/udev/rules.d if there is a file called 62-magick.rules. Is there?

Also in the output of:
    xrandr -q --verbose
post the second line, which should have 'connected' in it and probably LVDS or LVDS1.

[Sebastian Henneberg (sibi)]

The file 62-magick.rules was successfully copied to the udev rules directory.

xrandr says:

$ xrandr -q --verbose
Screen 0: minimum 320 x 200, current 1366 x 768, maximum 8192 x 8192
LVDS1 connected 1366x768+0+0 (0x49) normal (normal left inverted right x axis y axis) 277mm x 156mm
...

[Favux (favux-is)]

OK, it looks like you have the LVDS# bug. We just posted a fix for it the other day.

On the Overview page click on Code. On the line with the middle branch, the one that says unstable, you'll see 19 just before the "Fix LVDS# bug". Click on the 19 and then "browse files at revision 19". Download the "xrotate.py" file by clicking on the download arrow on the far right of its line. Then substitute that xrotate.py for the one in your magick-rotation folder.

[Sebastian Henneberg (sibi)]

Thank you for your support! The xrotate.py script worked like a charm after replacement.

Is there a way to use the automatic rotation with the LVDS# bug? The README just says that xrotate.py is an additional script which can be used with launchers...

[Favux (favux-is)]

Good!

Not sure I follow what you are asking. The xrotate.py is a rotation script and you can use it as a stand alone script. Like we did above with ./xrotate.py in the magick-rotation folder or with the path to xrotate.py. If you don't include one of the switches, such as right, inverted, and left, it will go through them sequentially i.e. rotate through 360 degrees. Other parts of Magick Rotation create the gui, determine the hinge state and current orientation, store user options, etc. But because your system reports LVDS1 you need the xrotate.py with the LVDS# fix because the unfixed one won't work.

[Michael Schwemmer (mschwemmer)]

Hello, I had the same issue with my X220t tablet and followed the instructions above. Downloading the updated xrotate.py file did do the trick. However, when I rotate the screen back to normal and use the stylus to touch the screen, the cursor position is about an inch or so above where I place the stylus. Furthermore, this seems to persist when I rotate the screen back to tablet mode. Except that in tablet mode, the cursor position seems to be about an inch or so to the left of where I place the stylus.

[Favux (favux-is)]

Hi Michael,

This should really be a separate bug report.

I'm doubting that behavior is due to Magick. Let's see if we can narrow it down a little.

Does it happen if you just change the screen orientation?
xrandr -o right

To get it back to normal:
xrandr -o normal

Does it happen if you rotate just the Wacom input tool i.e. the stylus? Obtain your stylus <device name> from 'xinput list' and using it in quotes:
xsetwacom set "device name" Rotate cw

Back to normal:
xsetwacom set "device name" Rotate none

Or do you have to change the screen orientation and the orientation of the stylus both?

[john burns (burnsajohn)]

Hello all, I noticed a different problem in xrotate.py on my lenovo x220t running fedora 15, and I stitched together my own solution which works well (I posted this in another thread, but perhaps it belongs here? or nowhere? I'm not really familiar with these forums):

Perhaps this has been taken care of... but none of the fixes here worked for my configuration: Lenovo X220t running Fedora 15. I have the newest wacom driver( xf86-input-wacom) as of today (10-28-2011).

I ran the debug script in xrotate.py and realized that the commands to rotate the touch and pen input were not being recognized because the devices were not being called correctly in xsetwacom. I found the simplest way to call the device properly is to just use the device id number.

The code was calling:

xsetwacom list devices

with output:

Wacom ISDv4 E6 Pen stylus id: 10 type: STYLUS
Wacom ISDv4 E6 Finger touch id: 11 type: TOUCH
Wacom ISDv4 E6 Pen eraser id: 16 type: ERASER

relevant code starting at line 738 (in "class rotate" which starts at line 652):

        # for versions less than Lucid we will check
        # xsetwacom to see if there are any devices to
        # rotate
        if self.wacom_count == 0:
            wacom_dev = linuxwacom()
            devices = getoutput("xsetwacom list")
            if devices:
                devices = devices.split("\n")
                for item in devices:
                    name = ""
                    item_list = item.split()
                    # Rebuild the device name with spaces but
                    # skip the last word because it is the tool type
                    for index in range(len(item_list) - 1):
                        name += item_list[index]
                        if index != (len(item_list) - 2):
                            name += " "
                    if debug:
                        print "name: " + name + " direction: " + direction
                    wacom_dev.rotate(name, direction)

The code calls the devises, splits them up into an array, then rebuilds the name. My fix just takes the element of that array that corresponds to the id number and hard codes that as the name for the device. There is probably a better way to fix that rather than hard coding the element of the array, but I don't know python at all and am sleepy!). The fix looks like this, where I just removed the loop under the comment "#skip the last word because it is the tool type" and replaced it with the item number in the array corresponding to the id number:

        # for versions less than Lucid we will check
        # xsetwacom to see if there are any devices to
        # rotate
        if self.wacom_count == 0:
            wacom_dev = linuxwacom()
            devices = getoutput("xsetwacom list")
            if devices:
                devices = devices.split("\n")
                for item in devices:
                    name = ""
                    item_list = item.split()
                    # Rebuild the device name with spaces but
                    # skip the last word because it is the tool type
                name = item_list[6]
                    if debug:
                        print "name: " + name + " di...

[john burns (burnsajohn)]

by the way, the message i was getting after turning debug on in the code was this:

$ ./xrotate.py normal
 Rotating screen
xrandr -o normal

xsetwacom set "Wacom ISDv4 E6 Pen stylus id: 10 type:" rotate none
Cannot find device 'Wacom ISDv4 E6 Pen stylus id: 10 type:'.

xsetwacom set "Wacom ISDv4 E6 Finger touch id: 11 type:" rotate none
Cannot find device 'Wacom ISDv4 E6 Finger touch id: 11 type:'.

xsetwacom set "Wacom ISDv4 E6 Pen eraser id: 16 type:" rotate none
Cannot find device 'Wacom ISDv4 E6 Pen eraser id: 16 type:'.

I suspect the xsetwacom just didn't like the way the code was defining the device name in the original script, which is why I changed it to just use the number of the device id, which worked just fine.

-j

[Favux (favux-is)]

Hi John, thank you for bringing this issue to our attention. The error message in the last post was very useful.

The reason the xsetwacom commands are failing is because they should read:
    xsetwacom set "Wacom ISDv4 E6 Pen stylus" rotate none
not
    xsetwacom set "Wacom ISDv4 E6 Pen stylus id: 10 type:" rotate none
The appending of 'id: 10 type:' is unexpected.

Because the ID # can change depending on boot order or if you have another usb device plugged in I do not recommend using it.

The sections you are working with, as the comment indicates, are "legacy" and intended for support of pre-kernel 2.6.32/Xserver 1.7 (Lucid). With those Xservers we couldn't rely on <xinput list> Since Fedora 15 has 2.6.38 and Xserver 1.10 the parsing should be happening up in 'class devices' around line 24. Fedora has the xf86-input-wacom-0.11.1 release as the default. Unlike Oneiric (0.11.0) they were smart enough to pick 0.11.1 (last tar release), which has the Portrait rotation bug fix. Due no doubt to Peter Hutterer.

Are you saying there was a xf6-input-wacom update to Fedora 15 on the 28th? I haven't updated in a week or so. Or did you clone the git repository?

So what we want to do is see why <xinput list> is failing. Enter in a terminal:
    xinput --list
and post the complete Wacom lines from the output. I don't remember a change to xf86-input-wacom that would change the output like that, but I can't remember the last time I cloned it. Not that long ago.

[john burns (burnsajohn)]

Hi Favux,

Thanks for the awesomely detailed reply.

here is the relevant output from xinput (I had to install xorg-x11-apps to get the command to work):

$ xinput --list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Wacom ISDv4 E6 Pen stylus id=10 [slave pointer (2)]
⎜ ↳ Wacom ISDv4 E6 Finger touch id=11 [slave pointer (2)]
⎜ ↳ SynPS/2 Synaptics TouchPad id=13 [slave pointer (2)]
⎜ ↳ TPPS/2 IBM TrackPoint id=14 [slave pointer (2)]
⎜ ↳ Wacom ISDv4 E6 Pen eraser id=16 [slave pointer (2)]

Come to think of it, maybe that's why the call to get the device names was coming from so deep in the script. xrotate.py probably tried to pull the device list from the xinput --list command at line 26, but that command didn't exist for me, so it went to a call that actually gave output "xsetwacom list"... And that is proibably why I had such a curt debug output... most of the script was being skipped due to lack of input from my computer.

So, after installing xorg-x11-apps (xorg-x11-apps-7.6-2.fc15.x86_64 for me) and the necessary dependencies, I tried the unmodified xrotate.py script again, and it worked flawlessly out of the box. Somehow I missed that I needed that package.

Here is what the debug output looks like now that the script gets output from xinput --list; much nicer:

$ ./xrotate.py
 Rotating screen
xrandr -o left

testing 2
testing 4
testing 10
rotating wacom device Wacom ISDv4 E6 Pen stylus
skipping next rotation check
xsetwacom set 10 rotate ccw

testing 11
rotating wacom device Wacom ISDv4 E6 Finger touch
skipping next rotation check
xsetwacom set 11 rotate ccw

testing 13
testing 14
rotating evdev device TPPS/2 IBM TrackPoint
going: left
normal: [1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0]
left
tablet x: 1366
screen x: 768
tablet y: 768
screen y: 1366
top x: 1366.0
max x: 1366.0
sum x: 2902.0
top y: 768.0
max y: 1366.0
sum y: 3500.0
tablet x offset: 0
tablet y offset: 0
screen x offset: 1366.0
screen y offset: 0.0
left: [0.0, -1.0, 1, 0.5622254758418741, 0.0, 0.0, 0.0, 0.0, 1.0]
xinput set-prop 14 'Coordinate Transformation Matrix' 0.0 -1.0 1 0.562225475842 0.0 0.0 0.0 0.0 1.0
left: [0.0, -1.0, 1, 0.5622254758418741, 0.0, 0.0, 0.0, 0.0, 1.0]
testing 16
rotating wacom device Wacom ISDv4 E6 Pen eraser
skipping next rotation check
xsetwacom set 16 rotate ccw

testing 3
testing 5
testing 6
testing 7
testing 8
testing 9
testing 12
testing 15

Thanks again for the input. I hope this helps someone... I guess I was missing the dependency somewhere.

-j

[john burns (burnsajohn)]

Oh, incidentally, I did git clone the xf86-input-wacom driver on the 28th of October, 2011, so I just figured it was the most up to date version as of that date, not that it was a new version released on the 28th. I'd post what version it is, but I'm embarassed to admit that I don't actually know how to get my computer to tell me that information...

[Favux (favux-is)]

The command for version is:
    xsetwacom -V
and should give you 0.11.99 for the most recent version. Version 1.0 is around the corner!

Glad you got it working. So xinput isn't installed by default in Fedora? You have to get it in the xorg-x11-apps package? I've been upgrading so I guess I forgot I had installed it at some point early on. We'll have to add the information. Thank you.

Say I have a question. Do you have sudo installed? I ask because I would like to know if the Installer worked for you or whether you had to install manually from the INSTALLER.txt.

[john burns (burnsajohn)]

Favux,

I assume I have sudo installed... I use the sudo command often enough during installations, and a quick search does not lead me to any other package samed sudo. I am realatively new to linux in general, so I can get stumped by simple questions... sorry.

As for the install, I ended up installing manually from the INSTALLER.txt. Unfortunately, I spent so much time digging through the xrotate.py script (that was my first look at python code) that I can't remember exactly what made me go through the steps in the intaller text. I believe I tried to install by running the 'magick-rotation' script, but the program did not run, and the installation files did not show up in the indicated folders, so I went through the manual installation instructions instead and that worked fine.

I don't really know why the install didn't work the first time, though, since I just went right to the manual instructions without giving it much thought.

Also, I just got this computer and fresh installed Fedora 15 about a week ago, so I suppose xinput is not installed by default.

Thank you for all the great input and quick responses. It's really cool to see the open source community at work!

-j