In accordance with a conversation I had with @ankith26 in discord, I modified the PR to instead display the result of platform.platform() instead of the driver reported by sdl2

Found a problem.

>>> import os
>>> os.environ["PYGAME_HIDE_SUPPORT_PROMPT"] = "1"
>>> import pygame
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\charl\AppData\Local\Programs\Python\Python39\lib\site-packages\pygame\__init__.py", line 409, in <module>
    platform,
NameError: name 'platform' is not defined
>>>

That's an easy fix

@Starbuck5 should be fixed now

This PR is not dead, but is awaiting a pretty significant change according to a conversation in discord

OK, I will hold off on my review until the significant change has appeared (cryptic :D)

Waiting for #3379 to resolve. The future of this PR is something to the effect of:
A pygame.debug() method that gets everything relevant to the current setup. If display is initialized, it grabs the driver. If mixer is initialized, it grabs the SDL mixer info, etc.. and either prints to console or writes to a log file called pygame_debug.txt in the cwd (or the user can provide a filepath to save to instead?)

@oddbookworm looks like this could be whipped into shape now that #3379 is merged.

I'll work on this in the next few days or so

Didn't mean to close the PR

New summary:
A pygame.debug method that can optionally write to a file, but by default prints to the console. Retrieves all the important information about a particular user's setup

If #3567 gets merged before this PR, then I don't need the special freetype logic and it'll behave like all of the others

Example test program:

import pygame

pygame.init()
pygame.debug()

Example output:

Platform:		Windows-10-10.0.22000-SP0
System:			Windows
Processor:		AMD64 Family 23 Model 113 Stepping 0, AuthenticAMD
Architecture:		Bits: 64bit	Linkage: WindowsPE

pygame version:		2.1.4.dev1
python version:		3.9.0

SDL versions:		Linked: 2.24.0	Compiled: 2.24.0
SDL Mixer versions:	Linked: 2.6.2	Compiled: 2.6.2
SDL Font versions:	Linked: 2.20.1	Compiled: 2.20.1
SDL Image versions:	Linked: 2.0.5	Compiled: 2.0.5
Freetype versions:	Linked: 2.11.1	Compiled: 2.11.1

I like the output, should provide a useful block to copy and paste into issue reports.

Should the function be called debug_info(), print_debug_info() or print_system_info() though instead? We have a few 'info' gathering functions (display.Info(), display.get_wm_info(), midi.get_device_info()) already that this would then fit among - though none of those also print straight to the console.

I'm concerned that debug() is too general a name for what this function does which is essentially gather and print a bunch of hardware and software type & version information.

Getting names right is hard.

If #3567 gets merged before this PR, then I don't need the special freetype logic and it'll behave like all of the others

Cool, I think we should wait for that then before merging this one

This code needs to be resilient against crashing in different possible pygame environments, including when different modules are unavailable or fail to import.

So I think this needs to handle the case of the sub modules being MissingModule, as well as printing the reason a module is missing (usually a trace back)

EDIT: I am on windows 11, confusingly the version number for windows 11 is still 10.0

I think this is a problem with windows 11 itself. The vast majority of programs report the OS as windows 10, so it has to be something in the OS