Friday, 26 November 2021

Fedora 35 on a Dell XPS13 9305

The Dell XPS 93xx (2020/2021) line with its Intel Iris XE integrated graphics has a native Debian developer edition available directly and its interesting to see how this works.

The Dell XPS 9305 is a 13.3" 16:9 model with fixed RAM (soldered to board) and limited connectity 2x Thunderbolt 4 (dual duty as direct power) and 1x USB-C 3.2, distinguishable from the 9310 which has even fewer ports and missig the battery indicator button/leds on the left side. With the limited connectivity a hub or dock is almost a necessity with options such as a Dell DA310 that will provide power to the machine (unlike the DA300) and supplying a 1GiB wired ethernet, 2x USB-A 3.2, monitor connectity via DisplayPort, HDMI and VGA and connected via a Thunderbolt port.

The historic risk of hardware and linux is that you can never been 100% that everything will work. However, I was pleasantly surprised that the majority of the XPS 9305 hardware and the DA310 dock is detected and supported out of the box with Fedora 35 and a 5.14.18/5.15.6 kernel with details below:
$ inxi -F Machine: Type: Laptop System: Dell product: XPS 13 9305 v: N/A serial: Mobo: Dell model: 0PPYW4 v: A02 serial: UEFI: Dell v: 1.0.9 date: 07/20/2021 CPU: Info: Quad Core model: 11th Gen Intel Core i7-1165G7 bits: 64 type: MT MCP cache: L2: 12 MiB Speed: 612 MHz min/max: 400/4700 MHz Core speeds (MHz): 1: 612 2: 582 3: 722 4: 998 5: 546 6: 564 7: 503 8: 691 Graphics: Device-1: Intel TigerLake-LP GT2 [Iris Xe Graphics] driver: i915 v: kernel Device-2: Microdia Integrated_Webcam_HD type: USB driver: uvcvideo Display: x11 server: X.Org 1.20.11 driver: loaded: modesetting unloaded: fbdev,vesa resolution: 1920x1080~60Hz OpenGL: renderer: Mesa Intel Xe Graphics (TGL GT2) v: 4.6 Mesa 21.2.5 Audio: Device-1: Intel Tiger Lake-LP Smart Sound Audio driver: snd_hda_intel Sound Server-1: ALSA v: k5.14.18-300.fc35.x86_64 running: yes Sound Server-2: PipeWire v: 0.3.40 running: yes Network: Device-1: Intel Wi-Fi 6 AX200 driver: iwlwifi IF: wlp164s0 state: up mac: 94:e2:xx:xx:xx:xx Device-2: Realtek RTL8153 Gigabit Ethernet Adapter type: USB driver: r8152 IF: enp0s13f0u2u1 state: down mac: a0:29:xx:xx:xx:xx IF-ID-1: bond0 state: up speed: -1 duplex: unknown mac: 94:e2:xx:xx:xx:xx IF-ID-2: bonding_masters state: N/A speed: N/A duplex: N/A mac: N/A $ lsub Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 007: ID 27c6:5335 Shenzhen Goodix Technology Co.,Ltd. Goodix Fingerprint Device Bus 003 Device 009: ID 413c:c010 Dell Computer Corp. Dell DA310 Bus 003 Device 013: ID 093a:2510 Pixart Imaging, Inc. Optical Mouse Bus 003 Device 005: ID 1d5c:5510 Fresco Logic Frescologic USB2.0 HUB Bus 003 Device 003: ID 0c45:6d13 Microdia Integrated_Webcam_HD Bus 003 Device 002: ID 8087:0029 Intel Corp. AX200 Bluetooth Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 005: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter Bus 002 Device 002: ID 1d5c:5500 Fresco Logic Frescologic USB3.1Gen2 HUB Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub $ lspci 0000:00:00.0 Host bridge: Intel Corporation 11th Gen Core Processor Host Bridge/DRAM Registers (rev 01) 0000:00:02.0 VGA compatible controller: Intel Corporation TigerLake-LP GT2 [Iris Xe Graphics] (rev 01) 0000:00:04.0 Signal processing controller: Intel Corporation TigerLake-LP Dynamic Tuning Processor Participant (rev 01) 0000:00:06.0 System peripheral: Intel Corporation Device 09ab 0000:00:07.0 PCI bridge: Intel Corporation Tiger Lake-LP Thunderbolt 4 PCI Express Root Port #0 (rev 01) 0000:00:07.1 PCI bridge: Intel Corporation Tiger Lake-LP Thunderbolt 4 PCI Express Root Port #1 (rev 01) 0000:00:08.0 System peripheral: Intel Corporation GNA Scoring Accelerator module (rev 01) 0000:00:0a.0 Signal processing controller: Intel Corporation Tigerlake Telemetry Aggregator Driver (rev 01) 0000:00:0d.0 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 USB Controller (rev 01) 0000:00:0d.2 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 NHI #0 (rev 01) 0000:00:0e.0 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller 0000:00:14.0 USB controller: Intel Corporation Tiger Lake-LP USB 3.2 Gen 2x1 xHCI Host Controller (rev 20) 0000:00:14.2 RAM memory: Intel Corporation Tiger Lake-LP Shared SRAM (rev 20) 0000:00:15.0 Serial bus controller [0c80]: Intel Corporation Tiger Lake-LP Serial IO I2C Controller #0 (rev 20) 0000:00:15.1 Serial bus controller [0c80]: Intel Corporation Tiger Lake-LP Serial IO I2C Controller #1 (rev 20) 0000:00:16.0 Communication controller: Intel Corporation Tiger Lake-LP Management Engine Interface (rev 20) 0000:00:19.0 Serial bus controller [0c80]: Intel Corporation Tiger Lake-LP Serial IO I2C Controller #4 (rev 20) 0000:00:19.1 Serial bus controller [0c80]: Intel Corporation Tiger Lake-LP Serial IO I2C Controller #5 (rev 20) 0000:00:1c.0 PCI bridge: Intel Corporation Device a0b8 (rev 20) 0000:00:1d.0 PCI bridge: Intel Corporation Device a0b3 (rev 20) 0000:00:1e.0 Communication controller: Intel Corporation Tiger Lake-LP Serial IO UART Controller #0 (rev 20) 0000:00:1f.0 ISA bridge: Intel Corporation Tiger Lake-LP LPC Controller (rev 20) 0000:00:1f.3 Audio device: Intel Corporation Tiger Lake-LP Smart Sound Technology Audio Controller (rev 20) 0000:00:1f.4 SMBus: Intel Corporation Tiger Lake-LP SMBus Controller (rev 20) 0000:00:1f.5 Serial bus controller [0c80]: Intel Corporation Tiger Lake-LP SPI Controller (rev 20) 0000:a3:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS525A PCI Express Card Reader (rev 01) 0000:a4:00.0 Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a) 10000:e0:06.0 PCI bridge: Intel Corporation 11th Gen Core Processor PCIe Controller (rev 01) 10000:e1:00.0 Non-Volatile memory controller: SK hynix Gold P31 SSD
Some installation references for 93xx series note that BIOS setting changes to secure boot/SATA mode are required but this was NOT my case and a clean F35 installation (booted from USB stick, via a Amazon/UGreen USB-C dongle) without such changes.

