GNOME Bugzilla – Bug 145430
Tablet Screen Rotation Problem
Last modified: 2018-02-10 03:20:24 UTC
I'm using gtk 2.4.3 and WinGimp 2.0.2 with the --use-wintab option in windows xp. I have a Toshiba Portege m200 tablet. In default regular laptop rotation mode, everything works fine. If the screen is rotated, gimp (or perhaps gtk) continues to register stylus movements as though still in regular laptop mode though the cursor (when not drawing/selecting/etc. on the screen) moves in orientation with the new screen orientation. So at 180 degree screen rotation, an upward movement of the stylus on the screen is recognized as down in gimp (and vice versa) and a right movement is left (and vice versa). At a 270 degree rotation (default portrait mode), up is right, right is down, down is left and left is up. So essentially the gimp continues to use the original screen orientation's directions even when screen is rotated. Sorry, I'm not sure how to explain it without drawing pictures. Thanks! (and thanks for the tablet pressure, it works great!)
I think this needs to be handled entirely in the driver or the lower-level GDK routines. Handling screen orientation definitely isn't GIMP's job so I am reassigning this to GTK+/GDK.
This can either be a problem in the GDK part of GTK+ or in the drivers for your hardware. The driver for my tablet doesn't support changing the orientation, so I can't test this myself, but I have asked another person with an Intuos tablet to test it after returning from vacation. In the meantime, there are some things you can do: - If you have access to some other drawing program that supports tablets, like Photoshop or Painter, see if it works correctly in that program. If it doesn't then it is almost certainly a problem with the drivers for your hardware. - Check the manufacturer's site if there are updated drivers available. This is boring old advice, but is worth giving a shot if you haven't already done it. - Check the manufacturer's web site, support forum etc. if other people have had similar problems.
*** Bug 172323 has been marked as a duplicate of this bug. ***
What's the progress on this bug, is there anything I can do to help? In answer to the above questions: - This is not a problem with driver since it works fine in Photoshop and Painter. - I updated the drivers yesterday. - Other people (from what I can tell on other forums) do have the same problem.
Thank you for answering the questions. As far as I know there hasn't been any progress on this bug since comment #2 was posted. What would be needed is a person who has this specific hardware, programming skills, and the time to figure out how to adjust the tablet initalization code in GTK+ so it takes into account the screen rotation. Or at least provide a code sample that shows how to make that tablet work properly when rotated and when using the Wintab API.
Given the appropriate pointers I might have the right programming skills, i certainly do have the hardware and free time too. Any suggestions where I might start looking?
Great! I suggest you start by downloading wtkit126.zip (Wintab SDK and C examples) and wt1pt1.zip (API specification) from http://www.pointing.com/FTP.HTM Compile and run one of the examples, for example SysPress, and see if it works correctly when you rotate your tablet. (I don't think it will...) If it doesn't work then you'll have to figure out what needs to be changed, how to determine the tablet rotation etc. I suggest you try to ask the manufacturer, see if there is additional documentation available, look for developer forums etc. I'm afraid I don't know anything about Tablet PC so I can't give any specific hints on where to find the info. At least for ordinary Wacom tablets there is a lot of info available from http://www.wacomeng.com/devsupport/index.html By starting with the simple test programs you can avoid the added complexity of compiling GTK+ at the beginning. If you can figure out how to change one of the test programs in a not too complicated way, it should be possible to then carry over the changes to GTK+.
This may be due to gtk picking up the screen geometry when it starts and not updating it when it changes. I think I've seen similiar problems when resizing the desktop via the display properties control panel, though I haven't really tracked it down so I could be wrong -- as always ;). The code is in gdkdisplay-win32.c.
JPE: If I understood Nicolas correctly the problem happens even if the orientation is changed before GIMP is started (see bug #172323). And as far as I can see GDK on Win32 actually handles resolution changes now (bug #151581).
You're right -- it seems that the issue here is input from the stylus.
To clarify: If Gimp is started whilst in portrait mode, the problem still occurs. Strangely enough, the problem is only there if input comes from the stylus. If it is from the mouse it behaves normally. Does this help us to pin down the issue?
The problem is probably that the stylus coordinates reported from the tablet through the Wintab API do not take into account the orientation. The mouse works because its coordinates are reported by another mechanism (regular windows messages, WM_MOUSEMOVE and friends). I think this is a bug/limitation in the drivers. Just because it works in Photoshop does not mean the drivers are bug free, and it is possible, even likely, that Photoshop has workarounds for bugs in various tablet drivers. It is also possible that Photoshop doesn't use the Wintab API for communicating with the tablet but instead uses the Inking API or similar. I believe the Inking API is the native API on Tablet PC, and Wintab is provided by a compatibility layer. There are precompiled versions of the test/example programs I mentioned earlier, available at http://www.pointing.com/Wintab/WT32X126.ZIP Try running the "syspress" program and draw on the gray area using your stylus. If it doesn't work correctly in portrait mode, we can blame the drivers. I then think the first action should be to ask whoever created the drivers that provide access to the Wintab API on your Tablet PC. Point them to the test programs and say it doesn't work in portrait mode and ask them to either fix the driver or say how to handle portrait mode through the Wintab API.
Syspress does not work in portrait mode, I'll contact Wacom and get back to you with results.
*** Bug 302435 has been marked as a duplicate of this bug. ***
The latest Wacom drivers for the TabletPC (4.92-4 downloaded from Wacom at http://www.wacom.com/tabletpc/driver.cfm) still exhibit this behaviour. Syspress doesn't work. Interchanging the X & Y channels in the Gimp device dialogue makes left/Right behave, but Up (still) = Down. In the Gimp the device status dialogue shows six WACOM devices in addition to the Core Pointer Wacom Tablet Puck Wacom Tablet ISD Stylus Wacom Tablet Eraser US Wacom Tablet Puck Wacom Tablet Pressure Stylus Wacom Tablet Eraser Stylus and switches between the Tablet ISD Stylus and Tablet Eraser US depending on which end of the stylus I present to the screen. If I use the original Microsoft drivers (or start Gimp with --ignore-wintab), then the only device that shows up is the Core Pointer. I think the Gimp (GTK+) see the updated WACOM drivers as if they were an external tablet, and doesn't see the pressure channel on the core pointer. I can interchange the X & Y Co-ordinates in the device settings for the Wacom devices this gets Left =Left but UP (still) = Down. I will contact Wacom and report back if I get any progress
Also reported for inkscape as http://sourceforge.net/tracker/index.php?func=detail&aid=1380883&group_id=93438&atid=604306
I am using the GTK+ 2.9? as well as the latest Wacom Tablet PC driver 4.94-3a and am experiencing the same problem. I have a HP Tablet PC model 4200.
same problem on a tc1100 here. as this bug seems to affect win xp tablet pc edition users only i suggest adding support for the ms inking api (InkCollector) and stop messing around with the over-aged wintab api. (especially since i'm afraid the existing wintab code is completely messed up. i've seen a wintab config dialog in inkscape featuring some 15 options NOT making it work versus no option at all in properly working photoshop and artweaver.) if there is someone working on this i'd like to join as part time tester/developer.
> i suggest adding support for the ms inking api (InkCollector) Great idea! When can we expect your patch? Nah, just being ironic, we don't necessarily expect ready-to-be-integrated code in the proper style to be submitted out of the blue. But if you want to help, it would be great if you at least could provide pointers to documentation, suitably licensed sample code, etc. Do you know if this "inking API" is available and usable on normal XP with a Wacom tablet? If not, I'm afraid it's going to be quite hard for me at least to test support for it, if such is added. Can we rely on you to test new DLLs if and when something is done about this? > and stop messing around with the over-aged wintab api. Hmm, isn't the greatest problem with Wintab that it has become involved in patent issues, sigh, and not its age as such? (And because of the patent issues other manufacturers than Wacom have stopped supporting it.) The Wintab API provides the features one needs, right? (Even if the implementations might have bugs...) Anyway, XInput is also quite old. > I've seen a wintab config dialog in inkscape featuring some 15 options There has been some fixes in the wintab code recently. Previously at least with Wacom tablets, all devices showed up duplicated to the upper levels. (As can be seen iin comment #15.) Is this part of the sillyness you noticed? This should be fixed in the upcoming GTK+ 2.10.10 for Wacom tablets. Inkscape presumably does not have any Wintab-specific code in it. It just uses GDK's platform-independent extended input device API, and shows the same dialogs, more or less, also on X11. Could you be more specific in what kind of useless config options it has? Presumably somebody has thought that the options are useful, at least on X11. If you feel differently, you should file a bug against Inkscape about it. Anyway, there is a separate bug for adding support for non-Wintab extended device APIs to gdk/win32, bug #343773. That is a more appropriate place for discussion and patches for the MS Inking API, actually.
ms tablet pc sdk enables development on win xp+wacom tablet. http://www.microsoft.com/downloads/details.aspx?familyid=4B14B74A-27E4-42C4-862F-273F6302EA4F&displaylang=en i could do testing at least one day each week (that could be thursday through sunday). coding by me would need some clear instructions on how to set up the necessary environment, and pointers to some initial code. (as i've never seen a line of gtk so far.) yes, wintab api provides the necessary features. the useless options are: 6 input devices to choose from, when there are max. 2 possible (pen/eraser). remapping x/y axis (but unfortunately no option to mirror, which in combination would work. but other programs detect all of this by themselves). 3 modes for each of the 6 devices where i can do nothing but guess what the right mode and the right device is. some more options (e.g. buttons) that i can't access as if i click on any control in the devices dialog every text in this dialog disappears - but that's another issue. and i don't care, so i just used --ignore-wintab so far and didn't file/comment bugs. i was just touched by the fact the inkscape people finally added another option (to disable wintab) which led to my original comment. i'd like to point out that there's another option (sigh!) we have: adding another (ouch!) option, to disable x/y tablet input (just use mouse coordinates) but keep pressure and device detection. this would possibly make all tablet pc users happy. otoh the ink api as far as i understand it is superior at least in providing sub-pixel resolution in contrast to wintab (again as far is i understand it).
sorry, the sdk link points to v1.5, see the bottom of the page for a newer version
> 6 input devices to choose from, when there are max. 2 possible (pen/eraser). that has been fixed recently and will be in gtk+ 2.10.10.
I installed the MS Tablet PC SDK (version 1.7) and then proceeded to try to have my Wacom ArtPad II being "emulated" as the pen on a Tablet PC. I found this page http://www.wacom.com/tabletpc/driver.cfm that says "This driver will support Ink on a desktop system that has the Tablet PC SDK installed. The Tablet PC SDK must be installed prior to installing the Penabled driver.", and as far as I can see, that's what I did. But no. I must have rebooted at least half a dozen times uninstalling and reinstalling either this Wacom driver, or the normal one, or trying having both at the same time. No success. Anyway, I haven't seen any mention of pressure sensitivity (not to mention pen tilt sensitivity) yet while cursorily browsing the Tablet PC SDK docs. Seems like the important points with Tablet PCs from Microsoft's point of view are handwriting and gesture recognition. But I guess I just need to read more carefully. Gee, seems like using the weird Tablet PC Automation API from plain C is going to be fun. I get the feeling I'm not too motivated to start hacking on this...
the plain c thing sounds frightening. my idea on this would be using c++ (the msdn has some c++ examples and api docs), and if the gtk+ codebase doesn't allow c++ for some reason add the precomplier's output. in general i'm not aware of an existing tablet pc that supports tilt or rotation. however, the api supports it: http://msdn2.microsoft.com/en-us/library/ms583840.aspx (requestable properties for inkcollector packet data) there's a free version of artrage 2 that makes use of the api and possibly has native support for tilt and rotation, on my tpc it emulates rotation by analyzing stroke direction, and tilt by providing a slider. however, for a first version collecting position and pressure (the default, as mentioned here: http://msdn2.microsoft.com/en-us/library/microsoft.ink.inkcollector.desiredpacketdescription.aspx) should do. here's example code (c# and vb): http://msdn2.microsoft.com/en-us/library/microsoft.ink.inkcollector.newpackets.aspx the api has different levels (including handwriting recognition at the higher end), but for our purpose the lowest (packet data) or second (strokes) should be sufficient. (step 4 or 5 of the InkOnly mode described here: http://msdn2.microsoft.com/en-us/library/microsoft.ink.collectionmode.aspx) as far as i can tell all painting apps i've seen capture strokes but this may be due to the fact the packet data was introduced in a later version of the api.
Just wanted to add that I am having the same problem on my MotionComputing table PC (windows XP). Maybe the patch would be easier to program if you just made a button on the toolbox to press when the screen changed instead of trying to reprogram the whole thing? Just a thought, as I know only a little about programing.
Good news! I just went to the Wacom site http://www.wacom.com/tabletpc/driver.cfm and downloaded the new driver which was released on April 12 (it says 4/12/07, so I'm assuming it's not 04 Dec 2007). And it works! I rotate my screen on my Tecra M4 tablet PC and the ink follows the pen and the pressure sensitivity works. Sorry, I was so elated, I didn't test tilt or other features, but... Also, it took a couple of tries, so some suggestions here. A - remove the old driver first! B - when the little wizard screens pop up, don't touch them. They'll go away on their own. You're done when a window comes up and specifically asks for a restart. Yay! It works.
One more little caveat - It won't work if you rotate your screen in mid-drawing-session. You have to close the drawing (don't even have to go out of GIMP!) and then re-open for it to work properly. But hey... am I bovvered!
i can confirm that the rotation is recognized with wacom's driver v5.05-5 on my tc1100. however, because of bug 154657 i can still not use the tablet features.
If anybody has time, could you please update this report by describing if this problem still happens in gtk+ 3.2 (or if 3.2 is impossible: in 3.0 or 2.24) and update this report by adding a comment and changing the "Version" field? Thanks a lot for your help.
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.