Announcement

Collapse
No announcement yet.

Linux 5.11 Adding An "Inhibited" Feature To Temporarily Disregard Select Input Devices

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Linux 5.11 Adding An "Inhibited" Feature To Temporarily Disregard Select Input Devices

    Phoronix: Linux 5.11 Adding An "Inhibited" Feature To Temporarily Disregard Select Input Devices

    The Linux kernel's input subsystem is gaining a new "inhibited" property feature as a policy to temporarily block input from given devices, including not using any event from them as a possible wake-up source...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Instead of doing it in libinput or as an extension in wayland bring it to the kernel. Great!

    Comment


    • #3
      Originally posted by nrndda View Post
      Instead of doing it in libinput or as an extension in wayland bring it to the kernel. Great!
      Doing this in the kernel allows the kernel to power-down the input devices while they are inhibited, saving power.

      Comment


      • #4
        Originally posted by hansdegoede View Post

        Doing this in the kernel allows the kernel to power-down the input devices while they are inhibited, saving power.
        But it also can be done from userspace, right? Some of devices and even subsystems allow this, as I remember correctly.

        Comment


        • #5
          Nice, this has many other good use-cases like disabling the touchpad when a mouse is plugged in.

          Comment


          • #6
            How this feature works for an inhibited keyboard in my head:

            Keyboard: **drunken, racist rant on Amazon Q/A about a blender**

            Kernel: Seriously, WTF. Go home keyboard, you're drunk. We're not posting that.

            Comment


            • #7
              Sounds like something potentially useful for TS/S environments. Or voting machines, in case you don't want to end up like Venezuela or the USA.

              Comment


              • #8
                Originally posted by nrndda View Post
                Instead of doing it in libinput or as an extension in wayland bring it to the kernel. Great!
                It's not OR, it's AND. If not in the Kernel, you would have to do it in libinput and wayland and xorg and sdl and everything else that might try to directly access the input device, which you can't possibly know in advance.

                Comment


                • #9
                  Originally posted by nrndda View Post

                  But it also can be done from userspace, right? Some of devices and even subsystems allow this, as I remember correctly.
                  Not sure what you mean with "it" which can also be done from userspace. Yes userspace could decide to ignore input events under certain circumstances itself, libinput already does that. But AFAIK there is no way for one process to cause events to not be send to another listening process.

                  If you mean get the same power-saving results with "it", no that is not possible, even if userspace closes all fds to /dev/input/event# nodes then at least for keyboards there will still be in kernel listeners active (to detect ctrl+alt+del, alt + up-arrow, sysrq and rfkill key presses). The new inhibit API tells the input-device's driver that the device is closed (and thus can go into a low power mode) even if there are in kernel listeners.

                  Comment


                  • #10
                    Originally posted by hansdegoede View Post
                    If you mean get the same power-saving results with "it", no that is not possible, even if userspace closes all fds to /dev/input/event# nodes then at least for keyboards there will still be in kernel listeners active (to detect ctrl+alt+del, alt + up-arrow, sysrq and rfkill key presses). The new inhibit API tells the input-device's driver that the device is closed (and thus can go into a low power mode) even if there are in kernel listeners.
                    By "it" I meant to switch to other power state where there will be no events and more powersave. But I have no clue how extensively it's been used across all input devices. Just my guess.

                    Comment

                    Working...
                    X