Initial partitioning of the harddrive can be done in Windows itself via disqkmngt.msc and overcoming gotchas if necessary. I didn't face issues but perhaps I did this without any new installations to the Windows machine and carving a 180GiB / 270GiB in favour for Linux on the 512GiB disk.

Post installation followed some of the steps from installations to Asus x202e laptop and an old HP netbook.
$ systemctl enable sshd autofs nfs-server --now && mkdir /net $ firewall-cmd --add-service={nfs,nfs3,mountd,rpc-bind,samba,samba-client} --permanent $ cat >> /etc/vimrc << EOF set ai sw=4 :nnoremap <CR> :nohlsearch <CR>/<BS> EOF $ cat > /etc/exports << EOF /export/public 192.168.0.0/16(rw,sync,no_root_squash) /export/src 192.168.0.0/16(ro,sync,no_root_squash) EOF $ cat >> /etc/inputrc << EOF set show-all-if-ambiguous on set editing-mode vi EOF $ cat >> /etc/profile.d/colorls.sh << EOF alias ls='ls -F --color=auto' 2>/dev/nul EOF $ cat > /etc/rc.local << EOF #!/bin/bash /usr/sbin/ntpdate uk.pool.ntp.org 2>/dev/null & /usr/sbin/logrotate /etc/logrotate.conf exit 0 EOF $ chmod a+x /etc/rc.local # disable core dump, although journal entry will exist via 'coredumpctl list' $ cat >> /etc/systemd/coredump.conf << EOF Storage=none ProcessSizeMax=0 EOF $ cat >> /etc/systemd/journald.conf << EOF SystemMaxUse=250M MaxRetentionSec=3month MaxFileSec=1month EOF $ cat > /etc/systemd/system/rtkit-daemon.service.d/override.conf << EOF [Service] LogLevelMax=3 EOF $ cat > /etc/systemd/system/NetworkManager.service.d/override.conf << EOF [Service] LogLevelMax=3 EOF $ systemctl mask systemd-journald-audit.socket $ systemctl daemon-reload $ rm /var/lib/systemd/coredump/* # disable debuginfod which can be horrifically slow # https://fedoraproject.org/wiki/Debuginfod $ rm /etc/debuginfod/*.urls $ echo "set debuginfod enabled off" > /etc/gdbinit.d/debuginfo.gdb $ grubby --update-kernel ALL --args selinux=0

