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....@qt-project.org [development-bounces+laszlo.p.agocs=nokia....@qt-project.org] on behalf of Zellner Johannes (Nokia-DXM/SiliconValley) Sent: Wednesday, May 23, 2012 11:36 PM To: development@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
