![]() It also (re)starts the service, and calls the CompactSettings upon settings changes. It lets you set all parameters, and stores them as preferences. SettingsActivity - this is the main screen that is shown when starting the program. The daemon is able to detect that the settings file has changed and to re-read it automatically. The demon is not able to determine the devices to use, screen size and orientation, etc, so it reads these parameters from the settings.cnf file, that was prepared by the Java part. The daemon is started by the Java app as root, because it needs such permissions to read/write events directly from /dev/input/event N device drivers from the underlying Linux OS. It reads all its parameters from the compact settings file. pinball_buttons_mapper (aka the daemon) - this is the standalone C program, actually doing all the "real" job: it waits for keyboard events, and generates multitouch events (simulating finger touches on the screen). The diagram in this step is an UML class diagram, showing the principal classes and entities, and their relations. (*) see Architecture The final architecture is based on a daemon, that is, a small standalone program (written in C and hence very fast) communicating with a Java service. This proved slightly too slow and introduced a noticeable lag, so I opted for a daemon written in C, and configured by a Java app. ![]() ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |