Help talk:Laptop page guidelines

Report special keys with function keys?

Should special keys like “power button” or “wireless switch” be included in the function keys table, if they reports events which can be captured by xev? If so, how should I name them? Dell Latitude 3500 example does not show them. -- Audeoudh (talk) 14:41, 5 May 2021 (UTC)

I would say no. The function keys table is meant for function key combinations, so I wouldn't include keys or combinations that didn't otherwise involve Fn or F1–F12. -- Flyingpig (talk) 16:52, 5 May 2021 (UTC)

I would also say no. Function keys mean that they are (usually) invoked with Fn. Some laptops do have a wireless switch which is a function key (usually XF86RFKill) though. Feel free to add an extra section if the power button is problematic.

--- NetSysFire (talk) 16:59, 5 May 2021 (UTC)

Couldn't the function keys table standard be a lot better?

Both as a reader and writer I find the current function key table standard to be quite terrible.

It uses poor wording (Visible and Marked both imply the exact same thing)

The 'Effect' column is meant to reference the key's assignment by the system, but this does not make sense when the system's default assignment for the key is wrong.

There is no column indicating whether or not the key works, I imagine the 'Effect' column was meant to be for that, but as I mentioned before, it makes no sense.

I would like to propose a new standard table that makes, at least to me, a lot more sense:

Key	Detected	Labeled	Working	Effect
Fn+NumPad0	Yes	Yes	Yes	XF86AudioMute
Fn+Down	Yes	Yes	Yes	XF86MonBrightnessDown
Fn+F8	Yes	No	Yes	XF86WLAN
Fn+F9	Yes	No	Yes	XF86Bluetooth.
Fn+F5	Yes	Yes	Partially	Eco Mode/XF86Battery
Fn+F7	No	Yes	No	Fitting Description

Key: Same as before

Detected: Same as what visible used to be

Labeled: Same as what marked used to be (Marked works too, but I feel like labeled makes more sense linguistically since we usually talk about keyboard labels and not markings)

Working: Does the key work or not?

Effect: What is the intended effect of the button? (As opposed to the default system assigned effect, since these keys are sometimes wrongly assigned)

There are also no longer question marks in the table, because they're superfluous in the first place.

Additionally, perhaps there should be standards for corner cases (for instance when a key is detected, but only when a specific kernel parameter is set a certain way, or if the key works, but only after it is manually given the correct assignment, or if the key is detected and can be assigned but doesn't work as intended by manufacturer (manufacturer specific keys that require specific applications, usually on windows, to work, yet are still detected on Linux and assigned keysyms properly), when a key is working as intended thanks to hardware detection but not actually detected by the kernel, etc)

Rabcor (talk) 03:31, 19 September 2021 (UTC)

It seems you misunderstood what Visible is. As described in Help:Laptop page guidelines#Example table 2, Visible means if the key is visible to the kernel. Marked means if there is a physical marking on the key, e.g a waxing moon on the sleep key.

Changing marked to labelled would be fine.

I would not like an additional "Working" column in the table because it is redundant. If it is visible, it should™ work in most cases. If a key is not visible without an appropriate kernel parameter, note this in the section but put the result in the table you would see if it is appropriately configured.

The information in the laptop pages should not be relevant to only specific DEs or even WMs. If it is visible to the kernel (Visible) column, it suffices. Since there are no defaults in Arch Linux and every user is encouraged to customize their system, defining the intended purpose of a key is hard. However, this would not apply if the keymap is all mixed up for some reason and needs additional configuration to work, e.g when there is a "Brightness increase" label on say F1 but it emits Play/Pause, which it would not do on Windows.

-- NetSysFire (talk) 02:53, 20 September 2021 (UTC)

I'm two year late to the party, but maybe we should create a template like Template:Laptops table header for this one?

I feel like "Labelled" would be easier to understand that "Marked" to ask if a key has a legend on it or not, but without a template it's going to be a lot of manual labor to update all the pages with a "Function keys" section :/ The bonus would be that like Template:Laptops table header, we could add legends to each headers with an explanation of what's expected where.

Thoughts? Erus Iluvatar (talk) 12:22, 4 April 2024 (UTC)

I'm already confused by having two columns for function keys, three columns would definitely be too much. -- Alad (talk) 08:26, 20 September 2021 (UTC)

I still think 'detected' makes more sense, e.g. it is 'detected' by the kernel. The kernel does not have eyes, nothing is technically speaking visible to the kernel.

For future reference, this is the relevant section for the model I am using MSI_GE75_Raider_8SX#Function_keys

Also, when you say "it should™ work in most cases.", that's the real kicker isn't it? What about the cases where this is not the case? My keyboard backlighting buttons are function keys, the kernel does not detect them, but they fully serve their intended purpose. What about airplane mode? I don't know if it is detected by the kernel or not, but it is not detected by X, yet it fully works (disables wifi and bluetooth as it should).

For that matter, how confident actually are you that this is what it's like for "most cases"? This might be the case for older laptop models, but manufacturers keep doing weird stuff to their laptops these days. The current standard may be fine for older models, but for new models we're almost definitely gonna be seeing more and more corner cases until the reality will be that for "most cases" the situation will not be as simple as you are describing.

We often see these kinds of shenanigans with 'gaming' branded laptops these days, and such laptops while they might not be the majority they are definitely not rare.

Whether we use the standard I suggested or not, I don't think there's much question about it that we need the standard to cover cases where the button works but is not detected by the kernel. And cases where the key is detected and assigned some keysym but cannot serve it's original purpose (like with my laptop's Turbo and Eco mode buttons)

