]> git.donarmstrong.com Git - qmk_firmware.git/commitdiff
resolves conflicts in rgblight.c
authorJack Humbert <jack.humb@gmail.com>
Tue, 26 Apr 2016 17:48:36 +0000 (13:48 -0400)
committerJack Humbert <jack.humb@gmail.com>
Tue, 26 Apr 2016 17:48:36 +0000 (13:48 -0400)
# Conflicts:
# quantum/rgblight.c

1  2 
README.md
quantum/rgblight.c

diff --combined README.md
index 749c97c8f1dc5012adcfa3c756202a378a02bead,ba65edb5687c93bb999f8eab614cbe3f59d3e1c2..d20557f597e9794218e66d932ec3abb9c2cc27c1
+++ b/README.md
@@@ -1,11 -1,13 +1,13 @@@
- # Quantum MK Firmware
+ # Quantum Mechanical Keyboard Firmware
  
- This is a keyboard firmware based on the [tmk_keyboard firmware](http://github.com/tmk/tmk_keyboard) with some useful features for Atmel AVR controllers, and more specifically, the [OLKB product line](http://olkb.co) and the [ErgoDox EZ](http://www.ergodox-ez.com) keyboard.
+ This is a keyboard firmware based on the [tmk_keyboard firmware](http://github.com/tmk/tmk_keyboard) with some useful features for Atmel AVR controllers, and more specifically, the [OLKB product line](http://olkb.co), the [ErgoDox EZ](http://www.ergodox-ez.com) keyboard, and the [Clueboard product line](http://clueboard.co/).
  
  QMK is developed and maintained by Jack Humbert of OLKB with contributions from the community, and of course, TMK.
  
  This documentation is edited and maintained by Erez Zukerman of ErgoDox EZ. If you spot any typos or inaccuracies, please [open an issue](https://github.com/jackhumbert/qmk_firmware/issues/new).
  
+ The OLKB product firmwares are maintained by Jack, the Ergodox EZ by Erez, and the Clueboard by [skullydazed](/skullydazed).
  ## Important background info: TMK documentation
  
  The documentation below explains QMK customizations and elaborates on some of the more useful features of TMK. To understand the base firmware, and especially what *layers* are and how they work, please see [TMK_README.md](/TMK_README.md).
  * If you're looking to customize a keyboard that currently runs QMK or TMK, find your keyboard's directory under `keyboard/` and run the make commands from there.
  * If you're looking to apply this firmware to an entirely new hardware project (a new kind of keyboard), you can create your own Quantum-based project by using `./new_project.sh <project_name>`, which will create `/keyboard/<project_name>` with all the necessary components for a Quantum project.
  
 +### Makefile Options
 +
  You have access to a bunch of goodies! Check out the Makefile to enable/disable some of the features. Uncomment the `#` to enable them. Setting them to `no` does nothing and will only confuse future you.
  
      BACKLIGHT_ENABLE = yes # Enable keyboard backlight functionality
      MIDI_ENABLE = yes      # MIDI controls
 -    # UNICODE_ENABLE = yes # Unicode support - this is commented out, just as an example. You have to use #, not //
 +    UNICODE_ENABLE = no    # <-- This is how you disable an option, just set it to "no"
      BLUETOOTH_ENABLE = yes # Enable Bluetooth with the Adafruit EZ-Key HID
  
 +### Customizing Makefile options on a per-keymap basis
 +
 +If your keymap directory has a file called `makefile.mk` (note the lowercase filename, and the `.mk` extension), any Makefile options you set in that file will take precedence over other Makefile options (those set for Quantum as a whole or for your particular keyboard).
 +
 +So let's say your keyboard's makefile has `CONSOLE_ENABLE = yes` (or maybe doesn't even list the `CONSOLE_ENABLE` option, which would cause it to revert to the global Quantum default). You want your particular keymap to not have the debug console, so you make a file called `makefile.mk` and specify `CONSOLE_ENABLE = no`.
 +
  ## Quick aliases to common actions
  
  Your keymap can include shortcuts to common operations (called "function actions" in tmk).
@@@ -106,27 -100,6 +108,27 @@@ We've added shortcuts to make common mo
  
  `DF(layer)` - sets default layer to *layer*. The default layer is the one at the "bottom" of the layer stack - the ultimate fallback layer. This currently does not persist over power loss. When you plug the keyboard back in, layer 0 will always be the default. It is theoretically possible to work around that, but that's not what `DF` does.
  
 +### Prevent stuck modifiers
 +
 +Consider the following scenario:
 +
 +1. Layer 0 has a key defined as Shift.
 +2. The same key is defined on layer 1 as the letter A.
 +3. User presses Shift.
 +4. User switches to layer 1 for whatever reason.
 +5. User releases Shift, or rather the letter A.
 +6. User switches back to layer 0.
 +
 +Shift was actually never released and is still considered pressed.
 +
 +If such situation bothers you add this to your `config.h`:
 +
 +    #define PREVENT_STUCK_MODIFIERS
 +
 +This option uses 5 bytes of memory per every 8 keys on the keyboard
 +rounded up (5 bits per key). For example on Planck (48 keys) it uses
 +(48/8)\*5 = 30 bytes.
 +
  ### Remember: These are just aliases
  
  These functions work the same way that their `ACTION_*` functions do - they're just quick aliases. To dig into all of the tmk ACTION_* functions, please see the [TMK documentation](https://github.com/jackhumbert/qmk_firmware/blob/master/tmk_core/doc/keymap.md#2-action).
@@@ -207,27 -180,6 +209,27 @@@ This will clear all mods currently pres
  
  This will clear all keys besides the mods currently pressed.
  
 +* `update_tri_layer(layer_1, layer_2, layer_3);`
 +
 +If the user attempts to activate layer 1 AND layer 2 at the same time (for example, by hitting their respective layer keys), layer 3 will be activated. Layers 1 and 2 will _also_ be activated, for the purposes of fallbacks (so a given key will fall back from 3 to 2, to 1 -- and only then to 0).
 +
 +#### Naming your macros
 +
 +If you have a bunch of macros you want to refer to from your keymap, while keeping the keymap easily readable, you can just name them like so:
 +
 +```
 +#define AUD_OFF M(6)
 +#define AUD_ON M(7)
 +#define MUS_OFF M(8)
 +#define MUS_ON M(9)
 +#define VC_IN M(10)
 +#define VC_DE M(11)
 +#define PLOVER M(12)
 +#define EXT_PLV M(13)
 +```
 +
 +As was done on the [Planck default keymap](/keyboard/planck/keymaps/default/keymap.c#L33-L40)
 +
  #### Timer functionality
  
  It's possible to start timers and read values for time-specific events - here's an example:
@@@ -244,91 -196,11 +246,91 @@@ if (timer_elapsed(key_timer) < 100) 
  
  It's best to declare the `static uint16_t key_timer;` outside of the macro block (top of file, etc). 
  
 +#### Example 1: Single-key copy/paste (hold to copy, tap to paste)
 +
 +With QMK, it's easy to make one key do two things, as long as one of those things is being a modifier. :) So if you want a key to act as Ctrl when held and send the letter R when tapped, that's easy: `CTL_T(KC_R)`. But what do you do when you want that key to send Ctrl-V (paste) when tapped, and Ctrl-C (copy) when held?
 +
 +Here's what you do:
 +
 +
 +```
 +static uint16_t key_timer;
 +
 +const macro_t *action_get_macro(keyrecord_t *record, uint8_t id, uint8_t opt)
 +{
 +      switch(id) {
 +        case 0: {
 +            if (record->event.pressed) {
 +                key_timer = timer_read(); // if the key is being pressed, we start the timer.
 +            } 
 +            else { // this means the key was just released, so we can figure out how long it was pressed for (tap or "held down").
 +                if (timer_elapsed(key_timer) > 150) { // 150 being 150ms, the threshhold we pick for counting something as a tap.
 +                    return MACRO( D(LCTL), T(C), U(LCTL), END  );
 +                }
 +                else {
 +                    return MACRO( D(LCTL), T(V), U(LCTL), END  );
 +                }
 +            }
 +            break;
 +        }
 +      }
 +    return MACRO_NONE;
 +};
 +```
 +
 +And then, to assign this macro to a key on your keyboard layout, you just use `M(0)` on the key you want to press for copy/paste.
 +
 +#### Example 2: Space Cadet Shift (making it easy to send opening and closing parentheses)
 +
 +In the [Modern Space Cadet Keyboard](http://stevelosh.com/blog/2012/10/a-modern-space-cadet/#shift-parentheses), one of cooler features is the Shift Parentheses. To quote Steve Losh:
 +
 +  > When held while pressing other keys, act like Shift.
 +  > When pressed and released on their own, type an opening or closing parenthesis (left and right shift respectively).
 +
 +```
 +static uint16_t key_timer;
 +
 +const macro_t *action_get_macro(keyrecord_t *record, uint8_t id, uint8_t opt)
 +{
 +      switch(id) {
 +        case 0: {
 +            if (record->event.pressed) {
 +                key_timer = timer_read(); // if the key is being pressed, we start the timer.
 +                register_code(KC_LSFT); // we're now holding down Shift.
 +            } else { // this means the key was just released, so we can figure out how long it was pressed for (tap or "held down").
 +                if (timer_elapsed(key_timer) < 150) { // 150 being 150ms, the threshhold we pick for counting something as a tap. 
 +                    register_code(KC_9); // sending 9 while Shift is held down gives us an opening paren
 +                    unregister_code(KC_9); // now let's let go of that key
 +                }
 +                unregister_code(KC_LSFT); // let's release the Shift key now.
 +            }
 +            break;
 +        }
 +        case 1: {
 +            if (record->event.pressed) {
 +                key_timer = timer_read(); // Now we're doing the same thing, only for the right shift/close paren key
 +                register_code(KC_RSFT); 
 +            } else { 
 +                if (timer_elapsed(key_timer) < 150) { 
 +                    register_code(KC_0); 
 +                    unregister_code(KC_0); 
 +                }
 +                unregister_code(KC_RSFT); 
 +            }
 +            break;
 +        }
 +      }
 +    return MACRO_NONE;
 +};
 +```
 +
 +And then, to assign this macro to a key on your keyboard layout, you just use `M(0)` on the key you want to press for left shift/opening parens, and `M(1)` for right shift/closing parens.
 +
  ## Additional keycode aliases for software-implemented layouts (Colemak, Dvorak, etc)
  
  Everything is assuming you're in Qwerty (in software) by default, but there is built-in support for using a Colemak or Dvorak layout by including this at the top of your keymap:
  
 -   #include <keymap_extras/keymap_colemak.h>
 +   #include <keymap_colemak.h>
  
  If you use Dvorak, use `keymap_dvorak.h` instead of `keymap_colemak.h` for this line. After including this line, you will get access to:
  
@@@ -371,7 -243,7 +373,7 @@@ This requires [some hardware changes](h
  
  ## International Characters on Windows
  
 -[AutoHotkey](https://autohotkey.com) allows Windows users to create custom hotkeys amont others.
 +[AutoHotkey](https://autohotkey.com) allows Windows users to create custom hotkeys among others.
  
  The method does not require Unicode support in the keyboard itself but depends instead of AutoHotkey running in the background.
  
@@@ -399,9 -271,9 +401,9 @@@ For this mod, you need an unused pin wi
  
      RGBLIGHT_ENABLE = yes
  
 -Please note that the underglow is not compatible with MIDI functions. So you cannot enable both of them at the same time.
 +Please note that the underglow is not compatible with audio output. So you cannot enable both of them at the same time.
  
 -Please add the following options into your config.h, and set them up according your hardware configuration.
 +Please add the following options into your config.h, and set them up according your hardware configuration. These settings are for the F4 by default:
  
      #define ws2812_PORTREG  PORTF
      #define ws2812_DDRREG   DDRF
      #define RGBLIGHT_SAT_STEP 17
      #define RGBLIGHT_VAL_STEP 17
  
 +You'll need to edit `PORTF`, `DDRF`, and `PF4` on the first three lines to the port/pin you have your LED(s) wired to, eg for B3 change things to:
 +
 +    #define ws2812_PORTREG  PORTB
 +    #define ws2812_DDRREG   DDRB
 +    #define ws2812_pin PB3
 +
  The firmware supports 5 different light effects, and the color (hue, saturation, brightness) can be customized in most effects. To control the underglow, you need to modify your keymap file to assign those functions to some keys/key combinations. For details, please check this keymap. `keyboard/planck/keymaps/yang/keymap.c`
  
  ### WS2812 Wiring
@@@ -445,4 -311,4 +447,4 @@@ what things are (and likely aren't) to
  - EEPROM has around a 100000 write cycle.  You shouldn't rewrite the
    firmware repeatedly and continually; that'll burn the EEPROM
    eventually.
 -                                      
 +                                      
diff --combined quantum/rgblight.c
index 5623c65de71a9b00a680f4e802f67dbeb02a8fe4,6adc9e2784da0de143b928b144031f7956caacb5..789af73d80720061570ec26dfc239f2b850d6cfe
@@@ -107,17 -107,17 +107,17 @@@ void setrgb(uint8_t r, uint8_t g, uint8
  uint32_t eeconfig_read_rgblight(void) {
    return eeprom_read_dword(EECONFIG_RGBLIGHT);
  }
 -void eeconfig_write_rgblight(uint32_t val) {
 -  eeprom_write_dword(EECONFIG_RGBLIGHT, val);
 +void eeconfig_update_rgblight(uint32_t val) {
 +  eeprom_update_dword(EECONFIG_RGBLIGHT, val);
  }
 -void eeconfig_write_rgblight_default(void) {
 -      dprintf("eeconfig_write_rgblight_default\n");
 +void eeconfig_update_rgblight_default(void) {
 +      dprintf("eeconfig_update_rgblight_default\n");
        rgblight_config.enable = 1;
        rgblight_config.mode = 1;
        rgblight_config.hue = 200;
        rgblight_config.sat = 204;
        rgblight_config.val = 204;
 -      eeconfig_write_rgblight(rgblight_config.raw);
 +      eeconfig_update_rgblight(rgblight_config.raw);
  }
  void eeconfig_debug_rgblight(void) {
        dprintf("rgblight_config eprom\n");
@@@ -136,12 -136,12 +136,12 @@@ void rgblight_init(void) 
    if (!eeconfig_is_enabled()) {
                dprintf("rgblight_init eeconfig is not enabled.\n");
      eeconfig_init();
 -              eeconfig_write_rgblight_default();
 +              eeconfig_update_rgblight_default();
    }
    rgblight_config.raw = eeconfig_read_rgblight();
        if (!rgblight_config.mode) {
                dprintf("rgblight_init rgblight_config.mode = 0. Write default values to EEPROM.\n");
 -              eeconfig_write_rgblight_default();
 +              eeconfig_update_rgblight_default();
                rgblight_config.raw = eeconfig_read_rgblight();
        }
        eeconfig_debug_rgblight(); // display current eeprom values
@@@ -189,8 -189,8 +189,13 @@@ void rgblight_mode(uint8_t mode) 
        } else {
                rgblight_config.mode = mode;
        }
++<<<<<<< HEAD
 +  eeconfig_update_rgblight(rgblight_config.raw);
 +  dprintf("rgblight mode: %u\n", rgblight_config.mode);
++=======
+   eeconfig_write_rgblight(rgblight_config.raw);
+   xprintf("rgblight mode: %u\n", rgblight_config.mode);
++>>>>>>> pr/286
        if (rgblight_config.mode == 1) {
                rgblight_timer_disable();
        } else if (rgblight_config.mode >=2 && rgblight_config.mode <=23) {
  
  void rgblight_toggle(void) {
    rgblight_config.enable ^= 1;
 -  eeconfig_write_rgblight(rgblight_config.raw);
 +  eeconfig_update_rgblight(rgblight_config.raw);
-   dprintf("rgblight toggle: rgblight_config.enable = %u\n", rgblight_config.enable);
+   xprintf("rgblight toggle: rgblight_config.enable = %u\n", rgblight_config.enable);
        if (rgblight_config.enable) {
                rgblight_mode(rgblight_config.mode);
        } else {
@@@ -299,8 -299,8 +304,8 @@@ void rgblight_sethsv(uint16_t hue, uint
                rgblight_config.hue = hue;
                rgblight_config.sat = sat;
                rgblight_config.val = val;
 -              eeconfig_write_rgblight(rgblight_config.raw);
 +              eeconfig_update_rgblight(rgblight_config.raw);
-               dprintf("rgblight set hsv [EEPROM]: %u,%u,%u\n", rgblight_config.hue, rgblight_config.sat, rgblight_config.val);
+               xprintf("rgblight set hsv [EEPROM]: %u,%u,%u\n", rgblight_config.hue, rgblight_config.sat, rgblight_config.val);
    }
  }