Bug 107358 - Some X11 clients can grab mouse and keyboard which make impossible to work with another X11 clients
Summary: Some X11 clients can grab mouse and keyboard which make impossible to work wi...
Status: RESOLVED MOVED
Alias: None
Product: Wayland
Classification: Unclassified
Component: XWayland (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Wayland bug list
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-07-24 11:28 UTC by mikhail.v.gavrilov
Modified: 2019-05-10 15:54 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Simple repruder showing normal behavior with grabs (2.32 KB, text/plain)
2018-07-25 14:08 UTC, Olivier Fourdan
Details

Description mikhail.v.gavrilov 2018-07-24 11:28:26 UTC
When I launching the game "A Story of a Band" mouse control stop working in all XWayland applications

Here this game: https://store.steampowered.com/app/856450/
If you want I can make gift for helping fix this issue if you add me as friend in steam store.

$ inxi -bM
System:    Host: localhost.localdomain Kernel: 4.18.0-0.rc5.git4.1.fc29.x86_64 x86_64 bits: 64 
           Desktop: Gnome 3.29.4 Distro: Fedora release 29 (Rawhide) 
Machine:   Type: Desktop System: Gigabyte product: Z87M-D3H v: N/A serial: <root required> 
           Mobo: Gigabyte model: Z87M-D3H serial: <root required> UEFI: American Megatrends v: F11 
           date: 08/12/2014 
CPU:       Quad Core: Intel Core i7-4770 type: MT MCP speed: 3762 MHz min/max: 800/3900 MHz 
Graphics:  Card-1: Advanced Micro Devices [AMD/ATI] Vega 10 XT [Radeon RX Vega 64] driver: amdgpu v: kernel 
           Display: wayland server: Fedora Project X.org 11.0 driver: fbdev,modesetting,vesa 
           resolution: 3840x2160~60Hz 
           OpenGL: renderer: Radeon RX Vega (VEGA10 DRM 3.26.0 4.18.0-0.rc5.git4.1.fc29.x86_64 LLVM 6.0.1) 
           v: 4.5 Mesa 18.1.4 
Network:   Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet driver: r8169 
Drives:    Local Storage: total: 14.77 TiB used: 4.16 TiB (28.2%) 
Info:      Processes: 495 Uptime: 15h 17m Memory: 31.29 GiB used: 26.83 GiB (85.7%) Shell: bash inxi: 3.0.18 


$ rpm -q xorg-x11-server-Xwayland
xorg-x11-server-Xwayland-1.20.0-5.fc29.x86_64
Comment 1 Olivier Fourdan 2018-07-24 12:01:16 UTC
I take it that the pointer works fine for all other Wayland clients.

Can you please provide the output of "xinput list" when the issue occurs?

Do you see any MotionNotify events when hovering the "xev" window, ButtonPress/ButtonRelease events when clicking inside the "xev" window?

Can you reproduce with another Wayland compositor such as "weston"?
Comment 2 mikhail.v.gavrilov 2018-07-24 15:03:19 UTC
(In reply to Olivier Fourdan from comment #1)
> I take it that the pointer works fine for all other Wayland clients.
yes, gnome-terminal not affected.

> Can you please provide the output of "xinput list" when the issue occurs?
Before game launch
$ xinput list
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ xwayland-pointer:15                     	id=6	[slave  pointer  (2)]
⎜   ↳ xwayland-relative-pointer:15            	id=7	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ xwayland-keyboard:15                    	id=8	[slave  keyboard (3)]

After game launch
$ xinput list
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ xwayland-pointer:15                     	id=6	[slave  pointer  (2)]
⎜   ↳ xwayland-relative-pointer:15            	id=7	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ xwayland-keyboard:15                    	id=8	[slave  keyboard (3)]

> Do you see any MotionNotify events when hovering the "xev" window,
> ButtonPress/ButtonRelease events when clicking inside the "xev" window?
How check this?

> Can you reproduce with another Wayland compositor such as "weston"?
Under "weston" this issue not happens, but under "weston" I don't see the game (I hear only music from splash screen)
Comment 3 mikhail.v.gavrilov 2018-07-24 15:11:11 UTC
> Do you see any MotionNotify events when hovering the "xev" window,
> ButtonPress/ButtonRelease events when clicking inside the "xev" window?
oh sorry, understand.

When the game is running not any MotionNotify events are displayed when I hovering "xev" window and also ButtonPress/ButtonRelease events not happens.
Comment 4 Olivier Fourdan 2018-07-25 12:39:55 UTC
Soorry, something's unclear, are the controls restored if you quit the game/close the window?
Comment 5 mikhail.v.gavrilov 2018-07-25 13:05:48 UTC
(In reply to Olivier Fourdan from comment #4)
> Soorry, something's unclear, are the controls restored if you quit the
> game/close the window?

yes of course
Mouse control not available only at a time when the game is running.
Comment 6 Olivier Fourdan 2018-07-25 14:08:23 UTC
Created attachment 140812 [details]
Simple repruder showing normal behavior with grabs

(In reply to mikhail.v.gavrilov from comment #5)
> yes of course
> Mouse control not available only at a time when the game is running.

Then it's just that the games issues an grab on the pointer...

Xwayland is a Wayland client but also an Xserver, which behaves like any other Xserver for the X11 clients, so if a client (the game) issues an acive pointer grab on the pointer, no other X11 cleitns will receive pointer events, that's the purpose of a grab.

However, ther eis no active grabs in Wayland, so other Wayland native clients are not affected by the X11 grab issued by the X11 cleints, which matches exactly what you describe.

To demonstrate that, I attached a very simple reproducer written in gtk2.

If you compile and run that reproducer on Wayland/Xwayland, it will bejave the same, no other X11 client wil lreceive pointer events as long as the client is running, whereas other Wayland native clients will remain unaffected.

In other words, this is normal.
Comment 7 mikhail.v.gavrilov 2018-07-25 15:16:54 UTC
(In reply to Olivier Fourdan from comment #6)
> To demonstrate that, I attached a very simple reproducer written in gtk2.
> 
> If you compile and run that reproducer on Wayland/Xwayland, it will bejave
> the same, no other X11 client wil lreceive pointer events as long as the
> client is running, whereas other Wayland native clients will remain
> unaffected.
> 
> In other words, this is normal.

You even overdid it, the game did not block the keyboard.
But I admit you were able to recreate the same effect.

I do not understand why you think this behavior is normal.
In a multitasking environment, when one application can influence another it is perceived as a system vulnerability.
It also opens up a large field of activity of extortionists software and simply poorly written software, which will create the illusion that the computer is frozen.

When I studing several year ago Wayland architecture I thought that for each X11 application would used separate XWayland client this allow fix all XServer problems in modern systems. At that time it was a problem with Remmina which sometimes did not want to give away control of mouse and keyboard and I had to kill XServer every time through the console.

I think  this should be fixed in Wayland environment for all type of applications.
Comment 8 mikhail.v.gavrilov 2018-07-25 15:56:45 UTC
May be related:
When I click on a specific area in the Opera browser, click happens in steam client.
Demonstration: https://youtu.be/FaDqGf1-QEM

Also instead of Opera browser may be another X11 application.Only native wayland applications not affected ti this bug.

It's very annoying bug too.
Comment 9 mikhail.v.gavrilov 2018-07-25 16:10:59 UTC
On this video I show that hover not working on reload button in gmail, because of XWayland bug: https://youtu.be/RZ70m2HjZ2Q
Comment 10 Olivier Fourdan 2018-07-26 14:36:00 UTC
(In reply to mikhail.v.gavrilov from comment #7)
> (In reply to Olivier Fourdan from comment #6)
> > To demonstrate that, I attached a very simple reproducer written in gtk2.
> > 
> > If you compile and run that reproducer on Wayland/Xwayland, it will bejave
> > the same, no other X11 client wil lreceive pointer events as long as the
> > client is running, whereas other Wayland native clients will remain
> > unaffected.
> > 
> > In other words, this is normal.
> 
> You even overdid it, the game did not block the keyboard.
> But I admit you were able to recreate the same effect.

I did not overdo it, I just reused an existing bit of code I use elsewhere to demonstate the effects of a active grab on a device on X11 (either keyboard or pointer).

> I do not understand why you think this behavior is normal.

It is normal because this is how X11 is designed, this is part of the protocol, applications can issue an active grab on input devices and block other clients from receiving input events:

$ man XGrabPointer

       The XGrabPointer function actively grabs control of the pointer and
       returns GrabSuccess if the grab was successful.  Further pointer events
       are reported only to the grabbing client.  XGrabPointer overrides any
       active pointer grab by this client.  If owner_events is False, all gen‐
       erated pointer events are reported with respect to grab_window and are
       reported only if selected by event_mask.  If owner_events is True and
       if a generated pointer event would normally be reported to this client,
       it is reported as usual.  Otherwise, the event is reported with respect
       to the grab_window and is reported only if selected by event_mask.  For
       either value of owner_events, unreported events are discarded.

> In a multitasking environment, when one application can influence another it
> is perceived as a system vulnerability.

That's why we came up with Wayland.

> It also opens up a large field of activity of extortionists software and
> simply poorly written software, which will create the illusion that the
> computer is frozen.

Again, works as designed/intended.

> When I studing several year ago Wayland architecture I thought that for each
> X11 application would used separate XWayland client this allow fix all
> XServer problems in modern systems. At that time it was a problem with
> Remmina which sometimes did not want to give away control of mouse and
> keyboard and I had to kill XServer every time through the console.

No, we do not spawn an Xwayland server per X11 client, that would break inter-client communication between X11 clients, things like copy/paste, drag and drop etc. would not work with such a design.

> I think  this should be fixed in Wayland environment for all type of
> applications.

Sure, this is why we have Wayland, but these applcations you mention are not using Wayland, thery are still using X11.

If you want this to be fixed, please ask the developers of all these applications to port their application to Wayland instead.
Comment 11 Jonas Ådahl 2018-07-26 14:46:35 UTC
Does the same issue happen on a plain Xorg session? If it does, I don't think there is anything we can do, as it, as Olivier pointed out, is how X11 is designed to work. If the issue do not reproduce on plain Xorg sessions, it might be that there is something we don't do on the Wayland session that would normally happen that the game uses to release the grab it took.
Comment 12 mikhail.v.gavrilov 2018-07-26 21:22:51 UTC
(In reply to Olivier Fourdan from comment #10)
> It is normal because this is how X11 is designed, this is part of the
> protocol, applications can issue an active grab on input devices and block
> other clients from receiving input events:

And you don't plan redesign X11 clients behaviour under Wayland environment?

> No, we do not spawn an Xwayland server per X11 client, that would break
> inter-client communication between X11 clients, things like copy/paste, drag
> and drop etc. would not work with such a design.

But possible also redesign inter-client communication between X11 clients and make similar to Wayland client.

> Sure, this is why we have Wayland, but these applcations you mention are not
> using Wayland, thery are still using X11.
> 
> If you want this to be fixed, please ask the developers of all these
> applications to port their application to Wayland instead.

It does not depend from our desire. And to desire this is look like to desire peace in the whole world. The world will never be perfect and the world of software too. But we can improve it if start spawn an Xwayland server per X11 client.

(In reply to Jonas Ådahl from comment #11)
> Does the same issue happen on a plain Xorg session? If it does, I don't
> think there is anything we can do, as it, as Olivier pointed out, is how X11
> is designed to work. If the issue do not reproduce on plain Xorg sessions,
> it might be that there is something we don't do on the Wayland session that
> would normally happen that the game uses to release the grab it took.

Yes, it reproduced under plain Xorg session, but as I described above it possible fixed under Wayland environment.
If you do not want to consider this as bug, then possible suggest this report as feature request for X11 clients in Wayland environment.
Because these old problems will not go away by themselves.

P.S. Is someone already looked at my video from 8 and 9 comment?
I don't know how reproduce it.
But it really often happens and spoils the nerves.
Comment 13 Olivier Fourdan 2018-07-27 07:08:42 UTC
(In reply to mikhail.v.gavrilov from comment #12)
> (In reply to Olivier Fourdan from comment #10)
> > It is normal because this is how X11 is designed, this is part of the
> > protocol, applications can issue an active grab on input devices and block
> > other clients from receiving input events:
> 
> And you don't plan redesign X11 clients behaviour under Wayland environment?

No, because the purpose of Xwayland is precisely to allow legacy X11 clients to run unchanged on a Wayland compositor.

In theory, it would be possible to change Xwayland to pretend a grab succeeded but not actually issue the active grabs even when the clients request it, but that will break those X11 clients that rely on grabs to work.

Besides, not all clients can be ported/redesigned. There are old, legacy, closed source, in-house software that nobody knows how to recompile that run on X11 for years and will never be ported to Wayland, this is where Xwayland comes into play. For those, we want Xwayland to behave like any other X11 server.

If developers on such X11 clients had to redesign X11 clients for Wayland, they'd rather spend their time porting to Wayland native instead, I reckon.
Comment 14 Olivier Fourdan 2018-07-27 07:15:47 UTC
(In reply to mikhail.v.gavrilov from comment #12)
> P.S. Is someone already looked at my video from 8 and 9 comment?
> I don't know how reproduce it.
> But it really often happens and spoils the nerves.

That's unrelated to this bug, it's a different problem.

I heard of similar issue with the Steam client, but this unclear to me if this is a compositor (gnome-shell/mutter) bug or Xwayland. Looks like the input region does not match the client window.

If you can reproduce at will with gnome-shell, can you try to reproduce in weston?
Comment 15 mikhail.v.gavrilov 2018-07-27 09:36:48 UTC
(In reply to Olivier Fourdan from comment #13)
> In theory, it would be possible to change Xwayland to pretend a grab
> succeeded but not actually issue the active grabs even when the clients
> request it, but that will break those X11 clients that rely on grabs to work.

How many clients or cases we know when grabs really needed?
I think the lesser of the evils is to break them, and not make the system vulnerable.
Comment 16 Jonas Ådahl 2018-07-27 09:45:22 UTC
(In reply to mikhail.v.gavrilov from comment #15)
> (In reply to Olivier Fourdan from comment #13)
> > In theory, it would be possible to change Xwayland to pretend a grab
> > succeeded but not actually issue the active grabs even when the clients
> > request it, but that will break those X11 clients that rely on grabs to work.
> 
> How many clients or cases we know when grabs really needed?
> I think the lesser of the evils is to break them, and not make the system
> vulnerable.

A large portion would probably be Steam games. I've seen games that map two windows, grab input on one, then render on the other. I assume such setups would break, while being valid X11 clients.
Comment 17 mikhail.v.gavrilov 2018-07-27 10:24:16 UTC
(In reply to Jonas Ådahl from comment #16)
> A large portion would probably be Steam games. I've seen games that map two
> windows, grab input on one, then render on the other. I assume such setups
> would break, while being valid X11 clients.

The situation will never improve if everything is left as it is.
If discard active grab then there is a chance that the developers of such programs start looking for more correct ways of interacting with the user.

Another case:
You are working through Citrix ICA client which active grab mouse and keyboard. And your Skype, Hangout or maybe SIP client begin ring. And due of active grab you can't answer to this call. Perhaps it was be a recruiter which wanted to invite you to an interview for the work of your dream. But you missed this call and your dream crashed because you are an enthusiast and are sitting on Linux.

We can scold developers of SIP clients who have not made Wayland version in 2050 year or developers of the crooked Citrix client, but it will not make Linux users happier because they have to live with the architecture that for some reason was inherited from applications of DOS era.
Comment 18 Olivier Fourdan 2018-07-27 12:52:03 UTC
FWIW, I think this bug should be closed as "NOTABUG", Xwayland is working as expected here.
Comment 19 mikhail.v.gavrilov 2018-07-27 15:28:03 UTC
(In reply to Olivier Fourdan from comment #18)
> FWIW, I think this bug should be closed as "NOTABUG", Xwayland is working as
> expected here.

I am agree with you it's no XWayland problem.
I am also understand your not desire deal with old Xorg code.
But this vulnerability should be fixed in Xorg code even by violating backward compatibility in next Xorg version.
We're all waiting for the X11 applications die by their own deaths, but it's too long process and all this time the Linux desktop will be worse than the Windows and MacOS desktop.

I suggest reassign this issue to Xorg developers and create CVE.
Comment 20 GitLab Migration User 2019-05-10 15:54:11 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/725.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.