Talk:Dell XPS 13 (9343)

From ArchWiki
Jump to navigation Jump to search

Read this first

If you are adding information about a bug/regression, PLEASE include a source link to a bug tracker, forum, etc. so that others can update this wiki page when the issue is resolved. Soren121 (talk) 20:30, 10 August 2015 (UTC)


This wiki states that linux buyers "should pay special attention to display configuration options (FHD/QHD+)" but then there is nothing mentioned about these options anywhere else.

Sorry, but can I ask what special attention should I pay? Do both screen options work fine in Linux?

Bulletmark (talk) 13:28, 1 June 2015 (UTC)

They both work fine, but HiDPI support is a necessity for the QHD+ screen, whereas you can get away with just changing text size on the FHD. HiDPI is still uneven on Linux; Gnome 3 currently has the best HiDPI support, while KDE 5's is a work-in-progress. Soren121 (talk) 13:45, 1 June 2015 (UTC)
Perhaps add your comment to the main page? I use GNOME 3 BTW and knew that. I don't really see the point of getting the QHD+ display and just scaling most things up. It also is glossy instead of matte, chews more battery, and causes slightly more heat. Bulletmark (talk) 13:53, 1 June 2015 (UTC)
Done. I agree with your points; that's exactly why I got the FHD model myself. The only configuration I had to do was increase the text scaling in Gnome to 1.25. Soren121 (talk) 06:45, 2 June 2015 (UTC)

Intel wifi option?

The page says:

"The Intel module has a 2-3 times wider reception range and way higher throughput, making it an worthwhile upgrade should you decide to do so."

I guess replacing the factory Broadcom card would void the warranty though? Is opening the case and replacing the card difficult? Perhaps comments about these could be added.

BTW. I am about to get a i5+8GB+256GB+broadcom wifi+FHD model delivered and will clobber the windows install with Arch. Hence my interest in this wiki page. I will contribute feedback when I do the install.

Bulletmark (talk) 04:36, 3 June 2015 (UTC)

As far as I know, if you replace the WiFi card, the rest of the laptop is still covered by the warranty. Dell is pretty good about user-serviceability; they even provide the service manual (PDF) for free. They will not, however, cover any damage that you may cause while working inside your laptop. It's quite easy to replace the WiFi card, but you do need a Torx T5 screwdriver and a plastic spudger to remove the bottom half of the case, and most people don't have those lying around. As for including instructions in the wiki, disassembling the laptop has no relevance to its support in Arch, so I don't think that would belong here. Soren121 (talk) 05:06, 3 June 2015 (UTC)
For the technical part of swapping things out Soren121 has got you covered pretty well already. Even if you have those tools though (I did the modification and am in fact the person that put up the information on the page, so yes, I had the tools ready), getting the bottom off can be a bit troublesome to say the least. For some parts you do have to apply a bit more force than you would think is good for the device, but don't worry, it's pretty sturdy and can handle it should you ever decide to go through with the modification. Once the bottom is removed its a matter of removing the single screw that holds the WiFi card in place, unplugging the two antenna-wires from the module, followed by, obviously, putting the new module in place and reversing the steps. The antenna wires are color-coded, and so are the replacement WiFi modules, so you should have no problem matching the antenna wires. Coldbird (talk) 14:11, 30 June 2015 (UTC)

VirtualBox freezing workaround

I just added a edit to provide a solution for the Broadwell related VirtualBox Virtual Machine startup freezing issues. However I'm not entirely sure if I placed this tip too well... while it does affect the Dell XPS 13 (as it obviously is a Broadwell based device), this issue does span over multiple device making me believe it might be better placed in the VirtualBox page than this one.

So, what do you guys think? Place it on the VirtualBox page or leave it here?

If we do move it to the VirtualBox page, should a reference link remain on the Dell XPS 13 (2015) page or should we treat this the same way we did the PulseAudio flat volumes issue? Coldbird (talk) 08:26, 7 July 2015 (UTC)

