Sender | Message | Time |
---|---|---|
23 Jan 2025 | ||
Sartek | Sorry I meant configuration option, I just realized it doesn't appear that termux has a preferences or settings interface which was where I was thinking it would make sense to be. Only the termux x11 app. | 05:53:40 |
ted | Sartek topics of configuration options and dead zones may be premature | 05:55:15 |
ted | given the functionality doesn't exist yet | 05:55:24 |
FZXO | use xinput | 06:08:46 |
FZXO | * use xinput bridge | 06:08:52 |
twaik | It will not be a preference/setting too. It will be a command for passing LD_PRELOAD and stuff to subsequent commands. | 06:08:53 |
FZXO | It's an app like input bridge but for controllers | 06:09:11 |
Sartek | Yeah, I was more trying to explain that translating controller input to mouse and keyboard can quickly become a mess and really isn't an elegant solution but could be hacked together. The issue with getting real controller input is that without root you can't create a device in the correct location that almost every single Linux application checks for controllers as you simply do not have the permissions on Android to do that. What you most likely have to do is override the normal executables behaviour to attempt to search for controller input devices in the usual place and have it instead access a virtual device in a place that android without root does have the permissions too. I believe Android has security that prevents game controller input being sent to an Android application unless it is in focus as we are using termux x11 that would then have to send it to the termux process in the background with whatever method is available further complicating it before termux then "emulates" a controller device in what the executable program thinks is /dev/input/js0 | 06:11:58 |
Sartek | Yeah I've heard of it but it's closed source and I don't feel comfortable using it on my main phone from a security perspective. | 06:13:20 |
hardray | seems like it's open source Inputbridge is close source tho | 06:22:00 |
hardray | * seems like it's open source Inputbridge is close source tho | 06:22:01 |
hardray | * seems like it's open source Inputbridge is close source tho | 06:22:07 |
Sartek | Yeah, there is also stuff like this that works on the wine side. https://github.com/nefarius/XInputHooker | 06:23:46 |
Sartek | * Yeah, there is also stuff like this that works on the wine side. https://github.com/nefarius/XInputHooker | 06:23:46 |
Sartek | This on windows for getting multiple keyboards and multiple mice to independently work in different games, good for multi seat gaming. https://nucleus-coop.github.io/docs/protoinput/ There is lots of stuff on the windows side that's used but will make anticheat software unhappy and will only work on wine. On the Linux side I don't think there there is that much out there as people usually have more control and don't need to resort to injecting code and replacing libraries with different implementations. | 06:29:06 |
Sartek | * This on windows for getting multiple keyboards and multiple mice to independently work in different games, good for multi seat gaming. https://nucleus-coop.github.io/docs/protoinput/ There is lots of stuff on the windows side that's used but will make anticheat software unhappy and will only work on wine. On the Linux side I don't think there there is that much out there as people usually have more control and don't need to resort to injecting code and replacing libraries with different implementations. | 06:29:07 |
twaik |
| 06:31:27 |
Sartek | Thank you, you have been very helpful, I don't have any experience with Android development so I wasn't aware that Unix sockets were available, I was under the impression that they were using network traffic through localhost. I'm happy with your proposed solution using LD_PRELOAD. I'll look more into it and do some research. I really appreciate you taking the time to explain the inner workings of how termux does things. | 06:43:25 |
Sartek | So I did some digging and apparently adb shell has access to /dev/input and with shizuku I can get a adb shell on the local device just by being connected to a wifi network, in the linked Reddit post it is mentioned that apps are prevented from creating named Unix sockets which is probably an issue. | 07:35:34 |
Sartek | https://www.reddit.com/r/termux/s/CXhvFQFbJt | 07:35:53 |
Sartek | Shizuku has a program called rish that you can run in termux to connect to shizuku. It might be a dead end. | 07:38:52 |
twaik | Who said apps are restricted from creating unix sockets? | 07:42:20 |
Sartek | Specifically named Unix sockets, it's a reddit post so maybe it's not true. | 07:42:45 |
twaik | There is no such restriction... | 07:43:08 |
twaik | And how exactly shizuku will help forwarding devices? Its ability to execute programs with debug privileges does not magically bring the ability to open device nodes in termux's app sandbox. | 07:44:59 |
Sartek | Yeah, so it's likely a dead end cause termux can't run inside an adb shell? I'll have to look into limitations of adb shell. | 07:48:54 |
twaik | Termux's programs can not run in adb because adb can not access /data/data/com.termux... Not related to sdk level or unix socket restriction or anything. They will work fine if you build the whole termux environment for, i.e. /data/local/tmp (AFAIK the only place ADB has write access to). | 07:51:28 |
Sartek | Okay so if I did that then in theory I could run a Linux executable and access my game controller. It wouldn't be able to send data to termux-x11 app for graphics as it can only write to /data/local/tmp it can't do any networking or Unix sockets or anything like that? | 07:57:34 |
twaik | termux-x11 can run in any android app sandbox since it instantiates X server on the side of your environment. And after this interacts with the main app code via Binder to avoid messing with permissions of Unix sockets. So it is signature/userid agnostic. | 08:00:03 |
Lofii changed their display name from Lofi to Lofii. | 08:28:07 |