[Development] Fixing input for eglfs and friends

[Jørgen Lind]

Hi
> The initial issue with our current input handling for platforms like eglfs, 
> which do not handle input on its own, is, that we have input plugins for 
> mouse/keyboard/touch (evdev), which are seperate from each other.
> So one needs to specify "-plugin evdevkeyboard" on the commandline in order to 
> get keyboard input. The evdev* plugins are trying to use udev to detect all 
> available devices and also handle the remove and add events for such input 
> devices.
> To get rid of the -plugin argument we would like to create the 
> keyboard/mouse/touch plugins always from eglfs directly. This works fine when 
> udev is present, but fails badly without udev, as all plugins currently 
> default to event0, if you dont specify the device explicitly again on the 
> commandline.
> A fix would be to add a fallback device discovery, which picks up all available 
> devices without udev and creates the specific keyboard/mouse handler.
> But this raised the problem of the lack of detecting if its a keyboard or 
> mouse or whatever from the evdev side, as evdev does not have such a 
> destinction. It just handles input events and does not care if its a key or 
> mouse event. Thus udev has some tricks to probe different attributes through 
> evdev to get the device type, which I dont really want to pull into our code.
> 
> For those reasons, I will go ahead and merge evdevkeyboard and evdevmouse as a 
> start. The merge potentially also adds the ability to properly send key and 
> mouse events from devices, that have both event types (like a scroll wheel on 
> the keyboard)
>  I cannot merge evdevtouch for now, since I dont have a proper touchdevice to 
> test with.
I think evdev is excelent, but eglfs isn't linux specific. When we made
eglfs it was intended as a platform which also could be copied and
altered to fix special embedded deviceses needs. Moving all this logic
into the plugins just so that we wont need to add -plugin at the command
line seems the wrong direction to take.

I think we should focus on keeping eglfs as small as possible, but
keeping the readability of the code, so that the entry level for "extending"
eglfs will be low.

Also what about the embedded devices that uses some other input api than
evdev. Do we include code for them in eglfs?

To solve the no -plugin problem, can't we do something like we do for
the platform plugins, ie. have a define which can contain a "list" of
plugins which should be loaded as default. Theres some interesting
semantics to this, but that can be left to the guy that implements
this to solve:)

Jørgen