Libinput Picking up Record & Replay Abilities For Input

[phoronix]

Phoronix: Libinput Picking up Record & Replay Abilities For Input

Linux input expert and libinput creator Peter Hutterer of Red Hat is working on support for libinput to handle natively recording and replaying of input events...

http://www.phoronix.com/scan.php?page=news_item&px=Libinput-Record-Replay

[uid313]

But since Wayland is more secure than X11 and prevents one application from reading input events from another application, I also support it prevents one application from inserting input events into another application?
So then only the compositor is allowed to do this?

I was thinking maybe GNOME Shell would need an extension for this.
But not sure how to write this.
GNOME haven't updated their gnome-shell extension generation utility to output ES6 classes, so it still have this ugly old prototype thing.
Not sure how to do it, if a virtual keyboard is needed?
Not sure if I need to interact with Caribou.
Writing a gnome-shell extension is rather difficult to test and debug.

Sounds like this could be useful for writing macros.

[KRiloshart]

I hate the direction we are moving in. Libinput should try to be as light as possible, this problem is not only with libinput but many core components are trying to be 'like systemd' forgetting Unix philosophy 'do one thing, do it best'

[M@GOid]

#Put tinfoil hat on



Great. Now the NSA hacking tools do not need to provide a way record your keystrokes. Red Hat will provide it to them on all future systems by default.

[polarathene]

I suppose this could be utilized for remote input too on Wayland?(via some protocol extension or something)

I hate the direction we are moving in. Libinput should try to be as light as possible, this problem is not only with libinput but many core components are trying to be 'like systemd' forgetting Unix philosophy 'do one thing, do it best'

Shouldn't be anything preventing you from splitting those out into separate modules or something I guess? systemd works like that afaik, you just have the option of using multiple components that are known to work well together? The article already states the motivation behind it, it does the job better than current existing option. It does so by utilizing a modern codebase.

Other than that it's being done by someone who has an interest in doing that specific area(input) really well. They can do what they like with their time, others get to benefit. If you're not keen on that don't use it. More than welcome to invest the time getting similar knowledge and putting the effort in to do it as separate components, maintaining and testing each one.

[Terrablit]

I hate the direction we are moving in. Libinput should try to be as light as possible, this problem is not only with libinput but many core components are trying to be 'like systemd' forgetting Unix philosophy 'do one thing, do it best'

Usually the most apparent thing when someone quotes "Unix philosophy" is that they understand neither software nor Unix.

At some point in time, the disparate parts of a system become complex enough that you need parts that exist solely to join specific parts. Sometimes that's with a generic method, like piping text between processes. But that's assuming that components only need to be joined in a one-to-one fashion - and with human intervention. In reality, computer needs are complex enough that parts need to work with each other. But not every part can understand the other while still obeying that philosophy (because then they take up the additional ancillary tasks of communicating with other parts), so either every user needs to be a master of gluing ten thousand lego bricks together in just the right way as to make a space ship, or you need actual architecture.

Then you end up with discrete units that serve general purposes in specific ways, but are made up of smaller specialized components, Think like GPUs, FPGAs, FPUs, sound cards, etc. They all fit into the system in a very specific way. And sometimes, it's simpler for one piece to do two things than to have two parts, because it's not just the functionality that can break, but the edges where you communicate between processes. Having everything in one place can make a project easier to manage and keep synchronized. But since we all insist on Linux being about "choice" we've got fools trying to feed a dozen USB drives directly into the PSU fan grill like candy and then wondering why things catch fire.

At some point, gluing text together and piping it around the house just doesn't work anymore. Text is inefficient by nature for computing tasks. Not that computers even understand what "plain text" is. It always has to parse it. The mere idea that we're using it everywhere flaunts purist Unix philosophy, because not only is the software doing its purpose, it also has to master a basic DSL that we use to glue with other things. And it's a fragile DSL, because it's rarely structured text, like JSON, but is instead human-readable formatted text. Text parsing tools which were intended for human interaction now become essential to the stability of the system.

