Open Bug 531320 Opened 15 years ago Updated 2 years ago

MouseEvent pressure does not work for drawing tablets on Linux

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

x86
Linux
defect

Tracking

()

People

(Reporter: ilmari.heikkinen, Unassigned)

References

Details

Attachments

(3 files, 1 obsolete file)

Mouse events fired by drawing tablets on Linux have a mozPressure of 0.0, regardless of the actual pressure.

The reason why this happens is two-fold:
 1. the extended input devices are disabled by default 
 2. GDK windows need to call gdk_input_set_extension_events to receive extended input events


To solve 1., extended input devices need to be enabled on app startup by calling gdk_device_set_mode(device, GDK_MODE_SCREEN). 

Note that calling that for the regular mouse will cause its event->x and event->y to be zeroes (I don't know why). And the regular mouse identifies itself as a pen device by default, so it's a bit tricky to detect.

Assuming that the regular mouse does not have a pressure axis, the initialization could be done by enabling only devices with a pressure axis:

for (GList *iter = gdk_devices_list(); iter; iter = g_list_next(iter)) {
    GdkDevice *device = (GdkDevice*)(iter->data);
    for (int i=0; i<device->num_axes; i++) {
        if (device->axes[i].use == GDK_AXIS_PRESSURE) {
            gdk_device_set_mode(device, GDK_MODE_SCREEN);
            break;
        }
    }
}

An alternative would be to have the user manually enable devices they want to use. Implementation would be a gtk_input_dialog_new -call in application settings, and saving & restoring thus obtained device modes from prefs on app startup.


To solve 2., each widget that wants to receive extended input events needs to call gdk_input_set_extension_events. I had success for content widgets by adding the following to /widget/src/gtk2/nsWindow.cpp:CreateGdkWindow:

gdk_input_set_extension_events (window,
                                GDK_POINTER_MOTION_MASK |
                                GDK_BUTTON_PRESS_MASK |
                                GDK_BUTTON_RELEASE_MASK,
                                GDK_EXTENSION_EVENTS_CURSOR);


For chrome, /widget/src/gtk2/mozcontainer.c:moz_container_realize should have a similar call:

gdk_input_set_extension_events (widget->window,
                                GDK_POINTER_MOTION_MASK |
                                GDK_BUTTON_PRESS_MASK |
                                GDK_BUTTON_RELEASE_MASK,
                                GDK_EXTENSION_EVENTS_CURSOR);


The above changes work on my system, debian testing, gtk+2.0 2.16.6-1, Xorg 7.3+18, xserver-xorg-input-wacom [from wacom-tools] 0.8.1.6-1

There's a strange input bug in GTK+ or X where to right mouse-button doesn't register after using the stylus, requiring a left-click or moving the mouse over a new widget to make right-click work again. Happens in GIMP and the GTK+ scribble-xinput.c example program as well.
Do you want this patch to be reviewed?
Reviewed, yeah I guess. 

There are two things I'm not all that sure about, though. The first is where to put the device mode sets (needs to be called on app startup). The second is that I'd really like to know that this doesn't break people's input handling. Because if there is some hypothetical mouse device with a pressure axis and it stops reporting x-y-coords after setting device mode to screen, it's going to break.

FWIW, here's what my GDK input axes look like:

Mouse0 has X
Mouse0 has Y

Cursor has X
Cursor has Y
Cursor has PRESSURE
Cursor has XTILT
Cursor has YTILT
Cursor has WHEEL

Stylus has X
Stylus has Y
Stylus has PRESSURE
Stylus has XTILT
Stylus has YTILT
Stylus has WHEEL

Eraser has X
Eraser has Y
Eraser has PRESSURE
Eraser has XTILT
Eraser has YTILT
Eraser has WHEEL

Core Pointer has X
Core Pointer has Y
Compile by doing
gcc `pkg-config --cflags --libs gtk+-2.0` -o xinput-list xinput-list.c
Attachment #414783 - Flags: review?(karlt)
Reason 1 is really bug 469756.  Unfortunately we'll need to sort out the
performance issues before we can fix this.  Perhaps minimizing the number of
extension events selected could help a little.  Those issues are even without
enabling any devices.  Perhaps the core pointer can have extension events
also?
Depends on: 469756
Re reason 2, the description of GtkInputDialog says,

"NOTE this widget is considered too specialized/little-used for GTK+, and will
 in the future be moved to some other package. If your application needs this
 widget, feel free to use it, as the widget does work and is useful in some
 applications; it's just not of general interest. However, we are not
 accepting new features for the widget, and it will eventually move out of the
 GTK+ distribution."

so we should probably find another means.

It seems to me that there should be some global means of selecting input
devices, rather than having to configure each app independently.

Enabling only devices with a pressure axis makes sense.

It doesn't seem right to me though to enable even devices that don't send
core pointer events.  Would it make sense to only enable devices that send
core events?
(I don't know how to get that information.)
Attachment #414783 - Flags: review?(karlt)
Blocks: 531466
This one lists the data in the GDKDevice struct, see http://library.gnome.org/devel/gdk/stable/gdk-Input-Devices.html

Output looks like this:

Device: Virtual core XTEST pointer
  Source: MOUSE
  Mode: DISABLED
  Has 0 keys and 2 axes.
  Axes: X Y 

Device: Wacom Intuos2 9x12 stylus
  Source: PEN
  Mode: DISABLED
  Has 248 keys and 6 axes.
  Axes: X Y PRESSURE XTILT YTILT WHEEL 

Device: Wacom Intuos2 9x12 eraser
  Source: ERASER
  Mode: DISABLED
  Has 248 keys and 6 axes.
  Axes: X Y PRESSURE XTILT YTILT WHEEL 

Device: Wacom Intuos2 9x12 cursor
  Source: CURSOR
  Mode: DISABLED
  Has 248 keys and 6 axes.
  Axes: X Y PRESSURE XTILT YTILT WHEEL 

Device: Microsft Microsoft Wireless Desktop Receiver 3.1A
  Source: MOUSE
  Mode: DISABLED
  Has 248 keys and 5 axes.
  Axes: X Y PRESSURE XTILT YTILT 

Device: Core Pointer
  Is the core pointer.
  Has cursor.
  Source: MOUSE
  Mode: SCREEN
  Has 0 keys and 2 axes.
  Axes: X Y
Attachment #414848 - Attachment is obsolete: true
Would this be a strong fingerprinting tool?
Component: Event Handling → User events and focus handling
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: