GNOME Bugzilla – Bug 145467
Stylus tablet does not work across multiple monitors
Last modified: 2011-02-04 16:16:16 UTC
Stylus tablet cursor cannot move across 3 monitors, only 2 and the cursor is offset when moved from left to right. Only works on 2nd and 3rd monitor, the cursor becomes more offset as the cursor moves from the 2nd monitor to the 3rd. The cursor cannot move to the 1st monitor at all. (tech details warning) gdk_input_translate_coordinates() in gdk/win32/gdkinput-win32.c uses GetSystemMetrics(SM_CXSCREEN) to calculate scale factors, but this returns the width of the screen of the primary display monitor which is probably not correct for a multi-monitor system. Maybe one should use SM_CXVIRTUALSCREEN instead (but not on Win95) and similar for SM_CYSCREEN. It probably should the dimensions of the "root window" (_gdk_parent_root) instead. That is the GdkWindow that covers all the monitors. (end tech details)
The Stylus pressure works fine, but the Stylus Cursor not following the mouse cursor accurately is the biggest problem, especially across multiple screens. Check for more details at http://groups.yahoo.com/group/gimpwin-users/messages look for Subject: "Tablet Issues"
I can reproduce this problem and it should definitely be fixable by some small changes to gdk_input_translate_coordinates. I don't think one can use the dimensions of _gdk_parent_root since gdkdisplay-win32.c currently only gets the working area (excludes the taskbar) instead of the whole screen for the primary monitor, which could get the scaling factors wrong. I have tested changing to SM_C{X,Y}VIRTUALSCREEN, and added SM_{X,Y}VIRTUALSCREEN to the offsets, and it seems to work, but I need to clean it up so it works on old systems (Win95) which don't have those constants. I will attach a patch for the source code in a few days if I don't find any serious problems with this approach.
Created attachment 30121 [details] [review] Patch for multi-monitor tablet support Here is a patch for the gtk-2-4 source code that makes the tablet work on multiple monitors for me. I have only tested it on Windows XP using a Wacom Graphire 3 USB tablet (driver version 4.78-6). On that system, it works when the secondary monitor is placed above and to the left of the primary monitor, and when it is placed to the right and below. It also works to restrict the tablet to a single monitor in the Wacom Tablet properties dialog in the Control Panel. Hopefully it works on other systems too. Mr. buttknock1, unless you compile GTK+ yourself, you will probably have to wait until a binary distribution is available of the next GTK+ bugfix release (that is, if the patch is accepted by the maintainers). Thanks for reporting the bug!
Once again, thanks Robert! (If you feel like asking for CVS commit privileges, tell them I am all for it.) Might it be a good idea to store the SM_C{XY} VIRTUALSCREEN values in global variables in _gdk_windowing_window_init() instead of calling GetSystemMetrics() from gdk_input_translate_coordinates()?
(Sorry for not answering immediately, Tor, I must have missed your last message somehow) Saving those values in global variables should definitely save some cycles. I can revise the patch in a few days. (One future enhancement would then be to handle the WM_SETTINGCHANGE message and reload such cached information so the user doesn't have to restart the application if display settings are changed. This would apply to other parts of GDK as well.) Regarding commit access it is a great honour to me that you think I am ready for it. Thanks! I think I'll wait a little while before asking for it, amongs other things I don't know yet how much spare time I'll have available the next few months.
This is Mr. buttknock1 glad to here this is getting solved, I'll finally be happy to work more with the GIMP on my system once binaries are available for windows. Thanks guys for looking into this!
Created attachment 30301 [details] [review] Revised patch for wintab multi-monitor support Here is an updated patch, which stores the screen size and offset once and uses the stored values when translating coordinates. I put everything in gdkinput-win32.c since I thought it would be confusing to have another set of gdk-global variables for screen size and offset in addition to _gdk_offset_{x,y} and _gdk_parent_root. If you think it belongs in _gdk_windowing_window_init instead, I can change that, or you can just rewrite it the way you want, I wouldn't mind.
Tor, have you gotten any time to look at my revised patch? If so, do you want me to change any aspects of it?
Not really looked at it yet, will do during the weekend. Thanks!
BTW, I don't really remember any longer why the GDK root window (on the primary monitor) is set to not include the taskbar's area. Maybe we should drop this, and just let applications open windows that are obscured by the taskbar if they insist? Maybe just put some fix in the fullscreen code to avoid the taskbar?
I just tried a very quick hack to use the whole screen even on the primary monitor. The biggest problem I could see is that dialog boxes are no longer centered on the working area but on the entire screen, which can easily be seen by making the taskbar ridiculously high. Maximizing windows works OK, i.e. they are correctly sized to cover the working area but not the taskbar, probably because GDK lets Windows handle that itself.
The use of SPI_GETWORKAREA also causes this problem: gdk_screen_get_root_window () returns the _gdk_parent_root. If you then call gdk_drawable_get_image() on this, the coords are refer to the origin of the desktop, not the origin of the work area (which differ in case the taskbar is at the top or left). This can be seen for instance in gtk-demo's color selector test: Put the taskbar on the left, make it non-auto-hide, click on the eyedropper and then click somewhere. The color you get is offset from where you clicked by the taskbar's width... Hans, I think the use of SPI_GETWORKAREA to get the root window's (later primary monitor's) dimensions is your idea originally. Up to version 1.14 of gdkwindow-win32.c there is a comment: "//HB: don't obscure tray window (task bar)" at the place where it uses SystemParametersInfo(SPI_GETWORKAREA) to get the root window's size. Do you remember what made you use change it to use that instead of GetSystemMetrics(SM_C{X,Y}SCREEN)? I think we should indeed forget the SPI_GETWORKAREA, let the "root window" cover the whole actual desktop, and handle any problems that might crop up separately.
Created attachment 30554 [details] [review] Trivial patch to include wll of the desktop in the GDK root window
Tor, regarding the gdk_drawable_get_image problem (isn't that the problem describe d in bug 149013?), are you sure that is not caused by forgetting to add/subtract _gdk_offset_{x,y} somewhere? Will it work on multi-monitor systems?
Yes indeed, bug #149013 seems to be the same as what I was talking about. Offsetting coordinates with _gdk_offset_{x,y} in some suitable place probably would work, yes. But still, what do we actually win by excluding taskbars (and Office's toolbars etc?) from the GDK root window?
The size of the root window should not matter, and I would definitely prefer if it covered all of the primary monitor. I would say that an application that depends on the size of the root window is broken as parts of the root window may not belong to any monitor if one has two monitors with different heights for example. The advantage of the current code is that gdk_screen_get_monitor_geometry for the primary monitor returns the working area so that dialog boxes are centered on the working area. It is not perfect since it only considers the working area on the primary monitor, but each monitor can have a working area (MONITORINFO.rcWork) that is smaller than the entire area of the monitor (rcMonitor). I don't know why the current code doesn't use rcWork, but it should be simple to change enum_monitor so that it uses it on all monitors. What do you think about changing the dimensions of the root window so it doesn't exclude taskbars, for example by setting the size to SM_C{X,Y}VIRTUALSCREEN if available, while letting the monitor rectangles (_gdk_monitors) be working areas? One could also make sure that _gdk_offset_{x,y} never becomes negative (if the taskbar is on top of the screen) to partially fix bug #149013, though the correct solution should be to use _gdk_offset_{x,y} in all places where it is needed. Otherwise things won't work when there is a monitor to the left or above the primary monitor.
IIRC the SPI_GETWORKAREA hack was to prevent some of The GIMP's confirmation dialogs to be under the taskbar (at least their buttons). But nowadays there has changed so much in the window positon handling, that it may be time to try something new ;-)
> What do you think about changing the dimensions of the root window so > it doesn't exclude taskbars, for example by setting the size to > SM_C{X,Y}VIRTUALSCREEN if available, while letting the monitor > rectangles (_gdk_monitors) be working areas? I think that would be a bit confusing, and not what applications expect. I am tempted to go ahead and drop the SPI_GETWORKAREA stuff, and hope that any hopefully minor new problem it causes will be soon noticed and fixed. The X11 backend doesn't seem to currently look at the _NET_WORKAREA property, which I think corresponds to SPI_GETWORKAREA. (See http://freedesktop.org/Standards/wm-spec/wm-spec-1.2.html#id2444515) Maybe later some API will be added to GDK and/or GTK that needs to know the location and size of taskbars semi-permanently attached to monitor edges.
OK, SPI_GETWORKAREA now dropped from CVS code (HEAD and gtk-2-4). Robert, could you rework your patch to use the _gdk_parent_root dimensions?
Certainly, I'll try to do it today or tomorrow.
Created attachment 30838 [details] [review] Patch for wintab multi-monitor support v3 Here is an updated patch against gtk-2-4. Tested in the same way as before.
Thanks. Patch applied to HEAD and gtk-2-4.
Was this patch applied to the new GTK+ binaries put up on Jernej Simoncic's GIMP for Windows page version 2.4.7?
Presumably not. Have patience.
thanx for the info, I'll test it as soon as it's available and post my findings here.
I downloaded the files on your page Tor and overwrote the GTK and GLIB files I had from my previous GTK+ installation, but so far nothing has changed. Am I doing something wrong? Do I need to install the files a certain way or can they just be overwritten?
Overwriting the files should work, I just tested using the gtk+-2.4.9-20040903.zip file from Tor's page, and my tablet seems to work fine across two monitors when using those binaries. There are two possibilities: 1. You somehow made a mistake when uncompressing the files so the binaries were not placed in the correct directories. Check the date of the libgdk-win32-2.0-0.dll file in the c:\program files\gtk...whatever...\bin directory, it should be 2004-09-03. You could try searching you harddrive(s) for files with that name to make sure there isn't another copy somewhere. 2. There is some remaining bug in GTK+ or possibly a problem with your tablet driver or something. You could try generating some debug messages, which may help us point out the problem. Follow these steps: 1. Close GIMP if you have it running 2. Start a command prompt (Start - Run - type in cmd.exe and click OK) 3. Type the following on one line and press Enter: "C:\Program Files\GIMP-2.0\bin\gimp-2.0.exe" --use-wintab --gdk-debug=input:misc > C:\gimplog.txt 4. GIMP should start. After it has started completely, just close it again. 5. Attach the gimplog.txt file to this bug. The file may get quite big, and it is only the first few pages that contain relevant information, so you can either open it in a text editor like wordpad and cut it off after a few pages, or compress it, for example with WinZip. If you have installed GIMP in a different location, then adjust the path accordingly. If you are using Windows ME or 98, use command.com instead of cmd.exe
Created attachment 31697 [details] gimplog.txt
Still no go on it, I did everything you have mentioned and nothing has changed. Look above at the gimplog.txt file to see if you see something fishy. Thanks for your help in this Robert.
I don't see anything suspicious in your log file, except that it might be incorrect to hardcode lcSysOrgX and lcSysOrgY to 0 as GTK+ currently does. My tablet driver seems to ignore that value, maybe yours doesn't. Has the behavior of the tablet cursor changed in any way since you changed to the new GTK+ binaries? In particular, is the offset between the system cursor and the GIMP tool cursor constant, or does it change, as you move the cursor horizontally? Does it work OK in the vertical direction? If the offset is constant then a likely explanation would be the lcSysOrgX value. Otherwise it is some other error.
Ok, in the vertical direction it is aligned ok, however the cursor is offset from the brush by a large amount horizontally, but it is constant in terms of movement in both directions now. However, when I switch it from screen to window, the cursor is closer to the brush, but the movement is not constant in either direction and it is gradually moving further out from left to right.
The hard-coding of lcSysOrgX sounds like a likely explanation based on your latest description. It should be simple to attempt a fix for that. Reopening this bug. Window mode gives cursor offset even on a single-monitor system. I think that it simply is wrong to use system tablet context in window mode, but it is probably not that easy to fix. Use screen mode.
Created attachment 31739 [details] [review] Patch for setting lcSysOrgX,Y from device Here is a patch for the gtk-2-4 source that changes the setting of lcSysOrgX and lcSysOrgY. As my tablet driver ignores the value of those fields I can only test that this patch doesn't seem to break anything for me. I think it should be fairly safe.
I'll test it as soon as the binaries are available. Thanx again Robert.
oh, one more thing, the cursor still doesn't move onto the 1st screen at all. Only the ones connected to the Nvidia card. The 1st one is connected to the onboard ATI Rage I have. I think you can see that in the gimplog.txt It works on the 1600x1200 and one of the 1024x768's but not the other one. I'm not sure if this can be solved or not, but it sure would be nice to have the program access all 3 screens via the tablet. With the mouse it's fine, however the stylus sticks to only the 2 screens.
That is the same problem. Isn't the cursor offset 1024 pixels to the right in the horizontal direction, i.e. the width of the leftmost monitor? According to the Wintab spec document from www.pointing.com, lcSysOrgX and lcSysOrgY "Together specify the origin of the screen mapping area for system cursor tracking, in screen coordinates". Now, on a multi-monitor Windows system, (0,0) is the upper left corner of the primary monitor (for compatibility) so x coordinates on the monitor that is to the left of the primary monitor are negative. If one looks at the log file you attached, lcSysOrgX is -1024 for the default system context, which should correspond to the leftmost pixel column on the leftmost monitor, but then we reset it to 0 before opening the tablet device. That should offset the system cursor 1024 pixels to the right if my guess is correct. The spec actually says that CTX_SYSORGX and CTX_SYSORGY "each return 0", but as the one I'm lookin at is dated May 9 1996, it was not written with multi-monitor systems in mind, and your tablet driver definitely returned a nonzero value (-1024).
Created attachment 31791 [details] libgdk-win32-2.0-0.zip (only for testing, use on your own risk).zip If you want to test this immediately, I attach a zipped libgdk-win32-2.0-0.dll (compiled yesterday from latest gtk-2-4 sources from CVS plus the patch above). Note that I accept absolutely no responsibility for anything that might happen if you choose to test it, so do not feel pressured to test it. If you are unsure, wait for new binaries from Tor. To test, extract the libgdk-win32-2.0-0.dll file into the GTK+ bin directory, but make sure to make a copy of the existing file with the same name first. Restore the original file after testing. If you test it, and it doesn't work, please generate a new gimplog.txt as described above (with the test dll still in place) and attach it here. I recommend that you don't use the attached file for any serious work, but only for testing this bug. Do not submit bug reports for any other bugs while using this file. I don't expect anything bad to happen, the attached file works just fine on my system. Still, use it on your own risk!
Comment on attachment 31791 [details] libgdk-win32-2.0-0.zip (only for testing, use on your own risk).zip You may have to rename the downloaded file to something that ends in .zip
That did it! But I got an error that popped up in a DOS window: (gimp-2.0.exe:3672): Gdk-CRITICAL **: file gdkinput-win32.c: line 1261 (gdk_devi ce_get_state): assertion `input_window != NULL' failed (gimp-2.0.exe:3672): Gdk-CRITICAL **: file gdkinput-win32.c: line 1261 (gdk_devi ce_get_state): assertion `input_window != NULL' failed Otherwise my tablet is working perfect now! Thank you Robert!
Great! Thanks for testing. Now we know my guess was correct. Those two error messages are caused by bug #141543 and can be ignored, just minimize the console window that shows up. Tor, could you please commit the suggested patch (31739) when you have time, unless you remember any reason to hard-code lcSysOrg* that way?
Thanks again, Robert. Patch committed to HEAD and gtk-2-4.