#10202 Custom F34 Workstation Respin for Framework Laptop
Closed: Fixed 2 years ago by humaton. Opened 2 years ago by coremodule.

  • Describe the issue

The Framework company is releasing a new laptop this summer and would like to be able to link users to a Fedora image made for this laptop. Normally, we would link to vanilla F34 and be done, but the 5.11 kernel that is included with F34 has issues with the wifi card, and the version of libfprint that ships does not support the fingerprint reader. I would like to request a respin of Fedora, similar to what was done with Lenovo in the past [0] with the latest 5.12 kernel and this scratch build of libfprint for F34 [1]. These two things (5.12 kernel and new libfprint) should fix the issues that the Framework laptop has with vanilla F34. This will allow the Framework company to point to this image for users who wish to install Fedora OOTB.

If we can do this similar to the way the respin for Lenovo was made (signed by official Fedora keys), that would be great.

One last thing that was requested was to enable fractional scaling by default in Wayland. As the resolution is fairly high for such a small screen, everything appears tiny on an install without fractional scaling. I know that GNOME has asked that we not enable fractional scaling by default because it's still marked as "experimental", but I know the Framework team would be glad to have that as users will have to enable it themselves to really be able to see or not. Can we do this too?

[0] https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/GLNSAYRBPHK6JIJFPQYXELZFQLM57MKH/#YCGP25ZAMHK35UV7LCBNN5VGVQA2VYPG
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=71533104


Requested a patched kernel for use with this to add the "deep" parameter to /sys/power/mem_sleep here: [0]

[0] https://bugzilla.redhat.com/show_bug.cgi?id=1980886

New libfprint waiting to be pushed to stable, could use some karma! [0]

[0] https://bodhi.fedoraproject.org/updates/FEDORA-2021-0787b217cf

Requested a patched kernel for use with this to add the "deep" parameter to /sys/power/mem_sleep here: [0]

[0] https://bugzilla.redhat.com/show_bug.cgi?id=1980886

Let me copy and paste the comment which I added to the bugzilla here too:

A patched kernel is not really an option here, since users need to be able to install security updates and we don't want to have to rebuild such a patched kernel on every kernel update just for the framework laptop.

But there is another option, you can add "mem_sleep_default=deep" to the kernel commandline to get the same result as the echo; and if we are going to spin a special image, then we might be able to insert that into the image, after which it should stick around since the previous kernel-commandline is re-used when installing newer kernel packages.

So thinking more about this and looking at what was done the previous time we respun an image with included updates for vendor-preload purposes, I'm not entirely sure if the kernel cmdline idea is the best option. Give how the previous image was published it really boils down to a mostly offical F33 respin with latest updates included, which means others might use it for other purposes too.

As such I think it might be better to just add a downstream patch to the regular Fedora kernels which enables mem_sleep_default=deep on the Framework laptop based on identifying it by its DMI strings.

The kernel is full of DMI quirks for various hw, but I don't think there is a pre-existing quirk mechanism we can use here in this case. Still adding one should not be hard. Ideally we would get the patch for this upstream, but otherwise it might be acceptable as a downstream (Fedora specific) kernel patch too; and that way the respun image would be as standard as possible, rather then it having Framework specific mods.

Note if such patch will be accepted into the Fedora kernels is not my call.

As of 1820UTC, the new libfprint is going stable.

Metadata Update from @mohanboddu:
- Issue tagged with: medium-gain, medium-trouble, ops

2 years ago

So, is pointing to the repins sufficient here? They should have the newer kernel and libfprint and work just like the GA ones...

Or do we need to do a more 'official' iso for them?

Metadata Update from @humaton:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata
Boards 1
Ops Status: Backlog