Add function to support split-keyboard in rgblight.[ch].

[mtei]

Description

The purpose of this PR is to add to quantum/rgblight.[ch] a function to synchronize RGB information provided to the transport layer for split keyboards. (Changes in transport layer of split keyboard are outside the scope of this PR.)

The synchronization feature is enabled in config.h by declaring #define RGBLIGHT_SPLIT.

The following functions are enabled by declaring #define RGBLIGHT_SPLIT.

#ifdef RGBLIGHT_SPLIT
  #define RGBLIGHT_STATUS_CHANGE_MODE (1<<0)
  #define RGBLIGHT_STATUS_CHANGE_HSVS (1<<1)
  #define RGBLIGHT_STATUS_CHANGE_TIMER (1<<2)
  #define RGBLIGHT_STATUS_ANIMATION_TICK (1<<3)

  typedef struct _rgblight_syncinfo_t {
    rgblight_config_t config;
    rgblight_status_t status;
  } rgblight_syncinfo_t;

  /* for split keyboard master side */
  uint8_t rgblight_get_change_flags(void);
  void rgblight_clear_change_flags(void);
  void rgblight_get_syncinfo(rgblight_syncinfo_t *syncinfo);
  /* for split keyboard slave side */
  void rgblight_update_sync(rgblight_syncinfo_t *syncinfo, bool write_to_eeprom);
#endif

Types of changes

• Core
• Bugfix
• New Feature
• Enhancement/Optimization
• Keyboard (addition or update)
• Keymap/Layout/Userspace (addition or update)
• Documentation

Checklist:

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document. (https://docs.qmk.fm/#/contributing)
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[Lenbok]

Is the purpose of this PR to enable synchronization/transmission of global timestamp between split halves to synchronize animations?

BTW, If you are not already aware of it, you may want to look at #4974 which removes the BACKLIT_DIRTY/RGB_DIRTY flags in favour of detecting value changes implicitly. (edit: I see you commented earlier on that PR, so are aware of it)

[mtei]

Is the purpose of this PR to enable synchronization/transmission of global timestamp between split halves to synchronize animations?

One of the aims of this PR is to enable the transmission of some synchronization information between the divided half to synchronize the animation.

BTW, If you are not already aware of it, you may want to look at #4974 which removes the BACKLIT_DIRTY/RGB_DIRTY flags ....

Yes, I know the #4974. This PR needs to have #4974 merged first, to delete global variable RGB_DIRTY.

[Lenbok]

I would love to see the i2c animations working nicely. I mentioned in #773 (comment) that the way that animation step times are currently computed means that any execution delays will offset the animation, leading to loss of visual synchronization. This fits in with my recent observations that the master side does tend to execute animations slower than the slave side. I just gave the delay-independent scheduling idea a quick test with:

Lenbok@092fa43

and with that change, the animations between the two halves stay synchronized very well (although having absolute step times means the animation tries to catch up when time is spent away from the animation e.g. on some other mode or with it switched off, so some reset/restart method is needed)

Explicit synchronization between halves of the kind you are working towards here would be only be needed under special circumstances, e.g. to init the animation to the starting frame when the mode changes.

[mtei]

I intended to make the same changes you made below.

-   last_timer = timer_read();
+   last_timer += interval_timer;

[Lenbok]

Quick @drashna, merge before another conflict creeps in!

[drashna]

Merged!
Waiting on Travis for 5509. But counting the seconds :D