Re: [PATCH] sh: maple: fix empty port handling
Artur Rojek <[email protected]>
| Newsgroups | gmane.linux.ports.sh.devel,gmane.linux.kernel |
|---|---|
| Message-ID | <[email protected]> |
On 2025-11-16 18:52, Florian Fuchs wrote: > On 16 Nov 13:34, Artur Rojek wrote: >> On 2025-11-12 23:46, Florian Fuchs wrote: >> > Hi Artur, >> > thank you so much for fixing the DC boot on linux again! >> > Adrian, thank you for looking at it! >> > >> > On 12 Nov 22:46, Artur Rojek wrote: >> > > thanks for the patch! Can this be tested with just regular >> > > controllers? >> > >> > Yes, indeed you can test it with the controller, when you compile with >> > joystick support, like: >> > >> > CONFIG_MAPLE=y >> > CONFIG_INPUT=y >> > CONFIG_INPUT_JOYDEV=y >> > CONFIG_INPUT_EVDEV=y >> > CONFIG_INPUT_JOYSTICK=y >> > CONFIG_JOYSTICK_MAPLE=y >> > >> > You should not put a VMU in though, as thats currently broken (I have a >> > patch ready). >> > >> > Then you can directly read from the evdev and listen for the button >> > presses: >> > bash-5.3# cat /dev/input/event2 | xxd >> > >> > You need to press a button for 20-30 times, as it seems to buffer the >> > events and outputs it in batches. >> > >> > Then, you should see the following outputs for the buttons: >> > >> > Button A: >> > 00000000: 7800 0000 94c3 0d00 0100 3001 0000 0000 x.........0..... >> > Button B: >> > 000001e0: 7800 0000 94c3 0d00 0100 3101 0100 0000 x.........1.... >> > Button X: >> > 000003b0: 7800 0000 94c3 0d00 0100 3301 0100 0000 x.........3..... >> > Button Y: >> > 00000900: 7800 0000 94c3 0d00 0100 3401 0100 0000 x.........4..... >> > >> > The Joystick should be detected like this: >> > / # dmesg|grep maple >> > maple: bus core now registered >> > maple (null): detected Dreamcast Controller: function 0x1: at (2, 0) >> > maple (null): no driver found >> > input: Dreamcast Controller as /devices/maple/2:00.1/input/input2 >> > >> > Another indicator is the dmesg log for empty ports: >> > maple (null): no devices to port 3 >> > >> > These messages were previously not there, as the empty ports were never >> > detected. >> >> Hey Florian, >> >> Before applying this patch, no input on a maple port is being >> registered >> until all 4 maple ports are populated (in my case by four >> controllers). >> Once all 4 are plugged in, I can register input on either of them by >> cat-ing their respective char devs. >> >> After applying the patch, I confirm that input can be read immediately >> for the present devices, even if the other ports are unpopulated. >> >> However, this patch also breaks hotplug on maple ports - I can no >> longer >> plug in additional controllers at runtime and have them show up. >> >> I think we need to hold off on this patch until the hotplug issue is >> addressed. >> > > Thank you for taking the time to test it! And sorry for the obvious > issue, > I think my testing was wrong as I just removed and plugged in an > already > registered device, and missed it with a new one. No worries. Thanks for looking into this - appreciated! On a side note, with your patch, after the initial disabling of unused ports, new maple codes (in maple_dma_handler) arrive only for the first and second port (and even despite MAPLE_RESPONSE_DEVINFO, no new devices are detected). The remaining two ports don't generate any codes at all on hotplug attempts. I don't know Maple bus to tell if this is normal or not, but make sure you test hotplug on all four ports. Cheers, Artur > > Regards, > Florian