Re: [Linuxwacom-discuss] A Multi-Monitor Question

[Alexander R. <ale...@ro...>]

On 11/19/2009 10:16 PM, Alexander Roalter wrote:
> On 11/19/2009 10:03 PM, Alexander Roalter wrote:
>> On 11/19/2009 04:38 AM, Ping wrote:
>>> Please see my comments in line.
>>>
>>> Ping
>>>
>>> On Wed, Nov 18, 2009 at 2:46 PM, Alexander Roalter <ale...@ro...
>>> <mailto:ale...@ro...>> wrote:
>>>
>>>     After a long delay, I was finally able to update my X and other things,
>>>     and after removing a superfluous twinview option I forgot in the
>>>     keyboard section of the xorg.conf, I now can use the tablet (Graphire4),
>>>     and with xsetwacom set Stylus0 Screen_No n set it to different monitors.
>>>
>>>     I have three monitors side-by-side on a 1680+1680+1920 by 1080 large
>>>     desktop.
>>>
>>>     If I though start the gimp or inkscape and use the XInput capabilities,
>>>     I get the ordinary mouse arrow right where it belongs, but the drawing
>>>     is done as if the entire desktop was used (therefore drawing a perfect
>>>     circle on the tablet, I get an ellipse which is three times as wide as
>>>     it is high.
>>>
>>>
>>> Did you try the "KeepShape" option.  The problem is that your tablet has
>>> a different width and height ration with your screen. If you use
>>> KeepShape, don't forget your other mappings, such as topX/Y and
>>> bottomX/Y will not work any more.
>>
>> Ok, tested that and it was worse than before, since only a tiny fraction
>> of the tablet is used anymore, and the behavior in x-direction remains
>> the same, in y direction now I can only paint on roughly 1/3rd of the
>> height -> even more distortion.
>>
>>>
>>>
>>> Which linuxwacom are you running?  0.8.5-4 removes the duplicated
>>> devices for you automatically.  Any version older than that will give
>>> you two sets of devices if you have one defined in your xorg.conf.  You
>>> could disable the hotplugging one by modifying the wacom fdi file under
>>> /local/share/hal/fdi/policy/20thirdparty (10-linuxwacom.fdi on Fedora. 
>>> I am not exactly sure where the file is located on your platform.  The
>>> name could be different too.).
>>
>> Tried now 0.8.5-4, with kernel module also, still the same results.
>>
>> I removed the fdi file and am now working with my self-set up files in
>> /etc/X11/xorg.conf (Stylus0, Eraser0, Pad0); Still, a device "Wacom
>> Graphire4 6x8" (without " pad", " eraser" or " cursor" extension added
>> => before I had 4 of these devices, and I don't know where this device
>> is specified) is in the list, but there's no problem (apparently) with
>> it, so simply don't use it.
>>
>> Since the cursor is displayed always on the correct position (but the
>> arrows on inkscape's rulers don't), I assume this is probably an X
>> error/problem. xidump displays values from 0 to 16000 (roughly), and I'm
>> not sure who does the computing for the output into the different input
>> streams =>
>>
>> Does X11 receive only one data stream from the driver containing the
>> absolute coordinates (0-16000 in both directions, together with
>> pressure, tilt etc), or does X11 receive both the exact data (XInput?)
>> as well as preprocessed data it uses when not in XInput mode, which then
>> is used to place the normal cursor? At least that's what I think is
>> happening here:
>>
>>
>> driver =====Normal Input Channel =====> X11 (delivers coordinates from
>> 					0 to 1680, 0 to 1050 as well as
>>                                         pressed buttons when in absolute
>>                                         mode, -1..+1 in both directions
>>                                         when in relative mode.
>>
>> driver =====XInput Channel ==========> X11 (delivers coordinates from
>>                                         0 to 16384, 0 to 16384 and
>>                                        pressure and tilt and whatever
>>                                         else to X11.
>>
>> or is it different, and the XInput Channel already gets again data from
>> 0 to 1680 (or erroneously from 0 to 5280) to X11? If this is the case,
>> then it probably is a driver problem, but if X gets the original data
>> and does the computing by itself, then it's clearly an X problem (or the
>> Wacom driver for X, if any)
>>
> 
> Hm, it can also be a GTK problem (i don't have any non-gtk XInput aware
> apps), so this thread might help (and keep the blame off the wacom driver):
> 
> http://www.gimpusers.com/forums/gimp-developer/10806-xinerama-and-wacom.html
> 
> 

To finalize this, I've now been able to recompile GTK+ with a (modified)
patch, and now it's all working as expected *hooray*

it is all in gdk/x11/gdkinput-x11.c, line 455 (Version 2.18.3) and forth:


  if (gdkdev->info.mode == GDK_MODE_SCREEN)
    {
      int core_pointer_x, core_pointer_y, cur_monitor;
      GdkRectangle mon_geometry;
      GdkScreen *cur_screen;

      gdk_display_get_pointer(gdk_drawable_get_display(window),
                              &cur_screen,
                              &core_pointer_x,
                              &core_pointer_y,
                              0);
      cur_monitor = gdk_screen_get_monitor_at_point(cur_screen,
                              core_pointer_x,
                              core_pointer_y);

      gdk_screen_get_monitor_geometry(cur_screen,
                              cur_monitor,
                              &mon_geometry);
/*
      x_scale = gdk_screen_get_width (gdk_drawable_get_screen (window))
/ device_width;
      y_scale = gdk_screen_get_height (gdk_drawable_get_screen (window))
/ device_height;
*/
      x_scale = mon_geometry.width / device_width;
      y_scale = mon_geometry.height / device_height;

      x_offset = - impl_window->input_window->root_x - priv->abs_x;
      y_offset = - impl_window->input_window->root_y - priv->abs_y;
    }

Don't forget to compile gtk+ with --with-xinput=yes, otherwise there
will be no support for XInput altogether in GTK applications (GIMP,
Inkscape, ...)


-- 
Cheers,
Alex