tiny-pilot
Support - Nintendo Switch (SmileBASIC 4) adjustment request
Before I begin, I do want to note that I am using an RPI 4b, but with Bookworm through a suggest method of manual installation. If the problem is because of using Bookworm, then please close this and disregard it.
I found this tool recently, which has exactly what I was looking for. The ability to copy code/data I produce on my computer and then transfer that over to my Nintendo Switch through automated keystrokes to inject into SmileBASIC 4. Using the Paste Text feature does just that. While typing code manually is one thing due to readability, having to type up "raw" data is another, as I plan to compile data on my computer as raw characters that are not readable, and it would be incredibly tedious to attempt to type that stuff in manually. Via keyboard is the only way to inject this data. Being able to automate it is a blessing.
But, I am running into some issues. While Paste Text works, sometimes it misses some ENTER keystrokes, causing the next line of code to append to the current line, resulting in syntax errors and such when trying to run it. It may be doing this also with manual typing. When I was initially setting this up, I had tried an RPi0w, but because of the weaker single-core CPU, it was slower with the forwarding process. But, I don't recall if I ran into this missing keystroke issue, so it may be something regarding the Switch and/or SmileBASIC 4's means of accepting keystrokes. Perhaps my RPi 4b is too fast for it? I don't wish to drop the Pi's CPU clock to slow this process down as a means to remedy this because I have the Pi doing other things for my home network at the same time. Perhaps an option to delay between keystrokes, or even after specific ones like the ENTER key?
One nice thing about TinyPilot is that I can also use the mouse with this environment, but that too has problems. A mouse connected to the system (wired or via dongle) will operate normally, but not with this method of forwarding. The cursor on the Switch/SmileBASIC always gets stuck in the lower-right corner. I did take a look at the code, and it says it's dealing with relative positioning, but after some testing, I'm thinking the Switch/SmileBASIC is handling this differently. I think it's looking at it in absolute terms and adding to the cursor's current position where the value is always positive.
To test this, I placed the mouse cursor in the TinyPilot browser window to the top-left corner of the usable area at (0,0). I used SmileBASIC's ability to emulate mouse movement with the R-Stick, and manually moved the cursor to the upper-left corner of the screen. So they are both at the top-right. I moved the TinyPilot cursor one pixel to the right. How this reflected on SmileBASIC was that it jumped a good deal to the right. Moved the TinyPilot cursor back to the left in the x=0 position, the SmileBASIC cursor did not move. TinyPilot cursor moved to the right one pixel again-> SmileBASIC cursor jumped to the right. I moved the TinyPilot cursor one more to the right at x=2 position. An even bigger jump with the SmileBASIC cursor to the right, roughly double. Move TinyPilot cursor back one to the left at x=1 position. SmileBASIC's cursor still jumped to the right, but is shorter than the previous jump.
I don't know if this is something that can be adjusted so it continues to work as it has on other devices WHILE making it work correctly with a Switch and SmileBASIC, but perhaps an option to adjust how the mouse operates?
Thanks for sharing all these details @DiscostewSM, this is a cool use case for TinyPilot! I'm sorry you're having issues with pasting and the cursor on your Switch running SmileBASIC 4.
Firstly, I should mention that TinyPilot doesn't officially support Bookworm, so it's possible these issues are related to that, but I'm not sure that is the primary issue.
While Paste Text works, sometimes it misses some ENTER keystrokes
Is this only on your Switch with SmileBASIC 4? Or can you reproduce the missing Enter on other target machines / software?
If it's only ever Enter that gets missed on SmileBASIC 4, that suggests the issue might lie with SmileBASIC 4 - perhaps it performs some kind of function when it sees Enter that causes this issue?
Perhaps an option to delay between keystrokes, or even after specific ones like the ENTER key
If you're interested in testing this, you could modify the send_keystrokes function to include a pause after the send_keystroke call.
A mouse connected to the system (wired or via dongle) will operate normally, but not with this method of forwarding. The cursor on the Switch/SmileBASIC always gets stuck in the lower-right corner.
This sounds like an issue with the mouse mode. TinyPilot currently only supports absolute mouse positioning. However, some devices (like drawing tablets and touchscreens) require relative mode input to function correctly - I suspect this might be the case with your Switch. We have open issues to support relative mouse mode, but they're not on our short-term roadmap yet.
Please let me know if you have any questions.
Being able to do this kind of injection is something I've wanted to do ever since SmileBasic 4 released on Switch back in 2019, but every method I tried prior to this with an RPi capable of it (on and off, not constantly over 6 years) pretty much fell through with major problems. Just getting individual keystrokes injected was problematic because for some reason, the method would constantly miss keystrokes on Switch (not other devices). But finding this, even with these small issues, it has greatly excited me that I can finally start doing what I wanted.
Decided to do a fresh install of Bullseye on my 4b using the simple installation, just because it would help reduce the complexity of diagnosing issues. Couldn't get that version installed on the 0w with the forced install of the simple installation, as it kept throwing an Illegal Instruction, signifying an incompatibility with the CPU. However, with using the 4b, I've limited myself currently to a direct connection (USB-C to USB-A cable by Anker) because of the situation regarding backfeed from an external power source, and have no other means for a connection. Thought about getting a splitter on Amazon, one that states one side is for power/charging and the other is for data, but those are also designed to grant at least some power through the data, like for usb flash storage. This is something I assume is NOT wanted. So I may look into the Tinypilot Power Connector. It's possible that some of the issues I have may be related to having a low amperage.
In any case, I did try the 4b connected to other devices, like the RPi3 I just pulled out of storage. The RPi3 has dedicated power from the wall with the power adapter that came with the kit, so that unit shouldn't have power issues as-is. No video capture with a cable atm, though it's not set to h264 because it complains in my browser when my PC has NordVPN active. Not seeing any issue with the keystroke injections to the RPi3 so far, but the mouse is quite laggy, jumping from location to location. It at least ends up in the general area where it supposed to be after a time. For some reason though, the left button clicks are acting like right-button clicks against the RPi3 Desktop UI. Here is what I see in the LOGS:
discopi4b python[626]: 2025-12-03 23:50:20.503 socket_api ERROR [SENSITIVE] Failed to forward mouse event: Failed to write to HID interface: /dev/hidg1. Is USB cable connected? [/SENSITIVE]
As mentioned, I'm using a direct connection that provides a small amount of amps as opposed to the 3A recommended, so that may be causing the lagginess. But the wrong button click? I dunno. I've got an old Windows laptop stored away that I can try testing with as well, to see if any of these behaviors show up there.
As far as the missing Enter keystrokes when using this on SmileBASIC, that could be because of how the application deals with that. For one, I doubt the developers ever thought someone would do such injections at high speed. Plus in the app, the Enter keystroke also indents the next line to the same indentation as the previous line, so it does multiple things. But I kind of imagine that would affect the next keystroke injection, not itself. When I have the time, I'll try that delay suggestion.
For the time being regarding mouse forwarding into SmileBASIC, I can deal with ignoring it and just plug in directly into the system for mouse utilization.
Thanks for sharing all this, @DiscostewSM.
So I may look into the Tinypilot Power Connector.
The TinyPilot Power Connector is designed exactly for this purpose (handling power and USB data) on the same USB-C port on self-built devices. We have more details about safely powering your Pi in our wiki.
The mouse click issue is an odd one that I haven't seen before. Unfortunately, the line from the logs you shared doesn't really tell us much beyond the device failing to forward a mouse event, which could be clicks or movement. If you have the full log, I can take a deeper look to see if there's anything that stands out. You can share a URL by going to System > Logs and then clicking "Get shareable URL".
When I have the time, I'll try that delay suggestion.
Awesome! I'm happy to help if you have any questions on this.
Please let me know if you have any questions.