BIOS

With Linux/grub installed, the grub menu has an entry that takes you directly to the UEFI BIOS; This machine (~Nov 2021) came with 1.0.9 but was Dell/Windows have enabled automated firmware and driver pushes which will lead to ZERO choice/forced BIOS upgrades if you boot into Windows when a new BIOS is available.

To disable under 1.1.0, enter BIOS and Update,Recovery -> UEFI capsule firmware updates = NO. This will also prevent BIOS updates initiated from fwupdmgr from Linux.

Graphics/Display

The graphics chip is fine and display is driven by the generic modesetting kernel driver, with hardware accelerated video decode (for mpv etc) supported over VAAPI with the intel drivers.
$ dnf install \ https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm \ https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm # install non-free iHD driver for VAAPI handling $ dnf -y install libva libva-utils intel-media-driver # force mpv to use h/w decode $ cat > /etc/mpv/mpv.conf << EOF hwdec=vaapi EOF # if this reports i915 then something is wrong $ vainfo | grep Driver vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 21.3.4 ()
The X11 driver can be left as is (modsetting) rather than the xorg-x11-drv-intel. Some minor tuning for the i915 kernel module is available to control GPU offloading:
$ cat > /etc/modprobe.d/i915.conf << EOF options i915 enable_guc=3 # framebuffer compression, further power reduction options i915 enable_fbc=1 EOF # rebuild initrm.img $ dracut --force
Upon next reboot, you should see:
$ dmesg | grep i915 [ 1.685690] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/tgl_dmc_ver2_12.bin (v2.12) [ 2.737213] i915 0000:00:02.0: [drm] GuC firmware i915/tgl_guc_69.0.3.bin version 69.0 [ 2.737216] i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc_7.9.3.bin version 7.9 [ 2.740614] i915 0000:00:02.0: [drm] HuC authenticated [ 2.741413] i915 0000:00:02.0: [drm] GuC submission enabled [ 2.741414] i915 0000:00:02.0: [drm] GuC SLPC enabled [ 2.741783] i915 0000:00:02.0: [drm] GuC RC: enabled
Video encoding with QuickSync is flawless and can be monitored by intel_gpu_top
# see ffmpeg QSV reference here $ ffmpeg -encoders | egrep "qsv|vaapi" $ ffmpeg -h filter=vpp_qsv $ ffmpeg -hwaccel qsv -c:v h264_qsv -i foo-1080.mp4 \ -c:a copy -c:v h264_qsv -b:v 8M -minrate 500k -maxrate 12M \ vf "vpp_qsv=transpose=clock,scale_qsv=w=720:h=-1:mode=hq" \ foo-720vbr.mp4
Whilst fierfox claims to have added h/w decode support for linux, version 94.0 with media.ffmpeg.vaapi.enabled = true will cause the browser tab to randomly crash whenever there is media on the page - this happens nearly ALL of the time although using YouTube and monitoring via intel_gpu_top I am not able to see any offloading - at this point, I have left the vaapi override as per default (off). Installing something like h264ify to force mp4 stream 100% causes the YouTube tab to crash.

UPDATE: Using firefox 97.0 seems to work for h/w video decode (MP4 and VP9) with driver 21.4.3 with the following config
  • gfx.webrender.all = true
  • media.ffmpeg.vaapi-drm-display.enabled = true
  • media.ffmpeg.vaapi.enabled = true

