New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace Joystick Polling with UDev #96

Closed
dvdhrm opened this Issue Sep 17, 2011 · 9 comments

Comments

Projects
None yet
3 participants
@dvdhrm

dvdhrm commented Sep 17, 2011

Running "strace" on an SFML binary gives me the following lines every frame:

stat("/dev/input/js0", 0x7fff14b3b870) = -1 ENOENT (No such file or directory)
stat("/dev/input/js1", 0x7fff14b3b870) = -1 ENOENT (No such file or directory)
stat("/dev/input/js2", 0x7fff14b3b870) = -1 ENOENT (No such file or directory)
stat("/dev/input/js3", 0x7fff14b3b870) = -1 ENOENT (No such file or directory)
stat("/dev/input/js4", 0x7fff14b3b870) = -1 ENOENT (No such file or directory)
stat("/dev/input/js5", 0x7fff14b3b870) = -1 ENOENT (No such file or directory)
stat("/dev/input/js6", 0x7fff14b3b870) = -1 ENOENT (No such file or directory)
stat("/dev/input/js7", 0x7fff14b3b870) = -1 ENOENT (No such file or directory)

(this is triggered by sfWindow_PollEvent() btw.)
It seems a bit overhead for me to check for 8 files every frame? Why not using hotplugging with libudev to watch for new joystick devices? Also, /dev/input/js* names may change on other linux distributions and udev is the only way to reliably get device paths.

Regards
David

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Sep 17, 2011

Member

Thanks, I didn't know about it.

Is libudev standard, or will people have to install it explicitely in order to use SFML?

Does is require to configure joysticks, or does it work out of the box?

Does it work on FreeBSD?

Member

LaurentGomila commented Sep 17, 2011

Thanks, I didn't know about it.

Is libudev standard, or will people have to install it explicitely in order to use SFML?

Does is require to configure joysticks, or does it work out of the box?

Does it work on FreeBSD?

@dvdhrm

This comment has been minimized.

Show comment
Hide comment
@dvdhrm

dvdhrm Sep 17, 2011

UDev is linux specific. Neither BSD or other UNIXes support it. libudev is crucial for every modern linux distribution (only embedded systems use other /dev setups). It is responsible of setting up /dev and keeping it up to date with all hotplugged devices. It reads the kernel uevent netlink socket and reacts on hotplugging events. You probably won't find any init-system that does not depend on udev so it is installed on every system.

X11 also switched to udev after abandoning HAL. So it is definitely the way to got. However, if you never used it, it will probably be a bigger patch for SFML. If I have time I will try to write a patch and send a pull request, but I just want to check that neither of you is working on better hotplugging support (instead of continuous polling).

FreeBSD has devd, but I am not very familiar with it so this would be linux specific.

dvdhrm commented Sep 17, 2011

UDev is linux specific. Neither BSD or other UNIXes support it. libudev is crucial for every modern linux distribution (only embedded systems use other /dev setups). It is responsible of setting up /dev and keeping it up to date with all hotplugged devices. It reads the kernel uevent netlink socket and reacts on hotplugging events. You probably won't find any init-system that does not depend on udev so it is installed on every system.

X11 also switched to udev after abandoning HAL. So it is definitely the way to got. However, if you never used it, it will probably be a bigger patch for SFML. If I have time I will try to write a patch and send a pull request, but I just want to check that neither of you is working on better hotplugging support (instead of continuous polling).

FreeBSD has devd, but I am not very familiar with it so this would be linux specific.

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Sep 17, 2011

Member

You probably won't find any init-system that does not depend on udev so it is installed on every system

I was asking about libudev, not udev.

However, if you never used it, it will probably be a bigger patch for SFML

It doesn't look very complicated (I found this tutorial: http://www.signal11.us/oss/udev/ ).

Member

LaurentGomila commented Sep 17, 2011

You probably won't find any init-system that does not depend on udev so it is installed on every system

I was asking about libudev, not udev.

However, if you never used it, it will probably be a bigger patch for SFML

It doesn't look very complicated (I found this tutorial: http://www.signal11.us/oss/udev/ ).

@dvdhrm

This comment has been minimized.

Show comment
Hide comment
@dvdhrm

dvdhrm Sep 17, 2011

I was asking about libudev, not udev.

Sorry, I forgot to mention that udev depends on libudev. So both should be available and already installed on all linux distributions. See http://packages.debian.org/squeeze/udev for instance (libudev0 is listed as dependency).
Many distributions even package libudev and udev as one single install-target.

However, if you never used it, it will probably be a bigger patch for SFML

It doesn't look very complicated (I found this tutorial: http://www.signal11.us/oss/udev/ ).

