rotation is wrong on Fujitsu P1630 in 12.04

[Archelon]

With Magick Rotation and the fujitsu kernel module on Kubuntu 12.04 on my p1630, the display rotates with the panel as it should, however the touchscreen input is not oriented correctly either in portrait mode or after returning to landscape mode. This is remedied by directly resetting the Coordinate Transformation Matrix (to the identity, regardless of the display orientation), Evdev Axis Calibration, and Evdev Axes Swap, after rotating the display panel, using

xinput set-prop [device] [property] [value]

where [device] can be obtained by `xinput list` (in my case it's 12) and then the three values of [property] whose values change incorrectly under rotation (as well as their values) can be found by `xinput list-props [device]`. So by making a shell script with the appropriate three commands for each orientation and invoking them with Magick Rotation's "Run after switch to tablet" and "Run after switch to normal" functions (under Setup on the right-click menu from the notification area green arrow icon), the correct behavior is achieved. Here are the commands I'm using:

For portrait orientation (n.b. "Rotation state in tablet mode" = `left`):

xinput --set-prop 12 260 3970 376 120 3922
xinput --set-prop 12 261 1
xinput --set-prop 12 133 1 0 0 0 1 0 0 0 1

For landscape orientation:

xinput --set-prop 12 260 109 3918 364 3972
xinput --set-prop 12 261 0
xinput --set-prop 12 133 1 0 0 0 1 0 0 0 1

(133 is Coordinate Transformation Matrix, 260 is Evdev Axis Calibration, and 261 is Evdev Axes Swap.)

I hope this is enough information to enable a fix for the p1630. (Incidentally, the bezel buttons aren't doing anything either; I haven't had time to figure out why yet.)

[Archelon (megapteryx)]

(I figured out that the bezel buttons have keycodes but I needed to assign keysyms [I used a .Xmodmap].)

[Favux (favux-is)]

Thanks for the information and the work around. Magick should be using the Coordinate Transformation Matrix to change axes for touch. Memory fades but I believe there was a point where evdev Axes Swap wasn't working and that should be a fallback now. Despite what was said at the time I believe the Axes Swap issue was fixed but Magick kept the change in methods.

I'm not clear why it isn't working for you. Both methods being accidently applied? It will probably be a while before I can look into the issue. Hope you won't mind me making belated reqests for information and maybe testing.

It would be helpful if you explained how you did the keysyms. I could add those instructions to the Rotation HOW TO's appendicies: http://forums.linuxmint.com/viewtopic.php?f=42&t=110395

[Favux (favux-is)]

Hi Archelon,

What kind of digitizer does it have? I'm getting the impression it might not be a Wacom digitizer. If it isn't we should figure out what driver it is using and if that driver has a problem with CTM. Also there have been more general bugs before involving the X Server itself. You should not need to do Axes Swap if using CTM. The matrices are in xrotate.py and there is more discussion of CTM here: http://forums.linuxmint.com/viewtopic.php?f=42&t=112852 Let's try some xinput commands to test rotation.

Use the "device name" you see for the digitizer from 'xinput list'.

The xinput CTM command for none/normal or no rotation is the identity matrix:
xinput set-prop "device name" "Coordinate Transformation Matrix" 1, 0, 0, 0, 1, 0, 0, 0, 1

The xinput CTM command for ccw/left rotation is:
xinput set-prop "device name" "Coordinate Transformation Matrix" 0, -1, 1, 1, 0, 0, 0, 0, 1

The xinput CTM command for half/inverted rotation is:
xinput set-prop "device name" "Coordinate Transformation Matrix" -1, 0, 1, 0, -1, 1, 0, 0, 1

The xinput CTM command for cw/right rotation is:
xinput set-prop "device name" "Coordinate Transformation Matrix" 0, 1, 0, -1, 0, 1, 0, 0, 1

Do they work correctly?

[Archelon (megapteryx)]

Favux, it's good to hear from you. I'm looking forward to working with you on this (but I'm very busy right now). To answer your questions so far:

The P1630's display is a touchscreen with ~9-inch diagonal, and I'm pretty sure it's not Wacom (I seem to remember reading that they hadn't made any that small and didn't have any plans to). I guess it's resistive, since it registers being poked with the plastic stylus. Based on my cursory reading of Wikipedia's Graphics_tablet article, apparently this would be neither an active nor a passive digitizer (since contact and pressure are necessary). But I have been unable to find any documentation, not even a manufacturer name. (There's nothing here: http://www.linlap.com/fujitsu_lifebook_p1630 or here: http://www.lapspecs.com/detail/fujitsu+lifebook+p1630, for example.)

I have verified that the Coordinate Transformation Matrix must be set to the identity (from the command line or with a script) under all circumstances, after xrotate.py executes. On the other hand, I have also verified that the evdev Axes Swap property must be set to 0 for Landscape and 1 for Portrait orientations. (And that I must do this manually, as well, after xrotate.py executes.) Also, using System Settings --> Display and Monitor --> Size & Orientation to rotate the display (I'm on KDE) and then using `xinput set-prop` to set the CTM as one would expect (e.g. `0, -1, 1, 1, 0, 0, 0, 0, 1` for ccw/left rotation) doesn't work, i.e. it leaves the input incorrectly rotated. So evidently something is handling the rotation correctly (without altering the CTM) and then xrotate.py is screwing it up (at least in part by altering the CTM).

It turns out I can't use an .Xmodmap to assign keysyms to the bezel buttons, because when I do so this bug: https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/998310 makes the system unusable for several minutes upon resume-from-suspend. So I'm still doing without the buttons, since I haven't had time to work on it (though I've got quite a bit more information to share, and I expect we can figure out another way to accomplish the objective; where should this be done?).

[Favux (favux-is)]

It is not clear to me how you are using Magick since it is not a Wacom or N-Trig digitizer. When you installed was the 62-magick.rules file added in /etc/udev/rules.d? The Fujitsu udev rule is picking the P1630 up? Did you compile the fujitsu-table.ko from MagickExtras or use the one native to Precise's kernel?

Let's try to identify the digitizer. Instead of using the ID# post the whole touch screen line from the 'xinput list' output. Also run 'cat /proc/bus/input/devices' and post the touch screens section in the output if it is there.

Anyway you can disable the CTM from xrotate.py and go back to the old method by using a switch that is in there. At about line #290 change the code to read:
# if not cur_ctm:
        # to disable CTM comment out above line and uncomment line below
        if cur_ctm:
            return None
Does that change anything?

There is info. on bezel buttons in the HOW TO I linked you to above. We could discuss them on the Ubuntu or Mint forum if you are a member of one of them.

[Archelon (megapteryx)]

This is probably not what you're asking, but:

Magick is running. I've got the green arrow icon in the system tray, and the display started autorotating with the panel only after I installed it. Issuing the command `sudo xxd -g1 /dev/input/magick-rotation` in a terminal and then rotating the display produces

archelon@ingelrayok:~$ sudo xxd -g1 /dev/input/magick-rotation
0000000: 8e a1 74 52 00 00 00 00 f5 b5 07 00 00 00 00 00 ..tR............
0000010: 05 00 01 00 01 00 00 00 8e a1 74 52 00 00 00 00 ..........tR....
0000020: f9 b5 07 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

How did you conclude it's not an N-Trig digitizer? I rather thought it was, but only because I thought that was the only remaining possibility.

To answer your actual questions/requests:

/etc/udev/rules.d/62-magick.rules is present.

When you say "the Fujitsu udev rule", are you referring to the line in 62-magick.rules that says

SUBSYSTEM=="input", ATTRS{name}=="Fujitsu FUJ02B[DF]", MODE="640", GROUP="magick", SYMLINK="input/magick-rotation"

? I'm not sure how to test this.

I'm using fujitsu-tablet.ko from MagickExtras (with DKMS).

archelon@ingelrayok:~$ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ Fujitsu Component USB Touch Panel id=12 [slave pointer (2)]
⎜ ↳ PS/2 Generic Mouse id=15 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
    ↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
    ↳ Power Button id=6 [slave keyboard (3)]
    ↳ Fujitsu FUJ02E3 id=7 [slave keyboard (3)]
    ↳ Video Bus id=8 [slave keyboard (3)]
    ↳ Fujitsu FUJ02B1 id=9 [slave keyboard (3)]
    ↳ Fujitsu FUJ02BF id=10 [slave keyboard (3)]
    ↳ Power Button id=11 [slave keyboard (3)]
    ↳ USB Camera id=13 [slave keyboard (3)]
    ↳ AT Translated Set 2 keyboard id=14 [slave keyboard (3)]
archelon@ingelrayok:~$

Here's all the "Fujitsu" output from cat /proc/bus/input/devices:

I: Bus=0003 Vendor=0430 Product=0530 Version=0100
N: Name="Fujitsu Component USB Touch Panel"
P: Phys=usb-0000:00:1d.2-1/input0
S: Sysfs=/devices/pci0000:00/0000:00:1d.2/usb8/8-1/8-1:1.0/input/input5
U: Uniq=
H: Handlers=mouse0 event5
B: PROP=0
B: EV=1b
B: KEY=c03 1 0 0 0 0
B: ABS=3
B: MSC=10

I: Bus=0019 Vendor=1734 Product=0001 Version=0101
N: Name="Fujitsu FUJ02BF"
P: Phys=FUJ02BF/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/FUJ02BF:00/input/input6
U: Uniq=
H: Handlers=sysrq kbd event6
B: PROP=0
B: EV=100033
B: KEY=10000300000000 6000002000000 0 100000020000000
B: MSC=10
B: SW=22

I: Bus=0019 Vendor=0000 Product=0006 Version=0000
N: Name="Fujitsu FUJ02B1"
P: Phys=FUJ02B1/video/input0
S: Sysfs=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:1f/FUJ02B1:00/input/input7
U: Uniq=
H: Handlers=kbd ...

[Archelon (megapteryx)]

So now I've tried disabling the CTM in xrotate.py, and the results were not what I expected. First I commented out line 290 and uncommented line 292, then I removed my rotation scripts from the autorun fields in Magick Rotation Setup, then rotated the panel; the input was oriented incorrectly. To be precise, there were two pointers; one of them followed the stylus, and the other appeared offset from its position and proceeded to move diagonally, both pointers flickering all the while. When I held the stylus stationary against the screen, the position of the pointer alternated rapidly among three different points, one of which was near the correct one. Then I rotated the panel back to its normal position, and much the same behavior persisted, although with things moving in different directions. Then I rotated the panel again, and it seemed about the same; but this time when I returned it to its original orientation the alternating|flickering behavior was still present but the axes along which the 'extra' pointer moved appeared to have been swapped.

Then I thought to restore my rotation scripts (rotate.sh and unrotate.sh), commenting out only the line in each setting the CTM to the identity. I restarted the system, and the touchscreen input was initially correct (unrotate.sh runs at startup). I rotated the display again. This time, there was no flickering|jumping around the screen, but the pointer's movement appeared to be reflected in the long axis (i.e., the vertical axis when the screen is in the portrait orientation). (It moved correctly in the vertical direction.) After returning to landscape mode, the pointer's behavior was correct again.

Then I uncommented the line in each of my rotation scripts setting the CTM to the identity, and rotated the panel to portrait mode and back. The pointer's behavior was exactly the same as in the last paragraph.

So I decided to try commenting out the evdev Axes Swap lines. With both the CTM and Axes Swap lines commented out, the behavior was again exactly the same. To be sure, I decided to try restarting the system. But it remained the same. So I put everything back the way I had it before: the only way it works properly, with xrotate.py unaltered and with my three-line rotate.sh and unrotate.sh scripts. After doing that and rotating the display (which should execute xrotate.py and then rotate.sh), the pointer's behavior was *still* the same. So I tried restarting the system again. And then it was okay.

[Favux (favux-is)]

Thank you Archelon. We've learned a few important things from your output. The Fujitsu P1630 is indeed a tablet supported by Robert Gerlach's fujitsu-tablet.ko. The key line in 'xinput list' is: Fujitsu FUJ02BF id=10 [slave keyboard (3)] You correctly identified the udev rule and [DF] means either D or F. So there is a match to FUJ02BF. Which means the fujitsu-tablet.ko should enable your bezel buttons and declare the swivel hinge signal. And since it auto-rotated after you installed it we have confirmation. The udev rule establishes a input node that Magick read's in /dev/input which you should be able to see.

What was throwing me was you do not have a digitizer but instead a Fujitsu touch screen. I guess my thinking was canalized to expect a digitizer so I missed the obvious. I'm pretty sure this is the touchscreen: Fujitsu Component USB Touch Panel id=12 [slave pointer (2)] and not some sort of Synaptic style touchpad on the P1630. The first two sections from the cat apply to the P1630 and we see the usb touch screen's Vendor and Product ID are "Vendor=0430 Product=0530". Which gives us something to google with.

Trying to follow your next post made my brain hurt. My problem, I know you worked hard to describe the behavior. From "there were two pointers; one of them followed the stylus, and the other appeared offset from its position and proceeded to move diagonally, both pointers flickering all the while. When I held the stylus stationary against the screen, the position of the pointer alternated rapidly among three different points, one of which was near the correct one" I believe I recognize the problem as I have seen it before when using my test evdev lash up for Magick. The evdev X driver is not handling the touch panel correctly.

Googling doesn't indicate a current X driver for Fujitsu usb touch. You probably should look over the Fujitsu web site for a linux driver. I think they had their own linux driver and maybe some folks used evtouch. If true then evdev is suppose to be the driver now. Allegedly sometimes if you give evdev the correct coordinates that straightens things out. Googling I found people setting up P series tablets from a few years ago and think I have the touch screen's coordinates. Or it could be the kernel driver hasn't been updated to feed a recent evdev driver the correct translation of the raw usb data. The kernel driver is probably in hid section of the kernel. It is possible it is a problem with it (or a competing driver) not being correctly black listed or white listed. Working in the hid part of the kernel is tough because you may have to modify multiple modules. See this HOW TO for an indication: http://ubuntuforums.org/showthread.php?t=1946486

[Favux (favux-is)]

Assuming it is a coordinate issue we want some information on how evdev is seeing the touch screen. So run:
    xinput list-props "Fujitsu Component USB Touch Panel"
and post the output. Then run 'man evdev' and take a look. We'll want to create a custom Fujitsu P1630 .conf file in /etc/X11/xorg.conf.d and match to the touch screen, put it on the evdev driver, and then add the coordinates. It is possible we might want to apply some other options also. Then cross our fingers.

[Archelon (megapteryx)]

Yes, I should have realized that the "Fujitsu FUJ02BF" in the output of `xinput list`(and `cat /proc/bus/input/devices`) was what "ATTRS{name}=="Fujitsu FUJ02B[DF]" in 62-magick.rules refers to. I can in fact see the udev input node, /dev/input/magick-rotation (which is of course what the `xxd` command I quoted above is reading from).

I'm still confused as to whether this thing is a "digitizer" or not. Fujitsu says it is one. They've got these pdfs:

http://solutions.ca.fujitsu.com/pdf/notebooks/lifebook/p/p1630_en.pdf
http://solutions.us.fujitsu.com/www/content/products/notebooks/brochures/DS_p1630_UMTS.pdf

(these have pictures), and this page:

http://solutions.us.fujitsu.com/www/products_notebooks.shtml?products/notebooks/tech_specs/p1630_ts

which all say "Digitizer: Resistive (Passive)" ---and that's pretty much all the information I see anywhere about that.
I guess it's actually made by Fujitsu; they have several pages of these things linked from here:

http://www.fujitsu.com/us/services/edevices/components/touchpanels/

When I have more time I'll try and figure out which one it is. In any case I'm sure "Fujitsu Component USB Touch Panel" (id=12) is the touchscreen. This machine doesn't actually have a touchpad (instead it has a "pointing stick" in the middle of the keyboard).

"Vendor=0430" and "Product=0530" aren't helping me find anything, so far. (This page http://artisan.karma-lab.net/mandriva-et-netbook-fujitsu-u810 turned up and got me confused for a while into thinking it might be a Sun Microsystems product, but that doesn't appear to be correct.)

That stuff I wrote in #7 *is* pretty hard to read. The main thing that stands out, for me, is that it looks like issuing any `xinput set-prop` command, even just the one that sets the calibration values (i.e. property 260, Evdev Axis Calibration), changes the behavior of the pointer from flickering all over the screen to just being misoriented (as if by a wrong coordinate transformation). I also don't understand why I get the same (wrong) behavior no matter what proper subset of those commands I use, or why I need to restart in order to fix it.

Apparently Fujitsu did produce some Linux drivers for their USB resistive touch panels. This page is all I can find on their site:

http://www.fujitsu.com/us/services/edevices/components/touchpanels/drivers.html

It says:

    The current Linux driver releases can be used in the following environment:
    LINUX Kernel Version 2.6.5, 2.6.9, 2.6.11, 2.6.15, 2.6.18, 2.6.21
    XWindow Version "X.orgX11R6.7", "X.orgX11R6.8.1", "X.orgX11R6.8.2", "X.orgX11R7.0", "X.orgX11R7.1", "X.orgX11R7.2"
    The current Linux driver release was confirmed with the following LINUX distributors: Fedora Core2/3/4/5/6, Fedora 7.
    Linux drivers are available to our customers by request; please contact us for details.

I don't know whether it would do us any good to obtain these drivers.

I'll post the output of `xinput list-props "Fujitsu Component USB Touch Panel"` in a separate comment.

[Archelon (megapteryx)]

In landscape mode:

archelon@ingelrayok:~$ xinput list-props "Fujitsu Component USB Touch Panel"
Device 'Fujitsu Component USB Touch Panel':
        Device Enabled (131): 1
        Coordinate Transformation Matrix (133): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
        Device Accel Profile (255): 0
        Device Accel Constant Deceleration (256): 1.000000
        Device Accel Adaptive Deceleration (257): 1.000000
        Device Accel Velocity Scaling (258): 10.000000
        Device Product ID (248): 1072, 1328
        Device Node (249): "/dev/input/event5"
        Evdev Axis Inversion (259): 0, 0
        Evdev Axis Calibration (260): 109, 3918, 364, 3972
        Evdev Axes Swap (261): 0
        Axis Labels (262): "Abs X" (253), "Abs Y" (254)
        Button Labels (263): "Button 0" (252), "Button Unknown" (251), "Button Unknown" (251), "Button Wheel Up" (137), "Button Wheel Down" (138)
        Evdev Middle Button Emulation (264): 0
        Evdev Middle Button Timeout (265): 50
        Evdev Third Button Emulation (266): 0
        Evdev Third Button Emulation Timeout (267): 1000
        Evdev Third Button Emulation Button (268): 3
        Evdev Third Button Emulation Threshold (269): 20
        Evdev Wheel Emulation (270): 0
        Evdev Wheel Emulation Axes (271): 0, 0, 4, 5
        Evdev Wheel Emulation Inertia (272): 10
        Evdev Wheel Emulation Timeout (273): 200
        Evdev Wheel Emulation Button (274): 4
        Evdev Drag Lock Buttons (275): 0
archelon@ingelrayok:~$

In portrait mode:

archelon@ingelrayok:~$ xinput list-props "Fujitsu Component USB Touch Panel"
Device 'Fujitsu Component USB Touch Panel':
        Device Enabled (131): 1
        Coordinate Transformation Matrix (133): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
        Device Accel Profile (255): 0
        Device Accel Constant Deceleration (256): 1.000000
        Device Accel Adaptive Deceleration (257): 1.000000
        Device Accel Velocity Scaling (258): 10.000000
        Device Product ID (248): 1072, 1328
        Device Node (249): "/dev/input/event5"
        Evdev Axis Inversion (259): 0, 0
        Evdev Axis Calibration (260): 3979, 379, 122, 3924
        Evdev Axes Swap (261): 1
        Axis Labels (262): "Abs X" (253), "Abs Y" (254)
        Button Labels (263): "Button 0" (252), "Button Unknown" (251), "Button Unknown" (251), "Button Wheel Up" (137), "Button Wheel Down" (138)
        Evdev Middle Button Emulation (264): 0
        Evdev Middle Button Timeout (265): 50
        Evdev Third Button Emulation (266): 0
        Evdev Third Button Emulation Timeout (267): 1000
        Evdev Third Button Emulation Button (268): 3
        Evdev Third Button Emulation Threshold (269): 20
        Evdev Wheel Emulation (270): 0
        ...

[Favux (favux-is)]

Sorry I'm a bit distracted. Working on the next alpha of Magick 1.7, trying to deal with a few more issues.

Sorry, it is a digitizer. Just not one with high resolution like a Wacom or N-Trig. That's what I meant. From what you've found it appears Fujitsu has stopped developing a driver for linux, those are very old kernels. The coordinates in list-props don't look correct from what I remember but I have them in Precise and right now I'm in Raring. I'll have to check but that may mean we have something. You usually have to make that directory. I have no idea why. For more details see this wiki page: http://sourceforge.net/apps/mediawiki/linuxwacom/index.php?title=Xorg.conf.d Peter is an Xorg developer and he wrote part of it and edited my parts. So it is good info. from the horse's mouth so to speak. Just be prepared to edit the .conf file from Recovery mode if you break X.

My suggestion is that you open two threads on Ubuntu forums. One for the touch screen driver which looks like it is suppose to be evdev at this point. The other for the bezel buttons. You've got plenty of information to put in the first post of both threads. That way you'll get more eyeballs. I'll join in of course but the more help the better.

I'm planning on marking this bug as invalid because I don't believe the rotation issue is a Magick bug. I think it is due to the driver. Thoughts?