Network API extended

[Lucashsmello]

Some functionalities that GIMX may provide for usage by other processes using a network API:

• Request GIMX Status:
  • Initializing or Running normally.
  • Connection status with devices, such as consoles, controllers and adapters.
• Request Turning off
• Edit configuration temporarily on real-time (similar to --curses option). This may include save it too.

For requesting GIMX status, i am thinking of implementing using an event driven protocol where a listener is registered at GIMX startup, so that GIMX inform its status when something changes.

Related to this forum post

I will probably implement this on branch master on my GIMX fork: https://github.com/Lucashsmello/GIMX. Do you accept pull Requests?

Any suggestions and ideas would be appreciated.

[matlo]

Sorry for the late reply. I am very busy these days.

I can accept pull requests, but you have to grant me permission to make closed-source derivatives of your work. I haven't done any closed-source version yet, but I want to be free to do so.

A good start point would be to make a library in shared/gimxnetwork handling all network IOs.

[Lucashsmello]

I no more pretend to do a event driven protocol for listening status (not in a near future). Check if gimx process has started and check if gimx has started listening on port 51914 is enough for my application. However, i'am trying to implement some new functionalities on the network protocol:

• Exit GIMX (equivalent to shift+ESC)
• Change Profile
• Change and get sensibility, dx, dy and other configurations without saving.
• Save changed configs.

I am thinking to implement by creating two additional network packages types in shared/gimx-network-protocol/protocol.h:

typedef enum {
    E_NETWORK_PACKET_CONTROLLER,
    E_NETWORK_PACKET_IN_REPORT,
	E_NETWORK_PACKET_IN_SYSTEM_COMMAND,
	E_NETWORK_PACKET_IN_CONFIG
} e_network_packet_type;

• E_NETWORK_PACKET_IN_SYSTEM_COMMAND: Currently will only includes a command to exit gimx. Maybe a restart/reload command may be useful.
• E_NETWORK_PACKET_IN_CONFIG: Change configuration such as sensibility and change profile. The implementation can be similar to E_NETWORK_PACKET_IN_REPORT:

typedef struct PACKED
{
  uint8_t packet_type; // E_NETWORK_PACKET_IN_CONFIG
  uint8_t nbConfigs; // number of elements in the following array
  struct PACKED
  {
    uint8_t id; // Configuration id. Each parameter (dx, dy, sensibility, ...) has a unique id. 
    uint32_t value; //Value to set. Network byte order
  } configs[0];
} s_network_packet_in_config;

What do you think? I don't see any problem except that in future E_NETWORK_PACKET_IN_SYSTEM_COMMAND struct/package may have to be modified to include a specific command that has parameter.

[matlo]

gimx has root permissions (setuid). Making it execute any command is a security issue.

Regarding the second feature, why not having a struct with all settings instead of an array? Another remark: the value should be a decimal.

[Lucashsmello]

gimx has root permissions (setuid). Making it execute any command is a security issue.

I will keep that in mind. I will avoid calling system(.) or equivalent functions at all costs. For exiting gimx, just calling set_done(); is enough (function from mainloop.c).

Regarding the second feature, why not having a struct with all settings instead of an array?

For compatibility reasons, when a new setting is added or changed. Currently, i already pretending to add a lot of new settings to gimx in order to improve mouse2axis translation. Each FPS game has it own strange way of translating the axes input to the character rotation speed. I implemented some of this new settings in my gimx fork, which currently is a mess. I will organize my code some day. I will explain all new settings in a new post/thread/issue.

A alternative way is a struct with all settings (like you said) and a version id:

typedef struct PACKED
{
  uint8_t packet_type; // E_NETWORK_PACKET_IN_CONFIG
  uint16_t version; // Maybe uint16_t is too much.
  float sensibility;
  int8_t dead_zone_X;
  int8_t dead_zone_Y;
  (...)
} s_network_packet_in_config;

[Lucashsmello]

Now i see that the name E_NETWORK_PACKET_IN_SYSTEM_COMMAND is not good, makes people think that will run a os command, using system(.) for example. Maybe E_NETWORK_PACKET_IN_CONTROL?

Also i changed my mind. Compatibility between versions do not worth the work. All settings in a single struct should be used.

[matlo]

Or E_NETWORK_PACKET_EXIT?

A plain struct is good enough. We can extend it if needed, and deprecate some of the fields as well.