Lutris 0.5.15 Fixes Crashes When Using Wayland With High DPI Gaming Mice

[indepe]

indepe pulling back control input/output devices under Unix like OS(not unique to Linux/BSD) is nasty because the Unix like OS design has you terminating applications to achieve this. Remember how I said there was a type 3 used in embedded. In embedded you let application for performance use libinput and connect to input devices directly one very big catch when detect non responsive by watchdog you terminate application. None of this simple disconnect the socket or waiting. See the idea of let application directly connect to keyboard and mouse with Linux/bsd/Unix like/Unix kernel design to get back control is kill application. Applications must only be allowed to indirectly connect by some form of proxy if you don't want to be terminating them.

Sorry to say you have been presuming you can do things that you simply cannot do with current Linux and BSD kernels indepe. If course if you want to implement a correct C2 SAK in Linux/BSD then things would change. Yes with some extension on C2 SAK to allow alt-tab and the like to work as well against the applications will that is currently holding the input device. Of course there is still the problem how to transfer the input device without killing the application.
...
Basically in theory what you are suggesting indepe could work but we have to work to the limits of the Linux and BSD kernels. and those limitations say no you cannot do that. Kernel changes required to allow applications sharing a single screen to have direct input and to be able to take back control at any time without killing the application is massive number of changes required.

From a security point of view I would love if applications could have direct input with the kernel being able to be the routing server with C2 SAK and a few extras for alt-tab and the like but we don't have this.

This is also incorrect. With ioctl (EVIOCREVOKE) you can revoke the ability to use a evdev file handle, and it will revoke a handle forwarded with dup or dup-like functions as well (I tested it).