I vote to move it to the VirtualBox page and remove it from this page. First off, VirtualBox is not a commonly-installed system service or application. You could reasonably expect most Linux desktop users to have Pulse installed (unless they're still scared of it), but not so with VirtualBox. Second, like you said, it affects all Broadwell machines, so it shouldn't just be kept here if at all. For example, originally I had only listed the Broadwell TTY switching bug here on this page. Later on, I noticed in the forums that people with the X1 Carbon, among other machines, were linking to this page for help. I moved that section to Intel graphics after that, because I realized they shouldn't have to hunt down the page for a device they don't have just to get help. Soren121 (talk) 16:22, 7 July 2015 (UTC)
The Intel bug was fixed from April, we're July now, so it can be safely deleted. -- Alad (talk) 17:47, 7 July 2015 (UTC)
True. My concern was that a lot of people using other distros reference the XPS 13 wiki page here, because it's one of the more complete XPS 13 Linux help pages available. The bug was fixed upstream but they still haven't released an update with it yet. I know Ubuntu and Arch backported the patch but many others haven't. Personally, I would prefer to wait and remove it when upstream releases that update. Soren121 (talk) 17:55, 7 July 2015 (UTC)
I've moved the VirtualBox freeze troubleshooting section to the VirtualBox page now. Everything's clean and nice on the XPS 13 page again. Coldbird (talk) 05:10, 9 July 2015 (UTC)


Since kernel 4.1.2-2 is now in the stable repositories, can the proposed kernel parameters in the Powersaving section be used without the linux-mainline kernel? The section doesn't say which exact changes or patches in the kernel are needed to make this work. I would just try it out but I am unsure how to confirm if it is actually working.

FlorianH (talk) 11:37, 16 July 2015 (UTC)

It should work fine with the standard 4.1 Arch kernel. The linux-mainline package doesn't include any extra patches. Soren121 (talk) 17:16, 23 July 2015 (UTC)

I had fairly frequent freezes which went away when I got rid of i915.enable_fbc=1. Is this just my system or is it worth mentioning?

DonJaime (talk) 10:56, 30 July 2015 (UTC)

It's not just you. I had to remove that option as well as the screen would flicker like crazy if I didn't. I guess it might be worthwhile mentioning on the page. Coldbird (talk) 12:11, 30 July 2015 (UTC)
It seems that the flicker we experience with the i915.enable_fbc=1 isn't actually a bug but rather an issue with the DVMT pre-allocated memory for the GPU. I've captured an error message in dmesg right after a flicker occured stating that this is the most likely issue. Sadly, our BIOS doesn't allow the configuration of the DVMT pre-allocated memory size, so we are stuck with the 64MB it preallocates by default. I did however find a tutorial on the x86 hackintosh community forums on how to manually change the BIOS saved settings for DVMT on the Dell XPS 13 9343 using the EFI shell (see here: I assume that if we changed this value to an higher setting, then the Framebuffer compression algorithm wouldn't run out of memory while doing its job anymore, avoiding the flicker entirely. Someone care to try this? I can't quite afford messing (up) with my setup over the week as I use my XPS 13 as my actual work machine. Coldbird (talk) 10:30, 3 August 2015 (UTC)
No-one else seems to be keen on low-level EFI-hacking. DVMT is meant to be *dynamic*. Rather than a problem with the pre-allocated memory, couldn't it be a problem with the pre-allocated/dynamically-allocated ratio chosen by the driver? DonJaime (talk) 13:43, 12 August 2015 (UTC)

A note says that "Enabling PSR support ... will further reduce idle power usage to ~2.6 W ..."; we should provide the basic power usage, prior to enabling this feature, so a user can evaluate if use it or not... should result in: "this feature allow you to reduce power usage from X to Y watts"; unfortunately now I can't do it on my own

--nTia89 (talk) 08:41, 20 August 2015 (UTC)

Enabling Tearfree in the xorg config seems to help somewhat. Mnhagan01 (talk) 14:34, 5 November 2015 (UTC)

Flickering and freezes have improved by kernel 4.3.3. I've edited the page to reflect this. DonJaime (talk) 13:30, 14 January 2016 (UTC)

No flicker anymore with this patch when using enable_psr=1 (Bugtracker). Still flicker with enable_psr=2. Dx2 (talk) 10:20, 23 May 2016 (UTC)

My ethernet stopped working when I enabled the kernel parameter pcie_aspm=force and I found a similar description here [1]. Shouldn't this be added as a warning/note? Jadelord (talk) 10:18, 24 May 2016 (UTC)

Tried the /sys/devices/.../power/ interface (e.g. setting /power/control to on) for the device and its bus? Although pcie_aspm=force could be the reason for some very rare system freezes for me (about 3 or 4 freezes within a year). They stopped appearing after removing the option from kernel cmdline and power saving is still pretty damn good. It might not get mentioned on the xps 13 wiki because pcie_aspm=force is not risk-free in general. Dx2 (talk) 10:02, 25 May 2016 (UTC)
I agree with you, and... ASPM for linux is a chimera, making hard to get a clear answer because (read somewhere googling) "ASPM is disabled by default IF BIOS doesn't acknowledge it" -> BUT this doesn't mean that the hardware don't support ASPM... in order to provide a `true meaning` feedback/advice/warning we have to 1. verify if Windows uses ASPM (this is a good move because if dell drivers don't enable it by default, probably there is an hardware ASPM trouble, I think...) 2. try out this kernel parameter thanks to the fact we are talking about a few little combination of hardware. --nTia89 (talk) 07:50, 27 May 2016 (UTC)


The sentence in Dell_XPS_13_(2015)#Connection_issues_with_Broadcom_wireless: "If your WiFi connection drops constantly, try disabling NetworkManager (if you have it installed) and fall back to using wifi-menu." makes no sense as NetworkManager and netctl both use wpa_supplicant to negotiate a wireless connection. Unless someone can make an exact relation between NetworkManager and this hardware, this sentence should be removed. -- Alad (talk) 06:13, 3 September 2015 (UTC)

Removed. If anyone has an objection, feel free to discuss. Soren121 (talk) 05:12, 30 September 2015 (UTC)

The render ring hang report

This section has no sources and the problem it describes is not reproducible. I haven't been able to find bug reports on the Mesa or kernel trackers that matches the description, nor have I experienced such an issue on my own XPS 13 with the latest Mesa drivers. Unless someone is able to provide a source/proof of the issue, I'd like to propose that we remove this section. Without knowing what the problem is, we won't know if the issue has been resolved (or if it even was an issue in the first place!) Soren121 (talk) 05:03, 30 September 2015 (UTC)

Sounds like a good idea; also, the version of Mesa mentioned in the section is almost 3 months old at this point and there have been a fair few bug-fix releases since then. Bryn (talk) 22:45, 1 October 2015 (UTC)
Also an excellent point. I'll remove it in a few days if no one raises an objection. Soren121 (talk) 22:52, 1 October 2015 (UTC)
Removed. If you have an objection, again, feel free to discuss. Soren121 (talk) 03:43, 11 October 2015 (UTC)

Touchpad with palm detection

I'd like to share with you a new configuration for touchpad pointed out by Barton George: touchpad with palm detection using "libinput" I haven't tried it!

--nTia89 (talk) 10:31, 7 October 2015 (UTC)

The Touchpad section of this wiki page has had instructions for using libinput for months now! :) And yes, it does work. The only drawback is that it is less configurable than the synaptics driver. Soren121 (talk) 14:00, 7 October 2015 (UTC)
Yes, I read it! I noticed a quiet different .conf file and this is a reason why I posted the link. --nTia89 (talk) 13:15, 8 October 2015 (UTC)
There is a test patch for palm detection Dx2 (talk) 11:05, 3 November 2015 (UTC)

Audio issues with Realtek ALC3263

I've experienced severe audio problems using 4.2.3-1 (and at least 4.2.2) and BIOS updated to A05. Sound worked for some undefined period of time and then speakers (or headphones) started producing crackling sounds and eventually sound became very distorted. dmesg output when this started:

   snd_hda_intel IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj
   snd_hda_intel 0000:00:1b.0: spurious response 0x0:0x0, last cmd=0x1470700
   snd_hda_intel 0000:00:1b.0: spurious response 0x0:0x0, last cmd=0x1470700
   snd_hda_intel 0000:00:1b.0: spurious response 0x0:0x0, last cmd=0x1470700

IRQ timing line showed up shortly after sound device was used and spurious response lines showed up when crackling started. This was clearly a driver problem and I tested different snd_hda_intel options, with no good results. Eventually I decided to enable more verbose debugging for sound devices and I built a custom kernel using current rc with arch default config (4.3.0-rc5-ARCH). When I booted into it I never experienced sound issues again. --Lknix (talk) 19:54, 13 October 2015 (UTC)

Late 2015 model with Skylake CPU

At beginning of October Dell refreshed the XPS line with skylake CPU. Firstly, should the wiki page/information on the previous model should be re-named to Early 2015? Secondly, anyone bought and tested the latest model with Linux? New model includes Thunderbolt 3 and USB 3.1 as that's part of intel skylake now. Perhaps that'll mean Linux support through intel code?

I'm planning on buying one of these, I'll update the page with any problems I run into. There's some discussion on the Dell forums about linux support here, seems like everything was working for them except WiFi. Xymostech (talk) 01:37, 5 November 2015 (UTC)
A new section or page should be made for the late 2013 xps 13 (9350). Most of this information for the earlier version do not apply. Wifi for dell xps 13 skylake is using a dw1802a chip which is a broadcom 4350. 4350 is in mainline kernel support from 4.4 onwards. There is a patch that can be applied to kernel and user must extract the 4350 driver from 4.4 branch. Besides that, the skylake intel video can enter X only if i915.preliminary_hw_support=1 in kernel boot command. There is something very wrong with the video though. There are two things that aren't working OOB besides wifi. Brightness keys f11, f12 are not registered as keys by xbindkeys -k and they do not work. Video played crashes X along with random but frequent screen flickering. Frank604 (talk) 17:56, 13 November 2015 (UTC)

New model page created: Dell_XPS_13_(9350) -- nTia89 (talk) 10:52, 13 October 2019 (UTC)

UXA vs. SNA and Suspend Issue

The wiki suggests switching the Intel Graphics Acceleration from UXA to SNA "... [i]f you encounter some artifacts and/or an unusable graphical environment after resuming from a suspend [...]." I myself encountered an issue using XFCE + LightDM where, after resuming from suspend and successfully unlocking the screen, the screen would fade to black and become unresponsive. Switching to UXA removed the issue and made suspend/resume reliable.

Clearly this is a workaround; UXA performance is pretty bad (with compositing, XFCE's alt-tab takes about 2 seconds to respond on my setup). Does anyone have more information about how SNA could affect a DE's suspend/resume routine? Ubuntu users have reported a similar bug here, and it appears that the issue doesn't affect Unity DE. Can anyone using Unity under Arch confirm that?

SNA is simply less tested (and therefore less reliable) than UXA. Consider filing an upstream bug report, but first, see if any of these match your issue: Soren121 (talk) 21:17, 27 October 2015 (UTC)

Sound and recording working in I2S mode with kernel 4.4

In the article, it's implied that the microphone doesn't work with the 4.4 kernel. However, using pulseaudio, I got both speakers and recording working again. No need to compile the kernel with a flag.
Fixed upstream! -- nTia89 (talk) 10:53, 13 October 2019 (UTC)

question about bluetooth

Why we need to link BCM20702A1* to BCM20702A0* (I'm talking about the last line: ln -rs BCM20702A1-0a5c-216f.hcd BCM20702A0-0a5c-216f.hcd), since kernel already looks for the BCM20702A1* one?

[mattia@arch-xps ~]$ dmesg | grep blue [ 1.353778] Bluetooth: Core ver 2.21 [ 1.353794] Bluetooth: HCI device and connection manager initialized [ 1.353797] Bluetooth: HCI socket layer initialized [ 1.353800] Bluetooth: L2CAP socket layer initialized [ 1.353805] Bluetooth: SCO socket layer initialized [ 1.373102] Bluetooth: hci0: BCM: chip id 63 [ 1.389112] Bluetooth: hci0: BCM20702A [ 1.390110] Bluetooth: hci0: BCM20702A1 (001.002.014) build 0000 [ 1.390476] bluetooth hci0: Direct firmware load for brcm/BCM20702A1-0a5c-216f.hcd failed with error -2 [ 1.390479] Bluetooth: hci0: BCM: Patch brcm/BCM20702A1-0a5c-216f.hcd not found

--nTia89 (talk) 16:46, 7 April 2016 (UTC)

"Fixed" upstream: recent kernel versions do not report it anymore.

nTia89 (talk) 13:30, 15 March 2021 (UTC)


I think the latest addition is wrong because compiling kernel 4.5+ with this config `CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y` simply force the legacy HDA mode, switching from the default I2S. So this has to be described in the right section. Let us know --nTia89 (talk) 16:20, 6 May 2016 (UTC)

The reason I added it there, was because I could not get the I2S mode to work after making only the configs listed before. By adding `CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y` and forcing into Legacy HDA, I was able to get the sound card working again. Being that I started in I2S, I decided that it should be in that section. I am new though, so please correct me if I am wrong.
--QuiGonSwag (talk) 16:30, 6 May 2016 (UTC)
first, if you reply, you have to indent using colon `:`...
second, anyway I disagree with your choice because the I2S sub-section talks about sound in the I2S mode, not the HDA, that is the sub-section above the I2S one! IMHO a good solution is to add a note box containing something like `...kernel 4.5+ is I2S by if you want to go back into HDA mode but staying on that have to force it via...`; since HDA sub-section is closely tied to kernels 4.4- while I2S sub-section it tied to kernels 4.5+, the best place where I will put the box is in the main section `Audio`.
third, I was helping a fellow with, I think, your same problem here 1 --nTia89 (talk) 17:55, 6 May 2016 (UTC)
I moved the `CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y` option to the HDA mode section and clarified what it does. Soren121 (talk) 17:57, 6 May 2016 (UTC)
for me, it's OK --nTia89 (talk) 18:02, 6 May 2016 (UTC)

the microphone issue

At the moment, the microphone doesn't work out-of-the-box, but nobody know if it's a kernel problem or ALSA/pulseaudio. I think it's the second case. Anyway we need to understand how we can fix it. In my opinion we have just to understand how to save setting change via alsamixer across the reboot or use another tool (pulseaudio has a plethora of these...). The idea could be:

  • if you have alsa, the change are saved via alsa store service
  • who has pulseaudio...???

I'm in the second category and I think change is not saved across the reboot is due to the lack of alsa store service; this because I have pulseaudio... --nTia89 (talk) 14:36, 13 May 2016 (UTC)
Fixed upstream! (kernel 5.2.20 and gnome 3.34) -- nTia89 (talk) 10:29, 13 October 2019 (UTC)

fan speed

how can we take control or simply show fan speed (in the unlucky time that is running)? --nTia89 (talk) 16:06, 29 May 2016 (UTC)

the solution (or at least a workaround) is into the `i8k` module. Unfortunately we need to pass the extra parameter `force=1` (meaning the laptop model is unsupported) in order to load it... --nTia89 (talk) 16:06, 29 May 2016 (UTC)
further information here 1 --nTia89 (talk) 16:10, 29 May 2016 (UTC)

SCSI card firmware

Information on SCSI firmware is missing from the wiki. Whenever I upgrade my linux kernel the following output is encountered

   upgraded linux (4.7.4-1 -> 4.7.6-1)
   >>> Updating module dependencies. Please wait ...
   >>> Generating initial ramdisk, using mkinitcpio. Please wait...
   ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'default'
     -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
   ==> Starting build: 4.7.6-1-ARCH
     -> Running build hook: [base
     -> Running build hook: [udev
     -> Running build hook: [resume
     -> Running build hook: [autodetect
     -> Running build hook: [modconf
     -> Running build hook: [block
     -> Running build hook: [filesystems
     -> Running build hook: [keyboard
     -> Running build hook: [fsck
     -> Running build hook: [consolefont
   ==> Generating module dependencies
   ==> Creating gzip-compressed initcpio image: /boot/initramfs-linux.img
   ==> Image generation successful
   ==> Building image from preset: /etc/mkinitcpio.d/linux.preset: 'fallback'
     -> -k /boot/vmlinuz-linux -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect
   ==> Starting build: 4.7.6-1-ARCH
     -> Running build hook: [base
     -> Running build hook: [udev
     -> Running build hook: [resume
     -> Running build hook: [modconf
     -> Running build hook: [block
   ==> WARNING: Possibly missing firmware for module: aic94xx
   ==> WARNING: Possibly missing firmware for module: wd719x
     -> Running build hook: [filesystems
     -> Running build hook: [keyboard
     -> Running build hook: [fsck
     -> Running build hook: [consolefont
   ==> Generating module dependencies
   ==> Creating gzip-compressed initcpio image: /boot/initramfs-linux-fallback.img
   ==> Image generation successful
   upgraded linux-headers (4.7.4-1 -> 4.7.6-1)

Notice the WARNING? This points to aic94xx-firmwareAUR and wd719x-firmwareAUR, both of which are SCSI firmwares. I have a feeling that only one might be required for Dell XPS 13 (2015). Has anyone installed a SCSI driver? If so which one? Is there a way to find out? I tried googling and duckduckgoing of course with no result. Jadelord (talk) 09:24, 10 October 2016 (UTC)

These messages appear for all Arch users (see here). It is not a problem, as the XPS 13 certainly does not have a SCSI bus. Soren121 (talk) 14:07, 10 October 2016 (UTC)

Stated here Mkinitcpio#Possibly_missing_firmware_for_module_XXXX too --nTia89 (talk) 13:00, 14 October 2016 (UTC)

Hidden Keyboard Keys (grab from the XPS 9360 page)

There are additional Fn+<Key> (sequences) that are not marked at all on the keyboard but underlying hardware generates them anyway. Here they are (if you find more add them to the table below):

Hidden Fn Keys
Fn+<Key> Resulting key (sequence)
Fn+Ins XF86Sleep
Fn+Super_L Super_R
Fn+B Pause
Fn+R Print
Fn+S Scroll_Lock
Fn+A / D / E / F / G / T / Q / W XF86Launch3
Table has been embedded below
- nTia89 (talk) 14:42, 18 March 2021 (UTC)

microphone is working (again) out-of-the-box

with one of the latest kernel update magically our internal microphone get back working without any manual fix I think this comes from the recent addition/edit to the kernel config: CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y

Do you notice it too? --nTia89 (talk) 18:11, 17 June 2017 (UTC)

I don't get the microphone to work, tried everything in pavucontrol. I'm on latest kernel 4.12.10 and latest BIOS A13.
--Epinephrine (talk) 10:30, 6 September 2017 (UTC)
I noticed is not enabled by default. I am on gnome 3.24 and I need to turn it on from the settings panel. --nTia89 (talk) 20:16, 8 September 2017 (UTC)
At the moment, it survives across reboots --nTia89 (talk) 11:01, 10 September 2017 (UTC)

Fixed upstream! (kernel 5.2.20, pulseaudio 13 and gnome 3.34) -- nTia89 (talk) 10:33, 13 October 2019 (UTC)

Need to add intel_iommu=off since kernel 4.13?

I have to add intel_iommu=off to my kernel parameters or my system won't restore properly from suspend. Can anyone confirm? See this forum post [2] for more details. Epinephrine (talk) 15:15, 11 October 2017 (UTC)

With latest kernel (e.g. 5.10) there is no need of that kernel parameter; suspend/resume works perfectly and out-of-the-box!
- nTia89 (talk) 14:39, 18 March 2021 (UTC)

Missing stuff

Fn keys are already reported here in the Talk page; Do you think it is worth of the "main" page? and, Where? What else is missing?

nTia89 (talk) 13:30, 15 March 2021 (UTC)

The function key table, as described in the Laptop page guidelines should be on the actual laptop page, yes.
Some sections also need to be moved, e.g all the firmware/BIOS related stuff should be in the "Firmware" section.
Please read the Laptop page guidelines and see for yourself. I have been mass-flagging laptop pages with this and I only stated major things in the templates description because there are simply so many laptop pages.
You are encouraged to use the talk page if you have any feedback regarding the guidelines.
-- NetSysFire (talk) 15:43, 16 March 2021 (UTC)
I enhanced page with information I consider important; remember, this is a 6 years old laptop and this page, like the device itself, is son of that time (and most of the information/instructions/consideration in there, too); the only thing is missing now is the function keys table; I am working on it but I will "post" it here, below, because I haven't found the right place on the main page as that is just an "accessory" information, on second thoughts here, the *Talk* page is a good place where put it...
nTia89 (talk) 14:04, 18 March 2021 (UTC)

Function keys

Key Visible?1 Marked?2 Effect
Fn+Esc No Yes Enables Fn lock
Fn+F1 Yes Yes XF86AudioMute
Fn+F2 Yes Yes XF86AudioLowerVolume
Fn+F3 Yes Yes XF86AudioRaiseVolume
Fn+F4 Yes Yes XF86AudioPrev
Fn+F5 Yes Yes XF86AudioPlay
Fn+F6 Yes Yes XF86AudioNext
Fn+F8 Yes Yes Switch display
Fn+F9 Yes Yes XF86Search
Fn+F10 Yes Yes Set keyboard backlight
Fn+F11 Yes Yes XF86MonBrightnessDown
Fn+F12 Yes Yes XF86MonBrightnessUp
Fn+Stamp Yes Yes XF86RFKill
Fn+Insert Yes No XF86Sleep
Fn+Super (left) Yes No Super (right)
Fn+B Yes No Pause
Fn+R Yes No Print
Fn+S Yes No Scroll_Lock
Fn+A / D / E / F / G / T / Q / W Yes No XF86Launch3
  1. The key is visible to xev and similar tools.
  2. The physical key has a symbol on it, which describes its function.
Note: I have tested all keys; feel free to test and report here, so we can promote the table out of "beta"

- nTia89 (talk) 14:37, 18 March 2021 (UTC)