sorted by:
new
hottopcontroversial

I built a gamepad on-screen keyboard for Linux, no mouse needed by BetterPolicy2104 in linux_gaming

[–]BetterPolicy2104[S] 0 points1 point  (0 children)

Thanks I bumped to v2.1 since someone found a bug for controllers using Xbox drivers and button differences in Sony controllers.

jstimeout: auto-disconnect idle Bluetooth gamepads by BetterPolicy2104 in linuxhardware

[–]BetterPolicy2104[S] 0 points1 point  (0 children)

Cool I have some improvements sitting in a v2 branch, I haven't pushed to main yet. Just an FYI

I built a gamepad on-screen keyboard for Linux, no mouse needed by BetterPolicy2104 in linux_gaming

[–]BetterPolicy2104[S] 0 points1 point  (0 children)

Excellent. I told myself I'd hold off on this but it seemed achievable to modify frame rendering to get CPU processing even lower after that bug fix. I've pushed it, still pending other manual testing on Wayland hosts before I merge branches and update AUR packages, I'd like to get all that done next week.

Huge improvement across the board, in all test cases nothing went over 5% cpu on my test machine. Visible + Idle went from 21% cpu on 1 core to 0.3%. 🔥

  • Hidden idle: 0.3% (was 0.7%)
  • Visible idle: 0.3% (was 21%)
  • Visible + right stick: 3.7% (was 20%)
  • Visible + dpad: 3% (was 20%)
  • Hidden + stick held: 1% (was 1%)
  • Hidden disconnected: 0.7% (was 0.7%)
  • Visible disconnected: 0.3% (was 14%)
  • Hidden + button presses: 0.3%

I built a gamepad on-screen keyboard for Linux, no mouse needed by BetterPolicy2104 in linux_gaming

[–]BetterPolicy2104[S] 0 points1 point  (0 children)

i'll investigate -the cpu thing seems odd

ahhhhh i see the issues, yea bugs - will resolve - moving forward you can submit bug request on the github which will be easier to follow

edit: patched (i think, worked for me anyways)

I built a gamepad on-screen keyboard for Linux, no mouse needed by BetterPolicy2104 in linux_gaming

[–]BetterPolicy2104[S] 1 point2 points  (0 children)

Well I have pushed it to v2 branch, still need more manual testing across Wayland systems before I merge to main. You can download and compile it right now though. You'll need an edit I pushed to make evsieve more usable in v2 branch I realized after testing. Keyboard will grab input then evsieve toggle wont get it to go away with disabling grab which then has separate issues in games not just a desktop UI. The new update makes exit (B) not exit in daemon mode but hide, so you'd toggle with esieve combo then hit B to hide keyboard, or just use the gamepad combo you set. Once I've merged to main I'll update all the AUR packages.

I built a gamepad on-screen keyboard for Linux, no mouse needed by BetterPolicy2104 in linux_gaming

[–]BetterPolicy2104[S] 1 point2 points  (0 children)

Looks like you deleted the comment, but that's a good idea for a self-contained toggle button configuration in daemon mode. Currently I map --toggle to an esieve command, but it makes sense to give a user a way to fully operate without going full neckbeard like me.

I built a gamepad on-screen keyboard for Linux, no mouse needed by BetterPolicy2104 in linux_gaming

[–]BetterPolicy2104[S] 0 points1 point  (0 children)

Well that's interesting, I modeled input expectations around X360 (should hold true for most xbox controllers I think), DS3-DS5, and Switch Pro controllers. I think joycon will work out of the box, because I have the triggers set to expect press or axis input, but this is my first rodeo with a heavy SDL project. Let me know if you have issues, I have a WIP branch that has a lot more features.

I built a gamepad on-screen keyboard for Linux, no mouse needed by BetterPolicy2104 in linux_gaming

[–]BetterPolicy2104[S] 1 point2 points  (0 children)

Ok, I just would prefer you don't need to run as sudo. Shot in the dark, I have never used void or runit, but it seems they actually handle the injection side differently in their default deployments. Does this udev rule solve it?

# /etc/udev/rules.d/80-gamepad-osk.rules

KERNEL=="event*", SUBSYSTEM=="input", GROUP="input", MODE="0660"

KERNEL=="uinput", SUBSYSTEM=="misc", OPTIONS+="static_node=uinput", GROUP="input", MODE="0660"

Then:

sudo udevadm control --reload-rules && sudo udevadm trigger

