[11:29] <alan_g> anpok: do we ever want multiple input modules? (I'm wondering if probe_input_platforms() must return a collection - things are simpler if there can be only one.)
[12:00] <anpok> alan_g: hm at some point I thought it would be useful.. but at the moment it is rather causing troubles when both x11 and evdev are in use..
[12:00] <anpok> in other words there is currently no use case for it
[12:01] <anpok> alan_g: by changing that you would avoid this problem: https://bugs.launchpad.net/mir/+bug/1528110
[12:02] <anpok> which only happens when you run as root from an x11 terminal..
[12:02] <alan_g> anpok: and it would greatly simplify addressing the issue Chris and I have been discussing in https://code.launchpad.net/~alan-griffiths/mir/fix-1543049/+merge/287644
[12:04] <alan_g> Would the hypothetical "useful" scenaro be better addressed by an input module that "talked" to multiple drivers underneath?
[12:08] <anpok> alan_g: I think just changing the code to yield a single result is fine untill we find a use case in which it would be "useful" -
[12:09] <anpok> or actually the use case was for unity8 to inject user input..
[12:09] <anpok> but they just changed the setup..
[12:10] <anpok> and they are currently allowed to use uinput to inject it there..
[12:10] <anpok> then again .. there are various places were we could allow input injection..
[12:19] <alan_g> Multiple "platforms" isn't how I'd support injection. Weird devices that use strange drivers mixed with normal ones, maybe, if that actually happens and matters.