[PSA] X11: Turning on XI2.2 by default

[Sadrul Chowdhury]

Hello everyone.

Summary: we are going to turn on support for XInput 2.2 by default for
Linux. Among other things, XI2.2 has better [multi] touch-support, and
has been in use in ChromeOS for a while.

More details: we currently use the 'use_xi2_mt' gyp variable to turn
on XI2.2, which sets the USE_XI2_MT define. This define is used in the
following files:
ash/touch/touch_hud_debug.cc
ash/touch/touch_uma.cc
base/message_loop/message_pump_x11.cc
build/common.gypi
chrome/browser/chromeos/login/chrome_restart_request.cc
chromeos/display/real_output_configurator_delegate.cc
ui/aura/root_window_host_x11.cc
ui/base/touch/touch_factory_x11.cc
ui/base/touch/touch_factory_x11.h
ui/base/ui_base_switches.cc
ui/base/ui_base_switches.h
ui/base/x/device_data_manager.cc
ui/base/x/device_data_manager.h
ui/base/x/events_x.cc
ui/base/x/events_x_unittest.cc

This change shouldn't affect any developers (most linux distro, e.g.
Ubuntu precise, has support for XI2.2). If this does break the build
for someone, you can add 'use_xi2_mt=0' to your GYP_DEFINES, and that
should fix the build issue. The eventual goal though is to remove this
flag altogether, and cleanup the relevant code around USE_XI2_MT.

The CL is here: https://codereview.chromium.org/19486006/ I plan on
landing it over the weekend.

Sadrul

[Jun Mukai]

Hi,

I got bunch of X11 error outputs when running aura_unittests and ash_unittests:

X Error of failed request:  BadImplementation (server does not implement operation)
  Major opcode of failed request:  131 (XInputExtension)
  Minor opcode of failed request:  46 ()
  Serial number of failed request:  26

It disappears with use_xi2_mt=0, so I suspect the XI2.2 would cause this.

The test result seems not changing, but this is a bit annoying.  Are there some plans to deal with this?

Note: I'm running those tests through chromoting remote desktop.

-- Jun Mukai

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
    http://groups.google.com/a/chromium.org/group/chromium-dev

[Wez]

Sounds like the Xvfb server that Chrome Remote Desktop uses has an incomplete XInput implementation. I wonder if there's an XInput features flag somewhere that Chromium should be checking before calling certain APIs?

[Lambros Lambrou]

I checked the output of "xdpyinfo -ext XInputExtension" on the console Xorg server and on the Xvfb server (Ubuntu Precise). They both show version 2.2 for this extension. So I don't know why Xvfb would be reporting these failures but not Xorg - they're both built from the same source package.

[Peter Mayo]

A bunch of the bots will still be using an Xvfb from before precise, built after lucid in order to handle xinput better than lucid could.

Perhaps it is time to retire that mechanism?  If so, ping me.

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

--

Peter Mayo |

Waterloo |

pete...@google.com |

519-880-3439

[Paweł Hajdan, Jr.]

I definitely recommend just running xvfb-run, and using older-than-system software is really not recommended.

Paweł

[Peter Mayo]

The Xvfb on lucid is absolutely inadequate, so using system software is only an option once all testers are off it.

Have we gotten to that point?  I looked at the new crimson-db, but it does not look complete, and I didn't see a success email on the big lucid cover bug (https://code.google.com/p/chromium/issues/detail?id=170262)  In fact I still see many open sub-bugs and dependent ones, so without clicking through all of them, it looks like we still have a ways to go.

Filed https://code.google.com/p/chromium/issues/detail?id=293883 to record the dependency, status and work.

Another option (only if necessary) is to recompile a sufficiently new package to include the required APIs, and replace the ancilary one with that.

Peter.

[Victor Khimenko]

On Wed, Sep 18, 2013 at 4:54 AM, Peter Mayo <pete...@google.com> wrote:

The Xvfb on lucid is absolutely inadequate, so using system software is only an option once all testers are off it.

Have we gotten to that point?  I looked at the new crimson-db, but it does not look complete, and I didn't see a success email on the big lucid cover bug (https://code.google.com/p/chromium/issues/detail?id=170262)  In fact I still see many open sub-bugs and dependent ones, so without clicking through all of them, it looks like we still have a ways to go.

You can not even build Chromium on Lucid and I see no complains which probably means that Licud bots are history:

https://groups.google.com/a/chromium.org/d/msg/chromium-dev/p5AT0X3LLCQ/Tr1i_c_mfI0J