(However the preferred solution I'd have in mind works very differently.)

[oiaohm]

Maybe that would be somehow convincing of whatever it is supposed to convince me of, if I hadn't already done it myself for the latency test (I was reading the input stream from the kernel at the same time as receiving the same event from the wayland compositor.) It does require root privileges, but I guess the compositor has them.

There is one huge elephant in the room. What you describe there does not work on secured linux kernel where capabilities have been limited for root.

I suspect I know the interface you talking about.

If it the one I am thinking of. Start monitoring input and now change TTYs notice that it keeps on monitoring input even if the TTY is a different user.

Wayland compositors run without root privillages. This means if you have two users logged in on different TTY running different wayland compositors they cannot reach across and effect each other.

What you described you could with Audio as well but we don't for the same reason.

Is hawck a safe program itself to be using the answer is no it not safe.

Lot of the stuff I do with uinput its not safe todo on a production system in fact lot of cases will not work because different root capabilities will be taken away by selinux..

The reality here there is a kernel feature missing.

Do what you just did but restrict it to a TTY Virtual console under Linux.

Yes just because you can do it with a power of capabilities under Linux does not mean you should.

I had missed EVIOCREVOKE do note there was a high privilege version of this EVIOCMUTE that use to be global as well. Also EVIOCMUTE had the problem of being overpowered and requiring root.

The fact you had to use root todo what you wanted you need a kernel patch. So that it can work with Wayland compositors not running as root.

Note you say I guess the compositor has them for root privillages the reality is wayland compositor normally don't have root privillages. You did something that you are allowed to-do debugging not allowed to-do as a users compositor because the compositor will not have the privilege.,

Remember even for X11 people want to run this without any root privileges.

indepe I am limiting my thinking to what you can get away doing from a compositor you have been allow yourself to consider since you can do it when as root debugging this can be used when that not the case.

Once you can start capturing all input you start having some security issues to consider. Kernel level SAK C2 you set short cuts to be captured and processed that trigger user space actions this is not generically snoop.

[indepe]

There is one huge elephant in the room. What you describe there does not work on secured linux kernel where capabilities have been limited for root.

I suspect I know the interface you talking about.

If it the one I am thinking of. Start monitoring input and now change TTYs notice that it keeps on monitoring input even if the TTY is a different user.

Wayland compositors run without root privillages. This means if you have two users logged in on different TTY running different wayland compositors they cannot reach across and effect each other.

What you described you could with Audio as well but we don't for the same reason.

Is hawck a safe program itself to be using the answer is no it not safe.

Lot of the stuff I do with uinput its not safe todo on a production system in fact lot of cases will not work because different root capabilities will be taken away by selinux..

The reality here there is a kernel feature missing.

Do what you just did but restrict it to a TTY Virtual console under Linux.

Yes just because you can do it with a power of capabilities under Linux does not mean you should.

I had missed EVIOCREVOKE do note there was a high privilege version of this EVIOCMUTE that use to be global as well. Also EVIOCMUTE had the problem of being overpowered and requiring root.

The fact you had to use root todo what you wanted you need a kernel patch. So that it can work with Wayland compositors not running as root.

Note you say I guess the compositor has them for root privillages the reality is wayland compositor normally don't have root privillages. You did something that you are allowed to-do debugging not allowed to-do as a users compositor because the compositor will not have the privilege.,

Remember even for X11 people want to run this without any root privileges.

indepe I am limiting my thinking to what you can get away doing from a compositor you have been allow yourself to consider since you can do it when as root debugging this can be used when that not the case.

Once you can start capturing all input you start having some security issues to consider. Kernel level SAK C2 you set short cuts to be captured and processed that trigger user space actions this is not generically snoop.

The only "huge elephant in the room" is that this appears to be all vague speculation.

The fact that you bring up hawck again indicates your assumptions about the interface I have used for my tests (I'm not just talking about it) are incorrect. It has nothing to do with creating a fake or substitute input stream. It is completely unlike hawck.

Also your assumptions about the consequences of running as non-root are not valid. My understanding is that a compositor which doesn't run as root will get its permissions for the input stream from the login process (for example). These permissions are bound to a specific instance. This requires a (secure) communication channel between the compositor and the login process. So if it wants another instance that is revoke-able, it needs to get a separate instance for that full-screen game/app, with its own permissions. In case ioct(EVIOCREVOKE) requires root privileges (which I won't even bother to test), it will just use the same channel to have the login process do the revoke.

This also means that these permissions are created in the same way as the compositors own permissions, so even in a "secured linux kernel" where the Wayland compositor works, that would work as well. Both or none.

And just as a reminder, my favored solution is very different and independent of all that.

EDIT: I meant EVIOCREVOKE, not EVIOCMUTE (I corrected it above.). I don't care about EVIOCMUTE.

[oiaohm]

Also your assumptions about the consequences of running as non-root are not valid. My understanding is that a compositor which doesn't run as root will get its permissions for the input stream from the login process (for example). These permissions are bound to a specific instance. This requires a (secure) communication channel between the compositor and the login process. So if it wants another instance that is revoke-able, it needs to get a separate instance for that full-screen game/app, with its own permissions..

https://patchwork.kernel.org/project/linux-input/patch/[email protected]/

There is problem with this path. If the wayland compositor gets input device access by login process this is passed over by a file handle and if you pass that file handle on to the applications it a duplicate.

Hence, once you call EVIOCREVOKE on any dup()ed fd, all fds for that open-file will be rather useless now (but still valid compared to close()!).

You would need to be on a different Virtual Consoles

Virtual Consoles disconnect of input devices can be undone when you change virtual consoles. This functionality is not exposed when applications are on the same virtual console.

This also means that these permissions are created in the same way as the compositors own permissions, so even in a "secured linux kernel" where the Wayland compositor works, that would work as well. Both or none.

You have missed the current design will is not design to target disconnect. Yes the login process end up having to create a new file handle when a wayland/x11 session end for input because the one it gave over to wayland or X11 user mode will be dead.

indepe it what gets called a duplicate file handle part of the problem. Second part is that a disconnected input handle to application the application may not be aware that it need to get a new handle.

You thought something was permissions when what is going on passed a file handle. Worse a duplicated file handle.

EVIOCREVOKE is the problem child. So wayland compositor passes on the file handle it go from login manager and the Wayland application call EVIOCREVOKE on file handle to got from the wayland compositors has now disconnected the Wayland compositor from input because this kills all duplicates of the file handle.

Yes if it was possible for Wayland compositor to take the file handle it got from the login manager or direct from device and make a new handle that the compositor can revoke without nuke it own would be solution to the input buffer problem. This would also be a Wayland protocol breaking change.

The old EVIOCMUTE. root requiring you could stop input and restart input. The current EVIOCREVOKE is a one way switch.

Yes you would want to pass a file handle of input device to applications that the EVIOCREVOKE did hit everything like it currently does. Also means to pause application input while you display authorization diagram or something.

indepe EVIOCMUTE was over powered because every input device in the system could be turned on and off by it without any consideration on what user was using it. EVIOCREVOKE is over powered because it takes out all duplicates of the file handle with no clean user control to define where the layers are.

Yes the catch here is technically the Wayland compositor running as your user and the Wayland application running as your user are in fact in the same layer.

Yes EVIOCREVOKE was designed to be used by session-processes as in Wayland compositors and X11 xservers and the like.

Remember the Wayland event system you can stop sending events to application do something with those events then start sending them again. The reality if item like Wayland is going to pass raw input device to applications for key input devices you really do want EVIOCMUTE.like item of course not a powerful. Like having flag in the cgroup around the application that is able to turn input device access on and off as in mute and unmute input device access. Then of course each application could have their own file buffer size for input events. Maybe make cgroups formally the layers EVIOREVOKE is limited by so that application cannot take out compositors input access..

Its not practical to expand the Wayland event buffer size because it has to stay the size it is due to file handle limit. You are starting to work the right way looking at how to have a independent buffer for mouse/keyboard events. Problem is features are missing that a compositor will required to go those route.

Remember users will change applications to full screen and windows and back again and this transitions need to be tidy.

[indepe]

https://patchwork.kernel.org/project/linux-input/patch/[email protected]/

There is problem with this path. If the wayland compositor gets input device access by login process this is passed over by a file handle and if you pass that file handle on to the applications it a duplicate.
...
EVIOCREVOKE is the problem child. So wayland compositor passes on the file handle it go from login manager and the Wayland application call EVIOCREVOKE on file handle to got from the wayland compositors has now disconnected the Wayland compositor from input because this kills all duplicates of the file handle.

Yes if it was possible for Wayland compositor to take the file handle it got from the login manager or direct from device and make a new handle that the compositor can revoke without nuke it own would be solution to the input buffer problem. This would also be a Wayland protocol breaking change.

....

So you restart the dicussion after 10 days and with nothing but false arguments? You just didn't understand what I wrote, and how it works. EVIOCREVOKE has to also close the file handles duplicates created with "dup" and related fucntions, because the compositor needs that to pass an opened filehandle to the fullscreen app.

However it does not close independently obtained file handles. That's why I wrote the compositor needs to get a separate file handle, It needs to get that from the login process (which has root privileges), not by using "dup" or "dup"-like functions. The login process will create it independently without using "dup". Then EVIOCREVOKE will only revoke the second file handle (and any obtained by duplciating the second handle), but not the first one.

I have tested that. EVIOCREVOKE will revoke a duplicate, but not an independtly obtained file handle.

This means that the compositors original file handle will continue to work.

Its not practical to expand the Wayland event buffer size because it has to stay the size it is due to file handle limit.
....

As I have said multiple times, and will keep repeating each time you bring this up, the file handle limit is not a problem either. However as I aslo said, that is a question I will not discuss with you as long as you keep rejecting everything I say. There would be no point.

[oiaohm]

So you restart the dicussion after 10 days and with nothing but false arguments? You just didn't understand what I wrote, and how it works. EVIOCREVOKE has to also close the file handles duplicates created with "dup" and related fucntions, because the compositor needs that to pass an opened filehandle to the fullscreen app.

However it does not close independently obtained file handles. That's why I wrote the compositor needs to get a separate file handle, It needs to get that from the login process (which has root privileges), not by using "dup" or "dup"-like functions. The login process will create it independently without using "dup". Then EVIOCREVOKE will only revoke the second file handle (and any obtained by duplciating the second handle), but not the first one.

I have tested that. EVIOCREVOKE will revoke a duplicate, but not an independtly obtained file handle.

This means that the compositors original file handle will continue to work.

Have you read over the logind specification on this. Logind specification does not promise that it will not send you a duplicated handle. So you have written a presume here.

Yes you are right if the compositor has managed to get a non duplicated file handle. Problem is how does the compositor know it has got a non duplicated handle. You write will create it independently without using "dup" problem the logind specification does not say this in fact says logind implementations can choose to use dup.

Yes there are logind implementations that duplicate input device passed over as long as handle still functional.

Also there is another fun fact. Does logind by specification have to stay up after the Wayland compositor/x11 server is started. The answer is no.

Remember startx with X11 and the same applies with Wayland compositor is that you can start them without a logind running. There may not be a login process or the login process may use duplication instead of getting new handle. These are configurations you have to design for..

Taking the input events out of the event que of Wayland is a Wayland protocol breaking change.

Also things are not as straight forwards either. Not all HID devices process EVIOCREVOKE correctly there are different kernel bugs about it. Proxy the event que is the most durable when dealing with not ideal drivers.

Yes durability vs performance vs stability.

As I have said multiple times, and will keep repeating each time you bring this up, the file handle limit is not a problem either. However as I aslo said, that is a question I will not discuss with you as long as you keep rejecting everything I say. There would be no point.

Rejecting what you are saying because work is required. Your testing is missing that the behaviors you are depending on are not written into specifications and are not always the case.

Its not valid to say Wayland compositor only works if login manager exists.

[indepe]

Have you read over the logind specification on this. Logind specification does not promise that it will not send you a duplicated handle. So you have written a presume here.

Not "logind". The display server login manager. That would probably be GDM or SDDM.

Yes you are right if the compositor has managed to get a non duplicated file handle.

Thanks for the confirmation.

Problem is how does the compositor know it has got a non duplicated handle. You write will create it independently without using "dup" problem the logind specification does not say this in fact says logind implementations can choose to use dup.

It will cooperate with the display server login manager to do so. I believe they are friends, so to speak.

Yes there are logind implementations that duplicate input device passed over as long as handle still functional.

Also there is another fun fact. Does logind by specification have to stay up after the Wayland compositor/x11 server is started. The answer is no.

Remember startx with X11 and the same applies with Wayland compositor is that you can start them without a logind running. There may not be a login process or the login process may use duplication instead of getting new handle. These are configurations you have to design for..

This is all unrelated and irrelevant.

Taking the input events out of the event que of Wayland is a Wayland protocol breaking change.

It's not because it would be an additional option for full screen apps, and both can work at the same time.

Also things are not as straight forwards either. Not all HID devices process EVIOCREVOKE correctly there are different kernel bugs about it. Proxy the event que is the most durable when dealing with not ideal drivers.

Yes durability vs performance vs stability.

Is there anything without any bugs? I think you are just being spiteful.

Rejecting what you are saying because work is required. Your testing is missing that the behaviors you are depending on are not written into specifications and are not always the case.

Its not valid to say Wayland compositor only works if login manager exists.

Work is required? So what? Maybe you are just trying to create the impression that there are problems with this approach, when it is actually quite simple.

The problems you talk about don't even exist. They require no solution.

[oiaohm]

Not "logind". The display server login manager. That would probably be GDM or SDDM.

https://wayland.pages.freedesktop.org/weston/toc/running-weston.html#running-weston-on-a-stand-alone-back-end

This is where you are wrong. GDM/SDDM don't come into this. The display and input devices to the Wayland compositor or X11 x.org server bare metal running as user come from the seat manager. Yes the seat managers in use seatd or logind or consolekit2 providing logind interfaces..

seatd in particular can be configured that once it handed over single copy of the graphical output and input devices it terminates.

The reality here is your first problem is the seat managers.

There is no instruction to send to a seat manger to say give me another copy of the input/output handles that is not duplicated it in fact valid for seat managers if they are still running and asked again for input/output handles to duplicate the handle they have and send that back over. In the seat manager specifications they are not required to provide you with more than 1 copy of the handles.

Next is the nested compositor problem. Yes it the same as the seat manager that you cannot be sure that the compositor above you if you were asking for input handles is not just sending you duplicates.

So at this point we have not successful for sure got a non duplicated file handles of the input devices.

Next is the problem with EVIOCREVOKE function operation.

Once EVIOCREVOKE is called on file handle it dead. How is this a problem I will cover.

Moving in and out of application window this could be mouse/tab/what ever. So you are cutting off input when it leaves the window and then need to restore it when you come back to the window.

So leave Window EVIOCREVOKE handle dead. Buffers application created on that handle is dead. Compositor/what ever has to send that application a new handle and now application need to setup all this stuff all over again. Of course the compositor has to have got a clean non duplicated handle from somewhere.

What is really need is something like EVIOCMUTE that we don't have.

https://patchwork.kernel.org/project/linux-input/patch/[email protected]/

EVIOCMUTE was proposed by Wayland developers early on. It did not make it into mainline Linux.

Yes EVIOMUTE has not killed the filehandle of the input device. This means the allocated buffers by the application stay up. Yes you can resume.

We need so low privilege alternative EVIOMUTE with the same functionality of letting the input events on application be temporally stopped then resumed latter without the application itself needing todo anything. This would allow the compositor to talk only to the Kernel and not require application doing extra steps when it losing and gaining focus.

Yes it one thing to demo that using EVIOCREVOKE on a non duplicated handle works is completely different problem once you take into account in a desktop environment users can be changing what applications should be receiving input rapidly so cannot be generating a huge amount of overhead. The reality is the EVIOCREVOKE is going to generate too much overhead even if you can get non duplicated file handles.

EVIOMUTE was designed for the second half of the problem. The first part of the problem where you cannot be sure to get non duplicated handles was never solved way back then either.

[indepe]

GDM/SDDM don't come into this.

They are at the right place and the right time, with root access. Both keep running on Gnome/Mutter and Plasma/KWin. In principle it just takes a tiny single threaded process that sleeps most of the time.

Moving in and out of application window this could be mouse/tab/what ever. So you are cutting off input when it leaves the window and then need to restore it when you come back to the window.

As I said multiple times, I would see this as an option for full-screen apps, and there it does not matter at all if it takes 10 ms or 100 ms to get back into full-screen mode. The user needs to adjust to the visual impact first. EVIOCMUTE is not needed.

Certainly the compositor needs to know when to cut off the input, and it would appear it needs to know that anyway.

[oiaohm]

They are at the right place and the right time, with root access. Both keep running on Gnome/Mutter and Plasma/KWin. In principle it just takes a tiny single threaded process that sleeps most of the time.

https://wayland.pages.freedesktop.org/weston/toc/running-weston.html#running-weston-on-a-stand-alone-back-end

Read the like this time. GDM/SDDM have nothing todo with Gnome/Mutter and Plasma/KWin other than starting them.
Here a KDE developer putting it on the table for you.

https://blog.martin-graesslin.com/blog/2014/10/libinput-integration-in-kwinwayland/

The same is the case for Weston and obviously I looked at how it’s solved there and there is a very neat solution to support the use case we have in logind. The session controller can ask logind to open devices and logind provides a file descriptor to the opened device. In addition logind automatically takes care to close the file descriptors when a VT switch happens, which is extremely convenient for the use cases of Wayland compositors. So obviously I went for this solution as all it needs is connecting to very few D-Bus calls. This means the libinput integration in kwin_wayland will have a runtime dependency to a logind D-Bus interface.

I can find a gnome developer if you like. GBM/SDDM have nothing todo with the wayland compositors or Rootless X11 servers getting input devices or output devices.

Wayland compositor and rootless X11 server get their input devices from either a logind interface or a seatd interface.
indepe GDM/SDDM is the wrong place. Yes this does bring a very interesting question why does GBM/SDDM stay running instead of being a start on demand service.

There is no interface with logind dbus or seatd to get a non duplicated handles without question. These are also by their protocols not required to keep running.

As I said multiple times, I would see this as an option for full-screen apps, and there it does not matter at all if it takes 10 ms or 100 ms to get back into full-screen mode. The user needs to adjust to the visual impact first. EVIOCMUTE is not needed.

Think person on a laptop playing a game and recording with OBS with only a single screen. Speed of swapping between full screen game and OBS does come important particular with games that don't pause when put in background.

Sorry that 10ms to 100ms or more does matter. The switching need to be fast from full screen to another application and back for quite a few use cases indepe.

So this point of yours does not in fact hold.

Also what about the case of nested compositors Yes nested compositor can be full screen with application inside it full screen..