checks: Add various detections specific to Linux #161

mihawk90 · 2024-05-31T16:25:21Z

Description

This adds various detections aimed at helping us in linux-support to provide help quicker without having to dive deep into the log with every user. This should cover the most of the common questions and issues, and the myriad of possible combinations encountered on Discord.

Changes in detail:

renamed wayland.py to linux.py since this isn't just for Wayland anymore
moved the snap detection merged in core: Add Detection of unofficial Snap Package #137 to linux.py
for X11 vs. Wayland
- useful for advice on the various capture methods
- CRITICAL XWayland was already logged
- INFO Wayland was previously already detected, but not logged
- INFO X11 Logging + recommended captures
- WARNING Also logs PipeWire capture sources being used on X11. Currently this is only relevant for very recent GNOME versions and for recent(-ish) KDE versions. KDE doesn't actually support this either, but still advertises availability.
- CRITICAL On Wayland this also logs when no PipeWire captures are available
INFO Log usage of the Flatpak package
- helps to know this is an official package and is also relevant for plugin installation
INFO Distro + Version if available (unfortunately not on Flatpak)
- useful to advise on package managers and names for xdg-desktop-portals or plugin packages
INFO Desktop Environment
- useful for xdg-desktop-portals and the various limitations of specific DEs
INFO Missing default plugins
- currently checks for Browser, VLC, and WebSocket but can easily be extended if need be
- while AJA and BlackMagic plugins are technically a default functionality, these are essentially never asked for so I didn't see much reason to include them
INFO Missing v4l2loopback module for VCam functionality

Motivation and Context

