[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5aa7d2005114e7fc476ecdeeac8bea13@artur-rojek.eu>
Date: Sun, 16 Nov 2025 19:25:53 +0100
From: Artur Rojek <contact@...ur-rojek.eu>
To: Florian Fuchs <fuchsfl@...il.com>
Cc: John Paul Adrian Glaubitz <glaubitz@...sik.fu-berlin.de>, Yoshinori Sato
<ysato@...rs.sourceforge.jp>, Rich Felker <dalias@...c.org>,
linux-sh@...r.kernel.org, linux-kernel@...r.kernel.org, Paul Cercueil
<paul@...pouillou.net>
Subject: Re: [PATCH] sh: maple: fix empty port handling
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
Powered by blists - more mailing lists