Handle timeout response from empty ports of the maple bus to prevent a
stuck maple_sentq and a blocked maple bus.

When only some ports are used, e.g. if only keyboard is connected and the
other ports are empty, the device tends to timeout and return 0xff for
the empty port. This needs to be handled, just like the
MAPLE_RESPONSE_NONE response, to detect empty ports and to have usable
peripherals, if not all of the ports are utilized. Previously, an empty
port resulted in a never cleared maple_sentq which totally blocked the
maple bus to be used.

Signed-off-by: Florian Fuchs <fuchsfl@gmail.com>
---
Note: This patch was tested on real Sega Dreamcast hardware and resulted
in a usable keyboard, even when only 1 or 2 ports where populated. The
hot-plugging of the keyboard does also work fine.

The description of the timeout response can be obtained on the bottom of
of the page: https://mc.pp.se/dc/maplebus.html: "If no response is
received before the timeout, a word with all bits set (FFFFFFFF) is
written at the Result address."

 drivers/sh/maple/maple.c | 1 +
 include/linux/maple.h    | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/sh/maple/maple.c b/drivers/sh/maple/maple.c
index 6dc0549f7900..3d6c716cfc98 100644
--- a/drivers/sh/maple/maple.c
+++ b/drivers/sh/maple/maple.c
@@ -649,6 +649,7 @@ static void maple_dma_handler(struct work_struct *work)
 			list_del_init(&mq->list);
 			switch (code) {
 			case MAPLE_RESPONSE_NONE:
+			case MAPLE_RESPONSE_TIMEOUT:
 				maple_response_none(mdev);
 				break;
 
diff --git a/include/linux/maple.h b/include/linux/maple.h
index 3be4e567473c..4ae3cc6678a8 100644
--- a/include/linux/maple.h
+++ b/include/linux/maple.h
@@ -27,7 +27,8 @@ enum maple_code {
 	MAPLE_COMMAND_BWRITE,
 	MAPLE_COMMAND_BSYNC,
 	MAPLE_COMMAND_SETCOND,
-	MAPLE_COMMAND_MICCONTROL
+	MAPLE_COMMAND_MICCONTROL,
+	MAPLE_RESPONSE_TIMEOUT = 255
 };
 
 enum maple_file_errors {

base-commit: 24172e0d79900908cf5ebf366600616d29c9b417
-- 
2.43.0

Hi Florian.

On Wed, 2025-11-12 at 20:04 +0100, Florian Fuchs wrote:
> Handle timeout response from empty ports of the maple bus to prevent a
> stuck maple_sentq and a blocked maple bus.
> 
> When only some ports are used, e.g. if only keyboard is connected and the
> other ports are empty, the device tends to timeout and return 0xff for
> the empty port. This needs to be handled, just like the
> MAPLE_RESPONSE_NONE response, to detect empty ports and to have usable
> peripherals, if not all of the ports are utilized. Previously, an empty
> port resulted in a never cleared maple_sentq which totally blocked the
> maple bus to be used.
> 
> Signed-off-by: Florian Fuchs <fuchsfl@gmail.com>
> ---
> Note: This patch was tested on real Sega Dreamcast hardware and resulted
> in a usable keyboard, even when only 1 or 2 ports where populated. The
> hot-plugging of the keyboard does also work fine.
> 
> The description of the timeout response can be obtained on the bottom of
> of the page: https://mc.pp.se/dc/maplebus.html: "If no response is
> received before the timeout, a word with all bits set (FFFFFFFF) is
> written at the Result address."
> 
>  drivers/sh/maple/maple.c | 1 +
>  include/linux/maple.h    | 3 ++-
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/sh/maple/maple.c b/drivers/sh/maple/maple.c
> index 6dc0549f7900..3d6c716cfc98 100644
> --- a/drivers/sh/maple/maple.c
> +++ b/drivers/sh/maple/maple.c
> @@ -649,6 +649,7 @@ static void maple_dma_handler(struct work_struct *work)
>  			list_del_init(&mq->list);
>  			switch (code) {
>  			case MAPLE_RESPONSE_NONE:
> +			case MAPLE_RESPONSE_TIMEOUT:
>  				maple_response_none(mdev);
>  				break;
>  
> diff --git a/include/linux/maple.h b/include/linux/maple.h
> index 3be4e567473c..4ae3cc6678a8 100644
> --- a/include/linux/maple.h
> +++ b/include/linux/maple.h
> @@ -27,7 +27,8 @@ enum maple_code {
>  	MAPLE_COMMAND_BWRITE,
>  	MAPLE_COMMAND_BSYNC,
>  	MAPLE_COMMAND_SETCOND,
> -	MAPLE_COMMAND_MICCONTROL
> +	MAPLE_COMMAND_MICCONTROL,
> +	MAPLE_RESPONSE_TIMEOUT = 255
>  };
>  
>  enum maple_file_errors {
> 
> base-commit: 24172e0d79900908cf5ebf366600616d29c9b417

Thanks for your patch! I'll try to get it reviewed in the weekend.

In the meantime, I'll like to add Artur Rojek who did some work for Linux on the
Dreamcast as well if I remember correctly. Maybe he could test your patch as I
currently don't have my Dreamcast set up for testing.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

On 2025-11-12 22:31, John Paul Adrian Glaubitz wrote:
> Hi Florian.
> 
> On Wed, 2025-11-12 at 20:04 +0100, Florian Fuchs wrote:
>> Handle timeout response from empty ports of the maple bus to prevent a
>> stuck maple_sentq and a blocked maple bus.
>> 
>> When only some ports are used, e.g. if only keyboard is connected and 
>> the
>> other ports are empty, the device tends to timeout and return 0xff for
>> the empty port. This needs to be handled, just like the
>> MAPLE_RESPONSE_NONE response, to detect empty ports and to have usable
>> peripherals, if not all of the ports are utilized. Previously, an 
>> empty
>> port resulted in a never cleared maple_sentq which totally blocked the
>> maple bus to be used.
>> 
>> Signed-off-by: Florian Fuchs <fuchsfl@gmail.com>
>> ---
>> Note: This patch was tested on real Sega Dreamcast hardware and 
>> resulted
>> in a usable keyboard, even when only 1 or 2 ports where populated. The
>> hot-plugging of the keyboard does also work fine.
>> 
>> The description of the timeout response can be obtained on the bottom 
>> of
>> of the page: https://mc.pp.se/dc/maplebus.html: "If no response is
>> received before the timeout, a word with all bits set (FFFFFFFF) is
>> written at the Result address."
>> 
>>  drivers/sh/maple/maple.c | 1 +
>>  include/linux/maple.h    | 3 ++-
>>  2 files changed, 3 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/sh/maple/maple.c b/drivers/sh/maple/maple.c
>> index 6dc0549f7900..3d6c716cfc98 100644
>> --- a/drivers/sh/maple/maple.c
>> +++ b/drivers/sh/maple/maple.c
>> @@ -649,6 +649,7 @@ static void maple_dma_handler(struct work_struct 
>> *work)
>>  			list_del_init(&mq->list);
>>  			switch (code) {
>>  			case MAPLE_RESPONSE_NONE:
>> +			case MAPLE_RESPONSE_TIMEOUT:
>>  				maple_response_none(mdev);
>>  				break;
>> 
>> diff --git a/include/linux/maple.h b/include/linux/maple.h
>> index 3be4e567473c..4ae3cc6678a8 100644
>> --- a/include/linux/maple.h
>> +++ b/include/linux/maple.h
>> @@ -27,7 +27,8 @@ enum maple_code {
>>  	MAPLE_COMMAND_BWRITE,
>>  	MAPLE_COMMAND_BSYNC,
>>  	MAPLE_COMMAND_SETCOND,
>> -	MAPLE_COMMAND_MICCONTROL
>> +	MAPLE_COMMAND_MICCONTROL,
>> +	MAPLE_RESPONSE_TIMEOUT = 255
>>  };
>> 
>>  enum maple_file_errors {
>> 
>> base-commit: 24172e0d79900908cf5ebf366600616d29c9b417
> 
> Thanks for your patch! I'll try to get it reviewed in the weekend.
> 
> In the meantime, I'll like to add Artur Rojek who did some work for 
> Linux on the
> Dreamcast as well if I remember correctly. Maybe he could test your 
> patch as I
> currently don't have my Dreamcast set up for testing.

Hi Adrian,
I indeed did some minor work to restore Dreamcast support in Linux. Will
give this patch a try once I find some free time.

Florian,
thanks for the patch! Can this be tested with just regular controllers?
I don't own a Dreamcast keyboard.

Cheers,
Artur


> 
> Adrian

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.

btw, I have also a cdi file, that boots for me, although I heard there
were issues on the NTSC-U devices, if helpful:
https://github.com/foxdrodd/dreamcast-linux/releases/download/6.17.7/linux6177-joystick.cdi

Thank you for your efforts,
Florian

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.

> 
> btw, I have also a cdi file, that boots for me, although I heard there
> were issues on the NTSC-U devices, if helpful:
> https://github.com/foxdrodd/dreamcast-linux/releases/download/6.17.7/linux6177-joystick.cdi

Thanks for the cdi. I have no means to burn CDs anymore, so instead
I quickly built a small buildroot based rootfs, and booted it as
initramfs over serial line :-)

Cheers,
Artur

> 
> Thank you for your efforts,
> Florian

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.

Regards,
Florian

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