Open Bug 1207700 Opened 6 years ago Updated 6 months ago

Use XInput 2 device manager on GTK3

Categories

(Core :: Widget: Gtk, defect, P2)

Unspecified
Linux
defect

Tracking

()

REOPENED
81 Branch

People

(Reporter: acomminos, Assigned: stransky)

References

(Depends on 2 open bugs, Blocks 2 open bugs)

Details

(Whiteboard: tpi:+)

Attachments

(1 file)

We had to disable XI2/multidevice support in bug 1170342 due to focus and scrolling related issues. We should monitor these issues to see if it would be possible to re-enable XI2 in the future.
See Also: → 1207973
Blocks: gtk3
Please add option to reenable via about:config or something - I'm really got used to it...
(In reply to Kuba Niewiarowski from comment #1)
> Please add option to reenable via about:config or something - I'm really got
> used to it...

Just set MOZ_USE_XINPUT2=1 env variable which enables it in Firefox.
(In reply to Martin Stránský from comment #2)
> Just set MOZ_USE_XINPUT2=1 env variable which enables it in Firefox.

Not working...
I'm using Aurora builds from https://launchpad.net/~ubuntu-mozilla-daily/+archive/ubuntu/firefox-aurora
MOZ_USE_XINPUT2=1 is in Nightly (bug 1207973) but not yet in Aurora.
Duplicate of this bug: 1234005
Severity: normal → enhancement
Priority: -- → P3
Whiteboard: tpi:+
Blocks: 1321069
Using "MOZ_USE_XINPUT2=1" &e10s worked for me (https://bugzilla.mozilla.org/show_bug.cgi?id=1268599#c10), but not very smooth (scrolling, afterwords opening the menu item, then trying to scroll results in an un-scrollable page). Fedora already compiles FF with "MOZ_USE_XINPUT2=1", which is very smooth on my tablet.

However, it would be interesting how this is handled by Firefox for Android, which clearly needs touch support and XINPUT2.
No longer blocks: 1321069
Depends on: 1321069
Duplicate of this bug: 1390130
I think we can enable the XInput2 for recent Gtk+ versions (say Gtk+ >= 3.20) as the related Gtk+ focus bugs was fixed but for XInput2 only. Also Fedora enables XInput2 by default and we don't have any user complains.
Assignee: nobody → stransky
Severity: enhancement → normal
Priority: P3 → P2
Before the switch we need to address Bug 1182700. Bug 1170342, Bug 1196777 should be fixed for reasonable recent systems.
For Bug 1182700 looks like gnome folks gave up (https://bugzilla.gnome.org/show_bug.cgi?id=750994#c8) and recommend to use Wayland. I wonder how big complication is it and if benefits from enabled xinput2 outweigh it, especially when the focus bugs should be fixed on recent systems.
Gnome issue 750994 has been migrated to their Gitlab instance:
https://gitlab.gnome.org/GNOME/gtk/issues/558
Duplicate of this bug: 1597218
See Also: → 1601850

Is there any possibility of enabling this soon? Out-of-the-box Firefox is unusable with touchscreens, and as touchscreens become more common (e.g. I just upgraded my laptop to one that has a touchscreen), having this enabled quickly becomes quite important for a large number of users. Also, https://bugzilla.mozilla.org/show_bug.cgi?id=1182700 was just fixed in Kwin, and AFAIK that was the last blocker of this bug.

Also, AFAIK, Fedora enables MOZ_USE_XINPUT2 by default for these reasons, so apparently it's not too buggy :P

After some more thinking, it would probably make sense to enable it by default but disable it for KWin < 1.19.3, so those users don't get hit by the bug.

(In reply to QwertyChouskie from comment #13)

Also, https://bugzilla.mozilla.org/show_bug.cgi?id=1182700 was just fixed in Kwin, and AFAIK that was the last blocker of this bug.

Based on comment 10, it sounds like Gnome is affected as well, and the issue is not fixed there?

I am unable to reproduce using the steps in https://bugzilla.gnome.org/show_bug.cgi?id=750994#c0 with my laptop's touchpad, tested on Gnome Shell 3.36 (Ubuntu 20.04). I tried the same steps with FF and also can not reproduce it there. I suspect the bug was mitigated/had its impact lessened (perhaps unintentionally) in Gnome at some point, which then left the issue for KDE users (as per most of the comments in https://bugzilla.mozilla.org/show_bug.cgi?id=1182700).

(Also FYI, the KWin fix was just backported to the 5.18 series, so it should be fixed in the next 5.18.x point release, meaning Ubuntu 20.04 and its derivatives should get this fix soon.)

Martin, WDYT? Based on the above info, should we enable XInput 2 for KWin >= 5.19.3 (and >= 5.18.next)? How about other window managers?

Flags: needinfo?(stransky)

(In reply to Botond Ballo [:botond] from comment #18)

Martin, WDYT? Based on the above info, should we enable XInput 2 for KWin >= 5.19.3 (and >= 5.18.next)? How about other window managers?

Fedora has used XINPUT2 by default for five years and I don't have any reports so I guess it's okay to enable it for recent systems, at least for KDE/Gnome.

Flags: needinfo?(stransky)

(In reply to Martin Stránský [:stransky] from comment #19)

Fedora has used XINPUT2 by default for five years and I don't have any reports so I guess it's okay to enable it for recent systems, at least for KDE/Gnome.

Thanks!

(As this bug is assigned to you, I assume you'll write the enablement patch, but please let me know if you'd like me to.)

Pushed by abutkovits@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6c7f2177e485
[Linux] Enable XInput2 on Gtk 3.24 and newer, r=botond
Status: NEW → RESOLVED
Closed: 8 months ago
Resolution: --- → FIXED
Target Milestone: --- → 81 Branch
Depends on: 1660212
Regressions: 1661219
Regressions: 1661770

Let's revert that in Bug 1660212.

This bug should probably be reopened since the change was completely reverted.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
You need to log in before you can comment on or make changes to this bug.