add global gamescope microcompositor support#14871
Conversation
|
Thanks @aderumier I just wanted to say a proper thank you for
I really appreciate the collaboration and the fact that you didn’t just redo everything from scratch but iterated on the original idea and pushed it much further. It’s great to see Gamescope becoming a proper first-class, global feature in Batocera. /Rion |
|
@aderumier good job, please mark it as draft until finished a few of points:
|
I have only tested on xorg with xwayland, at minimum it need libwayland-client && libwaylab-server gamescope is using wlroots internally and run only on pure wayland or xwayland(wit xorg) I'm pretty noob with buildroot, so sorry, I'll try to reduce dependencies at minimum again. (I had already tried to reduce it) (the depend in .mk are ok , but i'm not sure in Config.in ) BR2_PACKAGE_WAYLAND_PROTOCOLS && BR2_PACKAGE_XWAYLAND are needed at minimum, I'm not sure about BR2_PACKAGE_WAYLAND I'll do test again. |
|
to be more precise, gamescope is opening a new wayland session over current Xorg with only the game running in this session fullscreen. And the game inside gamescope, can run with Xwayland or native wayland if it support it). |
|
@aderumier You can use TortoiseGit if you are working on windows ... I've made a small writeup here https://wiki.batocera.org/github-tortoisegit |
|
@aderumier i think you're confused. xwayland is for backward compatibility with wayland compositors. are you suggesting xorg -> gamescope -> wayland -> xwayland? i will look at their source code... |
|
ok we have a problem, it does look like wayland is needed. |
I have no issues running this on my R9 380X.. What do you mean by not the x86_64 I specifically developed this without issue using my older AMD RX 380X cards in the older pull request.. |
|
Read what I wrote. Older NVIDIA cards don't support Wayland. You can't add it to a broad OS image such as x86_64 without causing confusion not to mention the graphics stack ugliness. |
|
ok built it, yes it needs xwayland as a dependency. like this @aderumier and... |
My idea was instead to tap into this new function introduced in v42 by @bryanforbes With this we could just display a message to the user if gamescope is unsupported by the dGPU/APU |
|
easier said than done unfortunately. |
|
gamescope itself is building 3 libs statically with specific version: (wlroots=0.18 ,vkroots ,libliftoff 0.5) (fallback for theses 3 lib ares forced in gamescope meson as wlroots versions are not abi retrocompatible,and for example last sway already use 0.19) so ithe depends are more like this to be complete: GAMESCOPE_DEPENDENCIES = sdl2 glm stb libdrm pipewire libdecor luajit libavif wayland wayland-protocols xwayland hwdata #gamescope GAMESCOPE_DEPENDENCIES += host-pkgconf host-wayland hwdata libdisplay-info libinput libegl libgles libgbm pixman seatd udev #wlroots |
|
sorry this is incorrect. other dependencies are automatically pulled in by others already defined. if you build it as i wrote it, it should work. |
no, it's more They are not "wayland" server, wayland is a lib, and the "server" is the compositor : gamescope, sway, ... without xorg, you could used gamescope nested behind sway, or directly gamescope in standalone, managing the whole sessions nested standalone (I think that steamdeck steamos use standalone model) |
but, how can you use wayland currently with non zen3 cpu ? (intel cpu with radeon for example) could it better to make generic x86 xorg or wayland image ? instead only enable wayland for specific cpu > zen3 ? or install both xorg,wayland by default in x86 images, and allow to switch between them. |
I just want to clarify a couple of points from the X11 vs Wayland angle, especially since I originally did the Wine-only Gamescope PR and have spent a lot of time testing this on the current x86_64 image.
Architecturally, Gamescope is always a Wayland compositor, but on an Xorg session it is not actually that many layers in practice. What we really have is:
This is a very common setup today. Gamescope is explicitly designed to run either
Arch based setups like ChimeraOS, and distros such as Nobara and Bazzite, all ship variations of this model. Some use a dedicated "Gamescope session" that logs you directly into Gamescope on KMS, and the same tooling can also run nested from a regular X11 or Wayland desktop. In all of those cases the core idea is the same: Gamescope is a small compositor that can sit on top of an existing session and still talk directly to DRM for flips and scaling when the driver stack allows it. On the current generic x86_64 Batocera image I already run Gamescope this way on an AMD R9 380X (amdgpu, Mesa) without real issues:
For modern flat panels on supported AMD / Intel / NVIDIA GPUs this nested path is what actually unlocks most of the useful Gamescope workflows: resolution spoofing to force specific internal resolutions and aspect ratios (for example 4:3 on a 16:9 screen), upscaling from sub-native resolutions, using AMD FidelityFX Super Resolution or NVIDIA Image Scaling, applying ReShade, and enforcing clean frame rate limits with stable fullscreen behavior. Under the hood, the timing and resolution stack that makes this possible (including SwitchRes for downscaling, custom low resolution modes and non-standard refresh rates, whether the target is a flat panel or a CRT) is still built entirely around Xorg and direct xrandr/DRM mode programming. Wayland compositors today do not expose the same low level mode control that these tools rely on, so a Wayland first base would effectively drop that whole class of workflows. If Gamescope ends up available only on a future Zen3 Wayland image, all of these existing use cases on the generic x86_64 build lose access to something that is already working today, both for modern displays and for CRT/downscaling setups. I completely understand the concern about older NVIDIA cards and the different driver paths. But that is really a runtime support problem, not a reason to avoid shipping Gamescope for x86_64 entirely:
This is where the new capability detection work from @bryanforbes in
That way:
I would really hate to see it excluded from the generic image when it is already proven to work there for a large chunk of AMD/Intel and Nvidia users. To be clear, this is also why I do not think it makes sense to restrict Gamescope only to a future Wayland based, AMD handled build. With everything above in mind, that would be an unnecessarily narrow target for a feature that already works today on the generic x86_64 image:
|
|
@Redemp all the OS's you mentioned run Wayland by default and are forks of or provide an OS similar to SteamOS from which gamescope was designed for. the PR is still incomplete and should be marked as draft until things are tidied up. but for now in future we can do |
|
to detect for driver support, I think we can use eglinfo to detect gbm support nvidia amd grep on "EGL_WL_wayland_eglstream" should be enough (or maybe EGL_KHR_platform_wayland) BTW, at least on v42, the nvidia driver deployment is missing a symlink on gbm ln -s /usr/lib/libnvidia-allocator.so /usr/lib/gbm/nvidia-drm_gbm.so without it, gbm is not loaded and gamescope can't work. |
technically, they are already doing it in their new vr headset running on snapdragon. Note that they are plenty of usecase for gamescope outside handled devices
|
I did read what you wrote, and I completely understand the worry about older NVIDIA cards and not wanting to mislead those users. My point is that this does not have to mean "no Gamescope at all" on the generic x86_64 image. We already ship a lot of features that are not universally supported on every GPU or board:
On unsupported hardware if a user forces them anyway the renderer fails and they are simply dropped back to EmulationStation. Nothing is permanently broken, and users quickly learn "this option does not work on my card". Gamescope on x86_64 behaves in the same way in practice:
The problem you are describing ("wrong expectations for older NVIDIA") is a runtime capability problem, not a reason to exclude Gamescope from the generic image entirely. To be clear, this is also why I do not think it makes sense to restrict Gamescope only to a future Wayland based, AMD handled build. That would be an unnecessarily narrow target for a feature that already works today on the generic x86_64 image:
I hope this does not come across the wrong way, but from my perspective it currently feels a bit like the "Little Red Hen" story: a lot of work has already gone into getting Gamescope working reliably on the generic x86_64 build, exactly so existing users on modern displays and CRT setups can benefit from it. Restricting it only to a future Wayland based AMD image would be like baking the bread, but then telling most of the people who helped grow the wheat that they cannot have a slice. My only real ask is that we do not throw away a working, tested path for the generic image when a capability based approach can keep expectations sane for unsupported GPUs and still let all the hardware that already can run Gamescope actually use it. |
|
I'm very happy this is being worked on and hope it gets merged, having more control over adjusting resolutions is always good, especially for us with less than conventional displays. |
|
Man im so excited about this, want to thank all the ones that are involved for the hard work, valious time and dedication. Me and my friends sometime play games that only works at fixed resolutions and this would be god send on all kinds of displays, i have a hd crt and this would be a option that i dont have anywhere else, heck im going to send a message to RetroRGB and MarcoRetro they both have YT channels related to gaming and im sure they would be very interested in the progress of gamescope. |
|
I agree with the previous comments, because having an option to control resolutions is a significant advantage for Wine and other emulators. |
| ]) | ||
|
|
||
| # Retrieve nested refresh rate. | ||
| # Default 60 if undefined |
There was a problem hiding this comment.
Should we provide the default? If gamescope decides to change their default, our default will change unless we use one here.
There was a problem hiding this comment.
For now, I would like really to keep "auto" = default from gamescope without forcing param, as after looking at the code, it's a little bit more complex :
int g_nNestedRefresh = 0;
g_nNestedRefresh = gamescope::ConvertHztomHz( parse_integer( optarg, "nested-refresh" ) );
g_nOutputRefresh = g_nNestedRefresh;
if ( g_nOutputRefresh == 0 )
g_nOutputRefresh = ConvertHztomHz( 60 );
nested refresh is initialized to 0 , not 60.
Output refresh inherit from nested refresh if nested refresh is defined, if not it's forced to 60hz . I'll update the comment for now.
|
Want to add my +1 support for this initiative. Batocera would make a great OS for handheld systems. A lot o them use portrait native displays ... which means their image is rotated by 90 degrees by default and in driver you have to rotate the screen. This breaks compatibility with a lot of Wine games, both old and new. Also having the ability to lock in a particular refresh rate like 40 fps / hz would be another godsend for users of x86 handhelds, it would help save on battery life where a lot of these handhelds have only 1 supported refresh rate that you can vsync games to and thats 60 or 120 hz. This is overkill for a handheld. This feature would allow for the customizability to have the screen oriented at a desired resolution and frequency. |
|
I'd like to add my +1 support for this initiative too. I'm especially interested in the potential implications using batocera with CRTs, but overall it would be a really significant development... |
|
Definitely would want this for x86_64 devices in general instead of a confined set of hardware. Low-res LCDs and CRTs, which are ideal for low res content display, would benefit a lot from this without having to abide to hardware confinements (i.e. you should be able to use whatever modern hardware you want to). |
aderumier
force-pushed
the
gamescope
branch
2 times, most recently
from
434fd80 to
87596ef
Compare
|
I have updated the PR.
|
Thanks a lot for the update @aderumier this looks really good. The new GBM / So this should directly address one of the main concerns that was raised about older unsupported NVIDIA cards, while still keeping the door open for the hardware that already runs Gamescope without issues. |
could be great if somebody can test it, as I don't have old gpu without wayland support |
|
I've a |
|
It needs to be a card that doesn't support Wayland or Vulkan. These are the checks you need. There is also probably a minimum Vulkan version. We already have a script for Vulkan that is used in configgen for emulators that Bryan standardised. |
They are a not in gamescope github about old card using radeonsi " but it should work. (Thanks amd && kernel devs to still support older cards). With nvidia, i'll be more difficult, as It'll really need 515.43.04+ nvidia driver, as nvidia never wanted to implemented gbm before So these nvndia cards should work: |
|
Want to add my +1 support for this initiative, Other emulators that would benefit from Gamescope are Mugen (obviously Wine) and Ikemen, there are often games that offer resolutions/aspect ratios that do not match well with modern monitors. |
|
Great work, everyone — truly impressive progress. I also hope that the advancements around Gamescope integration may eventually help us get closer to a proper solution for Wine bezels as well. That would be a huge milestone for many of us who rely on Wine systems inside Batocera. Once again, hats off to the whole team for the dedication and continuous improvements. Keep up the amazing work! |
|
More comments from unknown users won't help merge the PR. Commits will. Please fix what's required to be done, thanks. |
So far, Bryan comments about generator have been addressed or commented, && dmanlfc packaging .mk && Config.in have been implemented. So , please make code comments if something else need to be fixed. I think the main concern of users is that they would like to be able use use it over Xorg too and not on wayland (so only on zen3 images). I think, what is could be great, is to be able to enable gamescope options menu in ES, based on presence of gamescope binary && driver support (gbm driver support function is already implemented) Not sure if they are some options is ES to call a script to hide/show a submenu based on a script ? (I known it's already possible to display dynamic values) |
|
@aderumier you haven't selected gamescope in any package or batocera-system Config.in, you haven't added it to the so if you want this added quickly, fix the basics outlined above with the selection for the zen3 image currently and then we can look at x86_64 after. welcome to the wider ecosystem :-) i'm also not sure on the |
|
fyi - #14914 |
yes, I known, I wanted to have more review before enabled it in
I don't known enough buildroot, if isn't it possible to build only gamescope with wayland dependencies , and other package without wayland ? (as It seem to using BR2_PACKAGE_WAYLAND for gamescope, will impact other package guild ?) I'll add zen3 for now, and look to do more their to build on generic x86. (I'm really not familiar with buildroot)
(draft done) the gbm detection is already in the code (in gamescope.py), throwning an error when game is launching if gbm support is not available. (but it could be even better if we could hide or greyout the gamescope menu if support is not available) |
gamescope is using specific versions of wlroots,libliftoff,vkroots. They are statically linked in the gamescope binary when enabled, gamescope is prefixing the emulator commandline. ex: gamescope -W 3840 -H 2160 -f -- /usr/bin/retroarch .... default gamescope output resolution is set to current monitor resolution
|
@dmanlfc I have include gamescope in batocera/system/Config.ini and fixed gamescope in es_features btw, BR2_PACKAGE_BATOCERA_TARGET_ZEN3 is confusing, as it's seem to enable x86-64-v3, but x86-64-v3 existing since haswell in 2013, so it's really not related to zen3. It could be great for some emus to have avx support, I don't known what is the plan is to only use "zen3" image for console like steamdeck or make is more generic pc image, but for "modern" cpus with x86-64-v3 support ? |
It's just a name convention Buildroot uses. The Zen3 image is aimed at x86 handhelds and has more cpu extensions than the standard x86_64 build providing compatibility to more hardware. For this image, Wayland is a first class citizen that's why we'll bring it in here first. |
No it's not possible. Many other packages will pick-up in the build that wayland is part of the ecosystem and enable wayland features in the package.
Yes this is what I want |
|
@aderumier Can you post result if you setup WinLems 1.42 with gamescope? you need 2 files in WinLems dir
Then extract place the 2 files to WinLems.pc-root-dir and setup autorun.cmd The game has no fullscreen-mode, just windowed - gamescope should push it to fullscreen ;) |
Ah ok, thanks. I understand now. so , I'll try to see the behaviour of other package with wayland enabled. I don't think it should hurt for emu, as it's not black|white , it should just add wayland lib support to the emu, not forcing it with breaking xorg support. |
|
@aderumier what's the status? |
I didn't have time to work on yet (super busy at work). I'll try to test next week. (I need to prepare a big vm for building the whole image,as it's pretty long). I want to test it on wayland image first, to see if they are no conflict with sway .(I have seen some report where it need special command line option). I could also be possible to run as main compositor instead sway (like on the steamos), but I don't known if it's handling fine multi monitors && other things. I have prepared amd && nvidia hardware to test, now I just need time |
14 participants
This is a continuation of this work:
#13690
Gamescope is a microcompositor allowing to any emulator or process is a wayland surfarce,
with upscaling|downscaling support with fsr or other modern techniques.
It's also add support for HDR for games supporting it. (mostly modern windows games).
For wine, it's really usefull, as currently, wine is using xrandr to switch the monitor resolution to the native game resolution with an automatic frequency (even if videomode is at batocer size defined, it'll can change it), and sometime it choose a bad unsupported frequency or resolution, and user can have a black screen or game not rendered full screen. (some 4k tvs have shit EDID).
This is also allowing some only 1080p games to run on steamdeck in 720p. (Most of the modern arcade games have fixed internal resolution, and are not able to downscale)
or allow to run 16:9 in 4:3 arcade cabinet monitor
Gamescope is compatible with AMD (Mesa 20.3+), Intel (Mesa 21.2+) , Nvidia proprietary driver (515.43.04+). So no legacy driver for nvidia, as it need gbm support.
I have tested myself and some friend with : nvidia rtx2070, nvidia quadro, amd rx 6600, Nvidia Quadro P1000, amd ryzen7 apu, steamdeck