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

371–380 of 382 posts

Re: Open-Sourcing our Firmware

#371

Post by jpetso »

bestouff wrote: post #104
sydney6 wrote: post #93

Earlier quoted context omitted.

I can imagine that the power draw in S3 could come from having (replacable) DDR Memory instead of (mostly soldered) LP-DDR Memory. edit: typo.

The problem is that current Intel laptops don't use S3 anymore, they use S0ix a.k.a. "modern standby", an abomination where the CPU doesn't really sleep and the battery drains fast. Dell, Lenovo, HP etc. all have the same problem.

S0ix has stronger requirements on the "correct" interaction between firmware/BIOS and OS, it offloads more work to the OS. Poorly implemented S0ix will drain the battery faster, but correctly implemented S0ix is as good as S3 or even better.

Lenovo put out a buggy S3 implementation on some systems that hasn't been tested well because it's only an optional "Linux suspend" setting. Drains twice as fast as Linux with correctly implemented S0ix. And the worst thing is, nobody except Lenovo do can fix it because it's all on the BIOS level, and their China-based firmware team has other priorities.

Well-implemented S3 is nice. But it's going to disappear. Both Intel and AMD are switching away with full force, vendors won't have S3 options in the BIOS going forward and the ones that remain will likely suck. On the other hand, S0ix support is coming together even on AMD platforms which were a little late to the party. Once it's working decently, I'd rather trust my OS than my laptop manufacturer's firmware team to suspend components correctly.

Re: Open-Sourcing our Firmware

#372

Post by jpetso »

panick21_ wrote: post #352
bbojan wrote: post #130

Earlier quoted context omitted.

Because I'm down the rabbit hole of highly customized keyboards, at one point I did a frequency analysis of the keys I use the most. Guess what was the most frequently used key? Cursor down followed by cursor up. For example, cursor down was pressed ~2.5x more times than space, or ~4 times more than letter E, which is was the most frequently used letter. Guess what are the smallest keys on a Mac-type keyboard (the la…

I love the ThinkPad with the Arrow Key and PgUp/PgDown all next to each other.

Rejoice, Lenovo is introducing a ThinkPad that finally lets them scrap this excellent setup for a mainstream rectangular keyboard: Z13 and Z16. Doubly sad because those look like a kick-ass AMD Ryzen implementation otherwise. Trippy sad because they also found a way to get rid of the physical TrackPoint buttons and still call it a ThinkPad.

The writing is on the wall, just wait for Lenovo to finally extinguish their ugly step-child of asymmetry and deprive us of the last good arrow key layout left in portable laptops.

Re: Open-Sourcing our Firmware

#373

Post by CamperBob2 »

talideon wrote: post #370
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?

The problem is that you're dealing with an analogue signal. The gold standard for debouncing because of that is a low-pass filter, which is implementable by a resistor and capacitor, and way more reliable (and responsive) than any software solution.

Can you describe a case in which rejecting a duplicate keypress that arrives within a specified number of milliseconds is ineffective, unreliable, or even suboptimal?

A lowpass filter is an empirical hack, not a gold standard. It has multiple disadvantages; rather than being "responsive," it adds latency to the initial input for no good reason, and it affects both rising and falling edges equally, again for no good reason. It also requires the addition of unnecessary physical components.

Re: Open-Sourcing our Firmware

#374

Post by brokenmachine »

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.

There's nothing wrong with software debouncing. Almost all fancy DIY exotic keyboards use software debouncing effectively.

In fact it's more customizable for quicker response than hardware RC debouncing.

There is, however, something wrong with shitty debouncing software.

Re: Open-Sourcing our Firmware

#375

Post by brokenmachine »

alar44 wrote: post #321
CamperBob2 wrote: post #282

Earlier quoted context omitted.

It bounces both ways but as long as you don't accept another keypress action (up or down) immediately after the first, you're fine.

You're fine either way. You either have to poll, or use interrupts. If you are polling, you don't need to debounce the circuit. If you use interrupts, you're going to have a very bad time if you don't. Interrupts are much more efficient. Polling is wasteful.

