Refactor cospad to current standards and enable support for backlight keycodes

[zvecr]

Description

Refactor staryu to current standards;

• Use of '#pragma once
• Cleaned up default keymap

Rotated LAYOUT_gamepad_6x4 back to portrait in the Configurator to match the name and macro.

Enable support for backlight keycodes;

• Only on/off at the moment
  • Another instance for Fix #3566 use an hardware timer for software PWM stability #3615 as software PWM wont light the leds up at all
• Kept support for existing cospad_bl_led_* functions in case they are required for keymaps (maybe a fork)

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.
• 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).

[zvecr]

@Njiallu This change should allow you to update your detrus keymap to use the standard backlight functions or keycodes.

[noroadsleft]

Rotated LAYOUT_gamepad_6x4 back to portrait in the Configurator to match the name and macro.

This was a deliberate choice because for gamepad usage, it's supposed to be landscape:

Realistically, the layout macro should be 6 columns and 4 rows (physically; even though it says 6x4); I didn't edit the layout macro when I added the Configurator data for that layout.

[zvecr]

@noroadsleft I feel the name and layout Configurator should all correlate. From a conceptual point, rotating a board (where it makes sense) is something that could be entirely done in the Configurators UI.

Given 1 keymap already exists in the repo, a good short term compromise could be to add both 6x4 and 4x6. However i will also back out the change if its the consensus.

[noroadsleft]

I feel the name and layout Configurator should all correlate.

That's fair. I left the name because I would have had to edit additional files. I was comfortable doing that, but it wasn't relevant to my goal, so I left it alone. The macro could just leave off the layout dimensions (LAYOUT_gamepad, without specifying 6x4/4x6). The layout and corresponding keymap were submitted with that name.

From a conceptual point, rotating a board (where it makes sense) is something that could be entirely done in the Configurators UI.

That's exactly what I did Notice the first four keys are all "x": 5; landscape for gamepad puts the top (in portrait) to the right, so the "first row" is on the right-edge of the board.

If I had to do it again, I probably would rotate the layout macro and regenerate the info.json object.

#define LAYOUT_gamepad( \
	k50, k40, k30, k20, k10, k00, \
	k51, k41, k31, k21, k11, k01, \
	k52, k42, k32, k22, k12, k02, \
	k53, k43,   k23,    k13, k03  \
) \
{ \
	{k00, k01, k02, k03},   \
	{k10, k11, k12, k13},   \
	{k20, k21, k22, k23},   \
	{k30, k31, k32, KC_NO}, \
	{k40, k41, k42, k43},   \
	{k50, k51, k52, k53}    \
}

That would require editing the detrus keymap though.

[mechmerlin]

The rotated numpad is one of the reasons why I really wanted this board, unfortunately they don't actually sell that case anymore. By the time I decided I wanted one, it was sold out and the new and "improved" v2 was deemed the cospad case.

On that note, depending on rotation, bootmagic lite key will change position. Can we change its location based on the LAYOUT_macro in use? @drashna

[drashna]

@mechmerlin No, we can't. The best we can do is have a define that controls the bootmagic config.

[mechmerlin]

Thanks!