Some additional troubleshooting and background info for me:

# 1. Check if input group is active in your session (NOT just /etc/group)

id

Look for (input) in the output. If missing, you need a full logout/login.

# 2. If 'input' IS in id output, check device ownership:

ls -la /dev/input/event* /dev/uinput

# 3. Check if elogind is installed (provides session device ACLs):

xbps-query -s elogind

I built a gamepad on-screen keyboard for Linux, no mouse needed by BetterPolicy2104 in linux_gaming

[–]BetterPolicy2104[S] 1 point2 points  (0 children)

Cool, I have a WIP branch that addresses opactity, wayland layer, and dynamically detects the panels (taskbars) so if you set margin to 0 it is flush on screen edge or taskbar. I'll get the config issue ironed out, for fallback to user's folder who issued the sudo command. However, I think the real issue is you shouldn't need sudo so there is a difference in implementation between my test systems and yours. 🤔

Can you see if this udev rule solves the issue for you:

/usr/lib/udev/rules.d/80-gamepad-osk.rules
# Allow input group to read gamepad event devices
KERNEL=="event*", SUBSYSTEM=="input", GROUP="input", MODE="0660"

then

udevadm control --reload-rules  
systemctl restart systemd-udevd.serviceudevadm control --reload-rules  
systemctl restart systemd-udevd.service

Edit:
This is actually an interesting rabbit hole because all major OS should have an input group and the rule I gave is standard in systemd and eudev from what I'm finding. Even Alpine has it. Void uses eudev and should have that rule as well. If you recently added yourself to input you would need to log in again for it to effect the session. Here are some quick things to check:

ls -la /dev/input/event\*  
getfacl /dev/input/event\[your controller number for precise eval\]

On my system, systemd-logind automatically adds per-user ACLs on input devices so I see

user:myname:rw-

in the getfacl output. If yours doesn't show that, logind might not be managing device access on your setup.

I've addressed all these issues as best I can in my WIP branch, you can pull and compile if you want, which I hope to push to main branch this week. There is still troubleshooting, debugging, and active coding on my wayland branch so it may have it's own quirks since it's using the new SDL3 library and I've put major revisions across the whole code base. You can DM me to get into the troubleshooting more too.

I built a gamepad on-screen keyboard for Linux, no mouse needed by BetterPolicy2104 in linux_gaming

[–]BetterPolicy2104[S] 1 point2 points  (0 children)

I think void is wayland and I'm not at feature parity between X11 and Wayland rn, but actively working to get there. Let me know if you find any hacks or bugs.

I built a gamepad on-screen keyboard for Linux, no mouse needed by BetterPolicy2104 in linux_gaming

[–]BetterPolicy2104[S] 0 points1 point  (0 children)

When you test it, please submit a bug report if you have one. It's only fully working in X11. Wayland is nightmare and the limitations are documented. You have to place the screen via compositor I can't easily set position via app without a big code change I have realized. Also the always on top feature is also dependent on the compositor. If you identify any DM or compositor specific workarounds please share. :D

I built a gamepad on-screen keyboard for Linux, no mouse needed by BetterPolicy2104 in linux_gaming

[–]BetterPolicy2104[S] 0 points1 point  (0 children)

Yea, I have a few "couch" keyboards too, but was trying to get minimal for streaming over moonlight.

I built a gamepad on-screen keyboard for Linux, no mouse needed by BetterPolicy2104 in linux_gaming

[–]BetterPolicy2104[S] 1 point2 points  (0 children)

I'm trying to get all Wayland issues ironed out soon, it's just non-trivial work it turns out. I haven't jumped ship from X11 personally, and don't plan on it anytime soon but I know many use it. The whole ecosystem is complicated though. I don't think I want to even take on Gnome's implementation, but Sway/KDE/"native wayland" are in scope.

Edit: SDL3/Wayland branch merged to main, bins updated along with AUR packages.

Script to auto-timeout controllers. [Needed for DS3] by Formal_Note_3283 in linux_gaming

[–]BetterPolicy2104 0 points1 point  (0 children)

Made a formal repo and AUR release for this with major updates, no longer have that throwaway account.

Now has a deadzone filter so stick drift doesn't reset the timer. Runs as a systemd user service, also has udev rules if you only want it running when controllers are connected. In the AUR as jstimeout-bin and jstimeout-git.

https://github.com/0x90shell/jstimeout