Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Open-Sourcing our Firmware

frame.work

Post reply on HN
Print view View original

241–250 of 382 posts

Re: Open-Sourcing our Firmware

#241

Post by CamperBob2 »

sydthrowaway wrote: post #237
CamperBob2 wrote: post #227

Earlier quoted context omitted.

Don't accept a keypress if the same key was previously pressed less than x milliseconds ago. What else is there to know about debouncing?

What is x? Is it related to human capability?

Key bounce takes place at timescales far shorter than human reaction times. Typically you'd base the interval on the mechanical characteristics of the keypad.

For instance, taking a look with a scope, if you observe that the signal stops bouncing after 3 milliseconds, it would be pretty safe to accept duplicate keypresses with a 10-ms guard interval.

Re: Open-Sourcing our Firmware

#242

Post by [deleted] »

alar44 wrote: post #233
ad8e wrote: post #207

Earlier quoted context omitted.

The scrambling is easy to see once you know it's happening: press k and l simultaneously on your Thinkpad keyboard. It'll always come out "lk" unless you deliberately separate them. Testing was done [0], but it's not written in an easy-to-understand way. As a summary, Thinkpad keys are scrambled within 15-23 ms. Usually, humans ascribe scrambled letters to their own mistakes, but this time it's the keyboard's fault.…

Wow. I'm surprised they don't do this on the component level. When I was working in embedded, I considered software debouncing a lazy hack. I'd rather sanitize the data before it hits software.

[deleted]

Re: Open-Sourcing our Firmware

#243

Post by halpert »

alar44 wrote: post #233
ad8e wrote: post #207

Earlier quoted context omitted.

The scrambling is easy to see once you know it's happening: press k and l simultaneously on your Thinkpad keyboard. It'll always come out "lk" unless you deliberately separate them. Testing was done [0], but it's not written in an easy-to-understand way. As a summary, Thinkpad keys are scrambled within 15-23 ms. Usually, humans ascribe scrambled letters to their own mistakes, but this time it's the keyboard's fault.…

Wow. I'm surprised they don't do this on the component level. When I was working in embedded, I considered software debouncing a lazy hack. I'd rather sanitize the data before it hits software.

It looks like he keyboard state is read by the driver, rather than the keyboard sending the state to the OS. How would you denounce on a hardware level with such a setup?

Re: Open-Sourcing our Firmware

#244

Post by google234123 »

ad8e wrote: post #165

I checked the keyboard debouncing logic [0] and it was fine. Some keyboards from other manufacturers, notably Lenovo Thinkpads, have absurd debouncing algorithms that scramble keys or add delays, so it's good to see Framework has a correct solution. [0]: https://github.com/FrameworkComputer/EmbeddedController/blob...

The copyright header at the top says "chromium".

Re: Open-Sourcing our Firmware

#245

Post by kop316 »

nrp wrote: post #43
kop316 wrote: post #2

Does the Framework support coreboot? IIRC it does not, and I was sort of surprised to not see that in this announcement. Their github also doesn't have any mention of coreboot: https://github.com/FrameworkComputer And it isn't here either: https://doc.coreboot.org/mainboard/index.html

We called out "We're continuing to invest in open source firmware development, with the goal of replacing other proprietary firmware we're currently stuck with in the future too." in the blog post. Coreboot is something we're very interested in and have done experimentation around. We went with an off-the-shelf proprietary BIOS/UEFI to derisk launching the Framework Laptop on time and satisfying the core goals on it…

Gotcha, thanks!

Re: Open-Sourcing our Firmware

#246

Post by rpdillon »

imiric wrote: post #154
gorjusborg wrote: post #151

Earlier quoted context omitted.

Are you talking about personal testimonials, or published data? If it's published data, mind sharing a link?

It was a recent thread here on HN. Let me see if I can find it... This comment: https://news.ycombinator.com/item?id=29807585 Some of these issues could be subjective, and I shouldn't decide based on that single report alone, but it was enough reason to reconsider the purchase, especially since, like I said, I really don't need a new machine.

Had mine since July, batch 1. No build quality issues at all from my perspective...one of my favorite keyboards to type on. Battery is not so good, though.

Re: Open-Sourcing our Firmware

#247

Post by fps-hero »

Teknoman117 wrote: post #232
ad8e wrote: post #165

I checked the keyboard debouncing logic [0] and it was fine. Some keyboards from other manufacturers, notably Lenovo Thinkpads, have absurd debouncing algorithms that scramble keys or add delays, so it's good to see Framework has a correct solution. [0]: https://github.com/FrameworkComputer/EmbeddedController/blob...

Out of curiosity, is there anything in particular that you're looking for? On a cursory glance, whenever a key state is sampled as different to the previously reported state, it immediately reports a state change and locks out any further reports for a specified amount of time. So, the report goes out the moment the state changes, so long as you can't perceive the debounce time, which I presume would be a few dozen m…

Yes. Essentially, when you see an edge, update the state immediately but have a guard interval before allowing further state changes.

Intuitively, this means register the event when you see the first edge, not once the bounces have finished.

For an example of incorrect denouncing, see most articles on denouncing (the hackaday article comes to mind), and the QMK firmware last time I checked (most keyboard set the denounce time to zero, so the debounce time just becomes the update rate).

Re: Open-Sourcing our Firmware

#248

Post by auxym »

poyu wrote: post #177
ad8e wrote: post #165

I checked the keyboard debouncing logic [0] and it was fine. Some keyboards from other manufacturers, notably Lenovo Thinkpads, have absurd debouncing algorithms that scramble keys or add delays, so it's good to see Framework has a correct solution. [0]: https://github.com/FrameworkComputer/EmbeddedController/blob...

Debounce is an interesting topic[0], I tend to use hardware debounce whenever possible on my own projects. [0]: https://hackaday.com/2010/11/09/debounce-code-one-post-to-ru...

There's some good info here if anyone is interested: http://www.ganssle.com/debouncing.htm

Re: Open-Sourcing our Firmware

#249

Post by weystrom »

nrp wrote: post #240
weystrom wrote: post #236

I wish they'd ship US ANSI keyboard in Europe, I would totally pick one up.

The International English keyboard option is ANSI. It is US English with a Euro symbol and Alt Gr.

Oh that's actually great, ot's just I've been burned before by German retailers with "English International" on ISO keyboards.

I might go do some shopping then. Say hello to Linus btw, his video has done marvels to deservedly promote your product.

Re: Open-Sourcing our Firmware

#250

Post by pabs3 »

wmf wrote: post #75
marcodiego wrote: post #19

What is the reason behind closed firmware? I understand that wifi devices may operate out of the certification depending on what the firmware does, but other devices... why do they have closed firmwares?

For BIOS/UEFI a lot of hardware vendors outsource their firmware to AMI and AMI keeps everything proprietary so they can keep charging money. (Coreboot is not an option for real computers because it doesn't have menus and various other things.)

Aren't there coreboot payloads for doing menus/etc?
Post reply on HN