So we grep and awk and pipe and hope the formatting never changes. And then we mock the filthy peasants who wonder why the system doesn't just do this out of the box on its own without instructions. It's not about getting work done or saving time. No! It's a philosophy. You can't use this stuff unless you believe in it. You've got to be a priest.

If there are any command-line tools you use with over ten arguments, it's a clear example of something that already violates what you imagine "Unix philosophy" to be. And those are all over your system. If you're fitting pieces together, at some point in time, they will share an edge with more than one piece, and thus will have more than one responsibility. Anyone who's ever put together a puzzle should understand this, as it's a basic two dimensional concept. And if each tool only does one thing, there couldn't possibly be more than two dimensions to it.

So it's perfectly fine for a tool to do more than one thing, as long as it does whatever you created it for well. And hopefully we all understand that computers haven't worked the way you think they should for anyone other than Richard Stallman (who emails himself webpages for freedom) for over two decades. Multi-purpose devices were the biggest win of the information age. It'd be a shame to throw that all away and start labeling all of our rocks for their assigned tasks.

This fetish we have for inserting humans into processes that are best handled by computers doesn't improve things. It slows them down. And it's not even because humans do it better, like some sort of mechanical turk doing secret complex computations that a machine could never understand. No, it's because at the end of the day, we fear computers and fear not understanding how they work. We fear being made obsolete. So we slow them down, and we favor approaches that don't only encourage bolting spoilers and wobbly windows all over them, but enable us to peek into every single aspect of them and verify that our tiny magic boxes are still obeying orders. We micro-manage them like the worst boss that ever existed on the face of the planet because we don't just want the task done, we want it done our way. In a way that we don't have to understand anything new. But with one-inch margins, more cowbell, and before Monday.

We'd get a lot more done with computers if we stopped insisting that people had to be able to change every single part of them without actually understanding computers. It's okay if there's a barrier to entry, as long as it's reasonable and there are some lower levels to get started. And it's okay if we have complex systems as long as we fix the bugs and the security vulnerabilities that inevitably occur when someone gets paid to be obtuse.

Now that the rant is over, this is going in LibInput so that multiple compositors can use the same code without having to rewrite it. It's pretty obvious that it's going in there so that people can have meaningful choices without duplicating effort. And I can't think of a better place to have something that records and replays input than right inside the input system - the chokepoint where all that input funnels through anyway. It's going to be on the outskirts of that code, of course. They're not building it into libc with a GCC extension or anything like that.

Meanwhile, I'm going to check the liquor cabinet and drink a toast to a dying world that insists on doing things the hard way. And then I'm going to ponder exactly how a potential real AI would react to all of this nonsense.

[schmidtbag]

Seems like this adds unnecessary bloat, complexity, and insecurity. I'm perfectly fine with having the ability to record and replay inputs (actually, I'd be surprised if this hasn't been available years ago - even Windows 3.1 allowed input recording) and I'm fine with the idea of libinput making it easier to do such things. But, the library itself shouldn't do this. What's so bad about installing a 3rd party tool?

[Masush5]

Seems like this adds unnecessary bloat, complexity, and insecurity. I'm perfectly fine with having the ability to record and replay inputs (actually, I'd be surprised if this hasn't been available years ago - even Windows 3.1 allowed input recording) and I'm fine with the idea of libinput making it easier to do such things. But, the library itself shouldn't do this. What's so bad about installing a 3rd party tool?

Probably the fact that not every 3rd party tool should be able to record all input. So putting it into libinput so that compositors can handle input recording without reinventing the wheel seems reasonable to me.

[StefanBruens]

Seems like this adds unnecessary bloat, complexity, and insecurity. I'm perfectly fine with having the ability to record and replay inputs (actually, I'd be surprised if this hasn't been available years ago - even Windows 3.1 allowed input recording) and I'm fine with the idea of libinput making it easier to do such things. But, the library itself shouldn't do this. What's so bad about installing a 3rd party tool?

Because you are completely clueless? Stop ranting, start reading!

The two additional tools do not add a single line of code to libinput, they just live in the same repository.

These are debugging/development tools, not some session recording and playback.

[pal666]

I hate the direction we are moving in.

nobody is taking slackware 1.0 from you