19:24:51 <brainycmurf> #startmeeting Workstation WG (2021-11-30)
19:24:51 <zodbot> Meeting started Wed Dec  1 19:24:51 2021 UTC.
19:24:51 <zodbot> This meeting is logged and archived in a public location.
19:24:51 <zodbot> The chair is brainycmurf. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
19:24:51 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:24:51 <zodbot> The meeting name has been set to 'workstation_wg_(2021-11-30)'
19:24:51 <brainycmurf> #meetingname workstation
19:24:51 <brainycmurf> #chair Allan
19:24:51 <zodbot> The meeting name has been set to 'workstation'
19:24:51 <zodbot> Current chairs: Allan brainycmurf
19:25:05 <brainycmurf> #info Present members: Allan, Tomas, Jens, Neal, Chris, Matthias
19:25:05 <brainycmurf> #info Present guests: Peter Jones, Justin Forbes, Felipe, Zac, David Duncan, Michel Salim
19:25:05 <brainycmurf> #info Regrets:
19:25:05 <brainycmurf> #info Missing:
19:25:05 <brainycmurf> #info Secretary: Tomas
19:25:06 <brainycmurf> #topic NVIDIA driver and secure boot
19:25:08 <brainycmurf> #link https://pagure.io/fedora-workstation/issue/155
19:25:10 <brainycmurf> Special guest stars: Peter Jones & Justin Forbes
19:25:12 <brainycmurf> Quick summary: if using Nvidia GPUs you can't use Nvidia drivers unless Secure Boot is turned off. (On some machines this might not even be possible). There's currently no capability to automatically disable Secure Boot, or to automatically install the Nvidia driver in a way that's compatible with Secure Boot.
19:25:16 <brainycmurf> Justin and Peter: you can run mokutil to import the keys from a 3rd party repository.
19:25:18 <brainycmurf> Justin: we can't extend the trust to RPM Fusion otherwise we would extend it to Nvidia as well and we don't want to do that. Users have to explicitly opt in to trusting Nvidia (by accepting their key).
19:25:23 <brainycmurf> Peter: we don't have kernel code in place to be able to use key just for a particular module, but there is some WIP for this.
19:25:26 <brainycmurf> Michael and others: current UX -> if a user installs Nvidia driver through Software, then restarts, it will fail to boot as the Nvidia module will fail to load. When the Nvidia driver is installed, Nouveau is blacklisted. "the problem is the efifb and vesafb are turned off once drm is on and since we have nvidia drm on, and blacklist nouveau, we have nothing". At that point, no boot is happening -> this is a bug and needs to be fixed.
19:25:31 <brainycmurf> Neal: PackageKit allows to raise a confirmation dialog, but not part of the dnf backend
19:25:33 <brainycmurf> Owen: we should concentrate on low level things and then build the UI/UX that works across spins based on the low level tooling
19:25:36 <brainycmurf> Justin: someone from RPM Fusion could generate the keys and set up the signing infrastructure, but that's a LOT of work. We should get the agreement from them that they will do so.
19:25:39 <brainycmurf> Michael: can we automatically install and enable the Nvidia driver, without the need for the user to manually install it through Software? Can we assume that the user trusts Nvidia, if they are using Nvidia hardware?
19:25:42 <brainycmurf> Justin: that [presumably, installing proprietary software] goes against Fedora policy. What if someone wants to use Nouveau? <Points raised that this likely wouldn't work in practice?>
19:25:45 <brainycmurf> Nvidia binary drivers don't support old GPUs, only those that need signed firmware.
19:25:47 <brainycmurf> Peter: the key enrolment process is deliberately complex - in order to prevent malware from circumventing it. We have to have a confirmation dialog that tells users what will happen next to enrol the key. This is the same as what happens with Windows or Apple hardware. There's going to have to be some education involved to tell users what will happen.
19:25:54 <brainycmurf> Two approaches to signing the driver: generate keys locally and enrol them (Ubuntu way) OR generate the key centrally and have it served by RPM Fusion. Generating keys locally would require changes in dkms.
19:25:57 <brainycmurf> There is some work in copr.fedorainfracloud.org:egeretto:akmods-secureboot.repo / copr.fedorainfracloud.org:egeretto:kmodtool-secureboot.repo that might add support for secure boot for akmod and dkms - generating per machine key and loaded through mok-utils.
19:26:01 <brainycmurf> Do we want to use a locally generated key or one provided by the repo? The latter (<INSERT REASONS>).
19:26:04 <brainycmurf> Justin: RPM Fusion generating their own key wouldn't be acceptable to Fedora. Would need to generate the key on Fedora infrastructure and then serve the key from RPM Fusion.
19:26:07 <brainycmurf> But - Fedora won't block the kernel on the Nvidia driver.
19:26:09 <brainycmurf> Will also require communication between Fedora kernel team and the Nvidia driver maintainers. Speaking of which - who would be the Nvidia driver maintainers? The existing RPM Fusion maintainers? Needs resolving.
19:26:12 <brainycmurf> We have to expect that the driver may not always be available. Video should fall back if the binary isn't available - that's a bug that needs to be fixed. (TODO: reach out to Adam Jackson and the graphics team to see what the status of this is.)
19:26:16 <brainycmurf> #topic Announcements & status updates
19:26:20 <brainycmurf> Anything the group needs to be aware of?
19:26:22 <brainycmurf> Next week's meeting - workstation planning live from Boston
19:26:24 <brainycmurf> Taiga is getting decommissioned - we had some tickets there. Anything valuable to save?
19:26:26 <brainycmurf> #info Last week's minutes have been posted
19:26:28 <brainycmurf> #link https://meetbot.fedoraproject.org/fedora-meeting-2/2021-11-23/workstation.2021-11-23-21.13.log.html
20:18:48 <brainycmurf> #endmeeting