[Development] Fixing input for eglfs and friends

[laszlo.p.agocs at nokia.com]

Hi,

Please do not merge the plug-ins. A monolithic "evdev" monster plug-in is not desirable and would certainly not classify as "generic" anymore.

The "static device discovery" should check the supported event types from the devices (this needs opening, an ioctl, and some bittesting so might not be lightning fast but on specific udev-less embedded devices it could be good enough). This is exactly what udev does too when it decides the device class (ID_INPUT_*). Although I'm not sure about the value this feature brings: if the embedded system does not have udev then its input device configuration is likely to be quite static so a simple hardcoded specification of the device nodes should be enough.

Furthermore sending key events from mouse buttons is not acceptable in any case. There might also be other type of input devices under /dev/input (sensors, tablets, etc.) so the classification cannot be avoided.

I somewhat disagree on the broken out of the box experience too: Specifying what input devices to use via -plugin parameters is perfectly fine on an embedded device because you will typically know what type of devices are or can get connected.

Those special "multi class" devices (like the scrollwheel on keyboard example) will usually result in multiple device nodes under /dev/input, one providing key events, the other the pointer ones.

Cheers,
Laszlo

________________________________________
From: development-bounces+laszlo.p.agocs=nokia.com at qt-project.org [development-bounces+laszlo.p.agocs=nokia.com at qt-project.org] on behalf of Zellner Johannes (Nokia-DXM/SiliconValley)
Sent: Wednesday, May 23, 2012 11:36 PM
To: development at qt-project.org
Subject: [Development] Fixing input for eglfs and friends

Hi,

as we are working on better support of embedded devices in Qt, we also are
tapping into the input handling.

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.

Also the udev part in platformsupport will get a fallback to detect devices at
startup.

Are there any concerns or better ways to solve the currently broken out-of-the
box experience with eglfs and such?


Johannes
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development