Any chance the G-sensor connection option can be re-added? Seems strange to have been locked out of hardware I paid for simply because others don’t have a feature. What is the difference between this the Vpro only options that only some customers have access too? Now that there is an entirely new board available the maintaining consistency argument seems to not hold water.
Did you pay any extra for this feature? No, it was just removed because of sillicon shortages…
vPro is a intel feature that is placed onto CPUs- not a seperate IC…
I paid for it yes and that is enough. I didn’t pay ‘extra’ for it because Framework didn’t charge me extra. Unlike other features that I did pay extra for. That they didn’t included the IC in future batches was a decision that was taken by Framework. Should I be locked out of my Vpro options in software because they can’t source the CPU’s with that feature in the future? Using your logic how much ‘extra’ does one have to pay to not be locked out of features through software?
What does a g sensor do in a machine with no spinning hd?
Which is pretty much why they removed it tbh…
They talked about it in a blog post but don’t recall which one atm. I really don’t understand the bother about it being removed from BIOS
I suppose it could be used in the afterlife when the motherboard is no longer in the laptop, and that afterlife IS an advertised official feature of this machine.
All else being equal, unless there is some reason specifically to remove it, I too would like all possible options available. And it’s at least possible that the sensor was an actual part of someone’s purchase decision, and so it’s wrong to change it after taking their money.
Not that I’m still bitter about Sony removing my Yellowdog partition from my PS3 or anything…
It’s a small thing but technically I have to admit a legit thing. The best fix for this would be simply a totally different fully open source bios so you didn’t have to beg the manufacturer to please you, but that is still dreaming.
As you summize in your later post, part of the appeal of Framework and something heavily advertised both through their influencer network as well as their site is the reuse of old boards. This type of behavior is in stark contrast to that proclaimed goal if at market whims I can loose access to features on already purchased products. Those of you trying to minimize this as ‘only a g sensor’ or ‘what can you use that for’ are only helping to normalize behavior that will in the long run not serve any of your interests.
On the contrary, nothing restricts you from adding it back after its use as a laptop is done. Framework does not need to throw an entire kitchen sink into this product to make it the perfect product for everyone. It was removed after batch 1 as I recall. So there are more laptops in existence without the g-sensor than there are with it. It was removed for cost reasons as much as a lack of usefulness.
You can rationlize it however you’d like but no one is asking for a sink or a kitchen. Just the setting that already existed in an earlier version of the BIOS, which was after batch 1, 2, 3, or 4. It was removed due to lack of ability to source the original IC. Unless you have a reversed engineered build to share of the proprietary BIOS, I’m not sure how you propose I ‘add it back in’. I’m unable to find the source you’re using for your information but if you really believe it was removed due to ‘lack of usefulness’ then you are insinuating much worse things of the Framework team than I am willing too.
Yeah and FW never found a use for it
This was the first quote in that thread. If they truly found a use for it I imagine they would have tried harder to keep it in.
I meant that you could plug a sensor into a TB4 port not that I have any way of exposing that functionality in BIOS, that was poor wording on my part. My apologies. Although I will take the opportunity to plug my personal desire for Coreboot!
How so? Why would they expose a setting that would only be relevant for a small subsection of users? That just seems like asking for a support nightmare.
Yes, and it states a possible use case that the user can take advantage of by installing an alternative OS. Kind of defeats your lack of usefulness argument. I’m not asking them to find me a use case, simply to allow me to enable it as was previously possible, so that I can find my own. I didn’t realize framework had a master list of all possible uses for their hardware but noted.
So you want me to spend more money to replace functionality that I already paid for?
Well this nightmare already exists in the form of other pay for access features in the BIOS as mentioned in my previous post. To say nothing of the whole new board generation they now support. So they can support multiple boards with different chipset options for each but this one feature that was already there is a bridge too far?
Not at all, I didn’t say you couldn’t find a use for it, just that FW couldn’t find one worth justifying the cost.
Sarcastic and unnecessary. FW’s appeal is that they don’t restrict you in what you can and cannot do with the machine you own. If you want to use a g-sensor then do so.
Pretty much. It’s not like the g-sensor was a huge part of their marketing. It was found and then quietly removed basically. Sorry that you feel gypped out of that. Seriously. I’m not saying FW is perfect or that they haven’t made missteps. While I can’t understand anyone purchasing a laptop and then not using it for a month for a problem like the RTC battery drain issue to surface, I recognize that it is a design flaw that other laptop makers do not seem to suffer from. Or the battery drain from the expansion cards, which are a key selling point for the FW.
I’m of the opinion that you are making a mountain out of a molehill, you disagree and that’s fine. Really not much else to say about the topic at this point.
That caveat didn’t exist in your original statement I’m only responding to your statements as written. In the quote you posted from Framework they specified more than one possbile use-case while others here and in other threads have posted many more. How does it cost them extra to keep something that was already there? It seems your argument is confusing not having one in some future batch with someone being able to use a previous version that already has it. I could be wrong, please correct me if I am.
Only pointing out the logical fallacy of your statement, surmising that if Framework doesn’t find a use for something then it’s justified that they abritarily lock users out of features post facto. Again I ask how can I use it if they have disabled it in BIOS? How is what they did not restricting me from using said hardware?
On the contrary myself and others have pointed out that old board re-use is indeed a heavily marketed part of the company’s selling point. They are suppose to be for right to repair and open access to hardware (up to where current NDA’s may allow). This kind of behavior, in my opinion, goes against this edict which is why I’m making this ‘mountain’. Not sure what you mean by ‘it was found’ but the quiet removal is telling.
Well let me help you, some people may or may not use their hardware differently than you or I and that’s ok, you don’t have to understand it. The key argument you seem to be glossing over is that Framework shouldn’t mandate this based on their ability to source future hardware whether for cost or lack of availability.
You’re free to stop whenever you’d like. Not sure why your trying to dicate an end to the conversation for others but telling none the less.
This had been going off-topic so it is now its own thread.
Also please make sure to treat each other with respect.
How so? Is it not about the BIOS? Why only our conversation and not the other mentions of the same thing by others in the same thread? Can we at least add the ‘from the BIOS’ context to the thread name?
When were we not?
Yeah…it kinda did.
By paying for an additional IC? By paying Insyde to create another version of the BIOS for a small subsection of users? A subsection which as a percentage of users, shrinks with every laptop sold?
Which is not the same as the g-sensor specifically, one is general and the other specific. What specific marketing have you seen regarding the g-sensor?
From the original topic. I certainly would never have known about the presence of the g-sensor without someone going through the support articles to find it.
Yeah, I already conceded that point in the above post.
Because this conversation is effectively over, it is no longer a conversation. I’ve said my piece on why you are unlikely to ever get what you want and what steps you can take to replicate the functionality if it is something you need. You choose not to accept that. That’s your choice. I have nothing new to add, everything after the first few posts has just be me re-iterating the same things over and over again and I’m tired of doing that. Say what you want in response to this, I promise I won’t respond, especially since a mod has asked us to tone things down. The only “solutions” I can think of, if you want to call them that, are downgrading to a previous BIOS revision in which the functionality was still exposed or selling your laptop. Neither of which sounds appealing to me but you do you.
Doesn’t matter. There’s no mention of screws (screw material, length, number of them, placement of screws). But the laptop came with them.
This is post-sale feature / functionality / capability nuking.
It’s not up to the community to decide what use cases OTHER people have. We don’t need to understand and accept their use case with the g-sensor.
There’s been multiple similar discussions (people not accepting other people’s use cases). It’s like, “Why do you put pineapple in your pizza?”…what do you care? The g-sensor thing is between them and Framework. We’re not here to judge the validity of a use case to THEM.
That’s the spirit.
I’ll concede that. I was referring to the fact that they did find uses in your quote, not sure that they ever got a chance to implement any of them due to the IC shortages.
The IC is already paid for I have it. I’m not asking them to add it back in for everyone simply to allow us to enable it, for those that got it, as it was originally. They build their own BIOS. That I’m aware of there is no further payment to Insyde for anything in this context (someone from the Framework Team please feel free to correct me if this is wrong). The option being exposed is a build time decision by the Framework Team and doesn’t involve Insyde other than in using their licensed software. They have other togglable options for features that a small subset of users have due to needing specific hardware that you have to pay extra for. So why is this different?
That’s fair, the context made it sound like they were hiding it not that it was documented.
Not trying to be rude I genuinely don’t see it but acknowledged now.
I see other possiblities.
That’s all I’m trying to do. Your making assumptions about possible outcomes and getting frustrated that I’m not coming to the same conclusion. Are you and I the only ones that can participate in the conversation? It’s not you I’m even trying to convince but the Framework Team. I wasn’t aware I had to limit my number of responses.
There is a reason we did not add a bios option to enable/disable the G-sensor.
In 11th Generation mainboard the IMU sensor is connected to a separate MCU in the Intel SOC called the Sensor Hub. This runs its own firmware, and handles communicating with the ALS and IMU, and then exposing data from these using a standardized interface to the OS. However the firmware cannot dynamically enable/disable specific sensors at run time.
To further complicate this, we can only bundle one firmware at a time in the bios as this firmware is stored in a specific region of bios flash.
On 12th gen we have moved the ALS sensor functionality to the EC, and entirely removed any need to enable this subsystem on the SOC to reduce the number of closed source firmware blobs needed.
I understand the reasoning but now 11th gen batch 1-4 doesn’t get to use something that’s on the board,
and that I was happy to see.