Getting touchpanel module ready for real devices #6
Conversation
The current emulator implementation is using the evdev input protocol which is appropiate for other devices as well so we make it unrelated to the emulator here. Differences between different target machines (and emulator) should be implemented as config options. Open-webOS-DCO-1.0-Signed-off-by: Simon Busch <[email protected]>
* read screen size when not defined by machine config from framebuffer * define static screen size for qemuarm and qemux86 machines Open-webOS-DCO-1.0-Signed-off-by: Simon Busch <[email protected]>
…device The evdev implementation should be suitable for most devices until we have a real multi touch implementation for the MT protocol. Open-webOS-DCO-1.0-Signed-off-by: Simon Busch <[email protected]>
ghost
assigned 
|
I like this change as it is heading in the same direction I was planning in order to extend the qemux86 touchpanel functionality in order to also support VirtualBox (which is very similar in how it supports the emulated touchpanel, yet different enough to require this module to become more generic). I'd like to enhance (or patch) the existing qemux86 UDEV support in OE to also recognize the VirtualBox (emulated) touchpanel to create a symlink at /dev/input/touchscreen0 (as currently happens for the qemu emulator) and likewise for any other devices that generate "standard" (enough) touchscreen events). In addition, there are a few subtle differences in the events from VirtualBox (IIRC, VirtualBox generates button events rather than pen down events) that will require minor changes in order to support both VirtualBox and Qemu, but might be helpful for supporting other devices as well. BTW, I'd love to see some examples of the events (e.g. from evtest) from some of the real (current porting target) devices. |
|
See the discussion in the base commit for this set of 6 pull-requests here #1 |
|
Understood, but I think this touchpanel change might stand on its own (or should be made to) and if so should be considered separately from the others since touchpanel support is critical for being able to interact with any port to a new target (be it VirtualBox or a real device). |
|
The change to qemux86.cmake introduces a new WEBOS_MACHINE_IMPL value ("device") which is
How would it be supplied in, for example, a custom build (with additional layers) without modifying the nyx-modules recipe to specifically pass it in? This needs to be addressed at a more general level, with build-webos support for it. I have no objection to the change per se, but it needs to go in as part of a comprehensive rework, not piecemeal. |
|
I believe the intention here is to introduce additional for a new "device" machine first in this component, so that a "device" machine could then be defined (presumably in the webos-ports layer) and used without having to instead call a device build an "emulator" in order to use this non-emulator-specific touchpanel code. The test for "device" is in addition to the test for "emulator" so I don't see that this breaks any of the existing "emulator" support or force any changes in meta-webos in order to be (or stay) compatible with this change. Perhaps we should come up with a better machine name than "device" (which is pretty generic). How about "evdevice" to indicate a machine implementation that supports standard evdev touchpanel (and keyboard) events? Or (if an "evdevice" still needs more machine-specific pieces), then perhaps we need to come up with a way to incorporate more general nyx components like an evdev touchpanel component into a more specific machine definition (than a generic "device" machine). |
|
I introduced the "device" value for the WEBOS_MACHINE_IMPL variable as I was missing a differentiation between a real target device and the emulator in nyx-modules. As of right meta-webos defines WEBOS_MACHINE_IMPL = "emulator" in it's distro configuration so it's so for every component when building for a real target device to the wrong value. To get it set to "device" we're just setting it in the nyx-modules recipe to this value. It's more a hack than a solution but I wanted it to stay away from my machine layer as distro things are nothing that should go into machine layers. If there wasn't a real plan yet for the WEBOS_MACHINE_IMPL variable about how it should be used, we have to formulate one as it will some serious problem how we differentiate between a real target device and the emulator. I don't like using "evdev" as possible value as the WEBOS_MACHINE_IMPL is used for the other modules as well to find out for what we're build: emulator or device |
|
In case anyone's wondering, there's a compete rework of the way nyx-modules builds on our to-do list. Unfortunately, or not depending on how eager you are for this change, there's a number of other things on that list as well 8) |
|
Any news? |
This is mainly about getting the touchpanel module ready for real devices. Commit messages will tell the details.
Please tell me if you have any questions about the implementation.
regards,
Simon