wii - char driver for gba / joybus devices#81
Conversation
- moved common stuff to si.h - use the identity of the device in match for uhid/gba - very basic char driver for gba right now can be initialized with mknod /dev/gba0 c gba 0
- still need to figure out why SI_RESET and SI_IDENTIFY require uint32_t when we are only sending 1 byte
- move multiboot to userland - go back to only a single send ioctl - the rest will also live in userland - cleanup joybus since we dont need shared code there either now
gcport is the gamecube port that has a device attached. it will match everything besides the gamecube controller, which currently uses the existing logic to attach as a uhid keeping things generic removed references to gba
- define the four physical ports in the conf - update the match to compare the channel to the unit number
| gcport[0-3]*) | ||
| unit=${i#gcport} | ||
| mkdev gcport$unit c 100 $unit "" "" $u_uucp | ||
| ;; |
There was a problem hiding this comment.
havent really been able to test this piece yet. still trying to figure out how to rebuild the MAKEDEV file i am guessing requires me to build a new img
There was a problem hiding this comment.
Try $TOOLDIR/bin/nbmake-evbppc MAKEDEV from src/etc
|
you are ready to proceed with the sequential steps of your workflow! Based on our conversation, you have two major tasks queued up. Here is how you can execute them step-by-step right now: Standard DeploymentTo deploy your Hosting content and configuration to your live site: npx -y firebase-tools@latest deploy --only hostingThis deploys to your default sites ( Preview ChannelsPreview channels allow you to test changes on a temporary URL before going live. Deploy to a Preview Channelnpx -y firebase-tools@latest hosting:channel:deploy CHANNEL_IDReplace ExpirationChannels expire after 7 days by default. To set a different expiration: npx -y firebase-tools@latest hosting:channel:deploy CHANNEL_ID --expires 1dCloning to LiveYou can promote a version from a preview channel to your live channel without rebuilding. npx -y firebase-tools@latest hosting:clone SOURCE_SITE_ID:SOURCE_CHANNEL_ID TARGET_SITE_ID:liveExample: npx -y firebase-tools@latest hosting:clone my-project:feature-beta my-project:live💻 Part 1: Run the Environment Script (Steps 1, 2, and 3)Now that you have your PowerShell terminal open as an administrator, execute your script commands in order: # Step 1: List the available Firebase skills
npx -y skills add firebase/agent-skills --list
# Step 2: Check your local/global baseline
npx -y skills list --agent antigravity
npx -y skills list --agent antigravity --global
# Step 3: Run your automated script to add/link the missing skills
.\refresh-env.ps1🏛️ Part 2: File the Business ClaimOnce your environment is refreshing, you can handle the business documentation. Depending on your business structure, make sure you have these three pieces of information ready:
If you have a specific claim portal open (like an insurance page or a government SBA form) and need help phrasing the technical description of the system outage, let me know! |
| /* | ||
| * libogc uses interrupts for non-blocking. i think this is ok for now | ||
| */ | ||
| delay(data->delay); |
There was a problem hiding this comment.
This is bad from a security point of view as it allows userspace to make the ioctl spin (with lock held!) for a very long time.
There was a problem hiding this comment.
thanks for the callout. libogc does some pretty convoluted stuff to set up interrupts, converting the delay into a number of cpu ticks and what looks like a queue of the messages to send.
my thought was to have the driver implement the delay and as a v2 figure out how to have an async solution. But I can remove this for now and have the delay in userspace.
does it make sense to keep the delay in the struct payload for now as an unused property or to add it whenever I get around to it? I dont know how much backwards compatibility matters / the implications of adding new properties in the future.
There was a problem hiding this comment.
If you can define a reasonable upper bound for the delay value and do it without masking interrupts, I'm ok with that as a stopgap solution.
There was a problem hiding this comment.
im just gonna write a bunch of thoughts based on the libogc implementation:
- they do something to convert the
us_delayinto a number of ticks - eventually calls this SYS_SetAlarm
- which seems to use KTickTaskStart to track the number of ticks since the alarm has been set
- and the queue seems to be managed by the DECR Register whose handler is written in assembly
thinking a bit ahead this entire architecture is independent of the serial interface. instead, is it possible to build out a solution that enables userspace to register a callback when DECR hits zero. that way the delay needed for si send can live in userspace. i just dont know if something like that is possible. if not, then keeping the delay in the struct payload makes sense so it can be improved upon in the future.
| struct si_channel *ch; | ||
|
|
||
| ch = &sc->sc_chan[saa->saa_index]; | ||
| if (IS_GCPAD(ch->ch_id)) { |
There was a problem hiding this comment.
Have you considered implementing the gcport ioctl interface in the uhid_si driver instead? Then userspace could choose which interface to use.
There was a problem hiding this comment.
yea i am definitely open to it. its my first time working with kernel and on top of it the uhid stuff was an extra layer of complexity so i chose to avoid touching too much of your work.
- Particularly the gcpad_rdesc - what would it mean for a different type of device to be attached like a gameboy? My understanding is that file is unique to the gcpad.
- What would it mean for someone to use usbhidctl on a gameboy?
I couldnt find a way to make sense of these types of things which is why I went with a different driver altogether. But if you have thoughts on this I would be very interested to hear. maybe those questions dont matter if you only care about using one or the other..
There was a problem hiding this comment.
Yeah makes sense. So I wonder if we should layer this such as gcport attaches to every port, and then uhid attaches to the gcport(s) with a GameCube controller / WaveBird plugged in. What do you think?
There was a problem hiding this comment.
ok yea let me try to figure this out
There was a problem hiding this comment.
hey @jaredmcneill im starting to work through this but one thing i wanted to run by you
uhid attaches to the gcport(s) with a GameCube controller / WaveBird plugged in
the way this PR is currently structured and this proposal differ from how things work today. correct me if i am wrong, but since the current uhid_si_match always returns 1, the uhid devices for each port are available even if none are plugged in during boot. with this change that will no longer be the case. that gets back to your original suggestion of implementing my ioctl on the uhid instead.
what makes more sense in your opinion? uhid with wonky results for non-controller devices or only attaching uhid when a controller is recognized?
There was a problem hiding this comment.
i am starting to lean more towards your original suggestion. i think the gameboy may be an outlier as a device that does not support polling but could be wrong
There was a problem hiding this comment.
What if we made uhid attach/detect automatically when a controller or wavebird is plugged in?
Co-authored-by: Jared McNeill <jmcneill@invisible.ca>
3 participants
Adds
/dev/gcport*char drivers to the nintendo wii to support additional devices on the gamecube controller ports.Working example of it can be found here
changes
uhidfor gamecube controllers. all others are mapped to this new generic char drivergcport_si.cwith an ioctl command to leverage the serial communication