I don't know the SFML code very well so I didn't want to make any assumptions about it. But if you think you can integrate it easily, I'd be happy, too.
libudev is a fairly simple library. A udev_monitor and udev_enumeration object would be enough for every sfWindow structure and adding the udev_monitor's FD to the event queue.
And when libudev reports a new joystick, one could simply enable that joystick and read the events from the new /dev/input/jsX file instead of reading all jsX files from 0-7.

dvdhrm commented Sep 17, 2011

I was asking about libudev, not udev.

Sorry, I forgot to mention that udev depends on libudev. So both should be available and already installed on all linux distributions. See http://packages.debian.org/squeeze/udev for instance (libudev0 is listed as dependency).
Many distributions even package libudev and udev as one single install-target.

However, if you never used it, it will probably be a bigger patch for SFML

It doesn't look very complicated (I found this tutorial: http://www.signal11.us/oss/udev/ ).

I don't know the SFML code very well so I didn't want to make any assumptions about it. But if you think you can integrate it easily, I'd be happy, too.
libudev is a fairly simple library. A udev_monitor and udev_enumeration object would be enough for every sfWindow structure and adding the udev_monitor's FD to the event queue.
And when libudev reports a new joystick, one could simply enable that joystick and read the events from the new /dev/input/jsX file instead of reading all jsX files from 0-7.

@ghost ghost assigned LaurentGomila Sep 17, 2011

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Sep 17, 2011

Member

I think it will be easy to change the Linux implementation to use libudev.

Thank you very much for your help.

Member

LaurentGomila commented Sep 17, 2011

I think it will be easy to change the Linux implementation to use libudev.

Thank you very much for your help.

@alexandre-janniaux

This comment has been minimized.

Show comment
Hide comment
@alexandre-janniaux

alexandre-janniaux Sep 29, 2011

And what about XInput2 ? It use the X11 server so it may work on BSD and Linux (not Mac) and uses udev or maybe whatever X11 uses, and supports lots of joystick likes XBox joysticks, and in the future sensitive screen (eg: ubuntu).

I don't really know anything about it, but it may be a good alternative.

alexandre-janniaux commented Sep 29, 2011

And what about XInput2 ? It use the X11 server so it may work on BSD and Linux (not Mac) and uses udev or maybe whatever X11 uses, and supports lots of joystick likes XBox joysticks, and in the future sensitive screen (eg: ubuntu).

I don't really know anything about it, but it may be a good alternative.

@dvdhrm

This comment has been minimized.

Show comment
Hide comment
@dvdhrm

dvdhrm Sep 30, 2011

Yes, that would be another option. But as long as SFML uses its own abstraction layer of input events, I don't think it makes sense to have XI2 as another abstraction layer in the backend.
Anyway, both are preferable over polling a static list of input devices.

dvdhrm commented Sep 30, 2011

Yes, that would be another option. But as long as SFML uses its own abstraction layer of input events, I don't think it makes sense to have XI2 as another abstraction layer in the backend.
Anyway, both are preferable over polling a static list of input devices.

@alexandre-janniaux

This comment has been minimized.

Show comment
Hide comment
@alexandre-janniaux

alexandre-janniaux Oct 4, 2011

sure, but if you are on windows XI2 isn't here, so you need an abstraction layer in all case ;) .
the advantages of XI2 is that it can use whatever exist, works for any X11 system and finally, you don't need another lib to handle any other input (like sensitive screen).

but I don't know anything about libudev, it may be the most used, maybe on android and mac too ?

alexandre-janniaux commented Oct 4, 2011

sure, but if you are on windows XI2 isn't here, so you need an abstraction layer in all case ;) .
the advantages of XI2 is that it can use whatever exist, works for any X11 system and finally, you don't need another lib to handle any other input (like sensitive screen).

but I don't know anything about libudev, it may be the most used, maybe on android and mac too ?

@LaurentGomila

This comment has been minimized.

Show comment
Hide comment
@LaurentGomila

LaurentGomila Jun 25, 2013

Member

I used libudev successfully, however it always reports joysticks twice: once as /dev/input/js* and once as /dev/input/event*. I don't know how to differenciate them, other than testing if their name contains "js" or "event" -- but this is exactly what libudev was supposed to avoid me to do.

After reading the kernel doc, I can see that /dev/input/js* nodes have been the standard for a while, so I think I'll stick with that. To solve the initial problem, I'll use inotify to avoid the expensive polling.

Member

LaurentGomila commented Jun 25, 2013

I used libudev successfully, however it always reports joysticks twice: once as /dev/input/js* and once as /dev/input/event*. I don't know how to differenciate them, other than testing if their name contains "js" or "event" -- but this is exactly what libudev was supposed to avoid me to do.

After reading the kernel doc, I can see that /dev/input/js* nodes have been the standard for a while, so I think I'll stick with that. To solve the initial problem, I'll use inotify to avoid the expensive polling.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment