No, initially it was snaps, but I changed to regular deb packages for this
Not brightness, cycles through different breathing speeds. All I want is for the backlight to actually stay on, but so far nothing allows that to happen.
No, initially it was snaps, but I changed to regular deb packages for this
Not brightness, cycles through different breathing speeds. All I want is for the backlight to actually stay on, but so far nothing allows that to happen.
This is really some odd behavior. I activated that breathing by accident just today. There was certainly no VIA app involved. I think I was trying to hit something like pos1 or something when whatever I hit triggered the breathing. Using the VIA website with the udev rules did fix it for me. The question is, what key combination activates that mode in the first place?
That’s odd. Even when I somehow activated it by accident today, Fn + Space was still changing brightness. Maybe @Matt_Hartley or someone else at Framework would be so kind and shed some light on this situation.
Try Fn + C.
I don’t see it listed on the FWL16 hotkey page, but Toggle backlight breathing, BL_BRTG
, is on the default keymap under Fn + C. I’m guessing it’s an oversight that it wasn’t listed on the hotkey page.
From the latest keyboard firmware v0.2.9/keyboards/framework/ansi/keymaps/default/keymap.c
[_FN] = LAYOUT(
FN_LOCK, KC_F1, KC_F2, KC_F3, KC_F4, KC_F5, KC_F6, KC_F7, KC_F8, KC_F9, KC_F10, KC_F11, KC_F12, KC_INS,
_______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______, _______,
_______, _______, RGB_TOG, RGB_MOD, RGB_HUI, RGB_SAI, RGB_SPI, RGB_VAI, _______, _______, KC_PAUS, _______, _______, _______,
_______, _______, KC_SYRQ, RGB_RMOD,RGB_HUD, RGB_SAD, RGB_SPD, RGB_VAD, KC_SCRL, _______, _______, _______, _______,
_______, _______, _______, BL_BRTG, _______, KC_BRK, _______, _______, _______, _______, _______, _______,
_______, _______, _______, _______, BL_STEP, _______, _______, KC_HOME, KC_PGUP, KC_PGDN, KC_END
),
Thanks, Fn+C did stop the breathing and now with that stopped Fn+Space does adjust brightness.
Looks like I am late to the party, looks like it is resolved now. Glad to hear you have it sorted.
Just stumbled upon this too when my non-RGB keyboard switched to breathing instead of static backlight. The FN + C key combo should really be listed on this page
Thank you. This fixed it for me. I’ve had this randomly happen and then vanish.
Follow up: Is there a similar hot key for the num pad?
Yep.
+ is Toggle backlight breathing, BL_BRTG
, on the default keymap when Numlock is off.
From the latest numpad firmware v0.2.9/keyboards/framework/numpad/keymaps/default/keymap.c
/*
* Extra keys for when numlock is disabled.
* Numlock keys are passed through to the number layer,
* and automatically remapped by the OS.
* ┌────┬────┬────┬────┐
* 4 keys │ │ │ │ │
* ├────┼────┼────┼────┤
* 4 keys │ │ │ │ │
* ├────┼────┼────┼────┤
* 3 keys │Home│ ↑ │PgUp│BL │
* ├────┼────┼────┤Brtg│
* 4 keys │ ← │ │ → │ |
* ├────┼────┼────┼────┤
* 3 keys │End │ ↓ │PdDn│BL │
* ├────┴────┼────┤Step│
* 3 keys │ Insert │Del │ │
* └─────────┴────┴────┴
* 21 total
*/
[_FN] = LAYOUT(
_______, _______, _______, _______,
_______, _______, _______, _______,
_______, _______, _______,
_______, _______, _______, BL_BRTG,
_______, _______, _______,
_______, _______, BL_STEP
)
It’s not present on the Macropad though.
Fn+C worked for me. Now Fn+space cycles keyboard brightness as intended.
Thank you.
@Matt_Hartley ^ Perhaps you could pass this on, internally?
I don’t have RGB, so I’d remembered the only hotkey concerning the backlight I thought applied to mine. If “FN + C” had been listed just below the “FN + space” hotkey, it would’ve saved me some trouble.
@Aaron_Baff, the Chromium requirement is presumably due to Firefox’s lack of support for WebUSB.
Which absolutely I get and understand. I knew that. I’m not saying want to use Firefox. I’m saying I want to use something other than Chrome/Chromium. There’s plenty of Linux USB serial drivers/etc, I want to know if there’s one that’ll work for this hardware to flash this firmware.
You want something other than Chromium for Via point-and-click configuration (keyboard.frame.work) or for flashing firmware? They are very different things. Via doesn’t even do flashing, at all.
For flashing, the RP2040 used in the keyboards make it so easy that you don’t need serial drivers or anything like that. The RP2040 shows up as “mass storage”, like a flash drive, when you trigger bootloader mode, which can be done by holding certain keys during power up. Literally any device capable of moving a file to a flash drive, can flash firmware to a RP2040. Smartphone, tablet, your wifi router if it has a USB port (seriously). You could flash from a toaster, if it had a USB port & you could tell it to move one file.
Once I know the protocol/packets/etc, I can do my own connector, maybe, as a local service and just hack it using websockets or something and redirect the web UI parts through there, instead of the WebUSB.
So you’re looking for GUI configuration, like Via (keyboard.frame.work), not firmware uploading, correct?
The Via protocol will be available. Via used to be closed source, but they finally opened it up some time ago. And the protocol, or enough of it, would have had to be available anyway for it to talk to the open source QMK.
But if you’re looking to go as far as talking to the keyboards over the Via protocol and creating a GUI, I’d suggest just converting your keyboards to Vial/QMK instead of Via/QMK.
Vial offers desktop apps for Windows, Linux, and Mac, in addition to a web option at https://vial.rocks. The desktop apps work fully offline, unlike Via’s electron app. And Vial also has more features than Via. Tapdance, combos, key overrides, and a range of qmk settings. Much better than Via, imo. A community member made a Vial port here, Keyboard: VIA / VIAL support? . Currently, it has the macropad and ANSI keyboards, it wouldn’t be hard to add others. Files that you can just flash over, right away, are here, github.com/spdkils/Framework-macropad/releases.
@MJ1, might I ask what QMK, Via, and Vial are? I’ve never heard of any of this stuff. I assume they’re protocols by which a GUI configures something about the keyboard, like its layout?
QMK is the open source firmware that runs on the Framework keyboards.
Via is the GUI point-and-click interface that you see when you configure your keyboards using keyboard.frame.work. Via is separate from the QMK firmware on the keyboards, and was made by a different group. QMK just includes what is needed to talk to Via (if you enable it, as FW has done).
Vial is an alternative GUI which offers more features and offline desktop apps, in addition to a web browser GUI. But to use Vial to its full extent, you need to put a version of QMK on your keyboards that’s made to talk to Vial instead of Via.
This is what Vial looks like for configuring a FWL16 ansi/american keyboard layout.
There is also a mousekeys settings tab too, if enabled. You can see that on the macropad below. Looks like when he built the firmware he forgot to enable mousekeys for the ansi keyboard. Framework forgot that too! So the stock firmware that all the keyboards come with from Framework doesn’t currently offer mousekeys. It can be enabled, it takes one line MOUSEKEY_ENABLE = yes
in rules.mk in the firmware.
This is all Vial 0.7.1. Current as of now. When a newer major version comes out, you can see features added here get.vial.today/changelog
If you don’t have a Framework 16, I’d be happy to post screenshots of Via for any of the keyboards for comparison.
Each of the keyboards, full, numpad, macropad, use their own RP2040 MCU ( microcontroller unit), on which Framework has placed or “flashed” QMK. The RP2040 was a good choice because it’s well-supported by QMK, very easy to flash, and generally hard to “brick” or put into a state where it no longer works.
Every time I find my cat napping on my laptop I find the breathing mode enabled. What is it for exactly? Struggling to find any situation where it might be useful.
No clue, to be honest.
I’d argue it has no use, besides being a novelty.
But people do like some things that have no practical use. They can bring entertainment and joy to an otherwise boring day. Like RGB lights, for example. Unless you have programmed your RGB keyboard to provide something useful, indication of something, it has no purpose or practical use. But try to deny some people their RGB & you may come out bloody.
Breathing mode though, how much entertainment can it bring? And it actively distracts, and at night, hinders seeing the keys. Surely the novelty will wear off fast. I do not understand why Framework put Breathing-mode on the default keymap. I seriously suspect it wasn’t fully thought out. One, because it isn’t on their hotkey list, hotkeys-on-the-framework-laptop-16. Two, because people accidentally triggering it leads to confusion for some, questions if their keyboard is malfunctioning, and I imagine at least a few contacting support, costing Framework actual money. Way more hassle than it’s worth having it on the default layout. Of course, if that’s the worse accident one makes, in work as complicated as bringing us the FWL16 keyboards, you can count yourself as extremely lucky.
By the way, you can go to keyboard.frame.work and remove it.