Help talk:Laptop page guidelines

From ArchWiki

Using a "See also" section exclusively instead of a related articles box

The guidelines here say that a "See also" section should contain helpful links and Help:Style#Related articles box says that a "See also" section can be used "for a more complete and detailed list."

Given that a high quality laptop article should contain a hardware table in the top-right, I'm wondering if there's a preference to using "See also" exclusively instead of a related articles box for interwiki links. This would mean less information on the top-right side of a page (since there wouldn't be a related articles box). For example, Lenovo ThinkPad X1 Carbon (Gen 3) uses both a hardware table in the top-right and a related articles box below it, which looks alright, but it might look less cluttered if the links in the related articles box were instead moved to the "See also" section. For a more egregious example of where this can go wrong, see this weird-looking code block from Lenovo ThinkPad T450s.

The downside of using "See also" exclusively is that articles that are related (like articles for different generations of the Lenovo ThinkPad X1 Carbon) would now be at the bottom of the page, but the upside is that the top-right of the page would look less cluttered. I personally think that pages that currently do this look alright, but I'm interested in hearing what others think.

-- Flyingpig (talk) 21:52, 13 April 2021 (UTC)

The problem with the related articles box is that we have to violate the style guidelines to use them properly. It might result in this mess. To fix it you have to use html attributes in the table or you have to place the related articles box below it. Both are essentially style violations but since there are not many pages using both a hardware table and related articles I decided to violate Help:Style instead. I spoke with User:nl6720 in the wiki IRC channel about this and they mentioned that a template may make sense here.
And considering that the top right of the page is already loaded with hardware information I am not against decluttering it. I am wondering if moving all the laptop pages with generations (e.g the thinkpad x1 carbon) to a page with sub pages makes sense, e.g Lenovo Thinkpad X1 Carbon/Gen 1 but this may need to be discussed in a dedicated section.
-- NetSysFire (talk) 08:12, 14 April 2021 (UTC)
You know, now that I look at it a little closer, it doesn't seem like it's solely an issue with the related articles box. Really long hardware tables that extend down into the main body of the article still look a little strange because there's no margins around the hardware table (see previously mentioned examples). Thus, horizontal rules below a section heading and text hug the table really closely, so maybe some sort of template is warranted here…. -- Flyingpig (talk) 17:03, 14 April 2021 (UTC)
How would you feel about using collapsible elements for longer hardware tables that cut into the article's body? You would need to specify some HTML class attributes, but I think it looks somewhat nice when the hardware table is collapsed. The page will still look cluttered when the table is expanded though. -- Flyingpig (talk) 17:20, 30 April 2021 (UTC)

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 F1F12. -- 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 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)