I don't see why interrupts wouldn't work without hardware debouncing.

$2 micros are many MHz. All it has to do is save/compare one timestamp per interrupt.

So lets do some back-of-the-napkin calculations and say it takes 1us to store/compare the timestamp, a switch transitions 50 times per press on each change of state, and a person is typing at 100wpm (lets say 600cpm = 10cps).

I think these are pretty conservative numbers, 50 bounces sounds like a pretty crappy switch to me.

So 1000 transitions per second which would take 1ms, which means 1/1000th of the time is spent servicing the interrupts.

It's not going to cause a problem unless the coding is very inefficient.

Re: Open-Sourcing our Firmware

#376

Post by brokenmachine »

belfalas wrote: post #304
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...

This made me wonder if debouncing is also a thing with software keyboards? For years I have sworn that I type things correctly on the iPhone keyboard but it gets it wrong.

I'd assume that the capacitive touch sensing will certainly have some kind of debouncing as it crosses whatever the threshold is to register a touch or not.

Re: Open-Sourcing our Firmware

#377

Post by brokenmachine »

baybal2 wrote: post #365
ChuckNorris89 wrote: post #362

Earlier quoted context omitted.

>A mechanical bounce free switch is a no problem at all. Two questions: 1) do mechanical switches with zero bounce really exist? 2) are they cost effective enough to be used in consumer keyboards?

> 1) do mechanical switches with zero bounce really exist? You just use a switch with 2 outputs: for on, and off position. Triggering 2 at the same time is impossible. > 2) are they cost effective enough to be used in consumer keyboards? Surely less than a percentage of a cent in extra cost.

>You just use a switch with 2 outputs: for on, and off position. Triggering 2 at the same time is impossible.

You've pretty much just described a standard everyday bog standard switch.

It's either over the threshold resistance for triggering, or it isn't.

Nothing you've suggested here excludes a switch that changes state by bouncing between the two states 50 times per physical press when you sample at MHz speed, as most switches do.

Re: Open-Sourcing our Firmware

#378

Post by brokenmachine »

stormbrew wrote: post #164
imiric wrote: post #147

Earlier quoted context omitted.

From reports I've read the Framework laptop has poor build quality. This comment from here actually: https://news.ycombinator.com/item?id=29807585 I'd like to support their cause, but like you, I have way too many machines that already work well enough, that I can't justify another purchase unless it would offer a substantial improvement over my current setup (old ThinkPads). Plus I really can't function without a Tr…

> From reports I've read the Framework laptop has poor build quality. I'm gonna be really honest here and say that people have a very distorted subjective idea of what a 'sturdy laptop' is like. A lot of marketing money has been spent to make people think the only way to have a strong object is for it to be made of a rigid metal or glass material, so people go "oh my god the lid can FLEX this thing will break if I dr…

Sometimes I think that I must be the only one who doesn't throw his laptop into a backpack full of hammers while jogging everywhere.

Re: Open-Sourcing our Firmware

#379

Post by sannee »

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.

Firstly, hardware debouncing is a bit awkward to implement on a multiplexed matrix, since you need a debouncing circuit for each of your inputs (meaning about a dozen or so of them).

More importantly though, software debouncing offers greater flexibility. For keyboards, you usually[1] want to implement an asymmetric "eager" mode, where a key press gets registered immediately and only the key release is debounced. Since software usually does stuff on the key down event, this works to reduce latency.

[1] Well, that's what the various enthusiast mechanical keyboard firmwares do, I am not so sure that generic $random_corp keyboards do care...

Re: Open-Sourcing our Firmware

#380

Post by lukeschlather »

namibj wrote: post #346
lukeschlather wrote: post #272

Earlier quoted context omitted.

This reminds me of a weird issue I have with my Lenovo where sometimes the trackpoint and mouse buttons stop working until a reboot (but the trackpad still works.) I think I must trigger a race condition in the trackpoint drivers somehow but I have no idea how to debug it.

I remember such an issue; unloading and reloading the kernel module fixed it.

This is on Windows, I haven't tried installing Linux on the machine. It's also intermittent enough that it's virtually impossible to debug.
Post reply on HN