I'll perhaps give you that it's true that for most keys the current standard covers all that's required. Because most keys are standard keys that have standardized functions which can be detected and correctly by the kernel.

But there are cases where the key is detected by the kernel but wrongly assigned, and there are several examples of that even on my laptop. And there are cases where the keys are fully functional without being detected by the kernel, however the hell that can happen anyways. The normal keys may be more common, but these kinds of cases are certainly not going to be rare among a certain category of laptops and this needs to be accounted for somehow in the standards.

Or else what am I supposed to do as the writer of that section I linked to? The standard doesn't allow me to cover everything that needs to be covered. That is a problem, is it not?

-- Rabcor (talk) 10:20, 20 September 2021 (UTC)

As seen in Help:Laptop page guidelines#Capturing function keys, some keys are bound to e.g systemd-logind. You have to tell it to ignore the key or else it will not be visible to you in e.g xev.

I am not sure what keyboard backlight is controlling either, might be a firmware thing in my specific case or the kernel module is interpreting it since I can control the keyboard backlight via /sys.

I'd like to solve the specific problems instead of adding yet another column. In this case it may actually be a difference in kernel modules or configuration, see systemd-backlight@.service (systemd-backlight(8))

-- NetSysFire (talk) 11:59, 20 September 2021 (UTC)

