Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FEXCore: adds support for compat input prctl #4106

Merged
merged 1 commit into from
Oct 8, 2024

Conversation

slp
Copy link
Contributor

@slp slp commented Oct 8, 2024

The size of the input_event struct differs between 32 bits applications and 64 bits applications. To deal with this, the kernel implements a compat variant for the input syscalls, but it's only enabled for 32 bit processes.

In libkrunfw we're introducing a prctl that enables a 64 bit process to request the kernel to enable the compat variant for the input syscalls. This commit makes use of that interface for enabling/disabling the compat input variant as required.

The visible effect is that input devices such as gamepads work properly on emulated 32 bit applications.

The size of the input_event struct differs between 32 bits applications
and 64 bits applications. To deal with this, the kernel implements a
compat variant for the input syscalls, but it's only enabled for 32 bit
processes.

In libkrunfw we're introducing a prctl that enables a 64 bit process to
request the kernel to enable the compat variant for the input syscalls.
This commit makes use of that interface for enabling/disabling the
compat input variant as required.

The visible effect is that input devices such as gamepads work properly
on emulated 32 bit applications.

Signed-off-by: Sergio Lopez <[email protected]>
@slp
Copy link
Contributor Author

slp commented Oct 8, 2024

This one needs to be paired with: slp/linux@897560f

Does this kind of feature require a FEXConfig tunable too?

@Sonicadvance1
Copy link
Member

Short term this is probably a fine workaround. Long term I think it'll have problems when we do more 32-bit thunking and then 32-bit and 64-bit libraries are both reading gamepad inputs, but since that's a non-issue for today, it's not a real concern yet.

Does this kind of feature require a FEXConfig tunable too?

FEXConfig shouldn't matter here, it's a runtime detectable option and would always want it currently.

I assume your kernel code is having processes inherit the prctl value being set, which is why it happens in all processes. Seems reasonable to me.

Copy link
Collaborator

@alyssarosenzweig alyssarosenzweig left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that long-term FEX needs to learn how to do this emulation or we need to get something mainlined, for the benefit of platforms other than Asahi.

As a hot fix I am so so ok with this. +1.

@alyssarosenzweig
Copy link
Collaborator

Long term I think it'll have problems when we do more 32-bit thunking and then 32-bit and 64-bit libraries are both reading gamepad inputs, but since that's a non-issue for today, it's not a real concern yet.

I don't expect Linux FEX to ever thunk anything that would read gamepads on 32-bit. Even thunking things like SDL on 64-bit doesn't seem to vibe with how we've approached thunking in FEX. I know box does it but they make compatibility tradeoffs in doing so that I'd rather FEX not.

@slp
Copy link
Contributor Author

slp commented Oct 8, 2024

Short term this is probably a fine workaround. Long term I think it'll have problems when we do more 32-bit thunking and then 32-bit and 64-bit libraries are both reading gamepad inputs, but since that's a non-issue for today, it's not a real concern yet.

Yes, I also consider this a temporary fix.

Does this kind of feature require a FEXConfig tunable too?

FEXConfig shouldn't matter here, it's a runtime detectable option and would always want it currently.

I assume your kernel code is having processes inherit the prctl value being set, which is why it happens in all processes. Seems reasonable to me.

Originally I was clearing the value on fork(), but I've noticed trouble in some 32 bits apps. I didn't dig deep, but my guess is that 32 bits apps may fork without going to through the FEXLoader's main (which does makes sense). Keeping the value around and disabling it for 64 bit apps makes everything work as expected.

@Sonicadvance1 Sonicadvance1 merged commit 6a07ea7 into FEX-Emu:main Oct 8, 2024
12 checks passed
@neobrain
Copy link
Member

neobrain commented Oct 9, 2024

I don't expect Linux FEX to ever thunk anything that would read gamepads on 32-bit. Even thunking things like SDL on 64-bit doesn't seem to vibe with how we've approached thunking in FEX. I know box does it but they make compatibility tradeoffs in doing so that I'd rather FEX not.

FTR libSDL is definitely one of the better-behaving APIs. This should be straightforward to forward to host now that we have a better approach to forwarding windowing system use.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants