| 2013-10-10 05:51:46 |
Martin Pitt |
bug |
|
|
added bug |
| 2013-10-10 05:52:58 |
Thomas Voß |
mir: status |
New |
Triaged |
|
| 2013-10-10 05:53:05 |
Thomas Voß |
mir: importance |
Undecided |
Medium |
|
| 2013-10-10 05:53:09 |
Martin Pitt |
description |
Mir currently uses an inotify watch on /dev/input/ to detect hotplugged input events. That already led to race conditions like bug 1233944 and is generally not very robust. The canonical way to enumerate (for coldplugging at start) and get change notifications for (hotplugging events) hardware is to use uevents, which have a rather convenient client-side library "libudev". These are race free (i. e. you only get told after all udev rules got applied), very efficient (you only get wakeups if something actually changed), and easier to use as you get a lot of the actual information of the piece of hardware "for free" (i. e. already in the udev_device object).
http://www.freedesktop.org/software/systemd/libudev/ is the reference documentation (also in libudev-dev); you want the udev_monitor_* bits for receiving events, the enumerate bits for detecting devices at startup (coldplug), and udev_device_* for querying for attributes and properties (grep "udevadm info --export-db" for "input" about available properties, such as ID_INPUT_KEYBOARD=1).
http://www.signal11.us/oss/udev/ has an useful intro and example how to use this. I'm also happy to help you with reviewing code or answering any questions you have about the API.
The porting should not actually be too bad. Just like inotify, with pure libudev the monitor gives you an fd you select() on in the main loop, and if there's an event you just grab it with receive_device(). The libgudev library provides a very elegant integration into GLib main loops where you just connect the "uevent" signal to your handler, but I suppose Mir does not want to use this. |
Mir currently uses an inotify watch on /dev/input/ to detect hotplugged input events. That already led to race conditions like bug 1233944 and is generally not very robust. The canonical way to enumerate (for coldplugging at start) and get change notifications for (hotplugging events) hardware is to use uevents, which have a rather convenient client-side library "libudev". These are race free (i. e. you only get told after all udev rules got applied), very efficient (you only get wakeups if something actually changed), and easier to use as you get a lot of the actual information of the piece of hardware "for free" (i. e. already in the udev_device object).
http://www.freedesktop.org/software/systemd/libudev/ is the reference documentation (also in libudev-dev); you want the udev_monitor_* bits for receiving events, the enumerate bits for detecting devices at startup (coldplug), and udev_device_* for querying for attributes and properties (grep "udevadm info --export-db" for "input" about available properties, such as ID_INPUT_KEYBOARD=1).
http://www.signal11.us/oss/udev/ has an useful intro and example how to use this. I'm also happy to help you with reviewing code or answering any questions you have about the API.
The porting should not actually be too bad. Just like inotify, with pure libudev the monitor gives you an fd you select() on in the main loop, and if there's an event you just grab it with receive_device(). The libgudev library provides a very elegant integration into GLib main loops where you just connect the "uevent" signal to your handler, but I suppose Mir does not want to use this. Plus, the code should presumably get easier as you shouldn't need to actually open and query the input device any more; the udev properties and sysfs attributes should already tell you all you need to know. |
|
| 2013-10-10 05:53:10 |
Thomas Voß |
mir: importance |
Medium |
Low |
|
| 2013-10-10 05:53:30 |
Martin Pitt |
tags |
|
ubuntu-qa |
|
| 2013-10-10 05:55:35 |
Martin Pitt |
tags |
ubuntu-qa |
qa-touch |
|
| 2013-10-17 06:29:30 |
Daniel van Vugt |
summary |
Please move input detection to libudev |
[feature] Please move input detection to libudev |
|
| 2013-10-17 06:29:35 |
Daniel van Vugt |
tags |
qa-touch |
feature qa-touch |
|
| 2013-10-18 05:44:56 |
Daniel van Vugt |
summary |
[feature] Please move input detection to libudev |
[enhancement] Please move input detection to libudev |
|
| 2013-10-18 05:45:03 |
Daniel van Vugt |
tags |
feature qa-touch |
enhancement qa-touch |
|
| 2014-01-03 01:42:09 |
Daniel van Vugt |
tags |
enhancement qa-touch |
enhancement input qa-touch |
|
| 2014-01-07 20:58:43 |
kevin gunn |
description |
Mir currently uses an inotify watch on /dev/input/ to detect hotplugged input events. That already led to race conditions like bug 1233944 and is generally not very robust. The canonical way to enumerate (for coldplugging at start) and get change notifications for (hotplugging events) hardware is to use uevents, which have a rather convenient client-side library "libudev". These are race free (i. e. you only get told after all udev rules got applied), very efficient (you only get wakeups if something actually changed), and easier to use as you get a lot of the actual information of the piece of hardware "for free" (i. e. already in the udev_device object).
http://www.freedesktop.org/software/systemd/libudev/ is the reference documentation (also in libudev-dev); you want the udev_monitor_* bits for receiving events, the enumerate bits for detecting devices at startup (coldplug), and udev_device_* for querying for attributes and properties (grep "udevadm info --export-db" for "input" about available properties, such as ID_INPUT_KEYBOARD=1).
http://www.signal11.us/oss/udev/ has an useful intro and example how to use this. I'm also happy to help you with reviewing code or answering any questions you have about the API.
The porting should not actually be too bad. Just like inotify, with pure libudev the monitor gives you an fd you select() on in the main loop, and if there's an event you just grab it with receive_device(). The libgudev library provides a very elegant integration into GLib main loops where you just connect the "uevent" signal to your handler, but I suppose Mir does not want to use this. Plus, the code should presumably get easier as you shouldn't need to actually open and query the input device any more; the udev properties and sysfs attributes should already tell you all you need to know. |
Mir currently uses an inotify watch on /dev/input/ to detect hotplugged input events. That already led to race conditions like bug 1233944 and is generally not very robust. The canonical way to enumerate (for coldplugging at start) and get change notifications for (hotplugging events) hardware is to use uevents, which have a rather convenient client-side library "libudev". These are race free (i. e. you only get told after all udev rules got applied), very efficient (you only get wakeups if something actually changed), and easier to use as you get a lot of the actual information of the piece of hardware "for free" (i. e. already in the udev_device object).
http://www.freedesktop.org/software/systemd/libudev/ is the reference documentation (also in libudev-dev); you want the udev_monitor_* bits for receiving events, the enumerate bits for detecting devices at startup (coldplug), and udev_device_* for querying for attributes and properties (grep "udevadm info --export-db" for "input" about available properties, such as ID_INPUT_KEYBOARD=1).
http://www.signal11.us/oss/udev/ has an useful intro and example how to use this. I'm also happy to help you with reviewing code or answering any questions you have about the API.
The porting should not actually be too bad. Just like inotify, with pure libudev the monitor gives you an fd you select() on in the main loop, and if there's an event you just grab it with receive_device(). The libgudev library provides a very elegant integration into GLib main loops where you just connect the "uevent" signal to your handler, but I suppose Mir does not want to use this. Plus, the code should presumably get easier as you shouldn't need to actually open and query the input device any more; the udev properties and sysfs attributes should already tell you all you need to know.
also related to https://bugs.launchpad.net/mir/+bug/1238417 |
|
| 2014-02-17 05:52:41 |
Launchpad Janitor |
branch linked |
|
lp:~raof/mir/udevify-eventhub |
|
| 2014-02-17 06:08:47 |
Daniel van Vugt |
mir: status |
Triaged |
In Progress |
|
| 2014-02-17 06:08:55 |
Daniel van Vugt |
mir: assignee |
|
Chris Halse Rogers (raof) |
|
| 2014-02-17 06:08:58 |
Daniel van Vugt |
mir: milestone |
|
0.1.6 |
|
| 2014-02-28 03:46:03 |
Daniel van Vugt |
mir: milestone |
0.1.6 |
0.1.7 |
|
| 2014-03-14 05:37:30 |
Daniel van Vugt |
mir: milestone |
0.1.7 |
0.1.8 |
|
| 2014-03-16 11:16:56 |
Anca Emanuel |
bug |
|
|
added subscriber Anca Emanuel |
| 2014-03-17 10:13:03 |
PS Jenkins bot |
mir: status |
In Progress |
Fix Committed |
|
| 2014-04-02 09:01:01 |
Daniel van Vugt |
mir: status |
Fix Committed |
Fix Released |
|
| 2014-04-02 09:02:12 |
Daniel van Vugt |
mir (Ubuntu): status |
New |
Triaged |
|
| 2014-04-02 09:02:17 |
Daniel van Vugt |
mir (Ubuntu): importance |
Undecided |
Low |
|
| 2014-04-14 23:33:17 |
Launchpad Janitor |
mir (Ubuntu): status |
Triaged |
Fix Released |
|
| 2014-04-14 23:42:12 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/mir |
|
