Community Support is not a new category; it has been here for a while, but it wasn’t being used effectively. People were reporting their issues under the Framework Laptop 13 and Framework Laptop 16 categories instead. We’ve introduced new tags to the Community Support category and have started moving “community support” threads there so that users can easily find and organize relevant information.
We also redefined each category, which has led to more posts in the Community Support category, increasing visibility for these issues.
As I mentioned to Takaides, we haven’t announced anything new recently, which means no pre-orders or reviews of new products. There just isn’t much to talk about at the moment. Things will be lively again in the future and there will be more questions and more topics to be discussed
I do think that mentioning it is still being investigated can help. I believe that I can speak for a few community members here by saying we like to be kept in the loop of things. Silence regarding the issue can maybe feel like nothing is being done with it, and I think that may be what brings about the update questions.
We can provide more data points if needed to help speed up any updates, just let us know what data needs to be provided. (Hardware surveys, OS/kernel, bios settings, OC/UV data points like xtxu/RyzenAdj settings, etc)
Thank you for letting us know issues are still being worked on and that Framework is working on projects to improve the devices.
I think some of the problem is that FW don’t seem to do support in a process that users have become used to with other suppliers.
As an example.
I raised a bios bug with a different manufacturer.
There was some early interaction until we reach the bug status of “customer bug reproduced by supplier support team”
Then a delay until “alpha release for customer to confirm the fix works”
Once I confirmed it fixed the bug for me, the next status was being given a release version that will contain the fix.
The release version was released up to a month later.
The release notes for the prior release were continually updated, in the Known bugs section, once the “bug reproduced” step was reached.
I don’t see any of this interaction with users happening in relation to bios bugs.
I agree. There have been numerous commitments to improve software maintenance, particularly on BIOS updates which have not materialised. There are still bugs on the PD handling for the FW 13 AMD, and an accumulation of microcode and other patches which should really made available. Until FW’s support in this dimension improves, it is hard to recommend FW for business use.
Bad news, with a planned path forward, is much better than no news. Neutral news is better than bad news. Not everything has to be sunshine and daisies, but no news is particularly difficult.
In the fast-moving world of modern computers, yearly updates are better than no updates, but not what I expect in terms of software longevity. I understand Framework can’t do anything about proprietary/closed-source software provided by vendors that doesn’t have upgrades available, but many of these vendors (especially AMD and Intel) are releasing nearly monthly driver updates with bug and compatibility fixes, and security patches, as well as support for new features (October’s first AMD update includes support for “AMD Fluid Motion Frames (AFMF) 2,” which has major performance improvements specifically for gaming). As of October 2nd, issues had been reported to Framework (via community forums) of major crashing and issues related to this release. You chimed in on the same day to remind folks to use official Framework drivers, and, on the following day, confirmed Frameworks driver bundle was from April. To me, this is a compatibility issue for a bug fix, security patch, and new feature release. I feel that this specific update hits all of the points mentioned in the quote.
AMD has released 9 driver updates for CPU/APU/GPU alone, since Framework’s bundled drivers were last updated. (I’m going off of the Driver Build date of 2/22/2024, a few days before the Adrenalin 24.2.1 release on 2/26/2024.)
What is Framework’s intended policy regarding ongoing software (specifically drivers) support?
Unrelated note regarding response times
Also, as an aside, I don’t work for Framework, and can post whenever I please. I don’t know where you are located (and have no need to know), but it was well after what I hope would be an end of shift for California/PST based folks when you posted your response. I hope you are able to have downtime and aren’t burning the candle at both ends on my behalf. I can wait until standard business hours for a response (especially if you need to check with any other Framework employees to formulate a response). I am not sure if I appear hostile/angry (which is not my intent), but I want Framework to succeed, and that includes healthy work/life balance to prevent burnout. I am frustrated, but I do seriously want everyone at Framework, especially those in customer facing roles of any kind, to have a great day, everyday.
Thank you all for chiming in. I’ll share your feedback with our firmware team and the larger communications team to help improve our processes and provide more frequent updates.
In an ideal scenario, we’d release a beta version of the BIOS, and if no issues are found within a week or two, it would be promoted to stable. At that point, we would update the knowledge base articles, send emails to subscribers, and so on.
For the Framework Laptop 16, we discovered some bugs and have been in an ongoing period of tracking and investigation since this summer. I personally thought there wasn’t much to share (beyond the fact that we’re still working on it), but it seems I was mistaken.
Moving forward, I’ll make it a point to be more active in providing updates after we release a beta BIOS and before promoting it to stable.
This is really good—honestly, I would expect this as a customer.
Maybe we could track these bugs on GitHub instead of the community forums. This way, we could manage them more effectively and provide better visibility.
Do you think it would be easier to provide this data and track these issues on github instead of community forums?
Not gonna lie, it was 11:16 PM, sometimes it just happens
I think that tracking the issues and progress towards fixing using GitHub is an excellent solution to this. It can be organized a lot more easily compared to using community forums, and it’s a great location to have more technical details as well.
I definitely think it would be a lot easier to provide data and track issues on GitHub. Community forums are nice way to communicate big updates regarding things, but I think the more technical details and incremental progress updates through GitHub will be a lot easier to manage compared to different forum posts. For example, each beta bios could have updates listed in GitHub as well as any way we can help test the changes.
For the ability to provide data, I think anywhere could work but for convenience it should be close to the other data regarding the systems. If GitHub is being looked at for communication regarding updates, it maybe could have polls or ways to provide data about how we use the systems and would like to see them improve.
+1 for github or even better, a dedicated gitlab instance (historically, relying on any proprietary service tends to backfire sooner or later, but for now github will do).
Maybe a good start would be FW to enter in all the known bugs of the FW16 into the github issue list and then label which of those they intend to fix in BIOS 3.0.4 and FW can then update each one so we can all see progress towards the BIOS 3.0.4 release. We can then also see which bugs might be fixed and which might have to wait. (post 3.0.4)
I do understand that it is actually quite difficult to know when a BIOS is ready for release, because the risk of bricking customers laptops is not a 0% risk.
I don’t know if the FW 16 is “unbrickable”. By unbrickable, I mean even if you totally corrupt the BIOS flash, there is always a way to recover it without needing to solder anything.
For example some desktop and server motherboards can upgrade the BIOS even with the CPU removed!!! Almost 100% of ARM platforms are also unbrickable because they have ROM that can never be wiped, and it always has a feature whereby one can load the BIOS into ram via the Serial port and run that, thus allowing the system to boot and then be recovered.
Obviously, if the FW16 BIOS was unbrickable, FW would not need to be so cautious about BIOS updates.
it has, but I’ve been here longer haha! I don’t want to get this thread too off track, but I do appreciate all your work to keep things nice and tidy! I was mostly just commenting on how my feelings about the forum being less excited could have come from seeing more posts about support since I’ve been here since before there were products for people to even ask for support with!
To get back on track, I will say that I am glad to see your report on all the BIOS updates that have been released this year, and I’m glad to know that Kieran and the team are continuing to work hard on more updates in the future! It’s also great to see the whole conversation that has unfolded in this thread since your response to me. I really hope to see Framework continue to make progress on hardware and software longevity, as well as keeping the community in the loop about things!
Yes! Github would provide a clean slate, and allow for an easy to access, reliable source of information to find bug tracking, bios updates, or news in general regarding software updates.
EDIT: Make sure that the github is something that is easily noticed/accessed on the main Framework store page, that way people can easily access it an know where to go for more info.
