Rework keys module and add a common device implementation #1
Conversation
It makes no sense to have the same code in more than one module so we're splitting out the common input device handling code and just put the specific key handling into module specific code section. Open-webOS-DCO-1.0-Signed-off-by: Simon Busch <[email protected]>
For real target devices there is only a small subset of keys we're able to use. This is known handled and mapped within a device specific implementation which is separated from the emulator one. Open-webOS-DCO-1.0-Signed-off-by: Simon Busch <[email protected]>
|
@morphis , These pull requests are fairly sweeping and will need to be considered in detail. We are just looking at ways to restructure nyx-modules. The current approach was designed around supporting a relatively small number of target platforms, and will be unworkable if the community wants to add support for hundreds of different phones, tablets, or what have you. We're currently leaning towards some form of platform configuration file which specifies, for example, the type of touchscreen, LEDs, etc that need to be supoprted. That way the commonality will be more obvious, and easier to leverage. So, give us a little while on this set please. |
Yeah thats a problem. Within the code I submitted here is no machine
If you take a look at my other pull-requests for nyx-modules I changed
For sure. Do you already have a concrete timeline for hits? |
|
One other point that I think is often missed, simply because "we've always done it that way". There is no requirement that there be "one true nyx-modules component". Each "module" is simply a .so with a specific file name format, installed into a specified directory (which you can now get from the nyx.pc file). So, there can, at the extreme, be a one-repo-per-module approach, or for example, a nyx-modules-samsung or nyx-modules-sensation component. Thus a particular "bsp" could almost specify which modules to build by just including certain repos. Unlike the rest of the OS, Nyx, or more precisely the modules, are meant to be aware of the platform/device/machine that is being targeted. They are, after all, the platform abstraction mechanism for Open webOS. But that's a goal, rather than a complete reality right now. As we plow through the mass of code which was webOS 3.0.5, there are many cases where individual components were machine-aware in different ways, and we need to enhance nyx (and the modules) over time to remove those dependencies. Just look at the number of recipes which inherit from webos_machine_dep, webos_impl_dep, or webos_coreos_dep to see what I mean. Just as an example, we've now realized we need to add a nyx API for rebooting the device (specifically so we can deal with booting into DFU or DUT modes etc on "real" hardware) |
|
As for timeline, just starting on analyzing it. If I can define the way we really want to restructure nyx-modules with enough clarity for someone outside the offices to take it on .... you interested? (I said we'd take whatever help we can get 8) Your changes are already heading in the right direction, but of course we need to be thinking beyond the "quick fix". And right now, we're understaffed. I can generate more projects, faster, than I have the resources to execute. (Did I mention we're hiring?) Unfortunately, I'm going to need at least a week to clarify our thoughts on this and write it up. |
Interested yes, but I am running a little bit out of time already with
I am totally ok with this. Preferring real and right solutions over
Ok, please do this and take the time it needs to get it right :) |
The included commits separating common functionality of the keys module from target specific. Furthermore it's implementing a device variant of the module for WEBOS_TARGET_MACHINE_IMPL = "device" configuration setting.
Please tell me if you have any questions about the implementation.
regards,
Simon