uinput kernel module is not loaded automatically

Here is a proposed change to the init script.

--- bluetooth.orig 2010-05-23 23:21:27.604764873 -0500
+++ bluetooth 2010-05-23 23:24:53.606012449 -0500
@@ -14,6 +14,10 @@ set -e

 case "$1" in
   start)
+ #Try and load uinput kernel module. Bluez uses to pass
+ #keypresses from bluetooth deivces up to userspace.
+ modprobe uinput >/dev/null 2>&1
+
     #currently this init script exists only because of what appears to be
     #an egg and chicken problem
     # bluetoothd normally starts up by udev rules. it needs dbus to function,

This issue is now a priority due to ODM testing. This is expected functionality to work out of the box as compared with other operating systems.

Proposed patch is attached on comment 1.

Another way to solve this issue is to have uinput loaded in /etc/modules .. like we have "lp" & "rtc" modules today. uinput is used by many programs. But Ubuntu has no good way of loading it up.

The technique I propose in comment one comes from a disscussion on the ubuntu kernel mailing list where other services do this exact same technique to make sure uinput kernel module gets loaded.

Please let's not do modprobe calls in init scripts (or generally during boot), this is way too much overhead, and also it's not necessary on machines which do not have bluetooth.

There are three generally accepted ways to get the module loaded:

 - add some sensible modaliases to uinput (which doesn't seem adequate here, though)
 - make it a dependency of the bluetooth kernel module
 - built it into the kernel (which will be faster than unconditionally modprobing it during boot).

Seems like building this into the kernel may be the best thing to do...?

There are other projects that also need uinput and load it in the startup script, such as rinputd server.

The thread I started on the ubuntu kernel mailing list is here:
https://lists.ubuntu.com/archives/kernel-team/2010-May/010641.html

@Pitti - It's not really suitable to add a dependency to the bluetooth module, as the uinput device is required by userspace components of bluez, not the bluetooth kernel module. We'd prefer not to build it in, as it's only required on some systems, and not required for boot.

Adding it to the bluetooth init script would seem (to me) to be the most appropriate solution, and is done in other init scripts (as well as loading everything from /etc/modules). Or are we trying to move away from this?

What are your concerns with the overhead? Is this primarily about affecting machines with no bluetooth support?

@Jeremy
          I think the main conern is it slow down bootup. If it's already built in the kernel then this isn't an issue.

Hello Jeremy,

Jeremy Kerr [2010-07-28 2:37 -0000]:
> @Pitti - It's not really suitable to add a dependency to the bluetooth
> module, as the uinput device is required by userspace components of
> bluez, not the bluetooth kernel module.

Understood.

> We'd prefer not to build it in, as it's only required on some
> systems, and not required for boot.

But if we modprobe it in an init script, it's also loaded everywhere
on boot, but with much more overhead, so this seems worse to me?

> Adding it to the bluetooth init script would seem (to me) to be the most
> appropriate solution, and is done in other init scripts

cups is a major offender here, and its usage of modprobe is really EBW
(two of them should already autoload and need investigation, and the
third ought to go into /etc/modules).

> (as well as loading everything from /etc/modules). Or are we trying
> to move away from this?

We actually do, since these mean unconditional modprobe calls during
boot which just take time.

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

Martin,

> But if we modprobe it in an init script, it's also loaded everywhere
> on boot, but with much more overhead, so this seems worse to me?

My preference for the init script is that it's tied to the bluez
package; but the /etc/modules solution sounds reasonable enough.

I'm still chasing up on the config change to build-in uinput, will
update with details of that.

Jeremy

@Jeremy Kerr

Just to add .. you most likely know this... config changing is CONFIG_INPUT_UINPUT from "m" to "y".

Jerone: I've just uploaded a test build at http://kernel.ubuntu.com/~jk/bugs/584812/

Let me know if this resolves the issue for you.

@Jeremy

        Tested fresh 10.10 install with your kernel. Bluetooth devices, like bluetooth presenation remotes & buttons on bluetooth headphones work without any modification to the OS with it.

Patches posted to kernel-team.

This bug was fixed in the package linux - 2.6.35-17.23

---------------
linux (2.6.35-17.23) maverick; urgency=low

  [ Jeremy Kerr ]

  * [Config] build-in uinput module
    - LP: #584812

  [ Leann Ogasawara ]

  * Revert "[Config] [FTBS] ia64: Temporarily disable CONFIG_CEPH_FS"
  * Revert "[Config] [FTBS] ia64: Temporarily disable gpiolib"
  * Revert "[Config] [FTBS] sparc: Temporarily disable
    CONFIG_MTD_NAND_DENALI"
  * Revert "[Config] [FTBS] sparc: Temporarily disable
    CONFIG_MFD_JANZ_CMODIO"
  * Revert "[Config] [FTBS] sparc: Temporarily disable
    CONFIG_INFINIBAND_QIB"
  * [Config] Enable INTEL_IPS
    - LP: #601057
  * Remove ia64 support
  * [Config] Update portsconfigs after removing ia64 support
  * Remove sparc support
  * [Config] Update portsconfigs after removing sparc support

  [ Linus Torvalds ]

  * (pre-stable) mm: fix page table unmap for stack guard page properly

  [ Mathieu J. Poirier ]

  * SAUCE: (no-up) ARM: Resetting power_mode to its original value.
    - LP: #591941

  [ Upstream Kernel Changes ]

  * timer: add on-stack deferrable timer interfaces
    - LP: #601057
  * x86 platform driver: intelligent power sharing driver
    - LP: #601057
  * IPS driver: add GPU busy and turbo checking
    - LP: #601057
  * X86: intel_ips, check for kzalloc properly
    - LP: #601057
  * ips driver: make it less chatty
    - LP: #601057
 -- Leann Ogasawara <email address hidden> Tue, 17 Aug 2010 09:38:08 -0700

@Jeremy
                Thanks for all the work to get this in!