Re: [PATCH 1/2] SH/Dreamcast - joystick (Control pad)
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 signature.asc Description: This is a digitally signed message part.
Re: [PATCH 1/2] SH/Dreamcast - joystick (Control pad)
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 :-/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SH/Dreamcast - joystick (Control pad)
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SH/Dreamcast - joystick (Control pad)
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 signature.asc Description: This is a digitally signed message part.
Re: [PATCH 1/2] SH/Dreamcast - joystick (Control pad)
Hi Adrian,
On Sun, Feb 10, 2008 at 10:57:01PM +, 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<= 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<= 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SH/Dreamcast - joystick (Control pad)
Hi Adrian, On Mon, Feb 11, 2008 at 02:20:03PM +, 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SH/Dreamcast - joystick (Control pad)
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] SH/Dreamcast - joystick (Control pad)
On Sunday 10 February 2008, Adrian McMenamin wrote:
> +static int dc_pad_connect(struct maple_device *mdev)
> +{
> + ...
> + if (data&(1<= 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
signature.asc
Description: This is a digitally signed message part.
[PATCH 1/2] SH/Dreamcast - joystick (Control pad)
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.0 +0100
+++ drivers/input/joystick/maplecontrol.c 2008-02-10 22:50:17.0
+
@@ -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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+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<= 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<= 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;
+
