Remove Raspberry Pi userland

[zoltanvb]

Description

Userland was added at: #8132
However, its only use was with CRTSwitchRes together with VideoCore. Over the times, the legacy VideoCore drivers have lost usage as nowadays Mesa supports the VideoCore IV chip in RPi 0..3, and RPi 4 and/or 64-bit was never supported.

Option is kept to use the legacy drivers, but it is now utilized from the OS. It is only required if --enable-videocore is used to configure the build, and in this case userland install was required anyway, since only gfx/video_crt_switch.c used it from the RA source tree.

Tested building and basic RA operation.

Related Issues

Fixes #9966 . I will add a few words to RPi guide to cover installation of userland.

Reviewers

A confirmation would be nice that Lakka builds that still use videocore (GPICase and Pi02GPi) will still be able to build.

[LibretroAdmin]

@alphanu1 Is it OK to merge this or is the userland actually used for something still?

[alphanu1]

This was used to support video core 3 as well. If the user who has removed this can confirm CRT switching still works for PI2 and 3 using video core support then I guess it fine.

Just need to highlight that as it may cause regression.

[zoltanvb]

Change is quite trivial, VC source is still used, just from somewhere else, but certainly it is better to validate. It seems I can not test it unfortunately, as I read it not only needs the RPi + CRT, but an additional HDMI converter as well, since none of the Pi models builtin composite is suitable for SwitchRes, is that correct understanding?

Given that the last compilation failure was not reported for approx. 8 months (see #15971 ), probably there are not so many users around that would frequently get new builds. But, if there is anyone reading this who can test RPi + CRTSwitchRes, I can provide a new build if you tell me the environment.

[LibretroAdmin]

@alphanu1 So what's the status on this? By merging this are we removing support for something related to CRT SwitchRes or are we good here?

[alphanu1]

@LibretroAdmin, It possibly could. I no longer have a PI 2 or a PI 3. So, I cannot confirm any regression that this might cause. After the change to Calamity's switchres code. The PI will work with x11. However, if the source for the PI video driver is removed (part of above). Then, if the distro installed on the PI does not contain this RetroArch will not compile unless you install the above.

That being said CRT SwirchRes does not look for these in sources in the shared library folders. It points to the RA source folder "include/userland/interface/vmcs_host/". So removing this will break CRT SwitchRes for the PI.

[zoltanvb]

Seems not too much volunteers around for testing. I will make a try with what I have. Are there any settings which would let me test CRTSwitchRes operation on a basic level, using only RPi 1/2/3 and a current 4K TV (HDMI and composite available)?

Just for completeness sake:

if the distro installed on the PI does not contain this RetroArch will not compile

After this PR, RetroArch will not compile if the userland is not installed AND --enable-videocore is passed for compilation. If this option is given, RetroArch will anyway not compile even in the current state without the userland installed on OS level, since other parts of the code like the dispmanx driver do not use the baked-in include.

points to the RA source folder "include/userland/interface/vmcs_host/". So removing this will break CRT SwitchRes for the PI.

Apart from the removed files, the only changed line in this PR should account for this.

Note to self: contents of original PR is exactly the same as this:
raspberrypi/userland@e5803f2

[zoltanvb]

With one more change (to fix a crash when initiating switchres), I was able to see the resolution change happen to 1920x240 in the menu. (RPi 2, Debian Bullseye).