How should an application ask for uinput module load?

How should an application ask for uinput module load?

[Samuel Thibault]

Hi,

Given a freshly booted linux box, hence uinput is not loaded (why would
it be, it doesn't drive any real hardware) ; what is the right way(tm)
for an application to have the uinput module loaded, so that it can open
/dev/input/uinput for emulating keypresses?

- With good-old static /dev, we could just open /dev/input/uinput
  (installed by the distribution), and thanks to a
  alias char-major-10-223 uinput
  line somewhere in /etc/modprobe.d, uinput finally gets auto-loaded.

- With devfs, it doesn't look like it works (/dev/misc/uinput is not
  present and opening it just like if it existed doesn't work). But I
  read in archives that it could be feasible.

- With udev, this just cannot work. As explained in an earlier thread,
  even using a special filesystem that would report the opening attempt
  to udevd wouldn't work fine since udevd takes time for creating the
  device, and hence the original program needs to be notified ; this
  becomes racy.

So what is the correct way to do it? I can see two approaches:

Using modprobe:
- try to use /dev/input/uinput ; if it succeeds, fine.
- else, if errno != ENOENT, fail
- else, (ENOENT)
  - try to call `cat /proc/sys/kernel/modprobe` uinput
  - try to use /dev/input/uinput again ; if it succeeds, fine
    - else, assume that it really wasn't compiled, and hence fail.

Triggering auto-load by creating one's own node.
- try to use /dev/input/uinput ; if it suceeds, fine.
- else, if errno != ENOENT, fail
- else, (ENOENT)
  - mknod /somewhere/safe/uinput c 10 223
  - use /somewhere/safe/uinput ; if it succeeds, fine
    - else, assume that it really wasn't compiled, and hence fail.

I guess the same problem arises for loop devices and all such virtual
devices...

Regards,
Samuel

Re: How should an application ask for uinput module load?

[Samuel Thibault]

Hi,

Samuel Thibault, le Tue 28 Mar 2006 21:42:10 +0200, a écrit :
> what is the right way(tm) for an application to have the uinput
> module loaded, so that it can open /dev/input/uinput for emulating
> keypresses?
>
>...
> 
> I can see two approaches:
> 
> Using modprobe:
> - try to use /dev/input/uinput ; if it succeeds, fine.
> - else, if errno != ENOENT, fail
> - else, (ENOENT)
>   - try to call `cat /proc/sys/kernel/modprobe` uinput
>   - try to use /dev/input/uinput again ; if it succeeds, fine
>     - else, assume that it really wasn't compiled, and hence fail.
> 
> Triggering auto-load by creating one's own node.
> - try to use /dev/input/uinput ; if it suceeds, fine.
> - else, if errno != ENOENT, fail
> - else, (ENOENT)
>   - mknod /somewhere/safe/uinput c 10 223
>   - use /somewhere/safe/uinput ; if it succeeds, fine
>     - else, assume that it really wasn't compiled, and hence fail.
> 
> I guess the same problem arises for loop devices and all such virtual
> devices...

So? Nobody knows, or nobody cares?

Samuel

Re: How should an application ask for uinput module load?

[Dmitry Torokhov]

On 3/28/06, Samuel Thibault <samuel.thibault@ens-lyon.org> wrote:
> Hi,
>
> Given a freshly booted linux box, hence uinput is not loaded (why would
> it be, it doesn't drive any real hardware) ; what is the right way(tm)
> for an application to have the uinput module loaded, so that it can open
> /dev/input/uinput for emulating keypresses?
>
> - With good-old static /dev, we could just open /dev/input/uinput
>  (installed by the distribution), and thanks to a
>  alias char-major-10-223 uinput
>  line somewhere in /etc/modprobe.d, uinput finally gets auto-loaded.
>
> - With devfs, it doesn't look like it works (/dev/misc/uinput is not
>  present and opening it just like if it existed doesn't work). But I
>  read in archives that it could be feasible.
>
> - With udev, this just cannot work. As explained in an earlier thread,
>  even using a special filesystem that would report the opening attempt
>  to udevd wouldn't work fine since udevd takes time for creating the
>  device, and hence the original program needs to be notified ; this
>  becomes racy.
>
> So what is the correct way to do it? I can see two approaches:
>
> Using modprobe:
> - try to use /dev/input/uinput ; if it succeeds, fine.
> - else, if errno != ENOENT, fail
> - else, (ENOENT)
>  - try to call `cat /proc/sys/kernel/modprobe` uinput
>  - try to use /dev/input/uinput again ; if it succeeds, fine
>    - else, assume that it really wasn't compiled, and hence fail.
>
> Triggering auto-load by creating one's own node.
> - try to use /dev/input/uinput ; if it suceeds, fine.
> - else, if errno != ENOENT, fail
> - else, (ENOENT)
>  - mknod /somewhere/safe/uinput c 10 223
>  - use /somewhere/safe/uinput ; if it succeeds, fine
>    - else, assume that it really wasn't compiled, and hence fail.
>
> I guess the same problem arises for loop devices and all such virtual
> devices...
>

Hi Samuel,

I am not sure about loop devices but for uinput there is most likely a
daemon that needs to be started so I would just load the module
(modprobe uinput) right from the same script that starts the daemon.
You do not need to check if module has already been loaded, just try
loading it unconditionally and use /dev/input/uinput.

--
Dmitry