fedora-multimedia / negativo17

There exists an alternative multimedia repo to rpmfusion that also provides ffmpeg but this versions has compiled-in support for the FDK-aac library. If you must have FDK-aac support you can use the negativo17 repo BUT ensure that you continue to use the intel-media-driver from rpmfusion otherwise you'll find VAAPI hardware decoding failing.
$ dnf config-manager --add-repo=https://negativo17.org/repos/fedora-multimedia.repo $ dnf config-manager --save --setopt fedora-multimedia.exclude="intel-media-*" $ for i in rpmfusion-free rpmfusion-free-updates; do \ dnf config-manager --save --setopt $i.exclude="ffmpeg* mpv*" \ done

Display

Using the DA310's DisplayPort, connecting to an external monitor is simple - theres a dedicated F8 binding that initiates mirror'ing the screen, although this can be changed to be an extended desktop. The important note is that the DA310, whilst providing 3x video output connectors supporting up to 60hz refresh, ONLY supports one output at a time. Using the F8 key, I was not able to directly disable the laptop screen but I suspect this can be achieved via xrandr

Furthermore, using an inexpensive UGreen USB-C hub with HDMI output (connected to the right handside non-thunderbolt port), I am able to drive 3 monitors. The UGreen USB hub identifies itself as:
Bus 003 Device 004: ID 05e3:0610 Genesys Logic, Inc. Hub Bus 002 Device 003: ID 05e3:0749 Genesys Logic, Inc. SD Card Reader and Writer Bus 002 Device 002: ID 05e3:0626 Genesys Logic, Inc. USB3.1 Hub
Closing the laptop with the 2x external monitors (via DA310's DisplayPort and the UGreen hub's HDMI port) attached and configured works as expected - all screens temporarily blank and the system reconfigures itself. Note that machine has a preferance/order of ports in terms of video output: Thunderbolt ports (#1 main power, left side top, #2 secondary port, left side bottom) USB-C 3.1 (right side).

Networking

The wifi card has no issues although some earlier reports/older kernels suggested the Killer AX200 chip was not supported. The DA310 hub's GiB network interface (powered by a RealTek RTL8153) is also flawless - as per all my wired/wifi enabled machines, I create a bond interface for consistent IP assignement and this too works as expected even with the wired connection via the Thunerbolt 4 port.

Note that Linux will give your network connections predictable network names but this by default will include information about the PCI bus that the device is located: this means that the same DA310 ethernet jack will have a differernt names when plugged into the top left vs bottom left thunderbolt port. This need attention when creating the bonded ethernet devices (you will need to add both to the bonded interface unless you will always use the same thunderbolt port for connecting the DA310).

Following systemd.link we can override systemd's persistent device naming scheme.
$ lsusb | grep Ethernet Bus 002 Device 005: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter $ lsusb -v -s 002:005 | grep iMac iMacAddress 3 0C3796xxxxxx # setup persistent name $ cat > /etc/systemd/network/10-eth-da310.link << EOF [Match] MACAddress=0c:37:96:xx:xx:xx [Link] Name=ethda310 EOF
However, when we monitor the system logs for the device we see that the rules have not applied:
[17200.952775] r8152 2-1.1:1.0 (unnamed net_device) (uninitialized): Using pass-thru MAC addr xx:xx:xx:xx:xx:xx [17200.969596] r8152 2-1.1:1.0: load rtl8153b-2 v1 10/23/19 successfully [17200.999251] r8152 2-1.1:1.0 eth0: v1.12.11 [17201.038368] r8152 2-1.1:1.0 enp0s13f0u1u1: renamed from eth0
Using the device name from the system logs, we can verify that systemd did in fact try to rename but this failed due to MAC address not matching:
$ SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link /sys/class/net/enp0s13f0u1u1 ... Loaded timestamp for '/etc/systemd/network'. Parsed configuration file /usr/lib/systemd/network/99-default.link Parsed configuration file /etc/systemd/network/10-eth-da310.link Created link configuration context. ID_NET_DRIVER=r8152 enp0s13f0u1u1: Device has name_assign_type=4 enp0s13f0u1u1: Config file /usr/lib/systemd/network/99-default.link is applied enp0s13f0u1u1: Failed to get ACTION= property: No such file or directory enp0s13f0u1u1: Could not apply link configuration, ignoring: No such file or directory ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link Unload module index Unloaded link configuration context.
Notice the highlighted: Using pass-thru MAC addr - this is a Dell BIOS feature:
[network devices have] their own MAC address built into their chipsets. When dock/adapter is connected to a Dell system that supports MAC Pass-through, and the network driver is loaded on the system, the adapter specific MAC address will be overridden by the system specific MAC address from the BIOS
To prevent this behaviour update the BIOS settings: Pre-boot Bahviour -> MAC Address Pass-Through = Disabled and upon next boot:
$ dmesg ... [ 2183.450846] r8152 2-1.1:1.0 (unnamed net_device) (uninitialized): Invalid header when reading pass-thru MAC addr [ 2183.469019] r8152 2-1.1:1.0: load rtl8153b-2 v1 10/23/19 successfully [ 2183.497741] r8152 2-1.1:1.0 eth0: v1.12.11 [ 2183.522662] r8152 2-1.1:1.0 ethda310: renamed from eth0 $ SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link /sys/class/net/ethda310 ... Loaded timestamp for '/etc/systemd/network'. Parsed configuration file /usr/lib/systemd/network/99-default.link Parsed configuration file /etc/systemd/network/10-eth-da310.link Created link configuration context. ID_NET_DRIVER=r8152 ethtb16: Device has name_assign_type=4 ethtb16: Config file /etc/systemd/network/10-eth-da310.link is applied ethtb16: Failed to get ACTION= property: No such file or directory ethtb16: Could not apply link configuration, ignoring: No such file or directory ID_NET_LINK_FILE=/etc/systemd/network/10-eth-da310.link Unload module index Unloaded link configuration context.
Finally, the ethernet device on the bond will use the ethda310 device whos name will consistent no matter which physical port it is attached.
$ nmcli con \ add type bond \ con-name bond \ ifname bond0 \ mode active-backup \ primary ethda310 \ +bond.options "fail_over_mac=active,miimon=100,primary_reselect=always,updelay=200" \ ip4 192.168.0.123/24 \ gw4 192.168.0.1 \ ipv4.dns "8.8.4.4 8.8.8.8" \ ipv4.method manual \ ipv6.method ignore # create the slaves connections against the phys interfaces $ nmcli con \ add type wifi \ con-name bond-wlan \ slave-type bond \ master bond0 \ ifname wlp164s0 \ ssid your-wifi-ssid $ nmcli con \ add type ethernet \ con-name bond-eth \ slave-type bond \ master bond0 \ ifname ethda310 # update the wifi details seperate (not available in connnection setup above) $ nmcli con modify bond-wlan wifi-sec.key-mgmt wpa-psk $ nmcli con modify bond-wlan wifi-sec.psk your-wifi-password # disable the auto created interfaces tied to the physical devices $ nmcli c down your-wifi-ssid && nmcli c modify your-wifi-ssid autoconnect no $ nmcli c down ethda310 && nmcli c modify ethda310 autoconnect no # finally bring up the connection associated with bond0 device $ nmcli c up bond

Audio

Audio works and uses the newer Pipewire subsytem over raw Pulseaudio causes some issues for paprefs (won't install) which gives rise to some issues with creating multiple outputs redirect to a single output sink: for example, using a wired USB headset for zoom/conference calls and duplicate output to headset and speakers.

Using the default sound settings, it's a binary option - I've also noticed that when the USB headset is disconnected the subsequent boots the audio applications crash; mpv starts but hangs, YouTube crashes firefox etc and you must go and manually reset/reconfigure to use the onboard/headphone outputs.

The pipewire migration guide is not very helpful although it claims that the pulseaudio module-combine-sink is supported. It is possible to manually create the output sink for manually with pactl and pw-link
# create the output $ pactl load-module module-null-sink media.class=Audio/Sink sink_name=virtual-output channel_map=stereo # find the device names you want to route to virtual output device $ pw-link -o Midi-Bridge:Midi Through:(capture_0) Midi Through Port-0 v4l2_input.pci-0000_06_00.0-usb-0_1.7.2_1.0:out_0 v4l2_input.pci-0000_00_14.0-usb-0_3_1.0:out_0 alsa_output.usb-Plantronics_Plantronics_Blackwire_3210_Series_2FC9575B28134CEA815BE1C29F63D5D0-00.mono-fallback:monitor_MONO alsa_input.usb-Plantronics_Plantronics_Blackwire_3210_Series_2FC9575B28134CEA815BE1C29F63D5D0-00.iec958-stereo:capture_FL alsa_input.usb-Plantronics_Plantronics_Blackwire_3210_Series_2FC9575B28134CEA815BE1C29F63D5D0-00.iec958-stereo:capture_FR alsa_output.usb-Generic_USB_Audio_200901010001-00.HiFi__hw_Dock_1__sink:monitor_FL alsa_output.usb-Generic_USB_Audio_200901010001-00.HiFi__hw_Dock_1__sink:monitor_FR alsa_output.usb-Generic_USB_Audio_200901010001-00.HiFi__hw_Dock__sink:monitor_FL alsa_output.usb-Generic_USB_Audio_200901010001-00.HiFi__hw_Dock__sink:monitor_FR alsa_input.usb-Generic_USB_Audio_200901010001-00.HiFi__hw_Dock__source:capture_FL alsa_input.usb-Generic_USB_Audio_200901010001-00.HiFi__hw_Dock__source:capture_FR alsa_output.pci-0000_00_1f.3.analog-stereo:monitor_FL alsa_output.pci-0000_00_1f.3.analog-stereo:monitor_FR alsa_input.pci-0000_00_1f.3.analog-stereo:capture_FL alsa_input.pci-0000_00_1f.3.analog-stereo:capture_FR # manually link them together $ pw-link virtual-output:monitor_FL \ alsa_output.usb-Generic_USB_Audio_200901010001-00.HiFi__hw_Dock__sink:playback_FL $ pw-link virtual-output:monitor_FR \ alsa_output.usb-Generic_USB_Audio_200901010001-00.HiFi__hw_Dock__sink:playback_FR ...
The pipewire docs suggest making this a persistent virtual sink via system or user config:
$ cat > /etc/pipewire/virtual-sink.conf << EOF context.objects = [ ... { factory = adapter args = { factory.name = support.null-audio-sink node.name = "virtual-output" node.description = "A virtual device combining all physical outputs into one" media.class = Audio/Sink object.linger = true audio.position = [ FL FR ] } } ... ] EOF $ pipewire -v -c virtual-sink.conf [W][27767.124162] pw.context | [ context.c: 1331 pw_context_load_spa_handle()] 0x562d7db829e0: no library for support.null-audio-sink: No such file or directory [E][27767.124304] mod.adapter | [module-adapter.c: 252 create_object()] can't create node: No such file or directory [E][27767.124330] pw.conf | [ conf.c: 503 create_object()] can't create object from factory adapter: No such file or directory [E][27767.124664] default | [ pipewire.c: 123 main()] failed to create context: No such file or directory [D] pw.context [pipewire.c:209 unref_handle()] clear handle 'support.log' [D] pw.context [pipewire.c:209 unref_handle()] clear handle 'support.cpu'
But of course it doesn't work.
How to easily/visually create the links feeding into this device however... pipewire's lack of a paprefshurts here, although there is a context.exec block at this available to execute shell scripts/commands after each launch so a user could manually link all outputs together but user experience is obviously very poor.

Going back to PulseAudio

The biggest gripe I have with pipewire is, not only the items above, but that under certain loads, the audio becomes choppy and stutters - its just a terrible user experience. Luckily we can choose to go back to PulseAudio relatively easily:
$ dnf swap --allowerasing pipewire-pulseaudio pulseaudio $ dnf install pulseaudio-utils paprefs $ dnf remove pipewire pipewire-pulseaudio wireplumber
Following this, reboot and we'll be back to something much more stable.

Bluetooth

There appears to be no problem with bluetooth although there are a number of bug reports indicating that Intel AX200 bluetooth chip and Linux 5.15.4 onwards fails to initialise bluetooth devices upon reboots with hci0: command 0xfc05 tx timeout messages. This has been fixed in 5.15.15.

I have noticed pairing devices with the default installation can be hit and miss; attmpting to pair an bluetooth Apple keyboard (05ac:023a) I had to use bluetoothctl as bluetooth manager was not able to discover it, but was able to discover various phones and tablets:
$ bluetoothctl Agent registered [bluetooth]# power on Changing power on succeeded [bluetooth]# pairable on Changing pairable on succeeded [bluetooth]# scan on Discovery started [CHG] Controller 94:E2:3C:xxDELLxx Discovering: yes [NEW] Device 78:CA:39:xx:xx:xx 78-CA-39-xx-xx-xx ,,, [CHG] Device 78:CA:39:xx:xx:xx LegacyPairing: no [CHG] Device 78:CA:39:xx:xx:xx Name: Apple Wireless Keyboard [CHG] Device 78:CA:39:xx:xx:xx Alias: Apple Wireless Keyboard [CHG] Device 78:CA:39:xx:xx:xx LegacyPairing: yes [bluetooth]# pair 78:CA:39:xx:xx:xx Attempting to pair with 78:CA:39:xx:xx:xx [CHG] Device 78:CA:39:xx:xx:xx Connected: yes [agent] PIN code: xxxxxx [CHG] Device 78:CA:39:xx:xx:xx Modalias: usb:v05ACp023Ad0050 [CHG] Device 78:CA:39:xx:xx:xx UUIDs: 00001124-0000-1000-8000-00805f9b34fb [CHG] Device 78:CA:39:xx:xx:xx UUIDs: 00001200-0000-1000-8000-00805f9b34fb [CHG] Device 78:CA:39:xx:xx:xx ServicesResolved: yes [CHG] Device 78:CA:39:xx:xx:xx Paired: yes Pairing successful [CHG] Device 78:CA:39:xx:xx:xx WakeAllowed: yes [CHG] Device 78:CA:39:xx:xx:xx ServicesResolved: no [CHG] Device 78:CA:39:xx:xx:xx Connected: no [bluetooth]# trust 78:CA:39:xx:xx:xx [CHG] Device 78:CA:39:xx:xx:xx Trusted: yes Changing 78:CA:39:xx:xx:xx trust succeeded [bluetooth]# connect 78:CA:39:xx:xx:xx Attempting to connect to 78:CA:39:xx:xx:xx [CHG] Device 78:CA:39:xx:xx:xx Connected: yes Connection successful [CHG] Device 78:CA:39:xx:xx:xx ServicesResolved: yes
Once paired the laptop will remember the device across reboots and we can update minor udev configuration to ensure proper Apple keyboard mappings:
$ cat > /etc/udev/rules.d/99-apple-a1314.rules << EOF # /etc/udev/rules.d/99-apple-a1314.rules # for a 2009 Apple a1314 bluetooth wireless keyboard # # udevadm info -a -n /dev/hidraw1 # udevadm control --reload-rules # ACTION=="add", KERNELS=="*:05AC:023A.*", SUBSYSTEMS=="hid", RUN+="/usr/bin/udev-apple-a1314.sh" EOF $ cat > /usr/bin/udev-apple-a1314.sh << EOF #!/bin/bash if [ ! -d /sys/module/hid_apple/parameters ]; then echo "HID apple module directory not available, modprobe hid-apple???" # /sbin/modprobe hid-apple exit 1 fi echo 1 > /sys/module/hid_apple/parameters/iso_layout echo 1 > /sys/module/hid_apple/parameters/swap_opt_cmd echo 1 > /sys/module/hid_apple/parameters/fnmode echo 1 > /sys/module/hid_apple/parameters/swap_fn_leftctrl EOF $ chmod a+x /usr/bin/udev-apple-a1314.sh
Interestingly, the udev subsystem does not identify this via a product or vendor id as possible with a similar wired A1242 (a5ac:021e) keyboard which we can use udevadm test $(udevadm info -q path -n /dev/input/by-id/usb-Apple_Inc._Apple_Keyboard-event-kbd) and subsequently SUBSYSTEM=="input", ATTRS{idVendor}=="05ac", ATTRS{idProduct}=="021e"

Pairing the same bluetooth device with a dual boot machine needs a little bit of trickery: in essense the bluetooth devices remembers an authorised token between itself and the paired device and this token is generated upon each pairing - if you pair with Linux and then Windows, the bluetooth device will have a different token when you go back to linux. This can be solved by manually syncing the token between your OSs. Linux keeps its tokens under /var/lib/bluetooth/host bluetooth mac/device bluetooh mac/info.

Webcam

The webcam (0c45:6d13) works fine but the position is painfully low (as natural on the screen on the laptop). If you wish to disable the webcam, this is possible via the BIOS or via a udev rule.
$ lsusb -tvv ... |__ Port 3: Dev 3, If 0, Class=Video, Driver=, 480M ID 0c45:6d13 Microdia /sys/bus/usb/devices/3-3 /dev/bus/usb/003/003 |__ Port 3: Dev 3, If 1, Class=Video, Driver=, 480M ID 0c45:6d13 Microdia /sys/bus/usb/devices/3-3 /dev/bus/usb/003/003 # lets find out udev visible info for rule $ udevadm info -a -n /sys/bus/usb/devices/3-3 ... looking at device '/devices/pci0000:00/0000:00:14.0/usb3/3-3': KERNEL=="3-3" SUBSYSTEM=="usb" DRIVER=="usb" ATTR{authorized}=="1" ATTR{avoid_reset_quirk}=="0" ATTR{bConfigurationValue}=="1" ATTR{bDeviceClass}=="ef" ATTR{bDeviceProtocol}=="01" ATTR{bDeviceSubClass}=="02" ATTR{bMaxPacketSize0}=="64" ATTR{bMaxPower}=="500mA" ATTR{bNumConfigurations}=="1" ATTR{bNumInterfaces}==" 2" ATTR{bcdDevice}=="9219" ATTR{bmAttributes}=="80" ATTR{busnum}=="3" ATTR{configuration}=="" ATTR{devnum}=="3" ATTR{devpath}=="3" ATTR{idProduct}=="6d13" ATTR{idVendor}=="0c45" ATTR{ltm_capable}=="no" ATTR{manufacturer}=="Sonix Technology Co., Ltd." ATTR{maxchild}=="0" # note that identifiers we use to identify and disable $ cat > /etc/udev/rules.d/99-webcam.rules << EOF SUBSYSTEM=="usb", ATTRS{idVendor}=="0c45", ATTRS{idProduct}=="6d13", ATTR{authorized}="0" EOF $ udevadm control --reload-rules
Because this is identified by the usb subsystem and driver the udev rule will only come into effect on boot. If you need to dynamically enable the webcam: echo 1 | sudo tee /sys/bus/usb/devices/3-3/authorized

Whilst at a desk with an external monitor running, using an external webcam like a Logitech C310 is an option although its useful to disable the external webcam microphone:
$ cat > /etc/udev/rules.d/70-logitech-c310.rules << EOF SUBSYSTEM=="usb", DRIVER=="snd-usb-audio", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="081b", ATTR{authorized}="0" EOF
The reason to mention this is that whilst most conference software will allow you to select inputs, its preferable to disable the microphone if at all possible but I've not found this option with the built in mic yet.

Virtualisation and Containerisation

There were no issues running QEMU / virt-manager with my Windows 7 image from a different machine - Intel documents how to perform graphics passthrough to the VM via vfio-pci but this is isn't something I've explored for Fedora yet as Intel documents refer to a Ubuntu kernel.

Containerisation (and rootless containers) via podman works with no additional configuration with Fedora 35 by default shipping and configured with container groups v2/unified heirarchy.

Power management via S0ix states

The Dell XPS 9305 has support for S0ix states (similar to S3/suspend to mem) as described by this Intel reference here with a troubleshooting materials here. I am still to investigate the impact of the modern S0ix states (opportunistic and explicit) but for certain reported that traditional "deep" sleep/hibernation is not supported with /sys/power/mem_sleep only supporting s2idle which we've observed working.

Fingerprint sensor

The fingerprint sensor does not work without manually overwritting system fingerprint handling shared libs from Dell's Debian based packages so I've left this alone. However, sometimes this can cause slight problems, particularly when using sudo or other authentication means.

For example, the login may take a while whilst PAM timeouts the query to the fingerprint daemon and you'll see similar journal errors:
sudo[7281]: pam_fprintd(sudo:auth): GetDevices failed: Connection timed out
For me, its simply easier just to disable this:
$ systemctl mask fprintd $ authselect disable-feature with-fingerprint

Conclusions

Overall, Fedora on this Dell XPS 13 9305 laptop has been an easy experience - long gone are the days, it seems, of fighting installers/BIOS/bootloaders as we had to even 10yrs ago, nevermind the days of Slackware in the 1990s. Almost all things work, and work well including the inbuilt micro SD card reader. Theres some minor annoyances switching off laptop screen when using external monitor but given that the we have working networks, graphic card h/w decode/encode acceleation and working docking station, it's not a bad platform to start your complaints.

No comments:

Post a Comment