Well, let me just say first that I have not checked if the systemd-backlight service is doing anything for this laptop or not (i'm rather confident it is not though). But what I have noticed is that these backlight keys work even when I have not booted into an OS (e.g. in BIOS) and that the setting is remembered between boots (e.g. if I set the kbd backlight to full and then reboot, then on the post screen the keyboard backlight will be full). Similarly the keyboard can remember the color profile used between different operating systems (if I configure the lighting scheme on windows, it will remain the same after I boot into Linux too, and on the post screen for that matter.)

As for the systemd-logind thing. We're not talking about a problem that needs fixing here. Or rather, we are, but I already fixed it. I have no motive at present to try to find a different way to fix it, nor do I have a reason to believe or care systemd-logind is related to the initial issue. If you want me to check these things, I will play along... But only if you give me every specific set of commands I need to run to do these checks, because I cannot be assed to dig them up myself since as I said before I have no motive to do so. If you want to do that though, I believe we should move that discussion to the relevant section for the laptop I'm testing it on.

If your only issue is that I didnd't name airplane mode something else, just rename the damn thing into whatever it should be named, the key works so it stands to reason that it is getting correctly assigned, it is safe to do so.

As far as I'm concerened, all these little details are just that, details. The important information is there, it's not in the exact format suggested by the standard which is unfortunate, but as I mentioned, it did not fit within the standard. Whether some key's effect is not labeled exactly correct doesn't matter because the reader will understand what the effect of the key is the way it is currently written anyways, and if someone has a problem with the way it is currently written they are free to rewrite it.

Rabcor (talk) 00:11, 21 September 2021 (UTC)

Accessibility

Can someone better clarify what parts of this are necessary? I can't find even a single laptop page other than the provided Dell_Latitude_3500 'example' that has this section, yet it seems to be deemed mandatory. Is it enough to denote what the various LEDs do? Inclusion or lack thereof a PC speaker? What do we need here?

Ensayia (talk) 02:28, 25 April 2022 (UTC)

Hi! Have a look at Toshiba Satellite L300 for an older page that got updated with an accessibility section.

From what I remember, many laptop pages were written before the laptop style rules were set in place, doubled with the fact that the accessibility section was not explicitly marked as required for a while, which explains why many laptop pages are not compliant . On that note, pease flag the pages you find with Template:Laptop style if you can, so that people watching the page or having the hardware can contribute it.

From what I understand, this section tries to answer the question "could a non-sighted person install Arch Linux on it's own" particularly in regards to UEFI settings (sonce it's a place hwere the OS is not yet setup with assistive software), but does not limits itself to only this information (e.g. if the user is deaf, has to troubleshoot and can use LED codes to that end).

--Erus Iluvatar (talk) 06:00, 25 April 2022 (UTC)

Looking at your example, and the Dell one, both only really indicate that the BIOS may be usable with a screen reader. I've never heard of any accessibility software that works pre-os and searching around online others concur. There are few to no hardware accessibility options on computers, especially modern ones which often lack status LEDs and system speakers. This problem seems to be approached somewhat backward. Is it really necessary to revise every article and slap the same redundant information on it or perhaps limit the accessibility notation to the few machines that might have those features?

-- Ensayia (talk) 12:28, 25 April 2022 (UTC)

Author of the laptop page guidelines here. I made the accessibility section mandatory recently because many new laptop pages just did not include that one at all, which is unfair to people with disabilities.

With screen reader I specifically mean OCR software here, many blind people use their phone to see. That could be clarified, I agree. To tone down the redundancy it is possible to use templates but since there are not many pages having accessibility information at all, I do not deem this necessary yet. If a laptop does not have any status LEDs, they do not need to be mentioned.

-- NetSysFire (talk) 21:28, 25 April 2022 (UTC)

I've added the OCR phone example from above[1] and some other small changes. As said above, I think it is useful to distinguish and group related obstacles to boot the Arch install image in the first place, and performing the installation. Also, the suggestion to use an accessibility notation is great. It would be ideal, if the section gives a clear and short overview to distinguish particularly non-/accessible devices. With more examples over time, it is perhaps possible to boil it down to a notation, but it will always be difficult to make perpetual comparable ratings and text is per se pretty accessible.

--Indigo (talk) 22:13, 13 May 2022 (UTC)

On this topic, I think we could add a few examples of pages where the accessibility section is well written, like System76 Oryx Pro#Accessibility ? --Erus Iluvatar (talk) 19:05, 24 June 2022 (UTC)

PS/2 identifiers in hardware tables

We have about 70..100 pages with non-empty "Keyboard" and/or "Touchpad" entries in PCI/USB ID column. I did not check them all, of course, but from several random pages I see that users tend to put PS/2 identifiers here. (Ok, one time I saw USB ID, but that was a mistake—it was ID for fingerprint sensor, not for touchpad.)

If you believe that PS/2 IDs are useful (could you explain, why?), then we should define a format. Look for PS/2 devices at linux-hardware.org—they often use long, cryptic (and just ugly) strings which are definitely not suitable for our small pretty tables:D Users copy some (I should say "some random") part of it (some hex digits), but such "partial identifier" does not identify well (or does not identify at all—it was easier for me to search for laptop model to find out its touchpad ID than vice versa).

I think we could hide PS/2 IDs in a link—e.g. [https://linux-hardware.org/very-long-id PS/2].

My current opinion: PCI/USB ID column is for PCI and USB IDs only, PS/2 info should not be allowed there. By the way, our guidelines page reads clearly:

> "If there is no applicable PCI/USB ID for this device, leave the column empty. Do not put Template:-, dashes or anything else into the column."

PS/2 ID is exactly "something else":D IMO:)

— Andrei Korshikov (talk) 21:51, 12 August 2025 (UTC)

Could you give an example for a page that has such "PS/2 IDs"? -- nl6720 (talk) 09:05, 13 August 2025 (UTC)

Sure. Random one: Dell XPS 13 (9340)—https://linux-hardware.org/?id=ps/2:04f3-31d1-ven-04f3-00-04f3-31d1-mouse

Or choose your favorite (sorry for ugly output, "nowiki" removes newlines, I think "Edit source" will display it prettier):

--regexp='[|] ?(Touchpad|Keyboard) ?[|]{2} ?[{]'

::Acer Nitro AN515-43.33533.830878.wikitext:6:| Touchpad || {{ic|04F3:312A}} || {{Yes}} ::Acer Predator PT515-52.36568.830881.wikitext:7:| Touchpad ||{{ic|04F3:3127}} || {{Yes}} ::Acer Predator PT515-52.36568.830881.wikitext:9:| Keyboard ||{{ic|0d62:7cb0}} || {{Yes}} ::Alienware m16 R1 AMD.36252.830893.wikitext:10:| Keyboard || {{ic|0d62:c2b0}} || {{Yes}} ::ASUS E402S.31744.830894.wikitext:12:| Touchpad || {{ic|0b05:0101}} || {{Yes}} ::ASUS ExpertBook B9450CEA.32201.830896.wikitext:14:| Touchpad || {{ic|04f3:3134}} || {{Yes}} ::ASUS ROG STRIX G17 (2022).35252.830905.wikitext:6:| Touchpad || {{ic|04F3:319B}} || {{Yes}} ::ASUS ROG STRIX G17 (2022).35252.830905.wikitext:8:| Keyboard || {{ic|0b05:19b6}} || {{Yes}} ::ASUS ROG Zephyrus Duo 15 GX550.32733.830907.wikitext:9:| Keyboard || {{ic|0b05:1866}} || {{Y|Partial}} ::ASUS ROG Zephyrus G14 (2022) GA402.34143.834309.wikitext:15:| Touchpad || {{ic|04F3:319B}} || {{Yes}} ::ASUS ROG Zephyrus G14 (2022) GA402.34143.834309.wikitext:17:| Keyboard || {{ic|0b05:19b6}} || {{Yes}} ::ASUS x205ta.20823.830911.wikitext:10:| Touchpad || {{ic|04f3:0026}} || {{Yes}} ::ASUS x205ta.20823.830911.wikitext:8:| Keyboard || {{ic|0b05:8585}} || {{Yes}} ::ASUS Zenbook Q408UG.33164.830916.wikitext:25:| Touchpad || {{ic|04f3:30f1}} || {{Yes}} ::Dell G5 SE 5505.32038.834583.wikitext:14:| Touchpad || {{ic|04F3:30CB}} || {{Yes}} ::Dell Inspiron 13 (5378).25159.842494.wikitext:16:| Touchpad ||{{ic|0740:0006CB}}|| {{Yes}} ::Dell Inspiron 7586.33422.830945.wikitext:10:| Touchpad || {{ic|04F3:30B6}} || {{yes}} ::Dell Inspiron N5010.11998.830946.wikitext:10:| Keyboard || {{ic|413c:8161}} || {{Yes}} ::Dell Inspiron N5010.11998.830946.wikitext:8:| Touchpad || {{ic|413c:8162}} || {{Yes}} ::Dell Latitude 5580.37369.839404.wikitext:18:| Touchpad || {{ic|044E:120B}} || {{Yes}} ::Dell Latitude 7440.35873.830951.wikitext:10:| Keyboard || {{ic|0001:0001}}|| {{Yes}} ::Dell Latitude 7440.35873.830951.wikitext:8:| Touchpad || {{ic|0488:104A}} || {{Yes}} ::Dell XPS 13 2-in-1 (9315).36394.830970.wikitext:6:| Touchpad || {{ic|0488:1035}} || {{Yes}} ::Dell XPS 13 2-in-1 (9315).36394.830970.wikitext:8:| Keyboard || {{ic|0488:1035}} || {{Yes}} ::Dell XPS 13 (9340).37168.831362.wikitext:14:| Touchpad || {{ic|04F3:31D1}} || {{Yes}} ::Dell XPS 13 (9343).20261.842459.wikitext:15:| Touchpad || {{ic|06cb:76ad}} || {{Yes}} ::Dell XPS 13 Plus (9320).34507.839717.wikitext:6:| Touchpad || {{ic|04F3:31D1}} || {{Yes}} ::Dell XPS 13 Plus (9320).34507.839717.wikitext:8:| Keyboard || {{ic|0001:0001}}|| {{Yes}} ::Dell XPS 15 (9510).34388.832076.wikitext:7:| Touchpad || {{ic|04f3:311c}} || {{Yes}} ::Dell XPS 15 (9570).27046.832077.wikitext:10:| Touchpad || {{ic|06CB:7A13}} || {{Yes}} ::Dell XPS 16 (9640).36602.838773.wikitext:6:| Touchpad || {{ic|04f3:311c}} || {{Yes}} ::Dell XPS 17 (9700).31595.833232.wikitext:17:| Touchpad || {{ic|04f3:311c}} || {{Yes}} ::Eve V (2017).34755.840176.wikitext:11:| Keyboard || {{ic|0603:00f1}} || {{Yes}} ::Eve V (2017).34755.840176.wikitext:9:| Touchpad || {{ic|0603:00f1}} || {{Yes}} ::Framework Laptop 13 (11th Gen Intel Core).36725.830989.wikitext:13:| Touchpad || {{ic|093a:0274}}|| {{Yes}} ::Framework Laptop 13 (12th Gen Intel Core).36724.830990.wikitext:13:| Touchpad || {{ic|093a:0274}}|| {{Yes}} ::Framework Laptop 13 (13th Gen Intel Core).36723.830991.wikitext:15:| Touchpad || {{ic|093a:0274}}|| {{Yes}} ::Framework Laptop 13.33355.842937.wikitext:20:| Touchpad || {{ic|093a:0274}}|| {{Yes}} ::Framework Laptop 13 (AMD Ryzen 7040 Series).36722.842939.wikitext:15:| Touchpad || {{ic|093a:0274}}|| {{Yes}} ::GPD Pocket 3.33870.843247.wikitext:26:| Touchpad || {{ic|258a:000c}} || {{Yes}} ::GPD Win Max.33282.842405.wikitext:20:| Keyboard || {{ic|?}} || {{Yes}} || {{ic|?}} || {{Yes}} || {{ic|PS/2 ?}} || {{Yes}} ::GPD Win Max.33282.842405.wikitext:22:| Touchpad || {{ic|?}} || {{Yes}} || {{ic|?}} || {{Yes}} || {{ic|I2C ?}} || {{Yes}} ::HP Omen 16-c0140AX.35620.831019.wikitext:18:| Touchpad || {{ic|04f3:31c2}} || {{Yes}} ::HP Pavilion 13-a252ur.30928.835192.wikitext:16:| Touchpad || {{Yes}} ::HP Spectre x360 13-aw0xxx.31036.831033.wikitext:15:| Touchpad || {{ic|06CB:CD50}} || {{Yes}} ::HP Spectre x360 (2020).31959.831029.wikitext:15:| Touchpad || {{ic|04F3:315B}} || {{Yes}} ::HP ZBook 14u G6.30907.831039.wikitext:18:| Touchpad || {{ic|06CB:82F5}} || {{Yes}} ::Huawei MateBook 14s.34483.831042.wikitext:7:| Touchpad || {{ic|27C6:01E0}} || {{Yes}} ::Lenovo IdeaPad 5i (16IRU9).37016.831048.wikitext:13:| Touchpad || {{ic|04f3:327e}}|| {{Yes}} ::Lenovo IdeaPad Flex 3 CB 11IGL05 Chromebook.35103.833485.wikitext:19:| Touchpad || {{ic|04f3:00a2}} || {{Yes}} ::Lenovo IdeaPad Flex 5 13IML05 Chromebook.33867.835355.wikitext:29:| Touchpad || {{ic|06cb:cde1}} || {{Yes}} ::Lenovo IdeaPad Flex 5 14IAU7.36240.831053.wikitext:15:| Touchpad || {{ic|}} || {{Yes}} ::Lenovo IdeaPad Gaming 3.34389.841147.wikitext:10:| Keyboard || {{ic|048d:c966}} || {{Yes}} ::Lenovo IdeaPad Gaming 3.34389.841147.wikitext:8:| Touchpad || {{ic|04F3:31AD}} || {{Yes}} ::Lenovo IdeaPad Miix 310-10ICR.35690.834760.wikitext:6:| Keyboard || {{ic|258a:1015}} || {{Yes}} ::Lenovo IdeaPad Slim 3 16ABR8.36234.841144.wikitext:18:| Touchpad || {{ic|04F3:327E}} || {{Yes}} ::Lenovo ThinkPad P1 (Gen 3).32202.831076.wikitext:8:| Touchpad || {{ic|06cb:00bd}} || {{Yes}} ::Lenovo ThinkPad T14 (AMD) Gen 3.34881.831772.wikitext:16:| Touchpad || {{ic|06cb:00f9}} || {{Yes}} ::Lenovo ThinkPad T14 (AMD) Gen 5.37018.843425.wikitext:7:| Touchpad || {{ic|06CB:00f9}} || {{Yes}} ::Lenovo ThinkPad T14_T14s (Intel) Gen 2.33915.838884.wikitext:6:| Touchpad || {{ic|06CB:CE68}} || {{Yes}} ::Lenovo ThinkPad T14_T14s (Intel) Gen 4.36974.835187.wikitext:8:| Touchpad || {{ic|04F3:3195}} || {{Yes}} ::Lenovo ThinkPad T14_T14s (Intel) Gen 5.37103.831367.wikitext:8:| Touchpad || {{ic|04F3:3195}} || {{Yes}} ::Lenovo ThinkPad T495.29535.834471.wikitext:17:| Touchpad || {{ic|06CB:CE68}} || {{Yes}} ::Lenovo ThinkPad X13 Gen 3.36579.833891.wikitext:6:| Touchpad || {{ic|04f3:3195}} || {{Yes}} ::Lenovo ThinkPad X13 Gen 4 (AMD).36257.831168.wikitext:6:| Touchpad || {{ic|06cb:ce67}} || {{Yes}} ::Lenovo ThinkPad X13 Gen 5.36787.831170.wikitext:6:| Touchpad || {{ic|06cb:00f9}} || {{Yes}} ::Lenovo ThinkPad X1 Carbon (Gen 7).29041.842108.wikitext:17:| Touchpad || {{ic|06cb:cd8b}} || {{Yes}} ::Lenovo ThinkPad X1 Extreme (Gen 4i).35111.831154.wikitext:7:| Touchpad || {{ic|04f3:3197}} || {{Yes}} ::Lenovo ThinkPad X1 Extreme (Gen 5).34904.831155.wikitext:7:| Touchpad || {{ic|04f3:320d}} || {{Yes}} ::Lenovo ThinkPad X1 Tablet (Gen 3).37261.833734.wikitext:13:| Keyboard || {{ic|17ef:60b5}} || {{Yes}} ::Lenovo ThinkPad X1 Yoga (Gen 6).33128.831162.wikitext:6:| Touchpad || {{ic|06cb:00fc}} || {{Yes}} ::Lenovo ThinkPad X1 Yoga (Gen 7).34457.835125.wikitext:7:| Touchpad || {{ic|06cb:00fc}} || {{Yes}} ::Lenovo V15 G2-ALC.33770.831186.wikitext:7:| Touchpad || {{ic|04f3:31be}} || {{Yes}} ::Lenovo XiaoXin 15are 2020.31182.831189.wikitext:11:| Keyboard || {{ic|0001:0001}} || {{Yes}} ::Lenovo XiaoXin 15are 2020.31182.831189.wikitext:9:| Touchpad || {{ic|04f3:3140}} || {{Yes}} ::Lenovo Yoga C940.29672.831200.wikitext:6:| Touchpad || {{ic|06cb:00be}} || {{Yes}} ::Lenovo Yoga Duet 7 13IML05.34043.831201.wikitext:9:| Touchpad || {{ic|17ef:60f8}} || {{Yes}} ::Lenovo Yoga Pro 7 14ASP10.37298.835409.wikitext:12:| Touchpad || {{ic|06cb:cfd8}} || {{Yes}} ::Lenovo Yoga Slim 6 (14APU8).37725.843488.wikitext:19:| Touchpad || {{ic|06cb:cef5}} || {{Yes}} ::Lenovo Yoga Slim 7i Aura (15ILL9).37055.839765.wikitext:9:| Touchpad || {{ic|04F3:06FA}} || {{Yes}} ::MacBookPro9,x.16188.830890.wikitext:6:| Touchpad || {{ic|05ac:0252}} || {{Yes}} ::MacBookPro9,x.16188.830890.wikitext:8:| Keyboard || {{ic|05ac:0252}} || {{Yes}} ::MSI GE75 Raider 8SX.33513.833486.wikitext:8:| Keyboard || {{ic|1038:1122}} || {{Yes}} ::MSI GL73 8SC.34061.831144.wikitext:8:| Keyboard || {{ic|1770:ff00}} || {{Yes}} ::MSI GS65.26369.833161.wikitext:9:| Keyboard || {{ic|1038:1122}} || {{Yes}} ::MSI GS66 11UX.33563.834255.wikitext:10:| Keyboard || {{ic|1038:1122}} || {{Yes}} ::MSI GS66 11UX.33563.834255.wikitext:8:| Touchpad || {{ic|06cb:cdad}} || {{Yes}} ::MSI GS75.34540.833160.wikitext:10:| Keyboard || {{ic|1038:1122}} || {{Yes}} ::MSI GS75.34540.833160.wikitext:8:| Touchpad || {{ic|8086:a324}} || {{Yes}} ::MSI Modern 15 - A11S.32746.833766.wikitext:8:| Touchpad || {{ic|04f3:30aa}}|| {{Yes}} ::MSI Modern 15 A5M.34908.833166.wikitext:6:| Touchpad || {{ic|06cb:7e7e}} || {{Yes}} ::MSI P15.30926.833150.wikitext:10:| Keyboard || {{-}} || {{Yes}} ::MSI P15.30926.833150.wikitext:8:| Touchpad || {{ic|06cb:cdaa}} || {{Yes}} ::MSI Prestige 13 AI Evo A2VM.37081.833157.wikitext:6:| Touchpad || {{ic|06CB:CEBD}} || {{Yes}} ::MSI Prestige 13 AI Evo A2VM.37081.833157.wikitext:8:| Keyboard || {{ic|1038:1122}} || {{Yes}} ::MSI Vector A18 HX A9WX.37446.841199.wikitext:6:| Touchpad || {{ic|04F3:31FD}} || {{Yes}} ::MSI Vector A18 HX A9WX.37446.841199.wikitext:8:| Keyboard || {{ic|0db0:0db0}} || {{Yes}} ::Razer Book 13 (2020).32286.831225.wikitext:15:| Touchpad || {{ic|1532:026a}} || {{Yes}} ::Razer Book 13 (2020).32286.831225.wikitext:21:| Keyboard || {{ic|1532:026a}} || {{Yes}} ::System76 Pangolin pang12.35636.831238.wikitext:12:| Touchpad || {{ic|0911:5288}} || {{Yes}} ::TUXEDO InfinityBook 14 v6.34469.831230.wikitext:15:| Touchpad || {{ic|093a:0255}} || {{Yes}} ::Xiaomi RedmiBook Pro 15 2022 Ryzen.34837.842474.wikitext:6:| Touchpad || {{ic|27C6:01E0}} || {{Yes}} ::Xiaomi RedmiBook Pro 15 2023.36709.831228.wikitext:13:| Touchpad || {{ic|04F3:3238}} || {{Yes}} ::Xiaomi RedmiBook Pro 16 2025.37275.833427.wikitext:13:| Touchpad || {{ic|27c6:0f90}} || {{Yes}} ::

— Andrei Korshikov (talk) 09:30, 13 August 2025 (UTC)

For comparison you can look at Ubuntu Certified, for example: https://ubuntu.com/certified/201912-27634

DELL09D6:00 27C6:01E0 is PS/2 ID in their representation. — Andrei Korshikov (talk) 09:37, 13 August 2025 (UTC)

Another example from Linux Hardware Database: https://linux-hardware.org/?id=ps/2:7e7e-7e7e-dell0740-00-06cb-touchpad

As you see, PS/2 ID in "pretty" format here is DELL0740:00 06CB:Touchpad. It was magically transformed into 0740:0006CB in Dell Inspiron 13 (5378). — Andrei Korshikov (talk) 09:53, 13 August 2025 (UTC)

By the way, this "ID" is not ID per se (at the end, PS/2 is not a bus and PS/2 devices cannot be enumerated like PCI or USB ones), it is a device name (to my understanding, it is a string which is reported by ACPI).

Look: https://linux-hardware.org/?view=search&name=DELL0740%3A00+06CB%3ATouchpad#list — we search by name, not by Vendor/Device IDs.

— Andrei Korshikov (talk) 10:02, 13 August 2025 (UTC)

Sample of minor names inconsistency between Ubuntu Certified and Linux Hardware Database.

DELL08B7:00 044E:120A Touchpad — https://ubuntu.com/certified/201901-26824

DELL08B7:00 044E:120A Mouse — https://linux-hardware.org/?view=search&name=DELL08B7%3A00+044E%3A120A

— Andrei Korshikov (talk) 10:18, 13 August 2025 (UTC)

Maybe we could allow stating "PS/2" without the ID? I think the issue comes from people not wanting to leave blank cells in the table.

-- Erus Iluvatar (talk) 10:07, 13 August 2025 (UTC)

👍 I think it would be fine to allow things like "PS/2" or "I2C" if their IDs are not useful. -- nl6720 (talk) 10:19, 13 August 2025 (UTC)

I agree.

> "people not wanting to leave blank cells in the table"

I had the same thoughts. — Andrei Korshikov (talk) 10:23, 13 August 2025 (UTC)

Add a requirement to list all the needed firmware packages

As Arch splitted the linux-firmware package into several ones, I think it is worth to list all the needed specific linux-firmware-… packages explicitly in the "Installation" section.

This topic was originally raised in the Add "Vendor" column to "wikitable archwiki-table-laptop" conversation with @Erus Iluvatar.

Example: Dell Inspiron 13 (5378)#Installation. Ok, not really good example because of two consecutive links, I mean the "linux-firmware-atheros Linux firmware" part.

— Andrei Korshikov (talk) 15:06, 15 August 2025 (UTC)

I don't think it's necessary to make it mandatory, but hinting at it is probably good. In the Installation guide we have not changed the wording and still point people to the meta-package, so it's probably not a requirement to list the specific firmware needed if it's a dependency of it.

-- Erus Iluvatar (talk) 08:17, 16 August 2025 (UTC)

Totally agree. I was thinking about "best practice" or just "recommendation", but have chosen the wrong word. Not a "requirement" or "mandatory option", of course. Tip—in a plain text or {{Tip|…}}—is enough IMO.

— Andrei Korshikov (talk) 10:41, 16 August 2025 (UTC)

Order of hardware components ("common parts")

As you definitely noticed, our hardware tables are a bit chaotical. I don't like it for two reasons.

At first, when the same visual element ("hardware table" in our case) looks different in different places the whole wiki part feels unprofessional?… amateur?… I'm not sure if I know the word, but I hope you see the point. It's kinda "created by crazy students".

At second (and this point is way more important IMO), random order means that we have to read the whole list every time. No way to skim/skip. I don't know polite words to describe my feeling when I have to read a random list over and over again :D

I've tried alphabetical order in Dell Inspiron 13 (5378) but I don't really like it: Audio is the first. wtf?! I do not care about the Audio!

My current suggestion: put the most important part(s) (GPU?) to the top, place other parts in alphabetical order.

What do you think?..

— Andrei Korshikov (talk) 20:36, 3 September 2025 (UTC)

I'm suggesting we copy the order of the linux-hardware probe, as arbitrary as it sounds the order "feels" right to me :P

-- Erus Iluvatar (talk) 08:03, 4 September 2025 (UTC)

Aha, I see the root of the "chaos":D (well, "chaos" in my perception:))

Anyway, my point is simple—the wiki is for readers, and, especially, newcomers—hardcore professionals read the source code:DD (or, at least, manual pages…)

So, our current "order" is convenient for hw-probe copy-pasting, but is not convenient for a person who is not aware about hw-probe or just bought their brand new laptop and wants to install Arch first time.

— Andrei Korshikov (talk) 19:23, 6 September 2025 (UTC)