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

261–270 of 382 posts

Re: Open-Sourcing our Firmware

#261

Post by gridspy »

halpert wrote: post #243
alar44 wrote: post #233

Earlier quoted context omitted.

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?

One way is a RC circuit - where the switch (the keyboard button) in series with a resistor then charges a capacitor. You specify the ratio of resistance to capacitance so it takes long enough for the switch to stop bouncing before the capacitor output rises to the sense level of your digital input.

But if you want to reduce hardware cost, you can eliminate many capacitors and resistors by doing it in firmware instead.

Re: Open-Sourcing our Firmware

#262

Post by sangnoir »

xvector wrote: post #192
sangnoir wrote: post #179

Earlier quoted context omitted.

That is not the same as saying the build quality is poor though: it's clearly a comparative statement. "The Tesla Model S is cheaper than the Model X" does not imply "The Model S is cheap". Replacing "Model S" in the sentence with a beat-up '97 Honda civic and it may be true, but there is not enough evidence contained in the sentence to support an absolute statement.

If a "hinge doesn't feel strong" and the keys are "mushy and creaky" that 100% indicates poor build quality. Perhaps our individual thresholds for quality differ, but either one of those two statements are dealbreakers for me.

Our individual thresholds for quality differ, that's for sure, because my definition is "Was the object built well, considering it's constraints?" As an example,if something is made of plastic (or "polycarbonate"[1]), I expect it to flex to a degree, and it can still be very well made (e.g. old school Nokia phones had incredible build quality and industrial design)

1. I hate that plastic had to be re-branded in this manner because a small-but-vocal contingent decided it "feels cheap" on phones, or somehow lowers build-quality. This resulted in glass-backed phones which ironically had to be kept in plastic cases to take advantage of plastic's superior elasticity.

Re: Open-Sourcing our Firmware

#263

Post by tssva »

xvector wrote: post #192
sangnoir wrote: post #179

Earlier quoted context omitted.

That is not the same as saying the build quality is poor though: it's clearly a comparative statement. "The Tesla Model S is cheaper than the Model X" does not imply "The Model S is cheap". Replacing "Model S" in the sentence with a beat-up '97 Honda civic and it may be true, but there is not enough evidence contained in the sentence to support an absolute statement.

If a "hinge doesn't feel strong" and the keys are "mushy and creaky" that 100% indicates poor build quality. Perhaps our individual thresholds for quality differ, but either one of those two statements are dealbreakers for me.

The correct quote regarding the hinge is, "the hinge doesn't feel as strong". "as strong" doesn't mean it isn't strong. It means the original commenter doesn't think it is as strong as another hinge not that it isn't strong. Since there is no data regarding actual hinge performance this is a subjective and not an objective evaluation. Keyboard feel is also very subjective, so one person saying the keyboard is "mushy and creaky" holds no real value either.

Re: Open-Sourcing our Firmware

#264

Post by halpert »

gridspy wrote: post #261
halpert wrote: post #243

Earlier quoted context omitted.

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?

One way is a RC circuit - where the switch (the keyboard button) in series with a resistor then charges a capacitor. You specify the ratio of resistance to capacitance so it takes long enough for the switch to stop bouncing before the capacitor output rises to the sense level of your digital input. But if you want to reduce hardware cost, you can eliminate many capacitors and resistors by doing it in firmware instead…

I’m not too familiar with hardware, but would you be able to differentiate between the unpressed state with such a scheme?

Re: Open-Sourcing our Firmware

#265

Post by alar44 »

halpert wrote: post #264
gridspy wrote: post #261

Earlier quoted context omitted.

One way is a RC circuit - where the switch (the keyboard button) in series with a resistor then charges a capacitor. You specify the ratio of resistance to capacitance so it takes long enough for the switch to stop bouncing before the capacitor output rises to the sense level of your digital input. But if you want to reduce hardware cost, you can eliminate many capacitors and resistors by doing it in firmware instead…

I’m not too familiar with hardware, but would you be able to differentiate between the unpressed state with such a scheme?

Of course. Hardware debouncing came long before software. It's basic electronics. Many switches have it built in.

Re: Open-Sourcing our Firmware

#266

Post by alar44 »

gridspy wrote: post #261
halpert wrote: post #243

Earlier quoted context omitted.

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?

One way is a RC circuit - where the switch (the keyboard button) in series with a resistor then charges a capacitor. You specify the ratio of resistance to capacitance so it takes long enough for the switch to stop bouncing before the capacitor output rises to the sense level of your digital input. But if you want to reduce hardware cost, you can eliminate many capacitors and resistors by doing it in firmware instead…

Yeah, I get where you're coming from, but a few dozen SMD caps and resistors ordered in that kind of bulk probably raises the cost by a penny. Of course you do technically have more points of failure I guess.

Re: Open-Sourcing our Firmware

#268

Post by fhaldridge7 »

mplanchard wrote: post #238
lillecarl wrote: post #100

Earlier quoted context omitted.

Having come from Debian, Ubuntu, and Manjaro I settled on what feels like the last distro I will use on my own systems: NixOS. It's not so much better, it's so much different. Every(ish) single package, every single line of configuration(ish) is under version control in a(couple) nix files. I share (most) of it between my systems. With flakes (and it's lockfile) it's a 100%(ish) deterministic system. Downside: The la…

Just wanted to echo all of this. I started with home-manager and then moved to NixOS over the holiday. It’s really been great: easy to set up, relatively easy to configure most things, and it’s so lovely to know that the changes I make are checked into version control for easy use across machines.

Same here. Over the holidays I first tried NixOS in a VM and really liked it. I had a lot of fun setting up the system. A week later I installed it as my main OS and is has been great so far

Re: Open-Sourcing our Firmware

#269

Post by alar44 »

CamperBob2 wrote: post #241
sydthrowaway wrote: post #237

Earlier quoted context omitted.

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.

You'd have to have two intervals though, one for on, one for off. It bounces both ways. Hardware is more elegant but obviously the tradeoffs depend on what you're implementing.

Re: Open-Sourcing our Firmware

#270

Post by 42jd »

Teknoman117 wrote: post #144
reacharavindh wrote: post #106

Earlier quoted context omitted.

I very much wanted to hear about this and damn :-( Video playback must be hardware accelerated by now and be super efficient. Another worry was about low power sleep modes and waking up, and looks like it is not solved too. I might have to suck it up and buy the Mac for my needs after all. I have my trusty Linux desktop for all my big compute needs. I was hoping to make the mobile machine also run Linux, but the spec…

It's still a real pain to get hardware accelerated video in a browser on Linux. Google is still outright refusing to support it in chromium, even though they do support it inside Chrome OS. There are few community patches floating around if you're willing to roll your own chromium to enable to Chrome OS hardware decode pathways on generic Linux. You can mostly get it working on Firefox if you play around with the con…

As a heads up they fixed the intel xe graphics sandboxing issue in firefox 96. See https://bugzilla.mozilla.org/show_bug.cgi?id=1698778 It works great on my Framework with NixOS. My about:config settings (taken from my home-manager):

graphics = { "media.ffmpeg.vaapi.enabled" = true; "media.rdd-ffmpeg.enabled" = true; "media.navigator.medidataencoder_vpx_enabled" = true; };

Post reply on HN