Adds support for the Dreamcast control pad.
This is a port of the 2.4 driver (never in mainline) by Yaegashi
Takeshi.
Signed-off-by: Adrian McMenamin <[email protected]>
======
--- /dev/null 2007-10-16 19:02:41.000000000 +0100
+++ drivers/input/joystick/maplecontrol.c 2008-02-10 22:50:17.000000000 +0000
@@ -0,0 +1,215 @@
+/*
+ * SEGA Dreamcast controller driver
+ * Based on drivers/usb/iforce.c
+ *
+ * Copyright Yaegashi Takeshi, 2001
+ * Ported to 2.6 by Adrian McMenamin, 2008
+ */
+
+#include <linux/kernel.h>
+#include <linux/slab.h>
+#include <linux/input.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/timer.h>
+#include <linux/maple.h>
+#include <asm/mach/maple.h>
+
+MODULE_AUTHOR("YAEGASHI Takeshi <[email protected]>");
+MODULE_DESCRIPTION("SEGA Dreamcast controller driver");
+MODULE_LICENSE("GPL");
+
+struct dc_pad {
+ struct input_dev *dev;
+ int open;
+};
+
+static void dc_pad_callback(struct mapleq *mq)
+{
+ unsigned short buttons;
+ struct maple_device *mapledev = mq->dev;
+ struct dc_pad *pad = mapledev->private_data;
+ struct input_dev *dev = pad->dev;
+ unsigned char *res = mq->recvbuf;
+
+ buttons = ~*(unsigned short *)(res+8);
+
+ input_report_abs(dev, ABS_HAT0Y,
+ (buttons & 0x0010 ? -1:0) + (buttons & 0x0020 ? 1:0));
+ input_report_abs(dev, ABS_HAT0X,
+ (buttons & 0x0040 ? -1:0) + (buttons & 0x0080 ? 1:0));
+ input_report_abs(dev, ABS_HAT1Y,
+ (buttons & 0x1000 ? -1:0) + (buttons & 0x2000 ? 1:0));
+ input_report_abs(dev, ABS_HAT1X,
+ (buttons & 0x4000 ? -1:0) + (buttons & 0x8000 ? 1:0));
+
+ input_report_key(dev, BTN_C, buttons & 0x0001);
+ input_report_key(dev, BTN_B, buttons & 0x0002);
+ input_report_key(dev, BTN_A, buttons & 0x0004);
+ input_report_key(dev, BTN_START, buttons & 0x0008);
+ input_report_key(dev, BTN_Z, buttons & 0x0100);
+ input_report_key(dev, BTN_Y, buttons & 0x0200);
+ input_report_key(dev, BTN_X, buttons & 0x0400);
+ input_report_key(dev, BTN_SELECT, buttons & 0x0800);
+
+ input_report_abs(dev, ABS_GAS, res[10]);
+ input_report_abs(dev, ABS_BRAKE, res[11]);
+ input_report_abs(dev, ABS_X, res[12]);
+ input_report_abs(dev, ABS_Y, res[13]);
+ input_report_abs(dev, ABS_RX, res[14]);
+ input_report_abs(dev, ABS_RY, res[15]);
+}
+
+static int dc_pad_open(struct input_dev *dev)
+{
+ struct dc_pad *pad = dev->private;
+ pad->open++;
+ return 0;
+}
+
+static void dc_pad_close(struct input_dev *dev)
+{
+ struct dc_pad *pad = dev->private;
+ pad->open--;
+}
+
+static int dc_pad_connect(struct maple_device *mdev)
+{
+ int i, error;
+ unsigned long data = be32_to_cpu(mdev->devinfo.function_data[0]);
+ struct dc_pad *pad;
+ struct input_dev *dev;
+
+ const short btn_bit[32] = {
+ BTN_C, BTN_B, BTN_A, BTN_START, -1, -1, -1, -1,
+ BTN_Z, BTN_Y, BTN_X, BTN_SELECT, -1, -1, -1, -1,
+ -1, -1, -1, -1, -1, -1, -1, -1,
+ -1, -1, -1, -1, -1, -1, -1, -1,
+ };
+
+ const short abs_bit[32] = {
+ -1, -1, -1, -1, ABS_HAT0Y, ABS_HAT0Y, ABS_HAT0X, ABS_HAT0X,
+ -1, -1, -1, -1, ABS_HAT1Y, ABS_HAT1Y, ABS_HAT1X, ABS_HAT1X,
+ ABS_GAS, ABS_BRAKE, ABS_X, ABS_Y, ABS_RX, ABS_RY, -1, -1,
+ -1, -1, -1, -1, -1, -1, -1, -1,
+ };
+
+ pad = kzalloc(sizeof(struct dc_pad), GFP_KERNEL);
+ if (!pad)
+ return -ENOMEM;
+
+ dev = input_allocate_device();
+ if (!dev) {
+ kfree(pad);
+ return -ENOMEM;
+ }
+
+ pad->dev = dev;
+
+ mdev->private_data = pad;
+
+ for (i = 0; i < 32; i++)
+ if (data & (1<<i) && btn_bit[i] >= 0)
+ pad->dev->keybit[BTN_JOYSTICK/32] |= BIT(btn_bit[i]);
+
+ if (pad->dev->keybit[BTN_JOYSTICK/32])
+ pad->dev->evbit[0] |= BIT(EV_KEY);
+
+ for (i = 0; i < 32; i++)
+ if (data&(1<<i) && abs_bit[i] >= 0)
+ pad->dev->absbit[0] |= BIT(abs_bit[i]);
+
+ if (pad->dev->absbit[0])
+ pad->dev->evbit[0] |= BIT(EV_ABS);
+
+ for (i = ABS_X; i <= ABS_BRAKE; i++) {
+ pad->dev->absmax[i] = 255;
+ pad->dev->absmin[i] = 0;
+ pad->dev->absfuzz[i] = 0;
+ pad->dev->absflat[i] = 0;
+ }
+
+ for (i = ABS_HAT0X; i <= ABS_HAT3Y; i++) {
+ pad->dev->absmax[i] = 1;
+ pad->dev->absmin[i] = -1;
+ pad->dev->absfuzz[i] = 0;
+ pad->dev->absflat[i] = 0;
+ }
+
+ pad->dev->private = pad;
+ pad->dev->open = dc_pad_open;
+ pad->dev->close = dc_pad_close;
+ pad->dev->event = NULL;
+ pad->dev->dev.parent = &mdev->dev;
+ pad->dev->name = mdev->product_name;
+ pad->dev->id.bustype = BUS_HOST;
+ input_set_capability(pad->dev, EV_ABS, MSC_SCAN);
+ input_set_drvdata(dev, pad);
+
+ error = input_register_device(pad->dev);
+ if (error) {
+ input_free_device(pad->dev);
+ kfree(pad);
+ return -ENODEV;
+ }
+
+ maple_getcond_callback(mdev, dc_pad_callback, HZ/50,
+ MAPLE_FUNC_CONTROLLER);
+
+ return 0;
+}
+
+static void dc_pad_disconnect(struct maple_device *mdev)
+{
+ struct dc_pad *pad = mdev->private_data;
+
+ input_unregister_device(pad->dev);
+ kfree(pad);
+}
+
+/* allow the controller to be used */
+static int probe_maple_controller(struct device *dev)
+{
+ struct maple_device *mdev = to_maple_dev(dev);
+ struct maple_driver *mdrv = to_maple_driver(dev->driver);
+ int error;
+
+ error = dc_pad_connect(mdev);
+ if (error)
+ return error;
+
+ mdev->driver = mdrv;
+
+ return 0;
+}
+
+static struct maple_driver dc_pad_driver = {
+ .function = MAPLE_FUNC_CONTROLLER,
+ .connect = dc_pad_connect,
+ .disconnect = dc_pad_disconnect,
+ .drv = {
+ .name = "Dreamcast_controller",
+ .probe = probe_maple_controller,
+ },
+};
+
+static int __init dc_pad_init(void)
+{
+ return maple_driver_register(&dc_pad_driver.drv);
+}
+
+static void __exit dc_pad_exit(void)
+{
+ driver_unregister(&dc_pad_driver.drv);
+}
+
+module_init(dc_pad_init);
+module_exit(dc_pad_exit);
Changes to the Kconfig and Makefile needed to build the Maple controlpad
code.
Signed-off-by: Adrian McMenamin <[email protected]>
======
diff --combined drivers/input/joystick/Kconfig
index 7c662ee,7c662ee..3566fa2
--- a/drivers/input/joystick/Kconfig
+++ b/drivers/input/joystick/Kconfig
@@@ -282,4 -282,4 +282,17 @@@ config JOYSTICK_XPAD_LED
This option enables support for the LED which surrounds the Big X on
XBox 360 controller.
+config JOYSTICK_MAPLE
+ tristate "Dreamcast control pad"
+ depends on SH_DREAMCAST
+ select MAPLE
+ help
+ Say Y here if you have a SEGA Dreamcast and want to use your
+ controller.
+
+ Most Dreamcast users will say Y.
+
+ To compile this as a module choose M here: the
+ module will be called maplecontrol.
+
endif
diff --combined drivers/input/joystick/Makefile
index e855abb,e855abb..62929ef
--- a/drivers/input/joystick/Makefile
+++ b/drivers/input/joystick/Makefile
@@@ -27,5 -27,5 +27,6 @@@ obj-$(CONFIG_JOYSTICK_TURBOGRAFX) += tu
obj-$(CONFIG_JOYSTICK_TWIDJOY) += twidjoy.o
obj-$(CONFIG_JOYSTICK_WARRIOR) += warrior.o
obj-$(CONFIG_JOYSTICK_XPAD) += xpad.o
+ obj-$(CONFIG_JOYSTICK_MAPLE) += maplecontrol.o
obj-$(CONFIG_JOYSTICK_IFORCE) += iforce/
On Sunday 10 February 2008, Adrian McMenamin wrote:
> +static int dc_pad_connect(struct maple_device *mdev)
> +{
> + ...
> + if (data&(1<<i) && abs_bit[i] >= 0)
could use a few spaces in that first expression
> +/* allow the controller to be used */
> +static int probe_maple_controller(struct device *dev)
> +{
> + struct maple_device *mdev = to_maple_dev(dev);
> + struct maple_driver *mdrv = to_maple_driver(dev->driver);
> + int error;
> +
> + error = dc_pad_connect(mdev);
> + if (error)
> + return error;
> +
> + mdev->driver = mdrv;
> +
> + return 0;
> +}
> +
> +static struct maple_driver dc_pad_driver = {
> + .function = MAPLE_FUNC_CONTROLLER,
> + .connect = dc_pad_connect,
> + .disconnect = dc_pad_disconnect,
> + .drv = {
> + .name = "Dreamcast_controller",
> + .probe = probe_maple_controller,
> + },
> +};
no remove function ? looks like the probe() forces a connect, but there's no
remove() to force a disconnect ...
-mike
On Mon, February 11, 2008 12:22 am, Mike Frysinger wrote:
>
> no remove function ? looks like the probe() forces a connect, but there's
> no
> remove() to force a disconnect ...
Removing these devices (or any other plugged directly into the maple
ports) is a quick way to destroy your Dreamcast: hence they were never
implemented I guess. But there is no convincing reason for the software
not doing so, I suppose. I can just put in comments about it.
Hi Adrian,
On Mon, Feb 11, 2008 at 02:20:03PM +0000, Adrian McMenamin wrote:
> On Mon, February 11, 2008 12:22 am, Mike Frysinger wrote:
> >
> > no remove function ? looks like the probe() forces a connect, but there's
> > no
> > remove() to force a disconnect ...
>
>
> Removing these devices (or any other plugged directly into the maple
> ports) is a quick way to destroy your Dreamcast: hence they were never
> implemented I guess. But there is no convincing reason for the software
> not doing so, I suppose. I can just put in comments about it.
But what will happen if the driver gets unloaded by user?
--
Dmitry
Hi Adrian,
On Sun, Feb 10, 2008 at 10:57:01PM +0000, Adrian McMenamin wrote:
> +
> +static int dc_pad_open(struct input_dev *dev)
> +{
> + struct dc_pad *pad = dev->private;
> + pad->open++;
> + return 0;
> +}
> +
> +static void dc_pad_close(struct input_dev *dev)
> +{
> + struct dc_pad *pad = dev->private;
> + pad->open--;
> +}
What is the point of the above 2 functions?
> +
> +static int dc_pad_connect(struct maple_device *mdev)
> +{
> + int i, error;
> + unsigned long data = be32_to_cpu(mdev->devinfo.function_data[0]);
> + struct dc_pad *pad;
> + struct input_dev *dev;
> +
> + const short btn_bit[32] = {
> + BTN_C, BTN_B, BTN_A, BTN_START, -1, -1, -1, -1,
> + BTN_Z, BTN_Y, BTN_X, BTN_SELECT, -1, -1, -1, -1,
> + -1, -1, -1, -1, -1, -1, -1, -1,
> + -1, -1, -1, -1, -1, -1, -1, -1,
> + };
> +
> + const short abs_bit[32] = {
> + -1, -1, -1, -1, ABS_HAT0Y, ABS_HAT0Y, ABS_HAT0X, ABS_HAT0X,
> + -1, -1, -1, -1, ABS_HAT1Y, ABS_HAT1Y, ABS_HAT1X, ABS_HAT1X,
> + ABS_GAS, ABS_BRAKE, ABS_X, ABS_Y, ABS_RX, ABS_RY, -1, -1,
> + -1, -1, -1, -1, -1, -1, -1, -1,
> + };
> +
> + pad = kzalloc(sizeof(struct dc_pad), GFP_KERNEL);
> + if (!pad)
> + return -ENOMEM;
> +
> + dev = input_allocate_device();
> + if (!dev) {
> + kfree(pad);
> + return -ENOMEM;
> + }
> +
> + pad->dev = dev;
> +
> + mdev->private_data = pad;
> +
> + for (i = 0; i < 32; i++)
> + if (data & (1<<i) && btn_bit[i] >= 0)
> + pad->dev->keybit[BTN_JOYSTICK/32] |= BIT(btn_bit[i]);
> +
> + if (pad->dev->keybit[BTN_JOYSTICK/32])
> + pad->dev->evbit[0] |= BIT(EV_KEY);
> +
> + for (i = 0; i < 32; i++)
> + if (data&(1<<i) && abs_bit[i] >= 0)
> + pad->dev->absbit[0] |= BIT(abs_bit[i]);
> +
> + if (pad->dev->absbit[0])
> + pad->dev->evbit[0] |= BIT(EV_ABS);
> +
> + for (i = ABS_X; i <= ABS_BRAKE; i++) {
> + pad->dev->absmax[i] = 255;
> + pad->dev->absmin[i] = 0;
> + pad->dev->absfuzz[i] = 0;
> + pad->dev->absflat[i] = 0;
> + }
> +
> + for (i = ABS_HAT0X; i <= ABS_HAT3Y; i++) {
> + pad->dev->absmax[i] = 1;
> + pad->dev->absmin[i] = -1;
> + pad->dev->absfuzz[i] = 0;
> + pad->dev->absflat[i] = 0;
> + }
> +
> + pad->dev->private = pad;
input_set_drvdata().. Oh, wait, you are doing it below...
> + pad->dev->open = dc_pad_open;
> + pad->dev->close = dc_pad_close;
> + pad->dev->event = NULL;
input_dev is zeroes upon initialization, no need to set unused methods
to NULL. Also please consider using a temp for input_dev, it should
reduce generated code a bit.
> + pad->dev->dev.parent = &mdev->dev;
> + pad->dev->name = mdev->product_name;
> + pad->dev->id.bustype = BUS_HOST;
> + input_set_capability(pad->dev, EV_ABS, MSC_SCAN);
I did not see the driver reporting MSC_SCAN events. Also, MSC_SCAN is
usually reprted as EV_MSC, not EV_ABS.
> + input_set_drvdata(dev, pad);
> +
> + error = input_register_device(pad->dev);
> + if (error) {
> + input_free_device(pad->dev);
> + kfree(pad);
> + return -ENODEV;
return error;
There is no reason to "hide" real error reported by input_register_device.
> + }
> +
> + maple_getcond_callback(mdev, dc_pad_callback, HZ/50,
> + MAPLE_FUNC_CONTROLLER);
Hmm, this could probably go into dc_pad_open so we dont poll hardware
if there are no users.
> +
> + return 0;
> +}
> +
> +static void dc_pad_disconnect(struct maple_device *mdev)
> +{
> + struct dc_pad *pad = mdev->private_data;
> +
Don't you need to stop polling callback? Either here ot in dc_pad_stop,
depending on where maple_getcond_callback() is.
> + input_unregister_device(pad->dev);
> + kfree(pad);
> +}
> +
--
Dmitry
On Monday 11 February 2008, Adrian McMenamin wrote:
> On Mon, February 11, 2008 12:22 am, Mike Frysinger wrote:
> > no remove function ? looks like the probe() forces a connect, but
> > there's no remove() to force a disconnect ...
>
> Removing these devices (or any other plugged directly into the maple
> ports) is a quick way to destroy your Dreamcast: hence they were never
> implemented I guess. But there is no convincing reason for the software
> not doing so, I suppose. I can just put in comments about it.
and not allow the driver to be built as a module until the comments become
code ...
-mike
On Mon, Feb 11, 2008 at 11:19:22AM -0500, Mike Frysinger wrote:
> On Monday 11 February 2008, Adrian McMenamin wrote:
> > On Mon, February 11, 2008 12:22 am, Mike Frysinger wrote:
> > > no remove function ? looks like the probe() forces a connect, but
> > > there's no remove() to force a disconnect ...
> >
> > Removing these devices (or any other plugged directly into the maple
> > ports) is a quick way to destroy your Dreamcast: hence they were never
> > implemented I guess. But there is no convincing reason for the software
> > not doing so, I suppose. I can just put in comments about it.
>
> and not allow the driver to be built as a module until the comments become
> code ...
> -mike
Normally drivers can be unbound from devices via sysfs even if they are
built-in, not modules.
--
Dmitry
On Mon, February 11, 2008 4:25 pm, Dmitry Torokhov wrote:
> On Mon, Feb 11, 2008 at 11:19:22AM -0500, Mike Frysinger wrote:
>> On Monday 11 February 2008, Adrian McMenamin wrote:
>> > On Mon, February 11, 2008 12:22 am, Mike Frysinger wrote:
>> > > no remove function ? looks like the probe() forces a connect, but
>> > > there's no remove() to force a disconnect ...
>> >
>> > Removing these devices (or any other plugged directly into the maple
>> > ports) is a quick way to destroy your Dreamcast: hence they were never
>> > implemented I guess. But there is no convincing reason for the
>> software
>> > not doing so, I suppose. I can just put in comments about it.
>>
>> and not allow the driver to be built as a module until the comments
>> become
>> code ...
>> -mike
>
> Normally drivers can be unbound from devices via sysfs even if they are
> built-in, not modules.
>
>
I meant comments about not being so silly as to start plugging maple
devices in and out of the ports on the DC. I understand the point about
the code and will rework appropriately.
All I wanted to do is take somebody's old code and get it to work on 2.6.
But nothing is that simple :-/
On Monday 11 February 2008, Adrian McMenamin wrote:
> On Mon, February 11, 2008 4:25 pm, Dmitry Torokhov wrote:
> > On Mon, Feb 11, 2008 at 11:19:22AM -0500, Mike Frysinger wrote:
> >> On Monday 11 February 2008, Adrian McMenamin wrote:
> >> > On Mon, February 11, 2008 12:22 am, Mike Frysinger wrote:
> >> > > no remove function ? looks like the probe() forces a connect, but
> >> > > there's no remove() to force a disconnect ...
> >> >
> >> > Removing these devices (or any other plugged directly into the maple
> >> > ports) is a quick way to destroy your Dreamcast: hence they were never
> >> > implemented I guess. But there is no convincing reason for the
> >>
> >> software
> >>
> >> > not doing so, I suppose. I can just put in comments about it.
> >>
> >> and not allow the driver to be built as a module until the comments
> >> become code ...
> >
> > Normally drivers can be unbound from devices via sysfs even if they are
> > built-in, not modules.
>
> I meant comments about not being so silly as to start plugging maple
> devices in and out of the ports on the DC. I understand the point about
> the code and will rework appropriately.
is that a maple bus limitation or a joystick issue ? if maple, then there
really isnt much holding back this driver ...
> All I wanted to do is take somebody's old code and get it to work on 2.6.
> But nothing is that simple :-/
better than nothing. if someone doesnt like the lack of functionality, they
know where the source is ;)
-mike