The current lack of output by the OBS Bot requires us to manually check for the same information on every log we are getting in linux-support. The detections and help texts (suggestions welcome!) should give users some pointers to help themselves when there is currently no supporter around (since linux-support isn't as frequented as the others). Obviously it also helps supporters to give faster responses without having to check every log manually.

Of course Linux has an inherent multitude of possible setups, which I tried to cover as best as possible without checking for every eventuality. It should cover the most frequent issues and questions collected over quite some time.

How Has This Been Tested?

Grabbed a random assortment of logs from the Discord:

#!/bin/bash

echo "===== Snap ====="
./loganalyzer.py --url "https://obsproject.com/logs/a8VNcRHD4vjHol3P"

echo "===== Flatpak ====="
./loganalyzer.py --url "https://obsproject.com/logs/MXdrIL75xKFyPNom"

echo "===== Wayland ====="
./loganalyzer.py --url "https://obsproject.com/logs/MXdrIL75xKFyPNom"

echo "===== XWayland ====="
./loganalyzer.py --url "https://obsproject.com/logs/1FaZYJAAwOsKvUxX"

echo "===== Wayland + no pipewire ====="
./loganalyzer.py --url "https://obsproject.com/logs/CN9BBx9uPPjBcGlA"

echo "===== X11 ====="
./loganalyzer.py --url "https://obsproject.com/logs/jBUCYqPE5LRHMRHB"

echo "===== X11 + PipeWire sources ====="
./loganalyzer.py --url "https://obsproject.com/logs/MQhnzM1TFjBgdxrO"

Types of changes

New feature (non-breaking change which adds functionality)
Tweak (non-breaking change to improve existing functionality)
Documentation (a change to documentation pages)

Checklist:

My code has been run through clang-format.
I have read the contributing document.
My code is not on the master branch.
The code has been tested.
All commit messages are properly formatted and commits squashed where appropriate.
I have included updates to all appropriate documentation.

RytoEX

If a commit changes one file in checks/, the commit prefix is that file's name without the file extension.

Always capitalize the first word in the commit message subject after the prefix.

I don't use Linux, so I'll probably need someone else to comment on the substance of the changes themselves.

mihawk90 · 2024-06-08T07:05:12Z

Fixed up.

Also added a note regarding the missing default plugins in OP.

Edit:
Adjusted some wording in the PipeWire Source detection to make it more consistent.
Wondering if I should add a note on game captures too though?

mihawk90 · 2024-06-08T20:47:56Z

Adjustments for unified PipeWire source in 30.2:

Added new pipewire-screen-capture-source detection
renamed "Screen Capture" to "Display Capture" throughout the help texts

For the Wayland logging, I already put a note in there that Global Hotkeys won't work, would it make sense to add Browser docks to that note as well?

mihawk90 · 2024-09-10T02:35:03Z

Rebased to current master to keep it up to date.

Groundwork for future linux-specific checks similar to the Windows and MacOS specific checks.

mihawk90 · 2024-11-21T23:45:01Z

Rebased to current master and also fixed the name for the VLC plugin being wrong.

RytoEX · 2024-11-22T21:21:10Z

I still need someone familiar with Linux or Linux support to give some insight here.

checks/linux.py

RytoEX · 2024-11-22T21:36:26Z

checks/linux.py

+    return [LEVEL_INFO, "X11",
+            "Window Capture is available via Xcomposite, while Display Capture is available via XSHM. We generally recommend sticking to \"Window Capture (Xcomposite)\" since \"Display Capture (XSHM)\" can introduce bottlenecks depending on your setup."]


Should this be emitted all the time even if the user is not using any captures?

Since this is only INFO this was intended, yes. We often get questions of what capture method to use, and there's not always someone around.

The message is intended for users when noone is around, the X11 info on the other hand is useful for the OBS Bot output for supporters.

I don't think the usage of XSHM warrants using a warning either since there are legitimate usecases, and I didn't want to split the logic even further. This is purely informational after all.

I have mixed feelings about always emitting an INFO like this, but I don't have enough experience in Linux support to accurately weigh the benefits vs. the noise.

If it helps, it's not much different then Windows logs always showing the Windows version and Admin status. It's a helper info for Supporters (although not being active in w-s I don't know how much it helps or what the differences are), and for endusers reading the analysis it doesn't provide much detail either.

The big difference being that on Linux there's more variables to consider (Distro, Desktop Environment, and Window System mostly). So yes we end up with 3 info bulletins instead of 2, but it is information we look at in every log anyway. So it takes a click off supporters and if noone's around it might help the occasional user. If not, well then they'll have to wait for someone to come around anyway 😅

Always showing the Windows version is "fine", which is why I'm okay with showing the Distro info elsewhere for Linux (though it might be nice if they could be a single item "system info"). This is mostly because we're aware of issues that only exist or are fixed in specific OS versions that are otherwise hard to diagnose from logged info.

The point I'm making here is that we're emitting an INFO giving blanket capture advice whether or not any such sources are detected. For all we know, the user won't be using any of the captures mentioned (maybe they're only using v4l2 or teleport or browser).

Yeah I get what you're saying.
I just honestly don't really see it being problematic.
If a user doesn't want to capture either windows or a display, they can just ignore it since it's clearly about window and display capture. Maybe we could reword it a little:

If you wish to capture a window or an entire display, captures are available via Xcomposite and XSHM respectively. We generally recommend sticking to "Window Capture (Xcomposite)" since "Display Capture (XSHM)" can introduce bottlenecks depending on your setup.

That should make it even clearer that it can and should be ignored if no captures are intended.

If users do end up getting confused by it we can remove it anytime as well. We won't know unless we have it first though.

And going back to the windows logs, the same can be said about the "Not Admin" factoid, which can lead users to assume they should be running it as admin (similar to the audio buffering factoid in the other PR).

RytoEX · 2024-11-22T21:39:18Z

checks/linux.py

+        return
+
+    modulesMissingList = []
+    modulesCheckList = ('obs-browser.so', 'obs-websocket.so', 'vlc-video.so')


What's the rationale for checking only these modules?

I was trying to find a balance between checking "everything" and those that might reasonably be missing and are actually asked for in support. This PR was also opened before the CMake rewrite hit master so a lot of things that might be disabled by default now used to be enabled by default so I figured it wouldn't make much sense to include.

Specifically for this list:
Most distros don't ship Browser by default, many don't ship Websocket due to missing dependencies, and VLC source requires VLC to be installed (and isn't available in Flatpak at all). So those are the 3 major ones that could be missing.
As noted in the OP I left out AJA and BlackMagic because they are virtually never asked for.

It just occurred to me that obs-x264.so might be useful to check for, although it's really only relevant for Fedora at the moment (the plugin is shipped in RPM Fusion not in Fedora repos).

That being said, I could check for all modules if desired.

I don't have a strong opinion on this. I just wanted to raise a question.

RytoEX · 2024-11-22T21:42:49Z

checks/linux.py

+    if len(hasV4L2Module) > 0:
+        return [LEVEL_INFO, "VCam not available",
+                """Using the Virtual Camera requires the <code>v4l2loopback</code> kernel module to be installed.<br>
+                If required, please refer to our <a href="https://github.com/obsproject/obs-studio/wiki/install-instructions#prerequisites-for-all-versions">Install Instructions</a> on how to install this on your distribution.<br>


Perhaps we should link to https://obsproject.com/kb/virtual-camera-troubleshooting instead (which also links to https://github.com/obsproject/obs-studio/wiki/install-instructions#prerequisites-for-all-versions).

I figured the KB page doesn't really have useful information to actually get it running, so I linked to the Install Instructions instead to save a round trip.

I don't really mind either way, just figured going to the instructions directly is faster.

I don't have a strong opinion. This is better than no message.

checks/linux.py

Penwy

Besides the use of split and indices, I agree with all additions and can speak to their usefulness for linux support.

checks/linux.py

kkartaltepe · 2024-11-23T16:40:52Z

overall its fine, im not sure I agree with trying to explain which captures to use on your platform for every log uploaded but we can always change it later if it becomes distracting to users.

tiberium-v · 2024-11-23T17:24:45Z

I think also they are useful. Also I have the feeling that we have more user in #linux-support, they don't like to follow the instructions for uploading the log and paste it via pastebin or co in. For me, who is sometimes on mobile, it is a pain to access it. So a more verbose log analyzer output is here helpful.

In general, I have the feeling, that the windows side has always more useful information in the analyzer output. Like the windows version/build. So the additions here with info about the linux distro/flatpak and which Display-Server is running is on my side welcome as someone who give support there.

PS: And the possibility that users getting more info's, how a problem can be fixed by their own, is also a good thing.

RytoEX · 2024-11-23T20:36:08Z

overall its fine, im not sure I agree with trying to explain which captures to use on your platform for every log uploaded but we can always change it later if it becomes distracting to users.

That was the point I was trying to make in this review thread.

RytoEX requested changes Jun 8, 2024

View reviewed changes

mihawk90 force-pushed the linux-detections branch from 1642751 to 49891e9 Compare June 8, 2024 07:03

mihawk90 force-pushed the linux-detections branch 6 times, most recently from 2bdb5d6 to aa89b4d Compare June 8, 2024 20:46

mihawk90 force-pushed the linux-detections branch from aa89b4d to 80378f0 Compare September 10, 2024 02:32

mihawk90 added 3 commits November 22, 2024 00:41

checks: Rename wayland.py to linux.py

6d34839

Groundwork for future linux-specific checks similar to the Windows and MacOS specific checks.

linux: Move Snap package detection from core

ed2bf98

linux: Log Wayland usage

651ca5f

mihawk90 force-pushed the linux-detections branch from 80378f0 to 823e84b Compare November 21, 2024 23:43

RytoEX requested changes Nov 22, 2024

View reviewed changes

mihawk90 added 2 commits November 22, 2024 22:51

linux: Log Flatpak usage

5f4fa87

linux: Detect unavailable PipeWire captures

f88a8a1

mihawk90 force-pushed the linux-detections branch from 823e84b to f92ef0f Compare November 22, 2024 22:15

mihawk90 added 4 commits November 22, 2024 23:50

linux: Detect PipeWire capture sources under X11

2fc6a54

linux: Log Distro info

71d6f05

linux: Log Desktop Environment info

64dfac1

linux: List and count missing default plugins

9176aff

Penwy reviewed Nov 22, 2024

View reviewed changes

checks/linux.py Outdated Show resolved Hide resolved

checks/linux.py Outdated Show resolved Hide resolved

mihawk90 force-pushed the linux-detections branch from f92ef0f to aeb09ae Compare November 22, 2024 22:52

linux: Detect unavailable Virtual Cam

72dbec6

mihawk90 force-pushed the linux-detections branch from aeb09ae to 9f35c5c Compare November 23, 2024 00:20

linux: Fix potential IndexError issues

a169dc9

mihawk90 force-pushed the linux-detections branch from 9f35c5c to a169dc9 Compare November 23, 2024 00:24

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

checks: Add various detections specific to Linux #161

checks: Add various detections specific to Linux #161

mihawk90 commented May 31, 2024 •

edited

Loading

RytoEX left a comment

mihawk90 commented Jun 8, 2024 •

edited

Loading

mihawk90 commented Jun 8, 2024 •

edited

Loading

mihawk90 commented Sep 10, 2024

mihawk90 commented Nov 21, 2024

RytoEX commented Nov 22, 2024

RytoEX Nov 22, 2024

mihawk90 Nov 22, 2024 •

edited

Loading

RytoEX Nov 23, 2024

mihawk90 Nov 23, 2024

RytoEX Nov 23, 2024

mihawk90 Nov 24, 2024

RytoEX Nov 22, 2024

mihawk90 Nov 22, 2024

RytoEX Nov 23, 2024

RytoEX Nov 22, 2024

mihawk90 Nov 22, 2024

RytoEX Nov 23, 2024

Penwy left a comment

kkartaltepe commented Nov 23, 2024

tiberium-v commented Nov 23, 2024 •

edited

Loading

RytoEX commented Nov 23, 2024

		return [LEVEL_INFO, "X11",
		"Window Capture is available via Xcomposite, while Display Capture is available via XSHM. We generally recommend sticking to \"Window Capture (Xcomposite)\" since \"Display Capture (XSHM)\" can introduce bottlenecks depending on your setup."]

checks: Add various detections specific to Linux #161

Are you sure you want to change the base?

checks: Add various detections specific to Linux #161

Conversation

mihawk90 commented May 31, 2024 • edited Loading

Description

Motivation and Context

How Has This Been Tested?

Types of changes

Checklist:

RytoEX left a comment

Choose a reason for hiding this comment

mihawk90 commented Jun 8, 2024 • edited Loading

mihawk90 commented Jun 8, 2024 • edited Loading

mihawk90 commented Sep 10, 2024

mihawk90 commented Nov 21, 2024

RytoEX commented Nov 22, 2024

Choose a reason for hiding this comment

mihawk90 Nov 22, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Penwy left a comment

Choose a reason for hiding this comment

kkartaltepe commented Nov 23, 2024

tiberium-v commented Nov 23, 2024 • edited Loading

RytoEX commented Nov 23, 2024

mihawk90 commented May 31, 2024 •

edited

Loading

mihawk90 commented Jun 8, 2024 •

edited

Loading

mihawk90 commented Jun 8, 2024 •

edited

Loading

mihawk90 Nov 22, 2024 •

edited

Loading

tiberium-v commented Nov 23, 2024 •

edited

Loading