Re: [PATCH] input/touchscreen/sur40: use COLORSPACE_RAW
On 27.06.19 10:20, Hans Verkuil wrote: > On 6/27/19 10:12 AM, Florian Echtler wrote: >> On 26.06.19 11:52, Hans Verkuil wrote: >>> This driver set the colorspace to SRGB, but that makes no sense for >>> a touchscreen. Use RAW instead. This also ensures consistency with the >>> v4l_pix_format_touch() call that's used in v4l2-ioctl.c. >> >> One question for clarification: this will only affect userspace applications >> which explicitly request a certain colorspace, correct? > > You can't request a colorspace from userspace. The driver sets it. What I meant is: ... will only affect applications which explicitly search for formats with a specific colorspace value. > In this case is it inconsistent anyway since VIDIOC_S_FMT will return RAW > (due to the v4l_pix_format_touch() call), but G/TRY_FMT will return SRGB > from the driver. TRY_FMT should return RAW as well, but it didn't call > v4l_pix_format_touch(), for which I posted a separate patch fixing that. OK, understood. Acked-by: Florian Echtler Best regards, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: [PATCH] input/touchscreen/sur40: use COLORSPACE_RAW
On 26.06.19 11:52, Hans Verkuil wrote: > This driver set the colorspace to SRGB, but that makes no sense for > a touchscreen. Use RAW instead. This also ensures consistency with the > v4l_pix_format_touch() call that's used in v4l2-ioctl.c. One question for clarification: this will only affect userspace applications which explicitly request a certain colorspace, correct? Best regards, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: [PATCH 5/7 RESEND] touchscreen/sur40: set device_caps in struct video_device
Sorry, didn't realize you'd also need my feedback. No complaints. Acked-by: Florian Echtler Best, Florian On 04.06.19 18:06, Dmitry Torokhov wrote: > Hi Hans, > > On Tue, Jun 04, 2019 at 02:36:27PM +0200, Hans Verkuil wrote: >> Instead of filling in the struct v4l2_capability device_caps >> field, fill in the struct video_device device_caps field. >> >> That way the V4L2 core knows what the capabilities of the >> video device are. >> >> But this only really works if all drivers use this, so convert >> this touchscreen driver accordingly. >> >> Signed-off-by: Hans Verkuil >> Cc: Florian Echtler >> --- >> Resend, adding Dmitry and linux-input to the CC list. >> >> Dmitry, if you want to take this through your tree, then that's OK by me. >> >> Alternatively, it can go through the media tree, but then I need your Ack. > > I am fine with it going through media tree. > > Acked-by: Dmitry Torokhov > > Thanks. > -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: exposing a large-ish calibration table through V4L2?
Hello Hans, On 14.02.2018 13:13, Hans Verkuil wrote: > > On 14/02/18 13:09, Florian Echtler wrote: >> >> The internal device memory contains a table with two bytes for each sensor >> pixel >> (i.e. 960x540x2 = 1036800 bytes) that basically provide individual black and >> white levels per-pixel that are used in preprocessing. The table can either >> be >> set externally, or the sensor can be covered with a black/white surface and a >> custom command triggers an internal calibration. >> >> AFAICT the usual V4L2 controls are unsuitable for this sort of data; do you >> have >> any suggestions on how to approach this? Maybe something like a custom IOCTL? > > So the table has a fixed size? > You can use array controls for that, a V4L2_CTRL_TYPE_U16 in a > two-dimensional array > would do it. Good to know, thanks. > See https://hverkuil.home.xs4all.nl/spec/uapi/v4l/vidioc-queryctrl.html for > more > information on how this works. This means I have to implement QUERY_EXT_CTRL, G_EXT_CTRLS and S_EXT_CTRLS, correct? Will this work in parallel to the "regular" controls that use the control framework? Best, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
exposing a large-ish calibration table through V4L2?
Hello Hans, I've picked up work on the sur40 driver again recently. There is one major feature left that is currently unsupported by the Linux driver, which is the hardware-based calibration. The internal device memory contains a table with two bytes for each sensor pixel (i.e. 960x540x2 = 1036800 bytes) that basically provide individual black and white levels per-pixel that are used in preprocessing. The table can either be set externally, or the sensor can be covered with a black/white surface and a custom command triggers an internal calibration. AFAICT the usual V4L2 controls are unsuitable for this sort of data; do you have any suggestions on how to approach this? Maybe something like a custom IOCTL? Best regards, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
[PATCH 4/4] add video control handlers using V4L2 control framework
This patch registers four standard control handlers using the corresponding
V4L2 framework.
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 64 +++
1 file changed, 64 insertions(+)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index d6fa25e..b92325b 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
@@ -209,6 +210,7 @@ struct sur40_state {
struct video_device vdev;
struct mutex lock;
struct v4l2_pix_format pix_fmt;
+ struct v4l2_ctrl_handler hdl;
struct vb2_queue queue;
struct list_head buf_list;
@@ -218,6 +220,7 @@ struct sur40_state {
struct sur40_data *bulk_in_buffer;
size_t bulk_in_size;
u8 bulk_in_epaddr;
+ u8 vsvideo;
char phys[64];
};
@@ -231,6 +234,11 @@ struct sur40_buffer {
static const struct video_device sur40_video_device;
static const struct vb2_queue sur40_queue;
static void sur40_process_video(struct sur40_state *sur40);
+static int sur40_s_ctrl(struct v4l2_ctrl *ctrl);
+
+static const struct v4l2_ctrl_ops sur40_ctrl_ops = {
+ .s_ctrl = sur40_s_ctrl,
+};
/*
* Note: an earlier, non-public version of this driver used USB_RECIP_ENDPOINT
@@ -737,6 +745,36 @@ static int sur40_probe(struct usb_interface *interface,
sur40->vdev.queue = &sur40->queue;
video_set_drvdata(&sur40->vdev, sur40);
+ /* initialize the control handler for 4 controls */
+ v4l2_ctrl_handler_init(&sur40->hdl, 4);
+ sur40->v4l2.ctrl_handler = &sur40->hdl;
+ sur40->vsvideo = (SUR40_CONTRAST_DEF << 4) | SUR40_GAIN_DEF;
+
+ v4l2_ctrl_new_std(&sur40->hdl, &sur40_ctrl_ops, V4L2_CID_BRIGHTNESS,
+ SUR40_BRIGHTNESS_MIN, SUR40_BRIGHTNESS_MAX, 1, clamp(brightness,
+ (uint)SUR40_BRIGHTNESS_MIN, (uint)SUR40_BRIGHTNESS_MAX));
+
+ v4l2_ctrl_new_std(&sur40->hdl, &sur40_ctrl_ops, V4L2_CID_CONTRAST,
+ SUR40_CONTRAST_MIN, SUR40_CONTRAST_MAX, 1, clamp(contrast,
+ (uint)SUR40_CONTRAST_MIN, (uint)SUR40_CONTRAST_MAX));
+
+ v4l2_ctrl_new_std(&sur40->hdl, &sur40_ctrl_ops, V4L2_CID_GAIN,
+ SUR40_GAIN_MIN, SUR40_GAIN_MAX, 1, clamp(gain,
+ (uint)SUR40_GAIN_MIN, (uint)SUR40_GAIN_MAX));
+
+ v4l2_ctrl_new_std(&sur40->hdl, &sur40_ctrl_ops,
+ V4L2_CID_BACKLIGHT_COMPENSATION, SUR40_BACKLIGHT_MIN,
+ SUR40_BACKLIGHT_MAX, 1, SUR40_BACKLIGHT_DEF);
+
+ v4l2_ctrl_handler_setup(&sur40->hdl);
+
+ if (sur40->hdl.error) {
+ dev_err(&interface->dev,
+ "Unable to register video controls.");
+ v4l2_ctrl_handler_free(&sur40->hdl);
+ goto err_unreg_v4l2;
+ }
+
error = video_register_device(&sur40->vdev, VFL_TYPE_TOUCH, -1);
if (error) {
dev_err(&interface->dev,
@@ -769,6 +807,7 @@ static void sur40_disconnect(struct usb_interface
*interface)
{
struct sur40_state *sur40 = usb_get_intfdata(interface);
+ v4l2_ctrl_handler_free(&sur40->hdl);
video_unregister_device(&sur40->vdev);
v4l2_device_unregister(&sur40->v4l2);
@@ -962,6 +1001,31 @@ static int sur40_vidioc_g_fmt(struct file *file, void
*priv,
return 0;
}
+static int sur40_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct sur40_state *sur40 = container_of(ctrl->handler,
+ struct sur40_state, hdl);
+ u8 value = sur40->vsvideo;
+
+ switch (ctrl->id) {
+ case V4L2_CID_BRIGHTNESS:
+ sur40_set_irlevel(sur40, ctrl->val);
+ break;
+ case V4L2_CID_CONTRAST:
+ value = (value & 0x0F) | (ctrl->val << 4);
+ sur40_set_vsvideo(sur40, value);
+ break;
+ case V4L2_CID_GAIN:
+ value = (value & 0xF0) | (ctrl->val);
+ sur40_set_vsvideo(sur40, value);
+ break;
+ case V4L2_CID_BACKLIGHT_COMPENSATION:
+ sur40_set_preprocessor(sur40, ctrl->val);
+ break;
+ }
+ return 0;
+}
+
static int sur40_ioctl_parm(struct file *file, void *priv,
struct v4l2_streamparm *p)
{
--
2.7.4
[PATCH 2/4] add default settings and module parameters for video controls
This patch adds parameter definitions and module parameters for the four
userspace controls that the SUR40 can currently provide.
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index 8375b06..8a5b031 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -149,6 +149,40 @@ struct sur40_image_header {
#define SUR40_TOUCH0x02
#define SUR40_TAG 0x04
+/* video controls */
+#define SUR40_BRIGHTNESS_MAX 0xff
+#define SUR40_BRIGHTNESS_MIN 0x00
+#define SUR40_BRIGHTNESS_DEF 0xff
+
+#define SUR40_CONTRAST_MAX 0x0f
+#define SUR40_CONTRAST_MIN 0x00
+#define SUR40_CONTRAST_DEF 0x0a
+
+#define SUR40_GAIN_MAX 0x09
+#define SUR40_GAIN_MIN 0x00
+#define SUR40_GAIN_DEF 0x08
+
+#define SUR40_BACKLIGHT_MAX 0x01
+#define SUR40_BACKLIGHT_MIN 0x00
+#define SUR40_BACKLIGHT_DEF 0x01
+
+#define sur40_str(s) #s
+#define SUR40_PARAM_RANGE(lo, hi) " (range " sur40_str(lo) "-" sur40_str(hi)
")"
+
+/* module parameters */
+static uint brightness = SUR40_BRIGHTNESS_DEF;
+module_param(brightness, uint, 0644);
+MODULE_PARM_DESC(brightness, "set initial brightness"
+ SUR40_PARAM_RANGE(SUR40_BRIGHTNESS_MIN, SUR40_BRIGHTNESS_MAX));
+static uint contrast = SUR40_CONTRAST_DEF;
+module_param(contrast, uint, 0644);
+MODULE_PARM_DESC(contrast, "set initial contrast"
+ SUR40_PARAM_RANGE(SUR40_CONTRAST_MIN, SUR40_CONTRAST_MAX));
+static uint gain = SUR40_GAIN_DEF;
+module_param(gain, uint, 0644);
+MODULE_PARM_DESC(gain, "set initial gain"
+ SUR40_PARAM_RANGE(SUR40_GAIN_MIN, SUR40_GAIN_MAX));
+
static const struct v4l2_pix_format sur40_pix_format[] = {
{
.pixelformat = V4L2_TCH_FMT_TU08,
--
2.7.4
[PATCH v4] add video controls for SUR40 driver
Iteration 4, now with min/max values for module parameters. Best regards, Florian
[PATCH 1/4] add missing blob structure field for tag id
The SUR40 can recognize specific printed patterns directly in hardware;
this information (i.e. the pattern id) is present but currently unused
in the blob structure.
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index f16f835..8375b06 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -81,7 +81,10 @@ struct sur40_blob {
__le32 area; /* size in pixels/pressure (?) */
- u8 padding[32];
+ u8 padding[24];
+
+ __le32 tag_id; /* valid when type == 0x04 (SUR40_TAG) */
+ __le32 unknown;
} __packed;
--
2.7.4
[PATCH 3/4] add panel register access functions
These functions provide write access to the internal LCD panel registers
which also control the sensor. They can be used to disable the
preprocessor, set the illumination brightness, and adjust gain/contrast
(which are stored together in one register internally called "vsvideo").
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 75 +++
1 file changed, 75 insertions(+)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index 8a5b031..d6fa25e 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -251,6 +251,81 @@ static int sur40_command(struct sur40_state *dev,
0x00, index, buffer, size, 1000);
}
+/* poke a byte in the panel register space */
+static int sur40_poke(struct sur40_state *dev, u8 offset, u8 value)
+{
+ int result;
+ u8 index = 0x96; // 0xae for permanent write
+
+ result = usb_control_msg(dev->usbdev, usb_sndctrlpipe(dev->usbdev, 0),
+ SUR40_POKE, USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+ 0x32, index, NULL, 0, 1000);
+ if (result < 0)
+ goto error;
+ msleep(5);
+
+ result = usb_control_msg(dev->usbdev, usb_sndctrlpipe(dev->usbdev, 0),
+ SUR40_POKE, USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+ 0x72, offset, NULL, 0, 1000);
+ if (result < 0)
+ goto error;
+ msleep(5);
+
+ result = usb_control_msg(dev->usbdev, usb_sndctrlpipe(dev->usbdev, 0),
+ SUR40_POKE, USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+ 0xb2, value, NULL, 0, 1000);
+ if (result < 0)
+ goto error;
+ msleep(5);
+
+error:
+ return result;
+}
+
+static int sur40_set_preprocessor(struct sur40_state *dev, u8 value)
+{
+ u8 setting_07[2] = { 0x01, 0x00 };
+ u8 setting_17[2] = { 0x85, 0x80 };
+ int result;
+
+ if (value > 1)
+ return -ERANGE;
+
+ result = usb_control_msg(dev->usbdev, usb_sndctrlpipe(dev->usbdev, 0),
+ SUR40_POKE, USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+ 0x07, setting_07[value], NULL, 0, 1000);
+ if (result < 0)
+ goto error;
+ msleep(5);
+
+ result = usb_control_msg(dev->usbdev, usb_sndctrlpipe(dev->usbdev, 0),
+ SUR40_POKE, USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+ 0x17, setting_17[value], NULL, 0, 1000);
+ if (result < 0)
+ goto error;
+ msleep(5);
+
+error:
+ return result;
+}
+
+static void sur40_set_vsvideo(struct sur40_state *handle, u8 value)
+{
+ int i;
+
+ for (i = 0; i < 4; i++)
+ sur40_poke(handle, 0x1c+i, value);
+ handle->vsvideo = value;
+}
+
+static void sur40_set_irlevel(struct sur40_state *handle, u8 value)
+{
+ int i;
+
+ for (i = 0; i < 8; i++)
+ sur40_poke(handle, 0x08+(2*i), value);
+}
+
/* Initialization routine, called from sur40_open */
static int sur40_init(struct sur40_state *dev)
{
--
2.7.4
[PATCH v3] add video controls for SUR40 driver
As discussed previously, here's the third iteration of my patch to add control functions for the SUR40 driver, with (hopefully) correct handling of default values/module parameters, using the V4L2 control framework. Best regards, Florian
[PATCH 3/4] add panel register access functions
These functions provide write access to the internal LCD panel registers
which also control the sensor. They can be used to disable the
preprocessor, set the illumination brightness, and adjust gain/contrast
(which are stored together in one register internally called "vsvideo").
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 75 +++
1 file changed, 75 insertions(+)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index 8a5b031..d6fa25e 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -251,6 +251,81 @@ static int sur40_command(struct sur40_state *dev,
0x00, index, buffer, size, 1000);
}
+/* poke a byte in the panel register space */
+static int sur40_poke(struct sur40_state *dev, u8 offset, u8 value)
+{
+ int result;
+ u8 index = 0x96; // 0xae for permanent write
+
+ result = usb_control_msg(dev->usbdev, usb_sndctrlpipe(dev->usbdev, 0),
+ SUR40_POKE, USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+ 0x32, index, NULL, 0, 1000);
+ if (result < 0)
+ goto error;
+ msleep(5);
+
+ result = usb_control_msg(dev->usbdev, usb_sndctrlpipe(dev->usbdev, 0),
+ SUR40_POKE, USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+ 0x72, offset, NULL, 0, 1000);
+ if (result < 0)
+ goto error;
+ msleep(5);
+
+ result = usb_control_msg(dev->usbdev, usb_sndctrlpipe(dev->usbdev, 0),
+ SUR40_POKE, USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+ 0xb2, value, NULL, 0, 1000);
+ if (result < 0)
+ goto error;
+ msleep(5);
+
+error:
+ return result;
+}
+
+static int sur40_set_preprocessor(struct sur40_state *dev, u8 value)
+{
+ u8 setting_07[2] = { 0x01, 0x00 };
+ u8 setting_17[2] = { 0x85, 0x80 };
+ int result;
+
+ if (value > 1)
+ return -ERANGE;
+
+ result = usb_control_msg(dev->usbdev, usb_sndctrlpipe(dev->usbdev, 0),
+ SUR40_POKE, USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+ 0x07, setting_07[value], NULL, 0, 1000);
+ if (result < 0)
+ goto error;
+ msleep(5);
+
+ result = usb_control_msg(dev->usbdev, usb_sndctrlpipe(dev->usbdev, 0),
+ SUR40_POKE, USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+ 0x17, setting_17[value], NULL, 0, 1000);
+ if (result < 0)
+ goto error;
+ msleep(5);
+
+error:
+ return result;
+}
+
+static void sur40_set_vsvideo(struct sur40_state *handle, u8 value)
+{
+ int i;
+
+ for (i = 0; i < 4; i++)
+ sur40_poke(handle, 0x1c+i, value);
+ handle->vsvideo = value;
+}
+
+static void sur40_set_irlevel(struct sur40_state *handle, u8 value)
+{
+ int i;
+
+ for (i = 0; i < 8; i++)
+ sur40_poke(handle, 0x08+(2*i), value);
+}
+
/* Initialization routine, called from sur40_open */
static int sur40_init(struct sur40_state *dev)
{
--
2.7.4
[PATCH 1/4] add missing blob structure field for tag id
The SUR40 can recognize specific printed patterns directly in hardware;
this information (i.e. the pattern id) is present but currently unused
in the blob structure.
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index f16f835..8375b06 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -81,7 +81,10 @@ struct sur40_blob {
__le32 area; /* size in pixels/pressure (?) */
- u8 padding[32];
+ u8 padding[24];
+
+ __le32 tag_id; /* valid when type == 0x04 (SUR40_TAG) */
+ __le32 unknown;
} __packed;
--
2.7.4
[PATCH 2/4] add default settings and module parameters for video controls
This patch adds parameter definitions and module parameters for the four
userspace controls that the SUR40 can currently provide.
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index 8375b06..8a5b031 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -149,6 +149,34 @@ struct sur40_image_header {
#define SUR40_TOUCH0x02
#define SUR40_TAG 0x04
+/* video controls */
+#define SUR40_BRIGHTNESS_MAX 0xFF
+#define SUR40_BRIGHTNESS_MIN 0x00
+#define SUR40_BRIGHTNESS_DEF 0xFF
+
+#define SUR40_CONTRAST_MAX 0x0F
+#define SUR40_CONTRAST_MIN 0x00
+#define SUR40_CONTRAST_DEF 0x0A
+
+#define SUR40_GAIN_MAX 0x09
+#define SUR40_GAIN_MIN 0x00
+#define SUR40_GAIN_DEF 0x08
+
+#define SUR40_BACKLIGHT_MAX 0x01
+#define SUR40_BACKLIGHT_MIN 0x00
+#define SUR40_BACKLIGHT_DEF 0x01
+
+/* module parameters */
+static uint brightness = SUR40_BRIGHTNESS_DEF;
+module_param(brightness, uint, 0644);
+MODULE_PARM_DESC(brightness, "set initial brightness");
+static uint contrast = SUR40_CONTRAST_DEF;
+module_param(contrast, uint, 0644);
+MODULE_PARM_DESC(contrast, "set initial contrast");
+static uint gain = SUR40_GAIN_DEF;
+module_param(gain, uint, 0644);
+MODULE_PARM_DESC(gain, "set initial gain");
+
static const struct v4l2_pix_format sur40_pix_format[] = {
{
.pixelformat = V4L2_TCH_FMT_TU08,
--
2.7.4
[PATCH 4/4] add video control handlers using V4L2 control framework
This patch registers four standard control handlers using the corresponding
V4L2 framework.
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 64 +++
1 file changed, 64 insertions(+)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index d6fa25e..b92325b 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
@@ -209,6 +210,7 @@ struct sur40_state {
struct video_device vdev;
struct mutex lock;
struct v4l2_pix_format pix_fmt;
+ struct v4l2_ctrl_handler ctrls;
struct vb2_queue queue;
struct list_head buf_list;
@@ -218,6 +220,7 @@ struct sur40_state {
struct sur40_data *bulk_in_buffer;
size_t bulk_in_size;
u8 bulk_in_epaddr;
+ u8 vsvideo;
char phys[64];
};
@@ -231,6 +234,11 @@ struct sur40_buffer {
static const struct video_device sur40_video_device;
static const struct vb2_queue sur40_queue;
static void sur40_process_video(struct sur40_state *sur40);
+static int sur40_s_ctrl(struct v4l2_ctrl *ctrl);
+
+static const struct v4l2_ctrl_ops sur40_ctrl_ops = {
+ .s_ctrl = sur40_s_ctrl,
+};
/*
* Note: an earlier, non-public version of this driver used USB_RECIP_ENDPOINT
@@ -737,6 +745,36 @@ static int sur40_probe(struct usb_interface *interface,
sur40->vdev.queue = &sur40->queue;
video_set_drvdata(&sur40->vdev, sur40);
+ /* initialize the control handler for 4 controls */
+ v4l2_ctrl_handler_init(&sur40->ctrls, 4);
+ sur40->v4l2.ctrl_handler = &sur40->ctrls;
+ sur40->vsvideo = (SUR40_CONTRAST_DEF << 4) | SUR40_GAIN_DEF;
+
+ v4l2_ctrl_new_std(&sur40->ctrls, &sur40_ctrl_ops, V4L2_CID_BRIGHTNESS,
+ SUR40_BRIGHTNESS_MIN, SUR40_BRIGHTNESS_MAX, 1, clamp(brightness,
+ (uint)SUR40_BRIGHTNESS_MIN, (uint)SUR40_BRIGHTNESS_MAX));
+
+ v4l2_ctrl_new_std(&sur40->ctrls, &sur40_ctrl_ops, V4L2_CID_CONTRAST,
+ SUR40_CONTRAST_MIN, SUR40_CONTRAST_MAX, 1, clamp(contrast,
+ (uint)SUR40_CONTRAST_MIN, (uint)SUR40_CONTRAST_MAX));
+
+ v4l2_ctrl_new_std(&sur40->ctrls, &sur40_ctrl_ops, V4L2_CID_GAIN,
+ SUR40_GAIN_MIN, SUR40_GAIN_MAX, 1, clamp(gain,
+ (uint)SUR40_GAIN_MIN, (uint)SUR40_GAIN_MAX));
+
+ v4l2_ctrl_new_std(&sur40->ctrls, &sur40_ctrl_ops,
+ V4L2_CID_BACKLIGHT_COMPENSATION, SUR40_BACKLIGHT_MIN,
+ SUR40_BACKLIGHT_MAX, 1, SUR40_BACKLIGHT_DEF);
+
+ v4l2_ctrl_handler_setup(&sur40->ctrls);
+
+ if (sur40->ctrls.error) {
+ dev_err(&interface->dev,
+ "Unable to register video controls.");
+ v4l2_ctrl_handler_free(&sur40->ctrls);
+ goto err_unreg_v4l2;
+ }
+
error = video_register_device(&sur40->vdev, VFL_TYPE_TOUCH, -1);
if (error) {
dev_err(&interface->dev,
@@ -769,6 +807,7 @@ static void sur40_disconnect(struct usb_interface
*interface)
{
struct sur40_state *sur40 = usb_get_intfdata(interface);
+ v4l2_ctrl_handler_free(&sur40->ctrls);
video_unregister_device(&sur40->vdev);
v4l2_device_unregister(&sur40->v4l2);
@@ -962,6 +1001,31 @@ static int sur40_vidioc_g_fmt(struct file *file, void
*priv,
return 0;
}
+static int sur40_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct sur40_state *sur40 = container_of(ctrl->handler,
+ struct sur40_state, ctrls);
+ u8 value = sur40->vsvideo;
+
+ switch (ctrl->id) {
+ case V4L2_CID_BRIGHTNESS:
+ sur40_set_irlevel(sur40, ctrl->val);
+ break;
+ case V4L2_CID_CONTRAST:
+ value = (value & 0x0F) | (ctrl->val << 4);
+ sur40_set_vsvideo(sur40, value);
+ break;
+ case V4L2_CID_GAIN:
+ value = (value & 0xF0) | (ctrl->val);
+ sur40_set_vsvideo(sur40, value);
+ break;
+ case V4L2_CID_BACKLIGHT_COMPENSATION:
+ sur40_set_preprocessor(sur40, ctrl->val);
+ break;
+ }
+ return 0;
+}
+
static int sur40_ioctl_parm(struct file *file, void *priv,
struct v4l2_streamparm *p)
{
--
2.7.4
Re: [PATCH 5/5] add module parameters for default values
On 06.02.2018 22:31, Hans Verkuil wrote: > On 02/06/2018 10:01 PM, Florian Echtler wrote: >> To allow setting custom parameters for the sensor directly at startup, the >> three primary controls are exposed as module parameters in this patch. >> >> +/* module parameters */ >> +static uint brightness = SUR40_BRIGHTNESS_DEF; >> +module_param(brightness, uint, 0644); >> +MODULE_PARM_DESC(brightness, "set default brightness"); >> +static uint contrast = SUR40_CONTRAST_DEF; >> +module_param(contrast, uint, 0644); >> +MODULE_PARM_DESC(contrast, "set default contrast"); >> +static uint gain = SUR40_GAIN_DEF; >> +module_param(gain, uint, 0644); >> +MODULE_PARM_DESC(contrast, "set default gain"); > > contrast -> gain Ah, typo. Thanks, will fix that. > Isn't 'initial gain' better than 'default gain'? Probably correct, yes. > If I load this module with gain=X, will the gain control also > start off at X? I didn't see any code for that. This reminds me: how can I get/set the control from inside the driver? Should I use something like the following: struct v4l2_ctrl *ctrl = v4l2_ctrl_find(&sur40->ctrls, V4L2_CID_BRIGHTNESS); int val = v4l2_ctrl_g_ctrl(ctrl); // modify val... v4l2_ctrl_s_ctrl(ctrl, val); > It might be useful to add the allowed range in the description. > E.g.: "set initial gain, range=0-255". Perhaps mention even the > default value, but I'm not sure if that's really needed. Good point, though - right now the code directly sets the registers without any clamping, I guess it would be better to call the control framework as mentioned above? Best regards, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/5] add missing blob structure field for tag id
On 06.02.2018 22:22, Hans Verkuil wrote: > On 02/06/2018 10:01 PM, Florian Echtler wrote: >> The SUR40 can recognize specific printed patterns directly in hardware; >> this information (i.e. the pattern id) is present but currently unused >> in the blob structure. >> >> >> __le32 area; /* size in pixels/pressure (?) */ >> >> -u8 padding[32]; >> +u8 padding[24]; >> + >> +__le32 tag_id; /* valid when type == 0x04 (SUR40_TAG) */ >> +__le32 unknown; >> >> } __packed; >> > Usually new fields are added before the padding, not after. > > Unless there is a good reason for this I'd change this. This is how the hardware sends it, so there's little choice in how to arrange the fields... Best regards, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
[PATCH 2/5] add control definitions
This patch adds parameter definitions for the four userspace controls that
the SUR40 can currently provide.
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index 8375b06..3af63415 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -149,6 +149,23 @@ struct sur40_image_header {
#define SUR40_TOUCH0x02
#define SUR40_TAG 0x04
+/* video controls */
+#define SUR40_BRIGHTNESS_MAX 0xFF
+#define SUR40_BRIGHTNESS_MIN 0x00
+#define SUR40_BRIGHTNESS_DEF 0xFF
+
+#define SUR40_CONTRAST_MAX 0x0F
+#define SUR40_CONTRAST_MIN 0x00
+#define SUR40_CONTRAST_DEF 0x0A
+
+#define SUR40_GAIN_MAX 0x09
+#define SUR40_GAIN_MIN 0x00
+#define SUR40_GAIN_DEF 0x08
+
+#define SUR40_BACKLIGHT_MAX 0x01
+#define SUR40_BACKLIGHT_MIN 0x00
+#define SUR40_BACKLIGHT_DEF 0x01
+
static const struct v4l2_pix_format sur40_pix_format[] = {
{
.pixelformat = V4L2_TCH_FMT_TU08,
--
2.7.4
[PATCH 4/5] register control handlers using V4L2 control framework
This patch registers four standard control handlers using the corresponding
V4L2 framework.
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 51 +++
1 file changed, 51 insertions(+)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index 7f6461d..66ef7e6 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -38,6 +38,7 @@
#include
#include
#include
+#include
#include
#include
@@ -198,6 +199,7 @@ struct sur40_state {
struct video_device vdev;
struct mutex lock;
struct v4l2_pix_format pix_fmt;
+ struct v4l2_ctrl_handler ctrls;
struct vb2_queue queue;
struct list_head buf_list;
@@ -207,6 +209,7 @@ struct sur40_state {
struct sur40_data *bulk_in_buffer;
size_t bulk_in_size;
u8 bulk_in_epaddr;
+ u8 vsvideo;
char phys[64];
};
@@ -220,6 +223,11 @@ struct sur40_buffer {
static const struct video_device sur40_video_device;
static const struct vb2_queue sur40_queue;
static void sur40_process_video(struct sur40_state *sur40);
+static int sur40_s_ctrl(struct v4l2_ctrl *ctrl);
+
+static const struct v4l2_ctrl_ops sur40_ctrl_ops = {
+ .s_ctrl = sur40_s_ctrl,
+};
/*
* Note: an earlier, non-public version of this driver used USB_RECIP_ENDPOINT
@@ -722,6 +730,23 @@ static int sur40_probe(struct usb_interface *interface,
sur40->vdev.queue = &sur40->queue;
video_set_drvdata(&sur40->vdev, sur40);
+ /* initialize the control handler for 4 controls */
+ v4l2_ctrl_handler_init(&sur40->ctrls, 4);
+ sur40->v4l2.ctrl_handler = &sur40->ctrls;
+
+ v4l2_ctrl_new_std(&sur40->ctrls, &sur40_ctrl_ops, V4L2_CID_BRIGHTNESS,
+ SUR40_BRIGHTNESS_MIN, SUR40_BRIGHTNESS_MAX, 1, SUR40_BRIGHTNESS_DEF);
+
+ v4l2_ctrl_new_std(&sur40->ctrls, &sur40_ctrl_ops, V4L2_CID_CONTRAST,
+ SUR40_CONTRAST_MIN, SUR40_CONTRAST_MAX, 1, SUR40_CONTRAST_DEF);
+
+ v4l2_ctrl_new_std(&sur40->ctrls, &sur40_ctrl_ops, V4L2_CID_GAIN,
+ SUR40_GAIN_MIN, SUR40_GAIN_MAX, 1, SUR40_GAIN_DEF);
+
+ v4l2_ctrl_new_std(&sur40->ctrls, &sur40_ctrl_ops,
+ V4L2_CID_BACKLIGHT_COMPENSATION, SUR40_BACKLIGHT_MIN,
+ SUR40_BACKLIGHT_MAX, 1, SUR40_BACKLIGHT_DEF);
+
error = video_register_device(&sur40->vdev, VFL_TYPE_TOUCH, -1);
if (error) {
dev_err(&interface->dev,
@@ -754,6 +779,7 @@ static void sur40_disconnect(struct usb_interface
*interface)
{
struct sur40_state *sur40 = usb_get_intfdata(interface);
+ v4l2_ctrl_handler_free(&sur40->ctrls);
video_unregister_device(&sur40->vdev);
v4l2_device_unregister(&sur40->v4l2);
@@ -947,6 +973,31 @@ static int sur40_vidioc_g_fmt(struct file *file, void
*priv,
return 0;
}
+static int sur40_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+ struct sur40_state *sur40 = container_of(ctrl->handler,
+ struct sur40_state, ctrls);
+ u8 value = sur40->vsvideo;
+
+ switch (ctrl->id) {
+ case V4L2_CID_BRIGHTNESS:
+ sur40_set_irlevel(sur40, ctrl->val);
+ break;
+ case V4L2_CID_CONTRAST:
+ value = (value & 0x0F) | (ctrl->val << 4);
+ sur40_set_vsvideo(sur40, value);
+ break;
+ case V4L2_CID_GAIN:
+ value = (value & 0xF0) | (ctrl->val);
+ sur40_set_vsvideo(sur40, value);
+ break;
+ case V4L2_CID_BACKLIGHT_COMPENSATION:
+ sur40_set_preprocessor(sur40, ctrl->val);
+ break;
+ }
+ return 0;
+}
+
static int sur40_ioctl_parm(struct file *file, void *priv,
struct v4l2_streamparm *p)
{
--
2.7.4
[PATCH 3/5] add panel register access functions
These functions provide write access to the internal LCD panel registers
which also control the sensor. They can be used to disable the
preprocessor, set the illumination brightness, and adjust gain/contrast
(which are stored together in one register internally called "vsvideo").
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 71 +++
1 file changed, 71 insertions(+)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index 3af63415..7f6461d 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -240,6 +240,81 @@ static int sur40_command(struct sur40_state *dev,
0x00, index, buffer, size, 1000);
}
+/* poke a byte in the panel register space */
+static int sur40_poke(struct sur40_state *dev, u8 offset, u8 value)
+{
+ int result;
+ u8 index = 0x96; // 0xae for permanent write
+
+ result = usb_control_msg(dev->usbdev, usb_sndctrlpipe(dev->usbdev, 0),
+ SUR40_POKE, USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+ 0x32, index, NULL, 0, 1000);
+ if (result < 0)
+ goto error;
+ msleep(5);
+
+ result = usb_control_msg(dev->usbdev, usb_sndctrlpipe(dev->usbdev, 0),
+ SUR40_POKE, USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+ 0x72, offset, NULL, 0, 1000);
+ if (result < 0)
+ goto error;
+ msleep(5);
+
+ result = usb_control_msg(dev->usbdev, usb_sndctrlpipe(dev->usbdev, 0),
+ SUR40_POKE, USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+ 0xb2, value, NULL, 0, 1000);
+ if (result < 0)
+ goto error;
+ msleep(5);
+
+error:
+ return result;
+}
+
+static int sur40_set_preprocessor(struct sur40_state *dev, u8 value)
+{
+ u8 setting_07[2] = { 0x01, 0x00 };
+ u8 setting_17[2] = { 0x85, 0x80 };
+ int result;
+
+ if (value > 1)
+ return -ERANGE;
+
+ result = usb_control_msg(dev->usbdev, usb_sndctrlpipe(dev->usbdev, 0),
+ SUR40_POKE, USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+ 0x07, setting_07[value], NULL, 0, 1000);
+ if (result < 0)
+ goto error;
+ msleep(5);
+
+ result = usb_control_msg(dev->usbdev, usb_sndctrlpipe(dev->usbdev, 0),
+ SUR40_POKE, USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+ 0x17, setting_17[value], NULL, 0, 1000);
+ if (result < 0)
+ goto error;
+ msleep(5);
+
+error:
+ return result;
+}
+
+static void sur40_set_vsvideo(struct sur40_state *handle, u8 value)
+{
+ int i;
+
+ for (i = 0; i < 4; i++)
+ sur40_poke(handle, 0x1c+i, value);
+ handle->vsvideo = value;
+}
+
+static void sur40_set_irlevel(struct sur40_state *handle, u8 value)
+{
+ int i;
+
+ for (i = 0; i < 8; i++)
+ sur40_poke(handle, 0x08+(2*i), value);
+}
+
/* Initialization routine, called from sur40_open */
static int sur40_init(struct sur40_state *dev)
{
--
2.7.4
[PATCH 5/5] add module parameters for default values
To allow setting custom parameters for the sensor directly at startup, the
three primary controls are exposed as module parameters in this patch.
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index 66ef7e6..d1fcb95 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -167,6 +167,17 @@ struct sur40_image_header {
#define SUR40_BACKLIGHT_MIN 0x00
#define SUR40_BACKLIGHT_DEF 0x01
+/* module parameters */
+static uint brightness = SUR40_BRIGHTNESS_DEF;
+module_param(brightness, uint, 0644);
+MODULE_PARM_DESC(brightness, "set default brightness");
+static uint contrast = SUR40_CONTRAST_DEF;
+module_param(contrast, uint, 0644);
+MODULE_PARM_DESC(contrast, "set default contrast");
+static uint gain = SUR40_GAIN_DEF;
+module_param(gain, uint, 0644);
+MODULE_PARM_DESC(contrast, "set default gain");
+
static const struct v4l2_pix_format sur40_pix_format[] = {
{
.pixelformat = V4L2_TCH_FMT_TU08,
@@ -374,6 +385,11 @@ static void sur40_open(struct input_polled_dev *polldev)
dev_dbg(sur40->dev, "open\n");
sur40_init(sur40);
+
+ /* set default values */
+ sur40_set_irlevel(sur40, brightness & 0xFF);
+ sur40_set_vsvideo(sur40, ((contrast & 0x0F) << 4) | (gain & 0x0F));
+ sur40_set_preprocessor(sur40, SUR40_BACKLIGHT_DEF);
}
/* Disable device, polling has stopped. */
--
2.7.4
[PATCH v2] [RFC] add video controls for SUR40 driver
As discussed previously, here's a second iteration of my patch to add control functions for the SUR40 driver, now using the V4L2 control framework.
[PATCH 1/5] add missing blob structure field for tag id
The SUR40 can recognize specific printed patterns directly in hardware;
this information (i.e. the pattern id) is present but currently unused
in the blob structure.
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index f16f835..8375b06 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -81,7 +81,10 @@ struct sur40_blob {
__le32 area; /* size in pixels/pressure (?) */
- u8 padding[32];
+ u8 padding[24];
+
+ __le32 tag_id; /* valid when type == 0x04 (SUR40_TAG) */
+ __le32 unknown;
} __packed;
--
2.7.4
Re: [PATCH 5/5] add default control values as module parameters
On 05.02.2018 15:56, Hans Verkuil wrote: > Please add a change log when you make a patch. > I for one would like to know why this has to be supplied as a module option. The idea here was that each individual SUR40 device will likely have slightly different "ideal" settings for the parameters, and by using the module options, you can set them right away at startup. I'm aware that the usual way to do this would be from userspace using v4l2-ctl, but the SUR40 is sort of a special case: the video settings will also influence the internal touch detection, and in the worst case, starting the driver with the default parameters from flash will immediately cause so many false-positive touch points to be detected that the graphical shell becomes unusable. This has actually happened several times during testing, so we considered a module option to be the easiest way for dealing with this. > Some documentation in the code would be helpful as well (e.g. I have no idea > what a 'vsvideo' is). Right - will do that, too. Best regards, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: [PATCH 4/5] add V4L2 control functions
Hello Hans, On Mon, 5 Feb 2018, Hans Verkuil wrote: On 02/05/2018 03:29 PM, Florian Echtler wrote: + +static int sur40_vidioc_queryctrl(struct file *file, void *fh, + struct v4l2_queryctrl *qc) Sorry, but this is very wrong. Use the control framework instead. See https://hverkuil.home.xs4all.nl/spec/kapi/v4l2-controls.html and pretty much all media drivers (with the exception of uvc). See for example this driver: drivers/media/pci/tw68/tw68-video.c (randomly chosen). It actually makes life a lot easier for you as you don't have to perform any range checks and all control ioctls are automatically supported for you. thanks for the quick reply, I wasn't aware of that framework at all :-) Will certainly use it. What's the earliest kernel version this is supported on, in case we want to backport this for our standalone module, too? Best regards, Florian -- "_Nothing_ brightens up my morning. Coffee simply provides a shade of grey just above the pitch-black of the infinite depths of the _abyss_."
[PATCH 4/5] add V4L2 control functions
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 114 ++
1 file changed, 114 insertions(+)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index 63c7264b..c4b7cf1 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -953,6 +953,119 @@ static int sur40_vidioc_g_fmt(struct file *file, void
*priv,
return 0;
}
+
+static int sur40_vidioc_queryctrl(struct file *file, void *fh,
+ struct v4l2_queryctrl *qc)
+{
+
+ switch (qc->id) {
+ case V4L2_CID_BRIGHTNESS:
+ qc->flags = 0;
+ sprintf(qc->name, "Brightness");
+ qc->type = V4L2_CTRL_TYPE_INTEGER;
+ qc->minimum = SUR40_BRIGHTNESS_MIN;
+ qc->default_value = SUR40_BRIGHTNESS_DEF;
+ qc->maximum = SUR40_BRIGHTNESS_MAX;
+ qc->step = 8;
+ return 0;
+ case V4L2_CID_CONTRAST:
+ qc->flags = 0;
+ sprintf(qc->name, "Contrast");
+ qc->type = V4L2_CTRL_TYPE_INTEGER;
+ qc->minimum = SUR40_CONTRAST_MIN;
+ qc->default_value = SUR40_CONTRAST_DEF;
+ qc->maximum = SUR40_CONTRAST_MAX;
+ qc->step = 1;
+ return 0;
+ case V4L2_CID_GAIN:
+ qc->flags = 0;
+ sprintf(qc->name, "Gain");
+ qc->type = V4L2_CTRL_TYPE_INTEGER;
+ qc->minimum = SUR40_GAIN_MIN;
+ qc->default_value = SUR40_GAIN_DEF;
+ qc->maximum = SUR40_GAIN_MAX;
+ qc->step = 1;
+ return 0;
+ case V4L2_CID_BACKLIGHT_COMPENSATION:
+ qc->flags = 0;
+ sprintf(qc->name, "Preprocessor");
+ qc->type = V4L2_CTRL_TYPE_INTEGER;
+ qc->minimum = SUR40_BACKLIGHT_MIN;
+ qc->default_value = SUR40_BACKLIGHT_DEF;
+ qc->maximum = SUR40_BACKLIGHT_MAX;
+ qc->step = 1;
+ return 0;
+ default:
+ qc->flags = V4L2_CTRL_FLAG_DISABLED;
+ return -EINVAL;
+ }
+}
+
+static int sur40_vidioc_g_ctrl(struct file *file, void *fh,
+ struct v4l2_control *ctrl)
+{
+
+ switch (ctrl->id) {
+ case V4L2_CID_BRIGHTNESS:
+ ctrl->value = sur40_v4l2_brightness;
+ return 0;
+ case V4L2_CID_CONTRAST:
+ ctrl->value = sur40_v4l2_contrast;
+ return 0;
+ case V4L2_CID_GAIN:
+ ctrl->value = sur40_v4l2_gain;
+ return 0;
+ case V4L2_CID_BACKLIGHT_COMPENSATION:
+ ctrl->value = sur40_v4l2_backlight;
+ return 0;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int sur40_vidioc_s_ctrl(struct file *file, void *fh,
+ struct v4l2_control *ctrl)
+{
+ u8 value = 0;
+ struct sur40_state *sur40 = video_drvdata(file);
+
+ switch (ctrl->id) {
+ case V4L2_CID_BRIGHTNESS:
+ sur40_v4l2_brightness = ctrl->value;
+ if (sur40_v4l2_brightness < SUR40_BRIGHTNESS_MIN)
+ sur40_v4l2_brightness = SUR40_BRIGHTNESS_MIN;
+ else if (sur40_v4l2_brightness > SUR40_BRIGHTNESS_MAX)
+ sur40_v4l2_brightness = SUR40_BRIGHTNESS_MAX;
+ sur40_set_irlevel(sur40, sur40_v4l2_brightness);
+ return 0;
+ case V4L2_CID_CONTRAST:
+ sur40_v4l2_contrast = ctrl->value;
+ if (sur40_v4l2_contrast < SUR40_CONTRAST_MIN)
+ sur40_v4l2_contrast = SUR40_CONTRAST_MIN;
+ else if (sur40_v4l2_contrast > SUR40_CONTRAST_MAX)
+ sur40_v4l2_contrast = SUR40_CONTRAST_MAX;
+ value = (sur40_v4l2_contrast << 4) + sur40_v4l2_gain;
+ sur40_set_vsvideo(sur40, value);
+ return 0;
+ case V4L2_CID_GAIN:
+ sur40_v4l2_gain = ctrl->value;
+ if (sur40_v4l2_gain < SUR40_GAIN_MIN)
+ sur40_v4l2_gain = SUR40_GAIN_MIN;
+ else if (sur40_v4l2_gain > SUR40_GAIN_MAX)
+ sur40_v4l2_gain = SUR40_GAIN_MAX;
+ value = (sur40_v4l2_contrast << 4) + sur40_v4l2_gain;
+ sur40_set_vsvideo(sur40, value);
+ return 0;
+ case V4L2_CID_BACKLIGHT_COMPENSATION:
+ sur40_v4l2_backlight = ctrl->value;
+ sur40_set_preprocessor(sur40, sur40_v4l2_backlight);
+ return 0;
+ default:
+ return -EINVAL;
+ }
+}
+
+
static int sur40_ioctl_parm(struct
[PATCH 3/5] add video control register handlers
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 70 +++
1 file changed, 70 insertions(+)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index 0dbb004..63c7264b 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -247,6 +255,80 @@ static int sur40_command(struct sur40_state *dev,
0x00, index, buffer, size, 1000);
}
+/* poke a byte in the panel register space */
+static int sur40_poke(struct sur40_state *dev, u8 offset, u8 value)
+{
+ int result;
+ u8 index = 0x96; // 0xae for permanent write
+
+ result = usb_control_msg(dev->usbdev, usb_sndctrlpipe(dev->usbdev, 0),
+ SUR40_POKE, USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+ 0x32, index, NULL, 0, 1000);
+ if (result < 0)
+ goto error;
+ msleep(5);
+
+ result = usb_control_msg(dev->usbdev, usb_sndctrlpipe(dev->usbdev, 0),
+ SUR40_POKE, USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+ 0x72, offset, NULL, 0, 1000);
+ if (result < 0)
+ goto error;
+ msleep(5);
+
+ result = usb_control_msg(dev->usbdev, usb_sndctrlpipe(dev->usbdev, 0),
+ SUR40_POKE, USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+ 0xb2, value, NULL, 0, 1000);
+ if (result < 0)
+ goto error;
+ msleep(5);
+
+error:
+ return result;
+}
+
+static int sur40_set_preprocessor(struct sur40_state *dev, u8 value)
+{
+ u8 setting_07[2] = { 0x01, 0x00 };
+ u8 setting_17[2] = { 0x85, 0x80 };
+ int result;
+
+ if (value > 1)
+ return -ERANGE;
+
+ result = usb_control_msg(dev->usbdev, usb_sndctrlpipe(dev->usbdev, 0),
+ SUR40_POKE, USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+ 0x07, setting_07[value], NULL, 0, 1000);
+ if (result < 0)
+ goto error;
+ msleep(5);
+
+ result = usb_control_msg(dev->usbdev, usb_sndctrlpipe(dev->usbdev, 0),
+ SUR40_POKE, USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
+ 0x17, setting_17[value], NULL, 0, 1000);
+ if (result < 0)
+ goto error;
+ msleep(5);
+
+error:
+ return result;
+}
+
+static void sur40_set_vsvideo(struct sur40_state *handle, u8 value)
+{
+ int i;
+
+ for (i = 0; i < 4; i++)
+ sur40_poke(handle, 0x1c+i, value);
+}
+
+static void sur40_set_irlevel(struct sur40_state *handle, u8 value)
+{
+ int i;
+
+ for (i = 0; i < 8; i++)
+ sur40_poke(handle, 0x08+(2*i), value);
+}
+
/* Initialization routine, called from sur40_open */
static int sur40_init(struct sur40_state *dev)
{
--
2.7.4
[PATCH 5/5] add default control values as module parameters
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index c4b7cf1..d612f3f 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -173,6 +173,14 @@ int sur40_v4l2_contrast = SUR40_CONTRAST_DEF; /*
blacklevel */
int sur40_v4l2_gain = SUR40_GAIN_DEF; /* gain */
int sur40_v4l2_backlight = 1;/* preprocessor */
+/* module parameters */
+static uint irlevel = SUR40_BRIGHTNESS_DEF;
+module_param(irlevel, uint, 0644);
+MODULE_PARM_DESC(irlevel, "set default irlevel");
+static uint vsvideo = SUR40_VSVIDEO_DEF;
+module_param(vsvideo, uint, 0644);
+MODULE_PARM_DESC(vsvideo, "set default vsvideo");
+
static const struct v4l2_pix_format sur40_pix_format[] = {
{
.pixelformat = V4L2_TCH_FMT_TU08,
@@ -372,6 +380,11 @@ static void sur40_open(struct input_polled_dev *polldev)
dev_dbg(sur40->dev, "open\n");
sur40_init(sur40);
+
+ /* set default values */
+ sur40_set_irlevel(sur40, irlevel);
+ sur40_set_vsvideo(sur40, vsvideo);
+ sur40_set_preprocessor(sur40, SUR40_BACKLIGHT_DEF);
}
/* Disable device, polling has stopped. */
--
2.7.4
[PATCH 0/5] [RFC] add video controls to SUR40 driver
The SUR40 (aka Pixelsense) has internal registers that expose sensor parameters such as brightness, gain etc. This patch creates V4L2 control items and maps them to the appropriate parameters. This is an initial submission for review, comments welcome! Best regards, Florian
[PATCH 1/5] add missing blob structure tag field
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index f16f835..8375b06 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -81,7 +81,10 @@ struct sur40_blob {
__le32 area; /* size in pixels/pressure (?) */
- u8 padding[32];
+ u8 padding[24];
+
+ __le32 tag_id; /* valid when type == 0x04 (SUR40_TAG) */
+ __le32 unknown;
} __packed;
--
2.7.4
[PATCH 2/5] add video control register definitions
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index 8375b06..0dbb004 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -149,6 +149,30 @@ struct sur40_image_header {
#define SUR40_TOUCH0x02
#define SUR40_TAG 0x04
+/* video controls */
+#define SUR40_BRIGHTNESS_MAX 0xFF
+#define SUR40_BRIGHTNESS_MIN 0x00
+#define SUR40_BRIGHTNESS_DEF 0xFF
+
+#define SUR40_CONTRAST_MAX 0x0F
+#define SUR40_CONTRAST_MIN 0x00
+#define SUR40_CONTRAST_DEF 0x0A
+
+#define SUR40_GAIN_MAX 0x09
+#define SUR40_GAIN_MIN 0x00
+#define SUR40_GAIN_DEF 0x08
+
+#define SUR40_VSVIDEO_DEF 0x86
+
+#define SUR40_BACKLIGHT_MAX 0x01
+#define SUR40_BACKLIGHT_MIN 0x00
+#define SUR40_BACKLIGHT_DEF 0x01
+
+int sur40_v4l2_brightness = SUR40_BRIGHTNESS_DEF; /* infrared */
+int sur40_v4l2_contrast = SUR40_CONTRAST_DEF; /* blacklevel */
+int sur40_v4l2_gain = SUR40_GAIN_DEF; /* gain */
+int sur40_v4l2_backlight = 1;/* preprocessor */
+
static const struct v4l2_pix_format sur40_pix_format[] = {
{
.pixelformat = V4L2_TCH_FMT_TU08,
--
2.7.4
Re: Regression on 4.10 with Logitech Quickcam Sphere
Hello again, solved it myself, posting here for the record. Solution is to install uvcdynctrl and running uvcdynctrl -i /usr/share/uvcdynctrl/data/046d/logitech.xml And voila, custom controls back again. Not well documented, but hey. Best regards, Florian On Sun, 1 Oct 2017, Florian Echtler wrote: Hello everyone, I recently upgraded from a 4.4 kernel to 4.10, and found that my Logitech Quickcam Sphere now behaves differently. More specifically, the pan/tilt controls do not work anymore - in fact, they are completely gone from "v4l2-ctl -L". I suspect that https://bugzilla.kernel.org/show_bug.cgi?id=111291#c10 may be related, and the new extension handling causes the pan/tilt controls to disappear. Question now is, how to get them back? Best, Florian -- "_Nothing_ brightens up my morning. Coffee simply provides a shade of grey just above the pitch-black of the infinite depths of the _abyss_."
Regression on 4.10 with Logitech Quickcam Sphere
Hello everyone, I recently upgraded from a 4.4 kernel to 4.10, and found that my Logitech Quickcam Sphere now behaves differently. More specifically, the pan/tilt controls do not work anymore - in fact, they are completely gone from "v4l2-ctl -L". In dmesg, I'm getting these messages: [ 10.129984] uvcvideo: Found UVC 1.00 device (046d:0994) [ 10.162212] uvcvideo 1-5:1.0: Entity type for entity Extension 4 was not initialized! [ 10.162215] uvcvideo 1-5:1.0: Entity type for entity Extension 10 was not initialized! [ 10.162216] uvcvideo 1-5:1.0: Entity type for entity Extension 12 was not initialized! [ 10.162217] uvcvideo 1-5:1.0: Entity type for entity Extension 8 was not initialized! [ 10.162218] uvcvideo 1-5:1.0: Entity type for entity Extension 11 was not initialized! [ 10.162220] uvcvideo 1-5:1.0: Entity type for entity Extension 9 was not initialized! [ 10.162221] uvcvideo 1-5:1.0: Entity type for entity Processing 2 was not initialized! [ 10.16] uvcvideo 1-5:1.0: Entity type for entity Extension 13 was not initialized! [ 10.162223] uvcvideo 1-5:1.0: Entity type for entity Camera 1 was not initialized! [ 10.162360] usbcore: registered new interface driver uvcvideo I suspect that https://bugzilla.kernel.org/show_bug.cgi?id=111291#c10 may be related, and the new extension handling causes the pan/tilt controls to disappear. Question now is, how to get them back? Best, Florian -- "_Nothing_ brightens up my morning. Coffee simply provides a shade of grey just above the pitch-black of the infinite depths of the _abyss_."
[RFC] [sur40] mapping of sensor parameters to V4L2?
Hi everyone, next chapter in the neverending story of reverse-engineering the SUR40: I've identified a couple of internal LCD panel registers which control some aspects of the built-in image sensor. In particular, these are called "Video Voltage", "Video Bias", and "IR Illumination Level". Now, I have two questions: - Video Voltage & Bias seem to affect the sensor gain. Does anyone with extensive background knowledge of image sensors want to venture a guess what the exact relation is? My own interpretation would be that Video Voltage is the actual amplifier gain and Video Bias is the black level... - Is there a sensible mapping of these values to V4L2 controls? Should I pick something from the USER class, or from CAMERA, or FLASH, or ... Thanks & best regards, Florian -- "_Nothing_ brightens up my morning. Coffee simply provides a shade of grey just above the pitch-black of the infinite depths of the _abyss_." -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] sur40: properly report a single frame rate of 60 FPS
On 06.07.2016 10:40, Hans Verkuil wrote: > On 07/05/16 09:06, Hans Verkuil wrote: >> On 07/05/2016 08:56 AM, Florian Echtler wrote: >>> On 05.07.2016 08:41, Hans Verkuil wrote: >>>> >>>> Why is s_parm added when you can't change the framerate? >>> >>> Oh, I thought it's mandatory to always have s_parm if you have g_parm >>> (even if it always returns the same values). >>> >>>> Same questions for the >>>> enum_frameintervals function: it doesn't hurt to have it, but if there is >>>> only >>>> one unchangeable framerate, then it doesn't make much sense. >>> >>> If you don't have enum_frameintervals, how would you find out about the >>> framerate otherwise? Is g_parm itself enough already for all userspace >>> tools? >> >> It should be. The enum_frameintervals function is much newer than g_parm. >> >> Frankly, I have the same problem with enum_framesizes: it reports only one >> size. These two enum ioctls are normally only implemented if there are at >> least two choices. If there is no choice, then G_FMT will return the size >> and G_PARM the framerate and there is no need to enumerate anything. >> >> The problem is that the spec is ambiguous as to the requirements if there >> is only one choice for size and interval. Are the enum ioctls allowed in >> that case? Personally I think there is nothing against that. But should >> S_PARM also be allowed even though it can't actually change the frameperiod? >> >> Don't bother making changes yet, let me think about this for a bit. > > OK, I came to the conclusion that if enum_frameintervals returns one or > more intervals, then s_parm should be present, even if there is only one > possible interval. > > I have updated the compliance utility to check for this. AFAICT, the original patch does meet the requirements, then? Or do you have any change requests? Best, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: [PATCH v2 1/3] sur40: properly report a single frame rate of 60 FPS
Hello Hans,
On 05.07.2016 08:41, Hans Verkuil wrote:
> On 05/31/2016 10:15 PM, Florian Echtler wrote:
>> The device hardware is always running at 60 FPS, so report this both via
>> PARM_IOCTL and ENUM_FRAMEINTERVALS.
>>
>> Signed-off-by: Martin Kaltenbrunner
>> Signed-off-by: Florian Echtler
>> ---
>> drivers/input/touchscreen/sur40.c | 20 ++--
>> 1 file changed, 18 insertions(+), 2 deletions(-)
>>
>> @@ -880,6 +893,9 @@ static const struct v4l2_ioctl_ops sur40_video_ioctl_ops
>> = {
>> .vidioc_enum_framesizes = sur40_vidioc_enum_framesizes,
>> .vidioc_enum_frameintervals = sur40_vidioc_enum_frameintervals,
>>
>> +.vidioc_g_parm = sur40_ioctl_parm,
>> +.vidioc_s_parm = sur40_ioctl_parm,
>
> Why is s_parm added when you can't change the framerate?
Oh, I thought it's mandatory to always have s_parm if you have g_parm
(even if it always returns the same values).
> Same questions for the
> enum_frameintervals function: it doesn't hurt to have it, but if there is only
> one unchangeable framerate, then it doesn't make much sense.
If you don't have enum_frameintervals, how would you find out about the
framerate otherwise? Is g_parm itself enough already for all userspace
tools?
> Sorry, missed this when I reviewed this the first time around.
No problem.
Best, Florian
--
SENT FROM MY DEC VT50 TERMINAL
signature.asc
Description: OpenPGP digital signature
Re: [GIT PULL FOR v4.8] Various fixes/improvements
Hello Hans, On 01.07.2016 16:45, Hans Verkuil wrote: > Florian Echtler (3): > sur40: properly report a single frame rate of 60 FPS > sur40: lower poll interval to fix occasional FPS drops to ~56 FPS > sur40: fix occasional oopses on device close Thanks for merging this, AFAICS these fixes will now be part of 4.8. We were hoping they might also be picked for the 4.4 LTS kernel, will this be decided by Greg KH or will it happen automatically? Best, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: [PATCH v6 11/11] Input: sur40 - use new V4L2 touch input type
On 30.06.2016 19:38, Nick Dyer wrote:
> Support both V4L2_TCH_FMT_TU08 and V4L2_PIX_FMT_GREY for backwards
> compatibility.
>
> Note: I have not tested these changes (I have no access to the hardware)
> so not signing off.
I will try to test this ASAP. However, I'm currently ill, so it might
take a while - sorry.
Best, Florian
> ---
> drivers/input/touchscreen/sur40.c | 121
> +++---
> 1 file changed, 88 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/input/touchscreen/sur40.c
> b/drivers/input/touchscreen/sur40.c
> index 880c40b..9ba68cf 100644
> --- a/drivers/input/touchscreen/sur40.c
> +++ b/drivers/input/touchscreen/sur40.c
> @@ -139,6 +139,27 @@ struct sur40_image_header {
> #define SUR40_GET_STATE 0xc5 /* 4 bytes state (?) */
> #define SUR40_GET_SENSORS 0xb1 /* 8 bytes sensors */
>
> +static const struct v4l2_pix_format sur40_pix_format[] = {
> + {
> + .pixelformat = V4L2_TCH_FMT_TU08,
> + .width = SENSOR_RES_X / 2,
> + .height = SENSOR_RES_Y / 2,
> + .field = V4L2_FIELD_NONE,
> + .colorspace = V4L2_COLORSPACE_SRGB,
> + .bytesperline = SENSOR_RES_X / 2,
> + .sizeimage = (SENSOR_RES_X/2) * (SENSOR_RES_Y/2),
> + },
> + {
> + .pixelformat = V4L2_PIX_FMT_GREY,
> + .width = SENSOR_RES_X / 2,
> + .height = SENSOR_RES_Y / 2,
> + .field = V4L2_FIELD_NONE,
> + .colorspace = V4L2_COLORSPACE_SRGB,
> + .bytesperline = SENSOR_RES_X / 2,
> + .sizeimage = (SENSOR_RES_X/2) * (SENSOR_RES_Y/2),
> + }
> +};
> +
> /* master device state */
> struct sur40_state {
>
> @@ -149,6 +170,7 @@ struct sur40_state {
> struct v4l2_device v4l2;
> struct video_device vdev;
> struct mutex lock;
> + struct v4l2_pix_format pix_fmt;
>
> struct vb2_queue queue;
> struct vb2_alloc_ctx *alloc_ctx;
> @@ -170,7 +192,6 @@ struct sur40_buffer {
>
> /* forward declarations */
> static const struct video_device sur40_video_device;
> -static const struct v4l2_pix_format sur40_video_format;
> static const struct vb2_queue sur40_queue;
> static void sur40_process_video(struct sur40_state *sur40);
>
> @@ -421,7 +442,7 @@ static void sur40_process_video(struct sur40_state *sur40)
> goto err_poll;
> }
>
> - if (le32_to_cpu(img->size) != sur40_video_format.sizeimage) {
> + if (le32_to_cpu(img->size) != sur40->pix_fmt.sizeimage) {
> dev_err(sur40->dev, "image size mismatch\n");
> goto err_poll;
> }
> @@ -432,7 +453,7 @@ static void sur40_process_video(struct sur40_state *sur40)
>
> result = usb_sg_init(&sgr, sur40->usbdev,
> usb_rcvbulkpipe(sur40->usbdev, VIDEO_ENDPOINT), 0,
> - sgt->sgl, sgt->nents, sur40_video_format.sizeimage, 0);
> + sgt->sgl, sgt->nents, sur40->pix_fmt.sizeimage, 0);
> if (result < 0) {
> dev_err(sur40->dev, "error %d in usb_sg_init\n", result);
> goto err_poll;
> @@ -593,13 +614,14 @@ static int sur40_probe(struct usb_interface *interface,
> goto err_unreg_v4l2;
> }
>
> + sur40->pix_fmt = sur40_pix_format[0];
> sur40->vdev = sur40_video_device;
> sur40->vdev.v4l2_dev = &sur40->v4l2;
> sur40->vdev.lock = &sur40->lock;
> sur40->vdev.queue = &sur40->queue;
> video_set_drvdata(&sur40->vdev, sur40);
>
> - error = video_register_device(&sur40->vdev, VFL_TYPE_GRABBER, -1);
> + error = video_register_device(&sur40->vdev, VFL_TYPE_TOUCH, -1);
> if (error) {
> dev_err(&interface->dev,
> "Unable to register video subdevice.");
> @@ -662,10 +684,10 @@ static int sur40_queue_setup(struct vb2_queue *q,
> alloc_ctxs[0] = sur40->alloc_ctx;
>
> if (*nplanes)
> - return sizes[0] < sur40_video_format.sizeimage ? -EINVAL : 0;
> + return sizes[0] < sur40->pix_fmt.sizeimage ? -EINVAL : 0;
>
> *nplanes = 1;
> - sizes[0] = sur40_video_format.sizeimage;
> + sizes[0] = sur40->pix_fmt.sizeimage;
>
> return 0;
> }
> @@ -677,7 +699,7 @@ static int sur40_queue_setup(struct vb2_queue *q,
> static int sur40_buffer_prepare(struct vb2_buffer *vb)
> {
> struct sur40_state *sur40 = vb2_get_drv_priv(vb->vb2_queue);
> - unsigned long size = sur40_video_format.sizeimage;
> + unsigned long size = sur40->pix_fmt.sizeimage;
>
> if (vb2_plane_size(vb, 0) < size) {
> dev_err(&sur40->usbdev->dev, "buffer too small (%lu < %lu)\n",
> @@ -751,7 +773,7 @@ static int sur40_vidioc_querycap(struct file *file, void
> *priv,
> strlcpy(cap->driver, DRIVER_SHORT, sizeof(cap->driver));
> strlcpy(cap->card, DRIVER_LONG, sizeof(cap->card));
> usb_make_path(sur40->usbdev, cap->bus_info, sizeof(cap->bus_info));
> - cap->device_caps = V
Re: [PATCH v5 9/9] Input: sur40 - use new V4L2 touch input type
On 23.06.2016 00:08, Nick Dyer wrote:
> diff --git a/drivers/input/touchscreen/sur40.c
> b/drivers/input/touchscreen/sur40.c
> index 880c40b..841e045 100644
> --- a/drivers/input/touchscreen/sur40.c
> +++ b/drivers/input/touchscreen/sur40.c
> @@ -599,7 +599,7 @@ static int sur40_probe(struct usb_interface *interface,
> sur40->vdev.queue = &sur40->queue;
> video_set_drvdata(&sur40->vdev, sur40);
>
> - error = video_register_device(&sur40->vdev, VFL_TYPE_GRABBER, -1);
> + error = video_register_device(&sur40->vdev, VFL_TYPE_TOUCH, -1);
> if (error) {
> dev_err(&interface->dev,
> "Unable to register video subdevice.");
As far as I could tell from looking at patch 1/9, the only visible
change for userspace will be the device name, so I'd be fine with this.
> @@ -794,7 +794,7 @@ static int sur40_vidioc_enum_fmt(struct file *file, void
> *priv,
> if (f->index != 0)
> return -EINVAL;
> strlcpy(f->description, "8-bit greyscale", sizeof(f->description));
> - f->pixelformat = V4L2_PIX_FMT_GREY;
> + f->pixelformat = V4L2_TCH_FMT_TU08;
I would suggest to leave the pixel format as it is. Rationale: the data
really is greyscale image intensity data (as also evidenced by [1]), not
just a synthetic image, and changing the pixel format would break all
userspace tools.
[1] https://github.com/mkalten/reacTIVision/issues/3#issuecomment-99931807
Best, Florian
--
SENT FROM MY DEC VT50 TERMINAL
signature.asc
Description: OpenPGP digital signature
Re: [PATCH v4 2/9] [media] v4l2-core: Add VFL_TYPE_TOUCH_SENSOR
On Wed, 22 Jun 2016, Nick Dyer wrote: On 22/06/2016 12:48, Florian Echtler wrote: On 20.06.2016 14:00, Hans Verkuil wrote: On 06/17/2016 04:16 PM, Nick Dyer wrote: Use a new device prefix v4l-touch for these devices, to stop generic capture software from treating them as webcams. Come to think of it, wouldn't it make sense to expose the other touch devices as generic frame grabbers, too, so you can easily view the debug output with any generic tool like cheese? While I like the idea of being able to use the generic tools, I think we needed to do something to stop these devices turning up in e.g. video conferencing software - it would cause a lot of confusion. There's nothing stopping particular tools adding the necessary code to handle touch devices if they feel their users want it. Just to clarify: from the userspace point-of-view, would this change simply modify the prefix of the device node (i.e. /dev/video1 -> /dev/v4l-touch1), or would it somehow affect the API? If it's just the device node name, then that shouldn't be a problem after all, because e.g. reacTIVision requires you to specify the exact camera to be used anyway. Florian -- "_Nothing_ brightens up my morning. Coffee simply provides a shade of grey just above the pitch-black of the infinite depths of the _abyss_." -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 2/9] [media] v4l2-core: Add VFL_TYPE_TOUCH_SENSOR
On 20.06.2016 14:00, Hans Verkuil wrote: > On 06/17/2016 04:16 PM, Nick Dyer wrote: >> Some touch controllers send out raw touch data in a similar way to a >> greyscale frame grabber. Add a new device type for these devices. >> >> Use a new device prefix v4l-touch for these devices, to stop generic >> capture software from treating them as webcams. >> >> Signed-off-by: Nick Dyer >> --- >> drivers/input/touchscreen/sur40.c| 4 ++-- >> drivers/media/v4l2-core/v4l2-dev.c | 13 ++--- >> drivers/media/v4l2-core/v4l2-ioctl.c | 15 ++- >> include/media/v4l2-dev.h | 3 ++- >> include/uapi/linux/videodev2.h | 1 + Generally a good idea in my opinion, but I think the SUR40 is a special case: the whole point of putting in a V4L2 driver was that software like reacTIVision, which already has a V4L2 interface, can then use that device like any other camera. Come to think of it, wouldn't it make sense to expose the other touch devices as generic frame grabbers, too, so you can easily view the debug output with any generic tool like cheese? Best, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
sur40: DMA-SG and performance question
Hello everyone, I've been doing some latency testing on my sur40 driver, and I've measured over 160 ms of round-trip delay (with an external high-speed camera, delay between lighting up an LED and seeing the on-screen response in the video stream). I'm aware that this value has to factor in screen refresh rates etc., but it still seems to me that at least 100 ms have to be accounted for purely by image acquisition and delivery. My question now is: can any of this latency be caused by my usage of DMA-SG (see [1] ff.), or is this a zero-copy operation, i.e. the data is delivered directly to the V4L2 buffer from the USB host controller? Thanks & best regards, Florian [1] https://git.kernel.org/cgit/linux/kernel/git/mchehab/linux-media.git/tree/drivers/input/touchscreen/sur40.c#n431 -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
[PATCH v2 3/3] sur40: fix occasional oopses on device close
Closing the V4L2 device sometimes triggers a kernel oops.
Present patch fixes this.
Signed-off-by: Martin Kaltenbrunner
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index 64e588c..85dedc1 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -448,7 +448,7 @@ static void sur40_process_video(struct sur40_state *sur40)
/* return error if streaming was stopped in the meantime */
if (sur40->sequence == -1)
- goto err_poll;
+ return;
/* mark as finished */
new_buf->vb.vb2_buf.timestamp = ktime_get_ns();
@@ -736,6 +736,7 @@ static int sur40_start_streaming(struct vb2_queue *vq,
unsigned int count)
static void sur40_stop_streaming(struct vb2_queue *vq)
{
struct sur40_state *sur40 = vb2_get_drv_priv(vq);
+ vb2_wait_for_all_buffers(vq);
sur40->sequence = -1;
/* Release all active buffers */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/3] sur40: properly report a single frame rate of 60 FPS
The device hardware is always running at 60 FPS, so report this both via
PARM_IOCTL and ENUM_FRAMEINTERVALS.
Signed-off-by: Martin Kaltenbrunner
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index 880c40b..4b1f703 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -788,6 +788,19 @@ static int sur40_vidioc_fmt(struct file *file, void *priv,
return 0;
}
+static int sur40_ioctl_parm(struct file *file, void *priv,
+ struct v4l2_streamparm *p)
+{
+ if (p->type != V4L2_BUF_TYPE_VIDEO_CAPTURE)
+ return -EINVAL;
+
+ p->parm.capture.capability = V4L2_CAP_TIMEPERFRAME;
+ p->parm.capture.timeperframe.numerator = 1;
+ p->parm.capture.timeperframe.denominator = 60;
+ p->parm.capture.readbuffers = 3;
+ return 0;
+}
+
static int sur40_vidioc_enum_fmt(struct file *file, void *priv,
struct v4l2_fmtdesc *f)
{
@@ -814,13 +827,13 @@ static int sur40_vidioc_enum_framesizes(struct file
*file, void *priv,
static int sur40_vidioc_enum_frameintervals(struct file *file, void *priv,
struct v4l2_frmivalenum *f)
{
- if ((f->index > 1) || (f->pixel_format != V4L2_PIX_FMT_GREY)
+ if ((f->index > 0) || (f->pixel_format != V4L2_PIX_FMT_GREY)
|| (f->width != sur40_video_format.width)
|| (f->height != sur40_video_format.height))
return -EINVAL;
f->type = V4L2_FRMIVAL_TYPE_DISCRETE;
- f->discrete.denominator = 60/(f->index+1);
+ f->discrete.denominator = 60;
f->discrete.numerator = 1;
return 0;
}
@@ -880,6 +893,9 @@ static const struct v4l2_ioctl_ops sur40_video_ioctl_ops = {
.vidioc_enum_framesizes = sur40_vidioc_enum_framesizes,
.vidioc_enum_frameintervals = sur40_vidioc_enum_frameintervals,
+ .vidioc_g_parm = sur40_ioctl_parm,
+ .vidioc_s_parm = sur40_ioctl_parm,
+
.vidioc_enum_input = sur40_vidioc_enum_input,
.vidioc_g_input = sur40_vidioc_g_input,
.vidioc_s_input = sur40_vidioc_s_input,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/3] sur40: lower poll interval to fix occasional FPS drops to ~56 FPS
The framerate sometimes drops below 60 Hz if the poll interval is too high.
Lowering it to the minimum of 1 ms fixes this.
Signed-off-by: Martin Kaltenbrunner
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index 4b1f703..64e588c 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -126,7 +126,7 @@ struct sur40_image_header {
#define VIDEO_PACKET_SIZE 16384
/* polling interval (ms) */
-#define POLL_INTERVAL 4
+#define POLL_INTERVAL 1
/* maximum number of contacts FIXME: this is a guess? */
#define MAX_CONTACTS 64
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] properly report a single frame rate of 60 FPS
Hello Hans,
On 23.05.2016 12:45, Hans Verkuil wrote:
>> +static int sur40_ioctl_parm(struct file *file, void *priv,
>> +struct v4l2_streamparm *p)
>> +{
>> +if (p->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
>> +p->parm.capture.timeperframe.numerator = 1;
>> +p->parm.capture.timeperframe.denominator = 60;
>> +}
>
> It should return -EINVAL if it is not of type VIDEO_CAPTURE. You should also
> set the
> V4L2_CAP_TIMEPERFRAME capability for this to work. The readbuffers field
> should also
> be set (typically to the minimum required number of buffers).
One question: should this be the same number of buffers as reported in
sur40_queue_setup (i.e. 3)? And is this still relevant with the pending
changes to alloc_ctx?
> Please check with v4l2-compliance! It would have warned about these issues.
Sorry for the noise (again ;-)
Best, Florian
--
SENT FROM MY DEC VT50 TERMINAL
signature.asc
Description: OpenPGP digital signature
[PATCH 1/3] properly report a single frame rate of 60 FPS
The device hardware is always running at 60 FPS, so report this both via
PARM_IOCTL and ENUM_FRAMEINTERVALS.
Signed-off-by: Martin Kaltenbrunner
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index 880c40b..fcc5934 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -788,6 +788,16 @@ static int sur40_vidioc_fmt(struct file *file, void *priv,
return 0;
}
+static int sur40_ioctl_parm(struct file *file, void *priv,
+ struct v4l2_streamparm *p)
+{
+ if (p->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
+ p->parm.capture.timeperframe.numerator = 1;
+ p->parm.capture.timeperframe.denominator = 60;
+ }
+ return 0;
+}
+
static int sur40_vidioc_enum_fmt(struct file *file, void *priv,
struct v4l2_fmtdesc *f)
{
@@ -814,13 +824,13 @@ static int sur40_vidioc_enum_framesizes(struct file
*file, void *priv,
static int sur40_vidioc_enum_frameintervals(struct file *file, void *priv,
struct v4l2_frmivalenum *f)
{
- if ((f->index > 1) || (f->pixel_format != V4L2_PIX_FMT_GREY)
+ if ((f->index > 0) || (f->pixel_format != V4L2_PIX_FMT_GREY)
|| (f->width != sur40_video_format.width)
|| (f->height != sur40_video_format.height))
return -EINVAL;
f->type = V4L2_FRMIVAL_TYPE_DISCRETE;
- f->discrete.denominator = 60/(f->index+1);
+ f->discrete.denominator = 60;
f->discrete.numerator = 1;
return 0;
}
@@ -880,6 +890,9 @@ static const struct v4l2_ioctl_ops sur40_video_ioctl_ops = {
.vidioc_enum_framesizes = sur40_vidioc_enum_framesizes,
.vidioc_enum_frameintervals = sur40_vidioc_enum_frameintervals,
+ .vidioc_g_parm = sur40_ioctl_parm,
+ .vidioc_s_parm = sur40_ioctl_parm,
+
.vidioc_enum_input = sur40_vidioc_enum_input,
.vidioc_g_input = sur40_vidioc_g_input,
.vidioc_s_input = sur40_vidioc_s_input,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] fix occasional oopses on device close
Closing the V4L2 device sometimes triggers a kernel oops.
Present patch fixes this.
Signed-off-by: Martin Kaltenbrunner
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index 7b1052a1..38ebb24 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -448,7 +448,7 @@ static void sur40_process_video(struct sur40_state *sur40)
/* return error if streaming was stopped in the meantime */
if (sur40->sequence == -1)
- goto err_poll;
+ return;
/* mark as finished */
new_buf->vb.vb2_buf.timestamp = ktime_get_ns();
@@ -736,6 +736,7 @@ static int sur40_start_streaming(struct vb2_queue *vq,
unsigned int count)
static void sur40_stop_streaming(struct vb2_queue *vq)
{
struct sur40_state *sur40 = vb2_get_drv_priv(vq);
+ vb2_wait_for_all_buffers(vq);
sur40->sequence = -1;
/* Release all active buffers */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] lower poll interval to fix occasional FPS drops to ~56 FPS
The framerate sometimes drops below 60 Hz if the poll interval is too high.
Lowering it to the minimum of 1 ms fixes this.
Signed-off-by: Martin Kaltenbrunner
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index fcc5934..7b1052a1 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -126,7 +126,7 @@ struct sur40_image_header {
#define VIDEO_PACKET_SIZE 16384
/* polling interval (ms) */
-#define POLL_INTERVAL 4
+#define POLL_INTERVAL 1
/* maximum number of contacts FIXME: this is a guess? */
#define MAX_CONTACTS 64
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sur40.c:undefined reference to `video_unregister_device'
I do still plan to fix this, but I have no idea right now how this can actually happen: if TOUCHSCREEN_SUR40 is enabled, then this will enable VIDEOBUF2_DMA_SG, and that will select most of the other V4L2 modules in turn - or am I missing something here? Best, Florian1 On 04.07.2015 19:56, kbuild test robot wrote: > Hi Florian, > > FYI, the error/warning still remains. You may either fix it or ask me to > silently ignore in future. > > tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > master > head: 14a6f1989dae9445d4532941bdd6bbad84f4c8da > commit: e831cd251fb91d6c25352d322743db0d17ea11dd [media] add raw video stream > support for Samsung SUR40 > date: 3 months ago > config: i386-randconfig-x006-201527 (attached as .config) > reproduce: > git checkout e831cd251fb91d6c25352d322743db0d17ea11dd > # save the attached .config to linux build tree > make ARCH=i386 > > All error/warnings (new ones prefixed by >>): > >drivers/built-in.o: In function `sur40_disconnect': >>> sur40.c:(.text+0x2ba09b): undefined reference to `video_unregister_device' >>> sur40.c:(.text+0x2ba0a3): undefined reference to `v4l2_device_unregister' >>> sur40.c:(.text+0x2ba0ae): undefined reference to `vb2_dma_sg_cleanup_ctx' >drivers/built-in.o: In function `sur40_stop_streaming': >>> sur40.c:(.text+0x2ba4bc): undefined reference to `vb2_buffer_done' >drivers/built-in.o: In function `sur40_probe': >>> sur40.c:(.text+0x2ba84a): undefined reference to `v4l2_device_register' >>> sur40.c:(.text+0x2ba8bd): undefined reference to `vb2_dma_sg_memops' >>> sur40.c:(.text+0x2ba8e9): undefined reference to `vb2_queue_init' >>> sur40.c:(.text+0x2ba912): undefined reference to `vb2_dma_sg_init_ctx' >>> sur40.c:(.text+0x2ba9a4): undefined reference to >>> `video_device_release_empty' >>> sur40.c:(.text+0x2ba9da): undefined reference to `__video_register_device' >sur40.c:(.text+0x2baa0d): undefined reference to `video_unregister_device' >sur40.c:(.text+0x2baa71): undefined reference to `v4l2_device_unregister' >drivers/built-in.o: In function `sur40_process_video': >>> sur40.c:(.text+0x2bac03): undefined reference to `vb2_plane_cookie' >>> sur40.c:(.text+0x2bac94): undefined reference to `v4l2_get_timestamp' >sur40.c:(.text+0x2baccd): undefined reference to `vb2_buffer_done' >drivers/built-in.o: In function `sur40_vidioc_querycap': >>> sur40.c:(.text+0x2bacf7): undefined reference to `video_devdata' >>> drivers/built-in.o:(.rodata+0x6d140): undefined reference to >>> `vb2_ioctl_reqbufs' >>> drivers/built-in.o:(.rodata+0x6d144): undefined reference to >>> `vb2_ioctl_querybuf' >>> drivers/built-in.o:(.rodata+0x6d148): undefined reference to >>> `vb2_ioctl_qbuf' >>> drivers/built-in.o:(.rodata+0x6d14c): undefined reference to >>> `vb2_ioctl_expbuf' >>> drivers/built-in.o:(.rodata+0x6d150): undefined reference to >>> `vb2_ioctl_dqbuf' >>> drivers/built-in.o:(.rodata+0x6d154): undefined reference to >>> `vb2_ioctl_create_bufs' >>> drivers/built-in.o:(.rodata+0x6d168): undefined reference to >>> `vb2_ioctl_streamon' > > --- > 0-DAY kernel test infrastructureOpen Source Technology Center > https://lists.01.org/pipermail/kbuild-all Intel Corporation > -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
[PATCHv2 4/4] return BUF_STATE_ERROR if streaming stopped during acquisition
When stop_streaming is called while a frame is currently being retrieved, the
buffer being filled will still be returned with BUF_STATE_DONE. By resetting
the sequence number and checking before returning the buffer, it can now
correctly be returned with BUF_STATE_ERROR.
Signed-off-by: Martin Kaltenbrunner
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index 8add986..8be7b9b 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -438,6 +438,10 @@ static void sur40_process_video(struct sur40_state *sur40)
dev_dbg(sur40->dev, "image acquired\n");
+ /* return error if streaming was stopped in the meantime */
+ if (sur40->sequence == -1)
+ goto err_poll;
+
/* mark as finished */
v4l2_get_timestamp(&new_buf->vb.v4l2_buf.timestamp);
new_buf->vb.v4l2_buf.sequence = sur40->sequence++;
@@ -723,6 +727,7 @@ static int sur40_start_streaming(struct vb2_queue *vq,
unsigned int count)
static void sur40_stop_streaming(struct vb2_queue *vq)
{
struct sur40_state *sur40 = vb2_get_drv_priv(vq);
+ sur40->sequence = -1;
/* Release all active buffers */
return_all_buffers(sur40, VB2_BUF_STATE_ERROR);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 2/4] add frame size/frame rate query functions
Add missing functions to query the single fixed frame size (960x540) and
supported frame rates. Technically, the SUR40 supports any arbitrary frame
rate up to 60 FPS, as it is polled and not interrupt-driven. For now, we
just report 30 and 60 FPS, which is sufficient to make most V4L2 tools work.
Signed-off-by: Martin Kaltenbrunner
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index e707b8d..d860d05 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -778,6 +778,33 @@ static int sur40_vidioc_enum_fmt(struct file *file, void
*priv,
return 0;
}
+static int sur40_vidioc_enum_framesizes(struct file *file, void *priv,
+ struct v4l2_frmsizeenum *f)
+{
+ if ((f->index != 0) || (f->pixel_format != V4L2_PIX_FMT_GREY))
+ return -EINVAL;
+
+ f->type = V4L2_FRMSIZE_TYPE_DISCRETE;
+ f->discrete.width = sur40_video_format.width;
+ f->discrete.height = sur40_video_format.height;
+ return 0;
+}
+
+static int sur40_vidioc_enum_frameintervals(struct file *file, void *priv,
+ struct v4l2_frmivalenum *f)
+{
+ if ((f->index > 1) || (f->pixel_format != V4L2_PIX_FMT_GREY)
+ || (f->width != sur40_video_format.width)
+ || (f->height != sur40_video_format.height))
+ return -EINVAL;
+
+ f->type = V4L2_FRMIVAL_TYPE_DISCRETE;
+ f->discrete.denominator = 60/(f->index+1);
+ f->discrete.numerator = 1;
+ return 0;
+}
+
+
static const struct usb_device_id sur40_table[] = {
{ USB_DEVICE(ID_MICROSOFT, ID_SUR40) }, /* Samsung SUR40 */
{ } /* terminating null entry */
@@ -829,6 +856,9 @@ static const struct v4l2_ioctl_ops sur40_video_ioctl_ops = {
.vidioc_s_fmt_vid_cap = sur40_vidioc_fmt,
.vidioc_g_fmt_vid_cap = sur40_vidioc_fmt,
+ .vidioc_enum_framesizes = sur40_vidioc_enum_framesizes,
+ .vidioc_enum_frameintervals = sur40_vidioc_enum_frameintervals,
+
.vidioc_enum_input = sur40_vidioc_enum_input,
.vidioc_g_input = sur40_vidioc_g_input,
.vidioc_s_input = sur40_vidioc_s_input,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 3/4] add extra debug output, remove noisy warning
Add dev_dbg statements for easier future debugging; also change the warning about packet ID mismatches to debug output to avoid flooding the logs. This warning is only important in a very specific/rare use case when trying to correlate input events with video data. Signed-off-by: Martin Kaltenbrunner Signed-off-by: Florian Echtler --- drivers/input/touchscreen/sur40.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/input/touchscreen/sur40.c b/drivers/input/touchscreen/sur40.c index d860d05..8add986 100644 --- a/drivers/input/touchscreen/sur40.c +++ b/drivers/input/touchscreen/sur40.c @@ -342,7 +342,7 @@ static void sur40_poll(struct input_polled_dev *polldev) * instead of at the end. */ if (packet_id != header->packet_id) - dev_warn(sur40->dev, "packet ID mismatch\n"); + dev_dbg(sur40->dev, "packet ID mismatch\n"); packet_blobs = result / sizeof(struct sur40_blob); dev_dbg(sur40->dev, "received %d blobs\n", packet_blobs); @@ -389,6 +389,8 @@ static void sur40_process_video(struct sur40_state *sur40) list_del(&new_buf->list); spin_unlock(&sur40->qlock); + dev_dbg(sur40->dev, "buffer acquired\n"); + /* retrieve data via bulk read */ result = usb_bulk_msg(sur40->usbdev, usb_rcvbulkpipe(sur40->usbdev, VIDEO_ENDPOINT), @@ -416,6 +418,8 @@ static void sur40_process_video(struct sur40_state *sur40) goto err_poll; } + dev_dbg(sur40->dev, "header acquired\n"); + sgt = vb2_dma_sg_plane_desc(&new_buf->vb, 0); result = usb_sg_init(&sgr, sur40->usbdev, @@ -432,11 +436,14 @@ static void sur40_process_video(struct sur40_state *sur40) goto err_poll; } + dev_dbg(sur40->dev, "image acquired\n"); + /* mark as finished */ v4l2_get_timestamp(&new_buf->vb.v4l2_buf.timestamp); new_buf->vb.v4l2_buf.sequence = sur40->sequence++; new_buf->vb.v4l2_buf.field = V4L2_FIELD_NONE; vb2_buffer_done(&new_buf->vb, VB2_BUF_STATE_DONE); + dev_dbg(sur40->dev, "buffer marked done\n"); return; err_poll: -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 1/4] reduce poll interval to allow full 60 FPS framerate
The SUR40 hardware can deliver images at up to 60 FPS; at full USB2 bandwidth,
one raw frame will take about 11 ms to transmit. If the poll interval is above
5 ms, fully handling one frame will take longer than 16 ms and the overall
frame rate will drop below 60 FPS. To get the full frame rate without blocking
all the time and still allowing for a bit of timing jitter, we reduce the poll
interval to 4 ms.
Signed-off-by: Martin Kaltenbrunner
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index a24eba5..e707b8d 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -125,7 +125,7 @@ struct sur40_image_header {
#define VIDEO_PACKET_SIZE 16384
/* polling interval (ms) */
-#define POLL_INTERVAL 10
+#define POLL_INTERVAL 4
/* maximum number of contacts FIXME: this is a guess? */
#define MAX_CONTACTS 64
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 0/4] [sur40] minor fixes & performance improvements
This patch series adds several small fixes, features & performance improvements. Many thanks to Martin Kaltenbrunner for testing the original driver & submitting the patches. Martin Kaltenbrunner (4): reduce poll interval to allow full 60 FPS framerate add frame size/frame rate query functions add extra debug output, remove noisy warning return BUF_STATE_ERROR if streaming stopped during acquisition drivers/input/touchscreen/sur40.c | 46 +-- 1 file changed, 44 insertions(+), 2 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] [sur40] minor fixes & performance improvements
On 25.05.2015 13:22, Hans Verkuil wrote: > On 05/21/2015 02:29 PM, Florian Echtler wrote: >> This patch series adds several small fixes, features & performance >> improvements. Many thanks to Martin Kaltenbrunner for testing the >> original driver & submitting the patches. > > The patches look good, but can you repost with better commit logs (i.e. not > just a subject line). Maintainers have become picky about that and without > logs > Mauro most likely will not accept it. Actually, I'm not even going to try :-) OK, will do that later today. Should I just send it as a new patch series, or in reply to the first one? What's the "best practice" here? Best, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
[PATCH 0/4] [sur40] minor fixes & performance improvements
This patch series adds several small fixes, features & performance improvements. Many thanks to Martin Kaltenbrunner for testing the original driver & submitting the patches. Martin Kaltenbrunner (4): reduce poll interval to allow full 60 FPS framerate add frame size/frame rate query functions add extra debug output, remove noisy warning return BUF_STATE_ERROR if streaming stopped during acquisition drivers/input/touchscreen/sur40.c | 46 +-- 1 file changed, 44 insertions(+), 2 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] add extra debug output, remove noisy warning
Signed-off-by: Martin Kaltenbrunner Signed-off-by: Florian Echtler --- drivers/input/touchscreen/sur40.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/input/touchscreen/sur40.c b/drivers/input/touchscreen/sur40.c index d860d05..8add986 100644 --- a/drivers/input/touchscreen/sur40.c +++ b/drivers/input/touchscreen/sur40.c @@ -342,7 +342,7 @@ static void sur40_poll(struct input_polled_dev *polldev) * instead of at the end. */ if (packet_id != header->packet_id) - dev_warn(sur40->dev, "packet ID mismatch\n"); + dev_dbg(sur40->dev, "packet ID mismatch\n"); packet_blobs = result / sizeof(struct sur40_blob); dev_dbg(sur40->dev, "received %d blobs\n", packet_blobs); @@ -389,6 +389,8 @@ static void sur40_process_video(struct sur40_state *sur40) list_del(&new_buf->list); spin_unlock(&sur40->qlock); + dev_dbg(sur40->dev, "buffer acquired\n"); + /* retrieve data via bulk read */ result = usb_bulk_msg(sur40->usbdev, usb_rcvbulkpipe(sur40->usbdev, VIDEO_ENDPOINT), @@ -416,6 +418,8 @@ static void sur40_process_video(struct sur40_state *sur40) goto err_poll; } + dev_dbg(sur40->dev, "header acquired\n"); + sgt = vb2_dma_sg_plane_desc(&new_buf->vb, 0); result = usb_sg_init(&sgr, sur40->usbdev, @@ -432,11 +436,14 @@ static void sur40_process_video(struct sur40_state *sur40) goto err_poll; } + dev_dbg(sur40->dev, "image acquired\n"); + /* mark as finished */ v4l2_get_timestamp(&new_buf->vb.v4l2_buf.timestamp); new_buf->vb.v4l2_buf.sequence = sur40->sequence++; new_buf->vb.v4l2_buf.field = V4L2_FIELD_NONE; vb2_buffer_done(&new_buf->vb, VB2_BUF_STATE_DONE); + dev_dbg(sur40->dev, "buffer marked done\n"); return; err_poll: -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] reduce poll interval to allow full 60 FPS framerate
Signed-off-by: Martin Kaltenbrunner
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index a24eba5..e707b8d 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -125,7 +125,7 @@ struct sur40_image_header {
#define VIDEO_PACKET_SIZE 16384
/* polling interval (ms) */
-#define POLL_INTERVAL 10
+#define POLL_INTERVAL 4
/* maximum number of contacts FIXME: this is a guess? */
#define MAX_CONTACTS 64
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] add frame size/frame rate query functions
Signed-off-by: Martin Kaltenbrunner
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index e707b8d..d860d05 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -778,6 +778,33 @@ static int sur40_vidioc_enum_fmt(struct file *file, void
*priv,
return 0;
}
+static int sur40_vidioc_enum_framesizes(struct file *file, void *priv,
+ struct v4l2_frmsizeenum *f)
+{
+ if ((f->index != 0) || (f->pixel_format != V4L2_PIX_FMT_GREY))
+ return -EINVAL;
+
+ f->type = V4L2_FRMSIZE_TYPE_DISCRETE;
+ f->discrete.width = sur40_video_format.width;
+ f->discrete.height = sur40_video_format.height;
+ return 0;
+}
+
+static int sur40_vidioc_enum_frameintervals(struct file *file, void *priv,
+ struct v4l2_frmivalenum *f)
+{
+ if ((f->index > 1) || (f->pixel_format != V4L2_PIX_FMT_GREY)
+ || (f->width != sur40_video_format.width)
+ || (f->height != sur40_video_format.height))
+ return -EINVAL;
+
+ f->type = V4L2_FRMIVAL_TYPE_DISCRETE;
+ f->discrete.denominator = 60/(f->index+1);
+ f->discrete.numerator = 1;
+ return 0;
+}
+
+
static const struct usb_device_id sur40_table[] = {
{ USB_DEVICE(ID_MICROSOFT, ID_SUR40) }, /* Samsung SUR40 */
{ } /* terminating null entry */
@@ -829,6 +856,9 @@ static const struct v4l2_ioctl_ops sur40_video_ioctl_ops = {
.vidioc_s_fmt_vid_cap = sur40_vidioc_fmt,
.vidioc_g_fmt_vid_cap = sur40_vidioc_fmt,
+ .vidioc_enum_framesizes = sur40_vidioc_enum_framesizes,
+ .vidioc_enum_frameintervals = sur40_vidioc_enum_frameintervals,
+
.vidioc_enum_input = sur40_vidioc_enum_input,
.vidioc_g_input = sur40_vidioc_g_input,
.vidioc_s_input = sur40_vidioc_s_input,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] return BUF_STATE_ERROR if streaming stopped during acquisition
Signed-off-by: Martin Kaltenbrunner
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index 8add986..8be7b9b 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -438,6 +438,10 @@ static void sur40_process_video(struct sur40_state *sur40)
dev_dbg(sur40->dev, "image acquired\n");
+ /* return error if streaming was stopped in the meantime */
+ if (sur40->sequence == -1)
+ goto err_poll;
+
/* mark as finished */
v4l2_get_timestamp(&new_buf->vb.v4l2_buf.timestamp);
new_buf->vb.v4l2_buf.sequence = sur40->sequence++;
@@ -723,6 +727,7 @@ static int sur40_start_streaming(struct vb2_queue *vq,
unsigned int count)
static void sur40_stop_streaming(struct vb2_queue *vq)
{
struct sur40_state *sur40 = vb2_get_drv_priv(vq);
+ sur40->sequence = -1;
/* Release all active buffers */
return_all_buffers(sur40, VB2_BUF_STATE_ERROR);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] sur40: fix occasional hard freeze due to buffer queue underrun
This patch fixes a kernel panic which occurs when buf_list is empty. This can
happen occasionally when user space is under heavy load (e.g. due to image
processing on the CPU) and new buffers aren't re-queued fast enough. In that
case, vb2_start_streaming_called can return true, but when the spinlock
is taken and sur40_poll attempts to fetch the next buffer from buf_list, the
list is in fact empty.
This patch needs to be applied on top of the queued one adding V4L2 support
to the sur40 driver.
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index 1e7dacf..d618514 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -380,6 +380,11 @@ static void sur40_process_video(struct sur40_state *sur40)
/* get a new buffer from the list */
spin_lock(&sur40->qlock);
+ if (list_empty(&sur40->buf_list)) {
+ dev_dbg(sur40->dev, "buffer queue empty\n");
+ spin_unlock(&sur40->qlock);
+ return;
+ }
new_buf = list_entry(sur40->buf_list.next, struct sur40_buffer, list);
list_del(&new_buf->list);
spin_unlock(&sur40->qlock);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: input_polldev interval (was Re: [sur40] Debugging a race condition)?
Hello Antonio, On 26.03.2015 22:10, Antonio Ospite wrote: > On Wed, 25 Mar 2015 15:10:44 +0100 > Florian Echtler wrote: >> >> Thanks - any other suggestions how to debug such a complete freeze? I >> have the following options enabled in my kernel config: >> >> Unfortunately, even after the system is frozen for several minutes, I >> never get to see a panic message. Maybe it's there on the console >> somewhere, but the screen never switches away from X (and as mentioned >> earlier, I think this bug can only be triggered from within X). Network >> also freezes, so I don't think netconsole will help? > > PSTORE + some EFI/ACPI mechanism, maybe? > http://lwn.net/Articles/434821/ > > However I have never tried that myself and I don't know if all the > needed bits are in linux already. > > JFTR, on some embedded system I worked on in the past the RAM content > was preserved across resets and, after a crash, we used to dump the RAM > from a second stage bootloader (i.e. before lading another linux > instance) and then scrape the dump to look for the kernel messages, but > AFAIK this is not going to be reliable —or even possible— on a more > complex system. thanks for your suggestions - however, this is a regular x86 system, so what I will try next is to reproduce the crash in a Virtualbox instance with the SUR40 device routed to the guest using USB passthrough and the serial console routed to the host. Hope this will give some clues. One more general question: what are possible reasons for a complete freeze? Only a spinlock being held with interrupts disabled, or are there other possibilities? Best, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: input_polldev interval (was Re: [sur40] Debugging a race condition)?
Hello Dmitry, On 25.03.2015 14:23, Dmitry Torokhov wrote: > On March 24, 2015 11:52:54 PM PDT, Florian Echtler > wrote: >> Currently, I'm setting the interval for input_polldev to 10 ms. >> However, with video data being retrieved at the same time, it's quite >> possible that one iteration of poll() will take longer than that. Could >> this ultimately be the reason? What happens if a new poll() call is >> scheduled before the previous one completes? > > This can't happen as we schedule the next poll only after current one > completes. > Thanks - any other suggestions how to debug such a complete freeze? I have the following options enabled in my kernel config: CONFIG_LOCKUP_DETECTOR=y CONFIG_HARDLOCKUP_DETECTOR=y CONFIG_DETECT_HUNG_TASK=y CONFIG_EARLY_PRINTK=y CONFIG_EARLY_PRINTK_DBGP=y CONFIG_EARLY_PRINTK_EFI=y Unfortunately, even after the system is frozen for several minutes, I never get to see a panic message. Maybe it's there on the console somewhere, but the screen never switches away from X (and as mentioned earlier, I think this bug can only be triggered from within X). Network also freezes, so I don't think netconsole will help? Best, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
input_polldev interval (was Re: [sur40] Debugging a race condition)?
Sorry for the continued noise, but this bug/crash is proving quite difficult to nail down. Currently, I'm setting the interval for input_polldev to 10 ms. However, with video data being retrieved at the same time, it's quite possible that one iteration of poll() will take longer than that. Could this ultimately be the reason? What happens if a new poll() call is scheduled before the previous one completes? Best, Florian On March 23, 2015 4:47:19 PM CET, Florian Echtler wrote: >Additional note: this happens almost never with the original code using >dma-contig, which is why I didn't catch it during testing. I've now >switched back and forth between the two versions multiple times, and >it's definitely a lot less stable with dma-sg and usb_sg_init/_wait. >Maybe that can help somebody in narrowing down the reason of the >problem? > >Best, Florian > >On 23.03.2015 12:57, Florian Echtler wrote: >> Hello everyone, >> >> now that I'm using the newly merged sur40 video driver in a >development >> environment, I've noticed that a custom V4L2 application we've been >> using in our lab will sometimes trigger a hard lockup of the machine >> (_nothing_ works anymore, no VT switching, no network, not even Magic >> SysRq). >> >> This doesn't happen with plain old cheese or v4l2-compliance, only >with >> our custom application and only under X11, i.e. as far as I can tell, >> when the input device is being polled at the same time. However, I >have >> a really hard time tracking this down, as even SysRq doesn't work >> anymore. A console continuously dumping dmesg or strace of our tool >> didn't really help, either. >> >> I assume that somehow the input_polldev thread is put to >sleep/waiting >> for a lock due to the video functions and that causes the lockup, but >I >> can't really tell where that might happen. Can somebody with better >> knowledge of the internals give some suggestions? >> >> Thanks & best regards, Florian >> -- SENT FROM MY PDP-11 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [sur40] Debugging a race condition?
Additional note: this happens almost never with the original code using dma-contig, which is why I didn't catch it during testing. I've now switched back and forth between the two versions multiple times, and it's definitely a lot less stable with dma-sg and usb_sg_init/_wait. Maybe that can help somebody in narrowing down the reason of the problem? Best, Florian On 23.03.2015 12:57, Florian Echtler wrote: > Hello everyone, > > now that I'm using the newly merged sur40 video driver in a development > environment, I've noticed that a custom V4L2 application we've been > using in our lab will sometimes trigger a hard lockup of the machine > (_nothing_ works anymore, no VT switching, no network, not even Magic > SysRq). > > This doesn't happen with plain old cheese or v4l2-compliance, only with > our custom application and only under X11, i.e. as far as I can tell, > when the input device is being polled at the same time. However, I have > a really hard time tracking this down, as even SysRq doesn't work > anymore. A console continuously dumping dmesg or strace of our tool > didn't really help, either. > > I assume that somehow the input_polldev thread is put to sleep/waiting > for a lock due to the video functions and that causes the lockup, but I > can't really tell where that might happen. Can somebody with better > knowledge of the internals give some suggestions? > > Thanks & best regards, Florian > -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
[sur40] Debugging a race condition?
Hello everyone, now that I'm using the newly merged sur40 video driver in a development environment, I've noticed that a custom V4L2 application we've been using in our lab will sometimes trigger a hard lockup of the machine (_nothing_ works anymore, no VT switching, no network, not even Magic SysRq). This doesn't happen with plain old cheese or v4l2-compliance, only with our custom application and only under X11, i.e. as far as I can tell, when the input device is being polled at the same time. However, I have a really hard time tracking this down, as even SysRq doesn't work anymore. A console continuously dumping dmesg or strace of our tool didn't really help, either. I assume that somehow the input_polldev thread is put to sleep/waiting for a lock due to the video functions and that causes the lockup, but I can't really tell where that might happen. Can somebody with better knowledge of the internals give some suggestions? Thanks & best regards, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: [GIT PULL FOR v4.1] sur40 driver and two small DocBook fixes
\o/ YAY! ;-) Sorry for the spam, but that needed to be said. Thanks again, Hans! Best, Florian On 16.03.2015 12:47, Hans Verkuil wrote: > This adds video capture support to the sur40 input driver. > > To quote the author: > > "The SUR40 is a quite peculiar touchscreen device which does > on-board image processing to provide touch data, but also allows to > retrieve the raw video image. Unfortunately, it's a single USB device > with two endpoints for the different data types, so everything (input & > video) needs to be squeezed into one driver." > > Regards, > > Hans > > The following changes since commit 3d945be05ac1e806af075e9315bc1b3409adae2b: > > [media] mn88473: simplify bandwidth registers setting code (2015-03-03 > 13:09:12 -0300) > > are available in the git repository at: > > git://linuxtv.org/hverkuil/media_tree.git for-v4.1m > > for you to fetch changes up to 69dc25b1cd764181a6b8c5b16b753ab645b3d55b: > > add raw video stream support for Samsung SUR40 (2015-03-16 12:43:10 +0100) > > > Florian Echtler (1): > add raw video stream support for Samsung SUR40 > > Hans Verkuil (2): > DocBook media: fix VIDIOC_CROPCAP type description > DocBook media: fix awkward language in VIDIOC_QUERYCAP > > Documentation/DocBook/media/v4l/vidioc-cropcap.xml | 9 +- > Documentation/DocBook/media/v4l/vidioc-g-crop.xml | 5 + > Documentation/DocBook/media/v4l/vidioc-g-selection.xml | 4 +- > Documentation/DocBook/media/v4l/vidioc-querycap.xml| 8 +- > drivers/input/touchscreen/Kconfig | 2 + > drivers/input/touchscreen/sur40.c | 429 > +++-- > 6 files changed, 436 insertions(+), 21 deletions(-) > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
[PATCH v5] add raw video stream support for Samsung SUR40
This patch adds raw video support for the Samsung SUR40 using vbuf2-dma-sg.
All tests from v4l2-compliance pass. Support for VB2_USERPTR is currently
disabled due to unexpected interference with dma-sg buffer sizes.
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/Kconfig | 2 +
drivers/input/touchscreen/sur40.c | 429 --
2 files changed, 419 insertions(+), 12 deletions(-)
diff --git a/drivers/input/touchscreen/Kconfig
b/drivers/input/touchscreen/Kconfig
index 5891752..f8d16f1 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -953,7 +953,9 @@ config TOUCHSCREEN_SUN4I
config TOUCHSCREEN_SUR40
tristate "Samsung SUR40 (Surface 2.0/PixelSense) touchscreen"
depends on USB
+ depends on MEDIA_USB_SUPPORT
select INPUT_POLLDEV
+ select VIDEOBUF2_DMA_SG
help
Say Y here if you want support for the Samsung SUR40 touchscreen
(also known as Microsoft Surface 2.0 or Microsoft PixelSense).
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index f1cb051..1e7dacf 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -1,7 +1,7 @@
/*
* Surface2.0/SUR40/PixelSense input driver
*
- * Copyright (c) 2013 by Florian 'floe' Echtler
+ * Copyright (c) 2014 by Florian 'floe' Echtler
*
* Derived from the USB Skeleton driver 1.1,
* Copyright (c) 2003 Greg Kroah-Hartman (g...@kroah.com)
@@ -12,6 +12,9 @@
* and from the generic hid-multitouch driver,
* Copyright (c) 2010-2012 Stephane Chatty
*
+ * and from the v4l2-pci-skeleton driver,
+ * Copyright (c) Copyright 2014 Cisco Systems, Inc.
+ *
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
@@ -31,6 +34,11 @@
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
/* read 512 bytes from endpoint 0x86 -> get header + blobs */
struct sur40_header {
@@ -82,9 +90,19 @@ struct sur40_data {
struct sur40_blob blobs[];
} __packed;
+/* read 512 bytes from endpoint 0x82 -> get header below
+ * continue reading 16k blocks until header.size bytes read */
+struct sur40_image_header {
+ __le32 magic; /* "SUBF" */
+ __le32 packet_id;
+ __le32 size; /* always 0x0007e900 = 960x540 */
+ __le32 timestamp; /* milliseconds (increases by 16 or 17 each frame) */
+ __le32 unknown; /* "epoch?" always 02/03 00 00 00 */
+} __packed;
/* version information */
#define DRIVER_SHORT "sur40"
+#define DRIVER_LONG"Samsung SUR40"
#define DRIVER_AUTHOR "Florian 'floe' Echtler "
#define DRIVER_DESC"Surface2.0/SUR40/PixelSense input driver"
@@ -99,6 +117,13 @@ struct sur40_data {
/* touch data endpoint */
#define TOUCH_ENDPOINT 0x86
+/* video data endpoint */
+#define VIDEO_ENDPOINT 0x82
+
+/* video header fields */
+#define VIDEO_HEADER_MAGIC 0x46425553
+#define VIDEO_PACKET_SIZE 16384
+
/* polling interval (ms) */
#define POLL_INTERVAL 10
@@ -113,21 +138,23 @@ struct sur40_data {
#define SUR40_GET_STATE 0xc5 /* 4 bytes state (?) */
#define SUR40_GET_SENSORS 0xb1 /* 8 bytes sensors */
-/*
- * Note: an earlier, non-public version of this driver used USB_RECIP_ENDPOINT
- * here by mistake which is very likely to have corrupted the firmware EEPROM
- * on two separate SUR40 devices. Thanks to Alan Stern who spotted this bug.
- * Should you ever run into a similar problem, the background story to this
- * incident and instructions on how to fix the corrupted EEPROM are available
- * at https://floe.butterbrot.org/matrix/hacking/surface/brick.html
-*/
-
+/* master device state */
struct sur40_state {
struct usb_device *usbdev;
struct device *dev;
struct input_polled_dev *input;
+ struct v4l2_device v4l2;
+ struct video_device vdev;
+ struct mutex lock;
+
+ struct vb2_queue queue;
+ struct vb2_alloc_ctx *alloc_ctx;
+ struct list_head buf_list;
+ spinlock_t qlock;
+ int sequence;
+
struct sur40_data *bulk_in_buffer;
size_t bulk_in_size;
u8 bulk_in_epaddr;
@@ -135,6 +162,27 @@ struct sur40_state {
char phys[64];
};
+struct sur40_buffer {
+ struct vb2_buffer vb;
+ struct list_head list;
+};
+
+/* forward declarations */
+static const struct video_device sur40_video_device;
+static const struct v4l2_pix_format sur40_video_format;
+static const struct vb2_queue sur40_queue;
+static void sur40_process_video(struct sur40_state *sur40);
+
+/*
+ * Note: an earlier, non-public version of this driver used USB_RECIP_ENDPOINT
+ * here by mistake which is very likely to have corrupted the firmware EE
Re: [PATCH v3][RFC] add raw video stream support for Samsung SUR40
Hello Hans, On 15.03.2015 17:26, Hans Verkuil wrote: > On 03/12/2015 08:37 PM, Florian Echtler wrote: >> On 09.03.2015 15:02, Hans Verkuil wrote: >>> On 03/09/2015 02:45 PM, Florian Echtler wrote: >>>> On 09.03.2015 11:09, Hans Verkuil wrote: >>>>> The error almost certainly comes from usb_submit_urb(). That function >>>>> does some >>>>> checks on the sgl: >>>>> >>>> I'll do my best to track this down. Do you think this is an error in my >>>> code, one in the USB subsystem, or some combination of both? >>> >>> If the USB core indeed requires scatter-gather segments of specific lengths >>> (modulo max), then that explains the problems. >>> So as suggested try to see if the usb core bails out in that check and what >>> the >>> 'max' value is. It looks like only XHCI allows SG segments of any size, so >>> I really >>> suspect that's the problem. But I also need to know the 'max' value to fully >>> understand the implications. >> >> Finally managed to confirm your suspicions on a kernel with a patched >> dev_err call at the location you mentioned: >> >> So the SG segments are expected in multiples of 512 bytes. I assume this >> is not something I can fix from within my driver? > > No, you can't. I would use dma-sg, but disable the USERPTR support. > Also comment why USERPTR support is disabled. > > This was interesting :-) > Thanks again for your help, new patch is submitted. Just for my understanding: is this a hardware limitation? And why does dma-sg select such a weird segment size like 4080? Best, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
[PATCH v4] add raw video stream support for Samsung SUR40
This patch adds raw video support for the Samsung SUR40 using vbuf2-dma-sg.
All tests from v4l2-compliance pass. Support for VB2_USERPTR is currently
disabled due to unexpected interference with dma-sg buffer sizes.
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/Kconfig | 2 +
drivers/input/touchscreen/sur40.c | 429 --
2 files changed, 419 insertions(+), 12 deletions(-)
diff --git a/drivers/input/touchscreen/Kconfig
b/drivers/input/touchscreen/Kconfig
index 5891752..f8d16f1 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -953,7 +953,9 @@ config TOUCHSCREEN_SUN4I
config TOUCHSCREEN_SUR40
tristate "Samsung SUR40 (Surface 2.0/PixelSense) touchscreen"
depends on USB
+ depends on MEDIA_USB_SUPPORT
select INPUT_POLLDEV
+ select VIDEOBUF2_DMA_SG
help
Say Y here if you want support for the Samsung SUR40 touchscreen
(also known as Microsoft Surface 2.0 or Microsoft PixelSense).
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index f1cb051..d5f054b 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -1,7 +1,7 @@
/*
* Surface2.0/SUR40/PixelSense input driver
*
- * Copyright (c) 2013 by Florian 'floe' Echtler
+ * Copyright (c) 2015 by Florian 'floe' Echtler
*
* Derived from the USB Skeleton driver 1.1,
* Copyright (c) 2003 Greg Kroah-Hartman (g...@kroah.com)
@@ -12,6 +12,9 @@
* and from the generic hid-multitouch driver,
* Copyright (c) 2010-2012 Stephane Chatty
*
+ * and from the v4l2-pci-skeleton driver,
+ * Copyright (c) Copyright 2014 Cisco Systems, Inc.
+ *
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
@@ -31,6 +34,11 @@
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
/* read 512 bytes from endpoint 0x86 -> get header + blobs */
struct sur40_header {
@@ -82,9 +90,19 @@ struct sur40_data {
struct sur40_blob blobs[];
} __packed;
+/* read 512 bytes from endpoint 0x82 -> get header below
+ * continue reading 16k blocks until header.size bytes read */
+struct sur40_image_header {
+ __le32 magic; /* "SUBF" */
+ __le32 packet_id;
+ __le32 size; /* always 0x0007e900 = 960x540 */
+ __le32 timestamp; /* milliseconds (increases by 16 or 17 each frame) */
+ __le32 unknown; /* "epoch?" always 02/03 00 00 00 */
+} __packed;
/* version information */
#define DRIVER_SHORT "sur40"
+#define DRIVER_LONG"Samsung SUR40"
#define DRIVER_AUTHOR "Florian 'floe' Echtler "
#define DRIVER_DESC"Surface2.0/SUR40/PixelSense input driver"
@@ -99,6 +117,13 @@ struct sur40_data {
/* touch data endpoint */
#define TOUCH_ENDPOINT 0x86
+/* video data endpoint */
+#define VIDEO_ENDPOINT 0x82
+
+/* video header fields */
+#define VIDEO_HEADER_MAGIC 0x46425553
+#define VIDEO_PACKET_SIZE 16384
+
/* polling interval (ms) */
#define POLL_INTERVAL 10
@@ -113,21 +138,23 @@ struct sur40_data {
#define SUR40_GET_STATE 0xc5 /* 4 bytes state (?) */
#define SUR40_GET_SENSORS 0xb1 /* 8 bytes sensors */
-/*
- * Note: an earlier, non-public version of this driver used USB_RECIP_ENDPOINT
- * here by mistake which is very likely to have corrupted the firmware EEPROM
- * on two separate SUR40 devices. Thanks to Alan Stern who spotted this bug.
- * Should you ever run into a similar problem, the background story to this
- * incident and instructions on how to fix the corrupted EEPROM are available
- * at https://floe.butterbrot.org/matrix/hacking/surface/brick.html
-*/
-
+/* master device state */
struct sur40_state {
struct usb_device *usbdev;
struct device *dev;
struct input_polled_dev *input;
+ struct v4l2_device v4l2;
+ struct video_device vdev;
+ struct mutex lock;
+
+ struct vb2_queue queue;
+ struct vb2_alloc_ctx *alloc_ctx;
+ struct list_head buf_list;
+ spinlock_t qlock;
+ int sequence;
+
struct sur40_data *bulk_in_buffer;
size_t bulk_in_size;
u8 bulk_in_epaddr;
@@ -135,6 +162,27 @@ struct sur40_state {
char phys[64];
};
+struct sur40_buffer {
+ struct vb2_buffer vb;
+ struct list_head list;
+};
+
+/* forward declarations */
+static const struct video_device sur40_video_device;
+static const struct v4l2_pix_format sur40_video_format;
+static const struct vb2_queue sur40_queue;
+static void sur40_process_video(struct sur40_state *sur40);
+
+/*
+ * Note: an earlier, non-public version of this driver used USB_RECIP_ENDPOINT
+ * here by mistake which is very likely to have corrupted the firmware EE
Re: [PATCH v3][RFC] add raw video stream support for Samsung SUR40
Hello Hans, On 09.03.2015 15:02, Hans Verkuil wrote: > On 03/09/2015 02:45 PM, Florian Echtler wrote: >> On 09.03.2015 11:09, Hans Verkuil wrote: >>> The error almost certainly comes from usb_submit_urb(). That function does >>> some >>> checks on the sgl: >>> >>> I wonder it the code gets there. Perhaps a printk just before the return >>> -EINVAL >>> might help here (also print the 'max' value). >>> >>> So you will have to debug a bit here, trying to figure out which test in >>> the usb >>> code causes the usb_sg_wait error. >> I'll do my best to track this down. Do you think this is an error in my >> code, one in the USB subsystem, or some combination of both? > > If the USB core indeed requires scatter-gather segments of specific lengths > (modulo max), then that explains the problems. > So as suggested try to see if the usb core bails out in that check and what > the > 'max' value is. It looks like only XHCI allows SG segments of any size, so I > really > suspect that's the problem. But I also need to know the 'max' value to fully > understand the implications. Finally managed to confirm your suspicions on a kernel with a patched dev_err call at the location you mentioned: Mar 12 20:33:51 sur40 kernel: [ 1159.509580] (null): urb 0 length mismatch: length 4080, max 512 Mar 12 20:33:51 sur40 kernel: [ 1159.509592] sur40 2-1:1.0: error -22 in usb_sg_wait So the SG segments are expected in multiples of 512 bytes. I assume this is not something I can fix from within my driver? Best regards, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: [PATCH v3][RFC] add raw video stream support for Samsung SUR40
On 09.03.2015 11:09, Hans Verkuil wrote: > Hi Florian, > > OK, the cause of this failure is this message: > > Mar 9 10:39:08 sur40 kernel: [ 1093.200960] sur40 2-1:1.0: error in > usb_sg_wait > > So you need to print the error message here (sgr.status) so that I can see > what > it is. I've amended the dev_debug call, the error returned from usb_sg_wait is also -22 (EINVAL). > The error almost certainly comes from usb_submit_urb(). That function does > some > checks on the sgl: > > I wonder it the code gets there. Perhaps a printk just before the return > -EINVAL > might help here (also print the 'max' value). > > So you will have to debug a bit here, trying to figure out which test in the > usb > code causes the usb_sg_wait error. I'll do my best to track this down. Do you think this is an error in my code, one in the USB subsystem, or some combination of both? Best, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: [PATCH v3][RFC] add raw video stream support for Samsung SUR40
On 21.02.2015 11:22, Hans Verkuil wrote: > On 02/20/2015 10:46 PM, Florian Echtler wrote: >> On 16.02.2015 12:40, Hans Verkuil wrote: >>> On 02/11/2015 12:52 PM, Florian Echtler wrote: >>> I prefer to dig into this a little bit more, as I don't really understand >>> it. Set the videobuf2-core debug level to 1 and see what the warnings are. >>> Since 'buf.qbuf' fails in v4l2-compliance, it's something in the VIDIOC_QBUF >>> sequence that returns an error, so you need to pinpoint that. >> OK, I don't currently have access to the hardware, but I will try this >> as soon as possible. Finally got a chance to try again with videobuf2-core.debug=1. Same result on 3.19 and 4.0-rc2, after running v4l2-compliance -s from today's master (full log attached, but important part is below): [11470.040067] vb2: __vb2_queue_alloc: allocated 3 buffers, 1 plane(s) each [11470.040136] vb2: vb2_mmap: queue is not currently set up for mmap [11470.040158] vb2: __qbuf_userptr: failed acquiring userspace memory for plane 0 [11470.040163] vb2: __buf_prepare: buffer preparation failed: -22 [11470.040172] vb2: __qbuf_userptr: failed acquiring userspace memory for plane 0 [11470.040175] vb2: __buf_prepare: buffer preparation failed: -22 [11470.040651] vb2: vb2_internal_qbuf: qbuf of buffer 0 succeeded [11470.040663] vb2: vb2_mmap: queue is not currently set up for mmap [11470.040676] vb2: __qbuf_userptr: failed acquiring userspace memory for plane 0 [11470.040680] vb2: __buf_prepare: buffer preparation failed: -22 [11470.040687] vb2: __qbuf_userptr: failed acquiring userspace memory for plane 0 [11470.040690] vb2: __buf_prepare: buffer preparation failed: -22 [11470.041167] vb2: vb2_internal_qbuf: qbuf of buffer 1 succeeded [11470.041178] vb2: vb2_mmap: queue is not currently set up for mmap [11470.041193] vb2: __qbuf_userptr: failed acquiring userspace memory for plane 0 [11470.041196] vb2: __buf_prepare: buffer preparation failed: -22 [11470.041203] vb2: __qbuf_userptr: failed acquiring userspace memory for plane 0 [11470.041207] vb2: __buf_prepare: buffer preparation failed: -22 [11470.041683] vb2: vb2_internal_qbuf: qbuf of buffer 2 succeeded [11470.051195] sur40 2-1:1.0: error in usb_sg_wait [11470.051250] vb2: vb2_internal_dqbuf: dqbuf of buffer 0, with state 0 I'm not familiar enough with the inner workings of videobuf2 to make any sense of it, any new insights from you guys? Thanks & best regards, Florian -- SENT FROM MY DEC VT50 TERMINAL Mar 6 12:03:38 sur40 kernel: [11467.159686] vb2: __vb2_queue_alloc: allocated 3 buffers, 1 plane(s) each Mar 6 12:03:38 sur40 kernel: [11467.160152] vb2: __vb2_queue_alloc: allocated 3 buffers, 1 plane(s) each Mar 6 12:03:38 sur40 kernel: [11467.160162] vb2: vb2_querybuf: buffer index out of range Mar 6 12:03:38 sur40 kernel: [11467.160209] vb2: __vb2_queue_alloc: allocated 3 buffers, 1 plane(s) each Mar 6 12:03:38 sur40 kernel: [11467.160212] vb2: __vb2_queue_alloc: allocated 3 buffers, 1 plane(s) each Mar 6 12:03:38 sur40 kernel: [11467.160215] vb2: vb2_querybuf: buffer index out of range Mar 6 12:03:38 sur40 kernel: [11467.160217] vb2: __vb2_queue_alloc: allocated 3 buffers, 1 plane(s) each Mar 6 12:03:38 sur40 kernel: [11467.160220] vb2: __vb2_queue_alloc: allocated 3 buffers, 1 plane(s) each Mar 6 12:03:38 sur40 kernel: [11467.160223] vb2: vb2_querybuf: buffer index out of range Mar 6 12:03:38 sur40 kernel: [11467.160235] vb2: __vb2_queue_alloc: allocated 3 buffers, 1 plane(s) each Mar 6 12:03:38 sur40 kernel: [11467.160872] vb2: __vb2_queue_alloc: allocated 3 buffers, 1 plane(s) each Mar 6 12:03:38 sur40 kernel: [11467.160923] vb2: __vb2_queue_alloc: allocated 3 buffers, 1 plane(s) each Mar 6 12:03:38 sur40 kernel: [11467.160927] vb2: vb2_querybuf: buffer index out of range Mar 6 12:03:38 sur40 kernel: [11467.160929] vb2: __vb2_queue_alloc: allocated 1 buffers, 1 plane(s) each Mar 6 12:03:38 sur40 kernel: [11467.160932] vb2: vb2_querybuf: buffer index out of range Mar 6 12:03:38 sur40 kernel: [11467.160937] vb2: __vb2_queue_alloc: allocated 3 buffers, 1 plane(s) each Mar 6 12:03:38 sur40 kernel: [11467.160941] vb2: __vb2_queue_alloc: allocated 3 buffers, 1 plane(s) each Mar 6 12:03:38 sur40 kernel: [11467.160944] vb2: __vb2_queue_alloc: allocated 3 buffers, 1 plane(s) each Mar 6 12:03:38 sur40 kernel: [11467.160947] vb2: vb2_querybuf: buffer index out of range Mar 6 12:03:38 sur40 kernel: [11467.160949] vb2: __vb2_queue_alloc: allocated 1 buffers, 1 plane(s) each Mar 6 12:03:38 sur40 kernel: [11467.160951] vb2: vb2_querybuf: buffer index out of range Mar 6 12:03:38 sur40 kernel: [11467.160954] vb2: __vb2_queue_alloc: allocated 3 buffers, 1 plane(s) each Mar 6 12:03:38 sur40 kernel: [11467.160958] vb2: __vb2_queue_alloc: allocated 3 buffers, 1 plane(s) each Mar 6 12:03:38 sur40 kernel: [11467.160961] vb2: __vb2_queue_alloc: allocated
Re: [PATCH v3][RFC] add raw video stream support for Samsung SUR40
On 16.02.2015 12:40, Hans Verkuil wrote: > On 02/11/2015 12:52 PM, Florian Echtler wrote: >> does anyone have any suggestions why USERPTR still fails with dma-sg? >> >> Could I just disable the corresponding capability for the moment so that >> the patch could perhaps be merged, and investigate this separately? > > I prefer to dig into this a little bit more, as I don't really understand > it. Set the videobuf2-core debug level to 1 and see what the warnings are. > > Since 'buf.qbuf' fails in v4l2-compliance, it's something in the VIDIOC_QBUF > sequence that returns an error, so you need to pinpoint that. OK, I don't currently have access to the hardware, but I will try this as soon as possible. > If push comes to shove I can also merge the patch without USERPTR support, > but I really prefer not to do that. How long until the next merge window closes? Best regards, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: [PATCH v3][RFC] add raw video stream support for Samsung SUR40
Hello again,
does anyone have any suggestions why USERPTR still fails with dma-sg?
Could I just disable the corresponding capability for the moment so that
the patch could perhaps be merged, and investigate this separately?
Best, Florian
On 04.02.2015 16:30, Florian Echtler wrote:
> This patch adds raw video support for the Samsung SUR40, now finally using
> videobuf2-dma-sg and the usb_sg_init/_wait helper functions. Further comments
> regarding buffer handling are invited, as v4l2-compliance -s still fails the
> USERPTR test.
>
> Signed-off-by: Florian Echtler
> ---
> drivers/input/touchscreen/sur40.c | 424
> --
> 1 file changed, 412 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/input/touchscreen/sur40.c
> b/drivers/input/touchscreen/sur40.c
> index f1cb051..33bc1b8 100644
> --- a/drivers/input/touchscreen/sur40.c
> +++ b/drivers/input/touchscreen/sur40.c
> @@ -1,7 +1,7 @@
> /*
> * Surface2.0/SUR40/PixelSense input driver
> *
> - * Copyright (c) 2013 by Florian 'floe' Echtler
> + * Copyright (c) 2014 by Florian 'floe' Echtler
> *
> * Derived from the USB Skeleton driver 1.1,
> * Copyright (c) 2003 Greg Kroah-Hartman (g...@kroah.com)
> @@ -12,6 +12,9 @@
> * and from the generic hid-multitouch driver,
> * Copyright (c) 2010-2012 Stephane Chatty
> *
> + * and from the v4l2-pci-skeleton driver,
> + * Copyright (c) Copyright 2014 Cisco Systems, Inc.
> + *
> * This program is free software; you can redistribute it and/or
> * modify it under the terms of the GNU General Public License as
> * published by the Free Software Foundation; either version 2 of
> @@ -31,6 +34,11 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> +#include
> +#include
>
> /* read 512 bytes from endpoint 0x86 -> get header + blobs */
> struct sur40_header {
> @@ -82,9 +90,19 @@ struct sur40_data {
> struct sur40_blob blobs[];
> } __packed;
>
> +/* read 512 bytes from endpoint 0x82 -> get header below
> + * continue reading 16k blocks until header.size bytes read */
> +struct sur40_image_header {
> + __le32 magic; /* "SUBF" */
> + __le32 packet_id;
> + __le32 size; /* always 0x0007e900 = 960x540 */
> + __le32 timestamp; /* milliseconds (increases by 16 or 17 each frame) */
> + __le32 unknown; /* "epoch?" always 02/03 00 00 00 */
> +} __packed;
>
> /* version information */
> #define DRIVER_SHORT "sur40"
> +#define DRIVER_LONG"Samsung SUR40"
> #define DRIVER_AUTHOR "Florian 'floe' Echtler "
> #define DRIVER_DESC"Surface2.0/SUR40/PixelSense input driver"
>
> @@ -99,6 +117,13 @@ struct sur40_data {
> /* touch data endpoint */
> #define TOUCH_ENDPOINT 0x86
>
> +/* video data endpoint */
> +#define VIDEO_ENDPOINT 0x82
> +
> +/* video header fields */
> +#define VIDEO_HEADER_MAGIC 0x46425553
> +#define VIDEO_PACKET_SIZE 16384
> +
> /* polling interval (ms) */
> #define POLL_INTERVAL 10
>
> @@ -113,21 +138,23 @@ struct sur40_data {
> #define SUR40_GET_STATE 0xc5 /* 4 bytes state (?) */
> #define SUR40_GET_SENSORS 0xb1 /* 8 bytes sensors */
>
> -/*
> - * Note: an earlier, non-public version of this driver used
> USB_RECIP_ENDPOINT
> - * here by mistake which is very likely to have corrupted the firmware EEPROM
> - * on two separate SUR40 devices. Thanks to Alan Stern who spotted this bug.
> - * Should you ever run into a similar problem, the background story to this
> - * incident and instructions on how to fix the corrupted EEPROM are available
> - * at https://floe.butterbrot.org/matrix/hacking/surface/brick.html
> -*/
> -
> +/* master device state */
> struct sur40_state {
>
> struct usb_device *usbdev;
> struct device *dev;
> struct input_polled_dev *input;
>
> + struct v4l2_device v4l2;
> + struct video_device vdev;
> + struct mutex lock;
> +
> + struct vb2_queue queue;
> + struct vb2_alloc_ctx *alloc_ctx;
> + struct list_head buf_list;
> + spinlock_t qlock;
> + int sequence;
> +
> struct sur40_data *bulk_in_buffer;
> size_t bulk_in_size;
> u8 bulk_in_epaddr;
> @@ -135,6 +162,27 @@ struct sur40_state {
> char phys[64];
> };
>
> +struct sur40_buffer {
> + struct vb2_buffer vb;
> + struct list_head list;
> +};
> +
> +/* forward declarations */
> +static const struct video_device sur40_video_device;
> +static const struct v4l2_pix_format sur40_video_format;
> +static const struct
[PATCH v3][RFC] add raw video stream support for Samsung SUR40
This patch adds raw video support for the Samsung SUR40, now finally using
videobuf2-dma-sg and the usb_sg_init/_wait helper functions. Further comments
regarding buffer handling are invited, as v4l2-compliance -s still fails the
USERPTR test.
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 424 --
1 file changed, 412 insertions(+), 12 deletions(-)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index f1cb051..33bc1b8 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -1,7 +1,7 @@
/*
* Surface2.0/SUR40/PixelSense input driver
*
- * Copyright (c) 2013 by Florian 'floe' Echtler
+ * Copyright (c) 2014 by Florian 'floe' Echtler
*
* Derived from the USB Skeleton driver 1.1,
* Copyright (c) 2003 Greg Kroah-Hartman (g...@kroah.com)
@@ -12,6 +12,9 @@
* and from the generic hid-multitouch driver,
* Copyright (c) 2010-2012 Stephane Chatty
*
+ * and from the v4l2-pci-skeleton driver,
+ * Copyright (c) Copyright 2014 Cisco Systems, Inc.
+ *
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
@@ -31,6 +34,11 @@
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
/* read 512 bytes from endpoint 0x86 -> get header + blobs */
struct sur40_header {
@@ -82,9 +90,19 @@ struct sur40_data {
struct sur40_blob blobs[];
} __packed;
+/* read 512 bytes from endpoint 0x82 -> get header below
+ * continue reading 16k blocks until header.size bytes read */
+struct sur40_image_header {
+ __le32 magic; /* "SUBF" */
+ __le32 packet_id;
+ __le32 size; /* always 0x0007e900 = 960x540 */
+ __le32 timestamp; /* milliseconds (increases by 16 or 17 each frame) */
+ __le32 unknown; /* "epoch?" always 02/03 00 00 00 */
+} __packed;
/* version information */
#define DRIVER_SHORT "sur40"
+#define DRIVER_LONG"Samsung SUR40"
#define DRIVER_AUTHOR "Florian 'floe' Echtler "
#define DRIVER_DESC"Surface2.0/SUR40/PixelSense input driver"
@@ -99,6 +117,13 @@ struct sur40_data {
/* touch data endpoint */
#define TOUCH_ENDPOINT 0x86
+/* video data endpoint */
+#define VIDEO_ENDPOINT 0x82
+
+/* video header fields */
+#define VIDEO_HEADER_MAGIC 0x46425553
+#define VIDEO_PACKET_SIZE 16384
+
/* polling interval (ms) */
#define POLL_INTERVAL 10
@@ -113,21 +138,23 @@ struct sur40_data {
#define SUR40_GET_STATE 0xc5 /* 4 bytes state (?) */
#define SUR40_GET_SENSORS 0xb1 /* 8 bytes sensors */
-/*
- * Note: an earlier, non-public version of this driver used USB_RECIP_ENDPOINT
- * here by mistake which is very likely to have corrupted the firmware EEPROM
- * on two separate SUR40 devices. Thanks to Alan Stern who spotted this bug.
- * Should you ever run into a similar problem, the background story to this
- * incident and instructions on how to fix the corrupted EEPROM are available
- * at https://floe.butterbrot.org/matrix/hacking/surface/brick.html
-*/
-
+/* master device state */
struct sur40_state {
struct usb_device *usbdev;
struct device *dev;
struct input_polled_dev *input;
+ struct v4l2_device v4l2;
+ struct video_device vdev;
+ struct mutex lock;
+
+ struct vb2_queue queue;
+ struct vb2_alloc_ctx *alloc_ctx;
+ struct list_head buf_list;
+ spinlock_t qlock;
+ int sequence;
+
struct sur40_data *bulk_in_buffer;
size_t bulk_in_size;
u8 bulk_in_epaddr;
@@ -135,6 +162,27 @@ struct sur40_state {
char phys[64];
};
+struct sur40_buffer {
+ struct vb2_buffer vb;
+ struct list_head list;
+};
+
+/* forward declarations */
+static const struct video_device sur40_video_device;
+static const struct v4l2_pix_format sur40_video_format;
+static const struct vb2_queue sur40_queue;
+static void sur40_process_video(struct sur40_state *sur40);
+
+/*
+ * Note: an earlier, non-public version of this driver used USB_RECIP_ENDPOINT
+ * here by mistake which is very likely to have corrupted the firmware EEPROM
+ * on two separate SUR40 devices. Thanks to Alan Stern who spotted this bug.
+ * Should you ever run into a similar problem, the background story to this
+ * incident and instructions on how to fix the corrupted EEPROM are available
+ * at https://floe.butterbrot.org/matrix/hacking/surface/brick.html
+*/
+
+/* command wrapper */
static int sur40_command(struct sur40_state *dev,
u8 command, u16 index, void *buffer, u16 size)
{
@@ -247,7 +295,6 @@ static void sur40_report_blob(struct sur40_blob *blob,
struct input_dev *input)
/* core function: poll for new input data */
static void sur40_
Re: [PATCH] add raw video support for Samsung SUR40 touchscreen
Hello everyone, On 04.02.2015 12:39, Hans Verkuil wrote: > On 02/04/15 12:34, Laurent Pinchart wrote: >> On Wednesday 04 February 2015 11:56:58 Florian Echtler wrote: >>> That's what I assumed, however, I'm running into the same problem as >>> with dma-sg when I switch to vmalloc...? >> >> I don't expect vmalloc to work, as you can't DMA to vmalloc memory directly >> without any IOMMU in the general case (the allocated memory being physically >> fragmented). >> >> dma-sg should work though, but you won't be able to use usb_bulk_msg(). You >> need to create the URBs manually, set their sg and num_sgs fields and submit >> them. Can I also use usb_sg_init/_wait for this? I can't find any other driver which uses USB in conjunction with dma-sg, can you suggest one I could use as an example? > Anyway Florian, based on Laurent's explanation I think trying to make > dma-sg work seems to be the best solution. And I've learned something > new :-) Thanks for the clarification, please ignore the v2 patch submission for now :-) Best, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
[PATCH v2][RFC] add raw video support for Samsung SUR40 touchscreen
Here's my updated version of the previous patch to add raw video streaming
support to the SUR40. So far, for reasons opaque to me, dma-contig is the
only allocator that works properly. Hoping for some feedback where the issue
might be hidden; perhaps it's related to the following test failure from
v4l2-compliance:
Streaming ioctls:
test read/write: OK
test MMAP: OK
fail: v4l2-test-buffers.cpp(951): buf.qbuf(node)
fail: v4l2-test-buffers.cpp(994): setupUserPtr(node, q)
test USERPTR: FAIL
test DMABUF: Cannot test, specify --expbuf-device
Total: 45, Succeeded: 44, Failed: 1, Warnings: 0
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/Kconfig | 2 +
drivers/input/touchscreen/sur40.c | 422 --
2 files changed, 412 insertions(+), 12 deletions(-)
diff --git a/drivers/input/touchscreen/Kconfig
b/drivers/input/touchscreen/Kconfig
index 5891752..f8d16f1 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -953,7 +953,9 @@ config TOUCHSCREEN_SUN4I
config TOUCHSCREEN_SUR40
tristate "Samsung SUR40 (Surface 2.0/PixelSense) touchscreen"
depends on USB
+ depends on MEDIA_USB_SUPPORT
select INPUT_POLLDEV
+ select VIDEOBUF2_DMA_SG
help
Say Y here if you want support for the Samsung SUR40 touchscreen
(also known as Microsoft Surface 2.0 or Microsoft PixelSense).
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index f1cb051..5962899 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -1,7 +1,7 @@
/*
* Surface2.0/SUR40/PixelSense input driver
*
- * Copyright (c) 2013 by Florian 'floe' Echtler
+ * Copyright (c) 2014 by Florian 'floe' Echtler
*
* Derived from the USB Skeleton driver 1.1,
* Copyright (c) 2003 Greg Kroah-Hartman (g...@kroah.com)
@@ -12,6 +12,9 @@
* and from the generic hid-multitouch driver,
* Copyright (c) 2010-2012 Stephane Chatty
*
+ * and from the v4l2-pci-skeleton driver,
+ * Copyright (c) Copyright 2014 Cisco Systems, Inc.
+ *
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
@@ -31,6 +34,11 @@
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
/* read 512 bytes from endpoint 0x86 -> get header + blobs */
struct sur40_header {
@@ -82,9 +90,19 @@ struct sur40_data {
struct sur40_blob blobs[];
} __packed;
+/* read 512 bytes from endpoint 0x82 -> get header below
+ * continue reading 16k blocks until header.size bytes read */
+struct sur40_image_header {
+ __le32 magic; /* "SUBF" */
+ __le32 packet_id;
+ __le32 size; /* always 0x0007e900 = 960x540 */
+ __le32 timestamp; /* milliseconds (increases by 16 or 17 each frame) */
+ __le32 unknown; /* "epoch?" always 02/03 00 00 00 */
+} __packed;
/* version information */
#define DRIVER_SHORT "sur40"
+#define DRIVER_LONG"Samsung SUR40"
#define DRIVER_AUTHOR "Florian 'floe' Echtler "
#define DRIVER_DESC"Surface2.0/SUR40/PixelSense input driver"
@@ -99,6 +117,13 @@ struct sur40_data {
/* touch data endpoint */
#define TOUCH_ENDPOINT 0x86
+/* video data endpoint */
+#define VIDEO_ENDPOINT 0x82
+
+/* video header fields */
+#define VIDEO_HEADER_MAGIC 0x46425553
+#define VIDEO_PACKET_SIZE 16384
+
/* polling interval (ms) */
#define POLL_INTERVAL 10
@@ -113,21 +138,23 @@ struct sur40_data {
#define SUR40_GET_STATE 0xc5 /* 4 bytes state (?) */
#define SUR40_GET_SENSORS 0xb1 /* 8 bytes sensors */
-/*
- * Note: an earlier, non-public version of this driver used USB_RECIP_ENDPOINT
- * here by mistake which is very likely to have corrupted the firmware EEPROM
- * on two separate SUR40 devices. Thanks to Alan Stern who spotted this bug.
- * Should you ever run into a similar problem, the background story to this
- * incident and instructions on how to fix the corrupted EEPROM are available
- * at https://floe.butterbrot.org/matrix/hacking/surface/brick.html
-*/
-
+/* master device state */
struct sur40_state {
struct usb_device *usbdev;
struct device *dev;
struct input_polled_dev *input;
+ struct v4l2_device v4l2;
+ struct video_device vdev;
+ struct mutex lock;
+
+ struct vb2_queue queue;
+ struct vb2_alloc_ctx *alloc_ctx;
+ struct list_head buf_list;
+ spinlock_t qlock;
+ int sequence;
+
struct sur40_data *bulk_in_buffer;
size_t bulk_in_size;
u8 bulk_in_epaddr;
@@ -135,6 +162,27 @@ struct sur40_state {
char phys[64];
};
+struct sur40_buffer {
+ stru
Re: [PATCH] add raw video support for Samsung SUR40 touchscreen
On 04.02.2015 11:22, Hans Verkuil wrote: > On 02/04/15 11:08, Florian Echtler wrote: >> On 04.02.2015 09:08, Hans Verkuil wrote: >>> You can also make a version with vmalloc and I'll merge that, and then >>> you can look more into the DMA issues. That way the driver is merged, >>> even if it is perhaps not yet optimal, and you can address that part later. >> OK, that sounds sensible, I will try that route. When using >> videobuf2-vmalloc, what do I pass back for alloc_ctxs in queue_setup? > vmalloc doesn't need those, so you can just drop any alloc_ctx related code. That's what I assumed, however, I'm running into the same problem as with dma-sg when I switch to vmalloc...? I've sent a "proper" patch submission again, which has all the other issues from the previous submission fixed. I'm hoping you can maybe have a closer look and see if I'm doing anything subtly wrong which causes both vmalloc and dma-sg to fail while dma-contig works. Best, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: [PATCH] add raw video support for Samsung SUR40 touchscreen
Hello Hans, On 04.02.2015 09:08, Hans Verkuil wrote: > I remain very skeptical about the use of dma-contig (or dma-sg for that > matter). Have you tried using vmalloc and check if the USB core isn't > automatically using DMA transfers for that? > > Basically I would like to see proof that vmalloc is not an option before > allowing dma-contig (or dma-sg if you can figure out why that isn't > working). > > You can also make a version with vmalloc and I'll merge that, and then > you can look more into the DMA issues. That way the driver is merged, > even if it is perhaps not yet optimal, and you can address that part later. OK, that sounds sensible, I will try that route. When using videobuf2-vmalloc, what do I pass back for alloc_ctxs in queue_setup? Best, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: [PATCH] add raw video support for Samsung SUR40 touchscreen
Sorry to bring this up again, but would it be acceptable to simply use dma-contig after all? Since the GFP_DMA flag is gone, this shouldn't be too big of an issue IMHO, and I was kind of hoping the patch could still be part of 3.20. Best, Florian On 29.01.2015 22:35, Florian Echtler wrote: > I'm still having a couple of issues sorting out the correct way to > provide DMA access for my driver. I've integrated most of your > suggestions, but I still can't switch from dma-contig to dma-sg. > As far as I understood it, there is no further initialization required > besides using vb2_dma_sg_memops, vb2_dma_sg_init_ctx and > vb2_dma_sg_cleanup_ctx instead of the respective -contig- calls, correct? > However, as soon as I swap the relevant function calls, the video image > stays black and in dmesg, I get the following warning: > > Call Trace: > [] dump_stack+0x45/0x57 > [] warn_slowpath_common+0x97/0xe0 > [] warn_slowpath_fmt+0x46/0x50 > [] usb_hcd_map_urb_for_dma+0x4eb/0x500 > [] ? schedule_timeout+0x124/0x210 > [] usb_hcd_submit_urb+0x135/0x1c0 > [] usb_submit_urb.part.8+0x1f6/0x580 > [] ? vmap_pud_range+0x122/0x1c0 > [] usb_submit_urb+0x35/0x80 > [] usb_start_wait_urb+0x6a/0x170 > [] ? usb_alloc_urb+0x1e/0x50 > [] ? usb_alloc_urb+0x1e/0x50 > [] usb_bulk_msg+0xd0/0x1a0 > [] sur40_poll+0x561/0x5e0 [sur40] > > Moreover, I'm getting the following test failure from v4l2-compliance: > > Streaming ioctls: > test read/write: OK > test MMAP: OK > fail: v4l2-test-buffers.cpp(951): buf.qbuf(node) > fail: v4l2-test-buffers.cpp(994): setupUserPtr(node, q) > test USERPTR: FAIL > test DMABUF: Cannot test, specify --expbuf-device > > Total: 45, Succeeded: 44, Failed: 1, Warnings: 0 -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: [PATCH] add raw video support for Samsung SUR40 touchscreen
Hello again, On 21.01.2015 14:29, Hans Verkuil wrote: > On 01/21/15 14:28, Florian Echtler wrote: >> On 20.01.2015 14:06, Laurent Pinchart wrote: >>> That depends on the platform and whether it can DMA to vmalloc'ed memory >>> :-) >>> To be totally safe I think vb2-dma-sg would be better, but I'm not sure >>> it's >>> worth the trouble. uvcvideo uses vb2-vmalloc as it performs a memcpy anyway. >> The SUR40 sends raw video data without any headers over the bulk >> endpoint in blocks of 16k, so I'm assuming that in this specific case, >> vb2-dma-sg would be the most efficient choice? I'm still having a couple of issues sorting out the correct way to provide DMA access for my driver. I've integrated most of your suggestions, but I still can't switch from dma-contig to dma-sg. As far as I understood it, there is no further initialization required besides using vb2_dma_sg_memops, vb2_dma_sg_init_ctx and vb2_dma_sg_cleanup_ctx instead of the respective -contig- calls, correct? However, as soon as I swap the relevant function calls, the video image stays black and in dmesg, I get the following warning: [ cut here ] WARNING: CPU: 1 PID: 37 at /home/kernel/COD/linux/drivers/usb/core/hcd.c:1504 usb_hcd_map_urb_for_dma+0x4eb/0x500() transfer buffer not dma capable Modules linked in: sur40(OE) videobuf2_dma_contig videobuf2_dma_sg videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev media dm_crypt joydev input_polldev wl(POE) snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi cfg80211 kvm_amd snd_seq kvm edac_core serio_raw snd_seq_device btusb snd_timer edac_mce_amd snd ipmi_si ipmi_msghandler k10temp sp5100_tco i2c_piix4 soundcore bnep 8250_fintek shpchp tpm_infineon rfcomm bluetooth mac_hid parport_pc ppdev lp parport hid_apple usbhid hid pata_acpi uas usb_storage amdkfd amd_iommu_v2 radeon psmouse pata_atiixp i2c_algo_bit ttm drm_kms_helper drm ahci libahci r8169 mii [last unloaded: sur40] CPU: 1 PID: 37 Comm: kworker/1:1 Tainted: P OE 3.19.0-031900rc6-generic #201501261152 Hardware name: Samsung SUR40/SDNE-R78BA2-20, BIOS SDNE-R78BA2-2000 11/04/2011 Workqueue: events_freezable input_polled_device_work [input_polldev] 05e0 8801320c3aa8 817c4584 0007 8801320c3af8 8801320c3ae8 81076df7 8800a71fa6c0 88013243f800 0010 0002 Call Trace: [] dump_stack+0x45/0x57 [] warn_slowpath_common+0x97/0xe0 [] warn_slowpath_fmt+0x46/0x50 [] usb_hcd_map_urb_for_dma+0x4eb/0x500 [] ? schedule_timeout+0x124/0x210 [] usb_hcd_submit_urb+0x135/0x1c0 [] usb_submit_urb.part.8+0x1f6/0x580 [] ? vmap_pud_range+0x122/0x1c0 [] usb_submit_urb+0x35/0x80 [] usb_start_wait_urb+0x6a/0x170 [] ? usb_alloc_urb+0x1e/0x50 [] ? usb_alloc_urb+0x1e/0x50 [] usb_bulk_msg+0xd0/0x1a0 [] sur40_poll+0x561/0x5e0 [sur40] [] input_polled_device_work+0x1b/0x30 [input_polldev] [] process_one_work+0x14d/0x460 [] worker_thread+0x11b/0x3f0 [] ? create_worker+0x1e0/0x1e0 [] kthread+0xc9/0xe0 [] ? flush_kthread_worker+0x90/0x90 [] ret_from_fork+0x7c/0xb0 [] ? flush_kthread_worker+0x90/0x90 ---[ end trace 30eaf6524fd028d3 ]--- Moreover, I'm getting the following test failure from v4l2-compliance: Streaming ioctls: test read/write: OK test MMAP: OK fail: v4l2-test-buffers.cpp(951): buf.qbuf(node) fail: v4l2-test-buffers.cpp(994): setupUserPtr(node, q) test USERPTR: FAIL test DMABUF: Cannot test, specify --expbuf-device Total: 45, Succeeded: 44, Failed: 1, Warnings: 0 Any suggestions how to deal with this? Best regards, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: [RFC PATCH 0/3] Introduce IIO interface for fingerprint sensors
Hello Teodora, On 23.01.2015 14:05, Baluta, Teodora wrote: > The fingerprint sensor acts more like a scanner device, so the > closest type is the V4L2_CAP_VIDEO_CAPTURE. However, this is not a > perfect match because the driver only sends an image, once, when > triggered. Would it be a better alternative to define a new > capability type? Or it would be acceptable to simply have a video > device with no frame buffer or frame rate and the user space > application to read from the character device /dev/videoX? Sorry if I jump in here right in the middle of this discussion, but some time ago, I wrote a fingerprint sensor driver for the Siemens ID Mouse (still part of the kernel AFAICT) which acts as a misc device and just creates a character device node that can be used to directly read a PGM file. Maybe this would be a slightly simpler approach than pulling in all the streaming-optimized features of V4L2? Best, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: [PATCH] add raw video support for Samsung SUR40 touchscreen
Hello everyone,
On 20.01.2015 14:06, Laurent Pinchart wrote:
> On Tuesday 20 January 2015 14:03:00 Hans Verkuil wrote:
>> On 01/20/15 13:59, Laurent Pinchart wrote:
>>> On Tuesday 20 January 2015 10:30:07 Hans Verkuil wrote:
I've CC-ed Laurent, I think he knows a lot more about this than I do.
Laurent, when does the USB core use DMA? What do you need to do on the
driver side to have USB use DMA when doing bulk transfers?
>>>
>>> How USB HCD drivers map buffers for DMA is HCD-specific, but all drivers
>>> exepct ehci-tegra, max3421-hcd and musb use the default implementation
>>> usb_hcd_map_urb_for_dma() (in drivers/usb/core/hcd.c).
>>>
>>> Unless the buffer has already been mapped by the USB driver (in which case
>>> the driver will have set the URB_NO_TRANSFER_DMA_MAP flag in
>>> urb->transfer_flags and initialized the urb->transfer_dma field), the
>>> function will use dma_map_sg(), dma_map_page() or dma_map_single()
>>> depending on the buffer type (controlled through urb->sg and
>>> urb->num_sgs). DMA will thus always be used *expect* if the platform uses
>>> bounce buffers when the buffer can't be mapped directly for DMA.
>>
>> So we can safely use videobuf2-vmalloc, right?
>
> That depends on the platform and whether it can DMA to vmalloc'ed memory :-)
> To be totally safe I think vb2-dma-sg would be better, but I'm not sure it's
> worth the trouble. uvcvideo uses vb2-vmalloc as it performs a memcpy anyway.
The SUR40 sends raw video data without any headers over the bulk
endpoint in blocks of 16k, so I'm assuming that in this specific case,
vb2-dma-sg would be the most efficient choice?
On that note, I've seen that vb2_dma_sg_{init|cleanup}_ctx will appear
only in 3.19. If I want to maintain a backwards-compatible version for
older kernels, what do I use in that case?
Best, Florian
--
SENT FROM MY DEC VT50 TERMINAL
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] add raw video support for Samsung SUR40 touchscreen
Hello Hans, On 19.01.2015 11:38, Hans Verkuil wrote: > Sorry for the delay. No problem, thanks for your feedback. >> Note: I'm intentionally using dma-contig instead of vmalloc, as the USB >> core apparently _will_ try to use DMA for larger bulk transfers. > As far as I can tell from looking through the usb core code it supports > scatter-gather DMA, so you should at least use dma-sg rather than dma-contig. > Physically contiguous memory should always be avoided. OK, will this work transparently (i.e. just switch from *-contig-* to *-sg-*)? If not, can you suggest an example driver to use as template? > I'm also missing a patch for the Kconfig that adds a dependency on > MEDIA_USB_SUPPORT > and that selects VIDEOBUF2_DMA_SG. Good point, will add that. >> +err_unreg_video: >> +video_unregister_device(&sur40->vdev); >> +err_unreg_v4l2: >> +v4l2_device_unregister(&sur40->v4l2); >> err_free_buffer: >> kfree(sur40->bulk_in_buffer); >> err_free_polldev: >> @@ -436,6 +604,10 @@ static void sur40_disconnect(struct usb_interface >> *interface) > Is this a hardwired device or hotpluggable? If it is hardwired, then this > code is > OK, but if it is hotpluggable, then this isn't good enough. It's hardwired. Out of curiosity, what would I have to change for a hotpluggable one? >> +i->type = V4L2_INPUT_TYPE_CAMERA; >> +i->std = V4L2_STD_UNKNOWN; >> +strlcpy(i->name, "In-Cell Sensor", sizeof(i->name)); > Perhaps just say "Sensor" here? I'm not sure what "In-Cell" means. In-cell is referring to the concept of integrating sensor pixels directly with LCD pixels, I think it's what Samsung calls it. Thanks & best regards, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
[PATCH] add raw video support for Samsung SUR40 touchscreen
This patch add support for the raw video stream from the Samsung SUR40
touchscreen device. Existing input device support is not affected by this
patch and can be used concurrently. videobuf2-dma-contig is used for buffer
management. All tests from current v4l2-compliance -s run pass (see
http://floe.butterbrot.org/external/results.txt for details).
Note: I'm intentionally using dma-contig instead of vmalloc, as the USB
core apparently _will_ try to use DMA for larger bulk transfers.
Signed-off-by: Florian Echtler
---
drivers/input/touchscreen/sur40.c | 423 --
1 file changed, 411 insertions(+), 12 deletions(-)
diff --git a/drivers/input/touchscreen/sur40.c
b/drivers/input/touchscreen/sur40.c
index f1cb051..bcd9ee2 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -1,7 +1,7 @@
/*
* Surface2.0/SUR40/PixelSense input driver
*
- * Copyright (c) 2013 by Florian 'floe' Echtler
+ * Copyright (c) 2014 by Florian 'floe' Echtler
*
* Derived from the USB Skeleton driver 1.1,
* Copyright (c) 2003 Greg Kroah-Hartman (g...@kroah.com)
@@ -12,6 +12,9 @@
* and from the generic hid-multitouch driver,
* Copyright (c) 2010-2012 Stephane Chatty
*
+ * and from the v4l2-pci-skeleton driver,
+ * Copyright (c) Copyright 2014 Cisco Systems, Inc.
+ *
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
@@ -31,6 +34,11 @@
#include
#include
#include
+#include
+#include
+#include
+#include
+#include
/* read 512 bytes from endpoint 0x86 -> get header + blobs */
struct sur40_header {
@@ -82,9 +90,19 @@ struct sur40_data {
struct sur40_blob blobs[];
} __packed;
+/* read 512 bytes from endpoint 0x82 -> get header below
+ * continue reading 16k blocks until header.size bytes read */
+struct sur40_image_header {
+ __le32 magic; /* "SUBF" */
+ __le32 packet_id;
+ __le32 size; /* always 0x0007e900 = 960x540 */
+ __le32 timestamp; /* milliseconds (increases by 16 or 17 each frame) */
+ __le32 unknown; /* "epoch?" always 02/03 00 00 00 */
+} __packed;
/* version information */
#define DRIVER_SHORT "sur40"
+#define DRIVER_LONG"Samsung SUR40"
#define DRIVER_AUTHOR "Florian 'floe' Echtler "
#define DRIVER_DESC"Surface2.0/SUR40/PixelSense input driver"
@@ -99,6 +117,13 @@ struct sur40_data {
/* touch data endpoint */
#define TOUCH_ENDPOINT 0x86
+/* video data endpoint */
+#define VIDEO_ENDPOINT 0x82
+
+/* video header fields */
+#define VIDEO_HEADER_MAGIC 0x46425553
+#define VIDEO_PACKET_SIZE 16384
+
/* polling interval (ms) */
#define POLL_INTERVAL 10
@@ -113,21 +138,23 @@ struct sur40_data {
#define SUR40_GET_STATE 0xc5 /* 4 bytes state (?) */
#define SUR40_GET_SENSORS 0xb1 /* 8 bytes sensors */
-/*
- * Note: an earlier, non-public version of this driver used USB_RECIP_ENDPOINT
- * here by mistake which is very likely to have corrupted the firmware EEPROM
- * on two separate SUR40 devices. Thanks to Alan Stern who spotted this bug.
- * Should you ever run into a similar problem, the background story to this
- * incident and instructions on how to fix the corrupted EEPROM are available
- * at https://floe.butterbrot.org/matrix/hacking/surface/brick.html
-*/
-
+/* master device state */
struct sur40_state {
struct usb_device *usbdev;
struct device *dev;
struct input_polled_dev *input;
+ struct v4l2_device v4l2;
+ struct video_device vdev;
+ struct mutex lock;
+
+ struct vb2_queue queue;
+ struct vb2_alloc_ctx *alloc_ctx;
+ struct list_head buf_list;
+ spinlock_t qlock;
+ int sequence;
+
struct sur40_data *bulk_in_buffer;
size_t bulk_in_size;
u8 bulk_in_epaddr;
@@ -135,6 +162,27 @@ struct sur40_state {
char phys[64];
};
+struct sur40_buffer {
+ struct vb2_buffer vb;
+ struct list_head list;
+};
+
+/* forward declarations */
+static struct video_device sur40_video_device;
+static struct v4l2_pix_format sur40_video_format;
+static struct vb2_queue sur40_queue;
+static void sur40_process_video(struct sur40_state *sur40);
+
+/*
+ * Note: an earlier, non-public version of this driver used USB_RECIP_ENDPOINT
+ * here by mistake which is very likely to have corrupted the firmware EEPROM
+ * on two separate SUR40 devices. Thanks to Alan Stern who spotted this bug.
+ * Should you ever run into a similar problem, the background story to this
+ * incident and instructions on how to fix the corrupted EEPROM are available
+ * at https://floe.butterbrot.org/matrix/hacking/surface/brick.html
+*/
+
+/* command wrapper */
static int sur40_command(struct sur40_state *dev,
Re: [RFC] [Patch] implement video driver for sur40
On 06.01.2015 11:23, Hans Verkuil wrote:
> On 01/06/2015 11:17 AM, Florian Echtler wrote:
>>> You're not filling in the 'field' field of struct v4l2_buffer when
>>> returning a
>>> frame. It should most likely be FIELD_NONE in your case.
>>>>fail: v4l2-test-buffers.cpp(611): buf.check(q, last_seq)
>>>>fail: v4l2-test-buffers.cpp(884): captureBufs(node, q, m2m_q,
>>>> frame_count, false)
>> OK, easy to fix. This will also influence the other two warnings, I assume?
> Most likely, yes.
Done. I would say that it's nearly ready for submission now (all tests
from v4l2-compliance -s pass), I still have to sort out all the warnings
from scripts/checkpatch.pl.
>>>> On a different note, I'm getting occasional warnings in syslog when I run
>>>> a regular video streaming application (e.g. cheese):
>> Is there another possible explanation?
> No :-)
> You are still missing a buffer somewhere. I'd have to see your latest source
> code
> to see what's wrong.
Weirdly enough, the syslog warning/error doesn't seem to occur anymore
since I've fixed the v4l2_buffer field. Perhaps some oddity within cheese?
I'm attaching the current source again for you to maybe have another
look; I will submit a proper patch in the next days.
Thanks again for your help!
Best, Florian
--
SENT FROM MY DEC VT50 TERMINAL
/*
* Surface2.0/SUR40/PixelSense input driver
*
* Copyright (c) 2013 by Florian 'floe' Echtler
*
* Derived from the USB Skeleton driver 1.1,
* Copyright (c) 2003 Greg Kroah-Hartman (g...@kroah.com)
*
* and from the Apple USB BCM5974 multitouch driver,
* Copyright (c) 2008 Henrik Rydberg (rydb...@euromail.se)
*
* and from the generic hid-multitouch driver,
* Copyright (c) 2010-2012 Stephane Chatty
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
/* read 512 bytes from endpoint 0x86 -> get header + blobs */
struct sur40_header {
__le16 type; /* always 0x0001 */
__le16 count; /* count of blobs (if 0: continue prev. packet) */
__le32 packet_id; /* unique ID for all packets in one frame */
__le32 timestamp; /* milliseconds (inc. by 16 or 17 each frame) */
__le32 unknown;/* "epoch?" always 02/03 00 00 00 */
} __packed;
struct sur40_blob {
__le16 blob_id;
u8 action; /* 0x02 = enter/exit, 0x03 = update (?) */
u8 unknown;/* always 0x01 or 0x02 (no idea what this is?) */
__le16 bb_pos_x; /* upper left corner of bounding box */
__le16 bb_pos_y;
__le16 bb_size_x; /* size of bounding box */
__le16 bb_size_y;
__le16 pos_x; /* finger tip position */
__le16 pos_y;
__le16 ctr_x; /* centroid position */
__le16 ctr_y;
__le16 axis_x; /* somehow related to major/minor axis, mostly: */
__le16 axis_y; /* axis_x == bb_size_y && axis_y == bb_size_x */
__le32 angle; /* orientation in radians relative to x axis -
actually an IEEE754 float, don't use in kernel */
__le32 area; /* size in pixels/pressure (?) */
u8 padding[32];
} __packed;
/* combined header/blob data */
struct sur40_data {
struct sur40_header header;
struct sur40_blob blobs[];
} __packed;
/* read 512 bytes from endpoint 0x82 -> get header below
* continue reading 16k blocks until header.size bytes read */
struct sur40_image_header {
__le32 magic; /* "SUBF" */
__le32 packet_id;
__le32 size; /* always 0x0007e900 = 960x540 */
__le32 timestamp; /* milliseconds (increases by 16 or 17 each frame) */
__le32 unknown; /* "epoch?" always 02/03 00 00 00 */
} __packed;
/* version information */
#define DRIVER_SHORT "sur40"
#define DRIVER_LONG"Samsung SUR40"
#define DRIVER_AUTHOR "Florian 'floe' Echtler "
#define DRIVER_DESC"Surface2.0/SUR40/PixelSense input driver"
/* vendor and device IDs */
#define ID_MICROSOFT 0x045e
#define ID_SUR40 0x0775
/* sensor resolution */
#define SENSOR_RES_X 1920
#define SENSOR_RES_Y 1080
/* touch data endpoint */
#define TOUCH_ENDPOINT 0x86
/* video data endpoint */
#define VIDEO_ENDPOINT 0x82
/* video header fields */
#define VIDEO_HEADER_MAGIC 0x46425553
#define VIDEO_PACKET_SIZE 16384
/* polling interval (ms) */
#define POLL_INTERVAL 10
/* maximum number of contacts FIXME: this is a guess? */
#define MAX_CONTACTS 64
/* control commands */
#define SUR40_GET_VERSION 0xb0 /* 12 bytes string*/
Re: [RFC] [Patch] implement video driver for sur40
On 06.01.2015 10:36, Hans Verkuil wrote:
> On 01/06/2015 10:29 AM, Florian Echtler wrote:
>> There's only one failing test left, which is this one:
>>
>> Streaming ioctls:
>> test read/write: OK
>> fail: v4l2-test-buffers.cpp(284): g_field() == V4L2_FIELD_ANY
>
> You're not filling in the 'field' field of struct v4l2_buffer when returning a
> frame. It should most likely be FIELD_NONE in your case.
>> fail: v4l2-test-buffers.cpp(611): buf.check(q, last_seq)
>> fail: v4l2-test-buffers.cpp(884): captureBufs(node, q, m2m_q,
>> frame_count, false)
OK, easy to fix. This will also influence the other two warnings, I assume?
>> On a different note, I'm getting occasional warnings in syslog when I run
>> a regular video streaming application (e.g. cheese):
>>
>> [ cut here ]
...
>> ---[ end trace 451ed974170f6e44 ]---
>>
>> Does this mean the driver consumes too much CPU resources?
>
> No, it means that your driver is not returning all buffers to vb2. Most
> likely this is missing in the vb2 stop_streaming op. When that is called
> your driver must return all buffers it has back to vb2 by calling
> vb2_buffer_done with state ERROR. The same can happen in the start_streaming
> op if that returns an error for some reason. In that case all buffers owned
> by the driver should be returned to vb2 with state QUEUED. See also
> Documentation/video4linux/v4l2-pci-skeleton.c as reference code.
I did actually build my driver code based on v4l2-pci-skeleton.c, and
I'm calling the exact same return_all_buffers function (see below) with
VB2_BUF_STATE_ERROR from my stop_streaming ioctl.
static void return_all_buffers(struct sur40_state *sur40,
enum vb2_buffer_state state)
{
struct sur40_buffer *buf, *node;
spin_lock(&sur40->qlock);
list_for_each_entry_safe(buf, node, &sur40->buf_list, list) {
vb2_buffer_done(&buf->vb, state);
list_del(&buf->list);
}
spin_unlock(&sur40->qlock);
}
Is there another possible explanation?
Thanks & best regards, Florian
--
SENT FROM MY DEC VT50 TERMINAL
signature.asc
Description: OpenPGP digital signature
Re: [RFC] [Patch] implement video driver for sur40
On Fri, 19 Dec 2014, Hans Verkuil wrote: drivers/media remains under heavy development, so for video capture drivers like yours you should always patch against either the mainline linux tree or (preferred) the media_tree.git repo (git://linuxtv.org/media_tree.git, master branch). As per your suggestion, I've switched development to 3.18, and now I'm nearly there in terms of v4l2-compliance (also see attachment). There's only one failing test left, which is this one: Streaming ioctls: test read/write: OK fail: v4l2-test-buffers.cpp(284): g_field() == V4L2_FIELD_ANY fail: v4l2-test-buffers.cpp(611): buf.check(q, last_seq) fail: v4l2-test-buffers.cpp(884): captureBufs(node, q, m2m_q, frame_count, false) test MMAP: FAIL test USERPTR: OK (Not Supported) test DMABUF: Cannot test, specify --expbuf-device Total: 45, Succeeded: 44, Failed: 1, Warnings: 0 Could you give some hints on what this means? On a different note, I'm getting occasional warnings in syslog when I run a regular video streaming application (e.g. cheese): [ cut here ] WARNING: CPU: 1 PID: 4995 at /home/apw/COD/linux/drivers/media/v4l2-core/videobuf2-core.c:2144 __vb2_queue_cancel+0x1d0/0x240 [videobuf2_core]() Modules linked in: sur40(OE) videobuf2_dma_contig videobuf2_memops videobuf2_core v4l2_common videodev media dm_crypt wl(POE) snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec_hdmi snd_hda_intel rfcomm bnep joydev input_polldev snd_hda_controller snd_hda_codec snd_hwdep kvm_amd kvm snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi edac_core snd_seq snd_seq_device serio_raw snd_timer sp5100_tco k10temp edac_mce_amd i2c_piix4 snd btusb soundcore bluetooth cfg80211 ipmi_si ppdev lp parport_pc ipmi_msghandler parport tpm_infineon mac_hid shpchp hid_apple usbhid hid uas usb_storage pata_acpi radeon i2c_algo_bit ttm psmouse drm_kms_helper pata_atiixp drm r8169 ahci mii libahci [last unloaded: sur40] CPU: 1 PID: 4995 Comm: cheese Tainted: P OE 3.17.1-031701-generic #201410150735 Hardware name: Samsung SUR40/SDNE-R78BA2-20, BIOS SDNE-R78BA2-2000 11/04/2011 0860 8800c2c1bd28 81796c37 0007 8800c2c1bd68 81074a3c 8800c2c1bd58 fff8800c05904f8 8800c05904d0 8800abd65d38 8800abd65d38 Call Trace: [] dump_stack+0x46/0x58 [] warn_slowpath_common+0x8c/0xc0 [] warn_slowpath_null+0x1a/0x20 [] __vb2_queue_cancel+0x1d0/0x240 [videobuf2_core] [] vb2_queue_release+0x1e/0x40 [videobuf2_core] [] _vb2_fop_release+0x71/0xb0 [videobuf2_core] [] vb2_fop_release+0x2e/0x50 [videobuf2_core] [] v4l2_release+0x41/0x90 [videodev] [] __fput+0xbd/0x250 [] fput+0xe/0x10 [] task_work_run+0xc4/0xe0 [] do_exit+0x196/0x470 [] ? zap_other_threads+0x82/0xa0 [] do_group_exit+0x44/0xa0 [] SyS_exit_group+0x17/0x20 [] system_call_fastpath+0x1a/0x1f ---[ end trace 451ed974170f6e44 ]--- Does this mean the driver consumes too much CPU resources? Thanks for your help & best regards, Florian -- "_Nothing_ brightens up my morning. Coffee simply provides a shade of grey just above the pitch-black of the infinite depths of the _abyss_."Driver Info: Driver name : sur40 Card type : Samsung SUR40 Bus info : usb-:00:13.2-1 Driver version: 3.17.1 Capabilities : 0x8521 Video Capture Read/Write Streaming Extended Pix Format Device Capabilities Device Caps : 0x0521 Video Capture Read/Write Streaming Extended Pix Format Compliance test for device /dev/video0 (not using libv4l2): Required ioctls: test VIDIOC_QUERYCAP: OK Allow for multiple opens: test second video open: OK test VIDIOC_QUERYCAP: OK test VIDIOC_G/S_PRIORITY: OK Debug ioctls: test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) test VIDIOC_LOG_STATUS: OK (Not Supported) Input ioctls: test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) test VIDIOC_ENUMAUDIO: OK (Not Supported) test VIDIOC_G/S/ENUMINPUT: OK test VIDIOC_G/S_AUDIO: OK (Not Supported) Inputs: 1 Audio Inputs: 0 Tuners: 0 Output ioctls: test VIDIOC_G/S_MODULATOR: OK (Not Supported) test VIDIOC_G/S_FREQUENCY: OK (Not Supported) test VIDIOC_ENUMAUDOUT: OK (Not Supported) test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) test VIDIOC_G/S_AUDOUT: OK (Not Supported) Outputs: 0 Audio Outputs: 0 Modulators: 0 Input/Output configuration ioctls: test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported) test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) test VIDIOC_DV_TIMINGS_CA
Re: [RFC] [Patch] implement video driver for sur40
On 19.12.2014 15:36, Hans Verkuil wrote:
> On 12/19/2014 03:30 PM, Florian Echtler wrote:
>> Ran the most recent version from git master, got a total of 6 fails, 4
>> of which are probably easy fixes:
>>
>>> fail: v4l2-compliance.cpp(306): missing bus_info prefix ('USB:1')
>>> test VIDIOC_QUERYCAP: FAIL
>> Changed the relevant code to:
>> usb_make_path(sur40->usbdev, cap->bus_info, sizeof(cap->bus_info));
>>
>>> fail: v4l2-test-input-output.cpp(455): could set input to invalid input 1
>>> test VIDIOC_G/S/ENUMINPUT: FAIL
>> Now returning -EINVAL when S_INPUT called with input != 0.
>>
>>> fail: v4l2-test-formats.cpp(322): !colorspace
>>> fail: v4l2-test-formats.cpp(429): testColorspace(pix.pixelformat,
>> pix.colorspace, pix.ycbcr_enc, pix.quantization)
>>> test VIDIOC_G_FMT: FAIL
>> Setting colorspace in v4l2_pix_format to V4L2_COLORSPACE_SRGB.
>>
>>> fail: v4l2-compliance.cpp(365): doioctl(node, VIDIOC_G_PRIORITY, &prio)
>>> test VIDIOC_G/S_PRIORITY: FAIL
>> Don't know how to fix this - does this mean VIDIOC_G/S_PRIORITY _must_
>> be implemented?
>>
>>> fail: v4l2-test-buffers.cpp(500): q.has_expbuf(node)
>>> test VIDIOC_EXPBUF: FAIL
>> Also not clear how to fix this one.
>>
>> Could you give some hints on the last two?
>
> Can you post the driver code you used to run these tests? And which kernel
> version
> and git tree did you base your patch on?
Driver code is attached (should be identical to the one from initial
mail). Kernel version used for the tests is 3.16.0-25 from Ubuntu
Utopic, git tree for patches is currently
https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git
I'm building the module standalone on the target machine, since it's not
powerful enough that you would want to do a full kernel build. However,
since the driver was merged into mainline, no other changes have been
made, so I think it shouldn't be a problem to patch against the original
git tree?
Best, Florian
--
SENT FROM MY DEC VT50 TERMINAL
/*
* Surface2.0/SUR40/PixelSense input driver
*
* Copyright (c) 2013 by Florian 'floe' Echtler
*
* Derived from the USB Skeleton driver 1.1,
* Copyright (c) 2003 Greg Kroah-Hartman (g...@kroah.com)
*
* and from the Apple USB BCM5974 multitouch driver,
* Copyright (c) 2008 Henrik Rydberg (rydb...@euromail.se)
*
* and from the generic hid-multitouch driver,
* Copyright (c) 2010-2012 Stephane Chatty
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
/* read 512 bytes from endpoint 0x86 -> get header + blobs */
struct sur40_header {
__le16 type; /* always 0x0001 */
__le16 count; /* count of blobs (if 0: continue prev. packet) */
__le32 packet_id; /* unique ID for all packets in one frame */
__le32 timestamp; /* milliseconds (inc. by 16 or 17 each frame) */
__le32 unknown;/* "epoch?" always 02/03 00 00 00 */
} __packed;
struct sur40_blob {
__le16 blob_id;
u8 action; /* 0x02 = enter/exit, 0x03 = update (?) */
u8 unknown;/* always 0x01 or 0x02 (no idea what this is?) */
__le16 bb_pos_x; /* upper left corner of bounding box */
__le16 bb_pos_y;
__le16 bb_size_x; /* size of bounding box */
__le16 bb_size_y;
__le16 pos_x; /* finger tip position */
__le16 pos_y;
__le16 ctr_x; /* centroid position */
__le16 ctr_y;
__le16 axis_x; /* somehow related to major/minor axis, mostly: */
__le16 axis_y; /* axis_x == bb_size_y && axis_y == bb_size_x */
__le32 angle; /* orientation in radians relative to x axis -
actually an IEEE754 float, don't use in kernel */
__le32 area; /* size in pixels/pressure (?) */
u8 padding[32];
} __packed;
/* combined header/blob data */
struct sur40_data {
struct sur40_header header;
struct sur40_blob blobs[];
} __packed;
/* read 512 bytes from endpoint 0x82 -> get header below
* continue reading 16k blocks until header.size bytes read */
struct sur40_image_header {
__le32 magic; /* "SUBF" */
__le32 packet_id;
__le32 size; /* always 0x0007e900 = 960x540 */
__le32 timestamp; /* milliseconds (increases by 16 or 17 each frame) */
__le32 unknown; /* "epoch?" always 02/03 00 00 00 */
} __packed;
/* version information */
#define DRIVER_SHORT "sur40"
#define DRIVER_LONG"Samsung SUR40
Re: [RFC] [Patch] implement video driver for sur40
On 18.12.2014 15:11, Hans Verkuil wrote:
> Run as 'v4l2-compliance -s' (-s starts streaming tests as well and it
> assumes you have a valid input signal).
> Mail if you have any questions about the v4l2-compliance output. The failure
> messages expect you to look at the v4l2-compliance source code as well,
> but even than it is not always clear what is going on.
Ran the most recent version from git master, got a total of 6 fails, 4
of which are probably easy fixes:
> fail: v4l2-compliance.cpp(306): missing bus_info prefix ('USB:1')
> test VIDIOC_QUERYCAP: FAIL
Changed the relevant code to:
usb_make_path(sur40->usbdev, cap->bus_info, sizeof(cap->bus_info));
> fail: v4l2-test-input-output.cpp(455): could set input to invalid input 1
> test VIDIOC_G/S/ENUMINPUT: FAIL
Now returning -EINVAL when S_INPUT called with input != 0.
> fail: v4l2-test-formats.cpp(322): !colorspace
> fail: v4l2-test-formats.cpp(429): testColorspace(pix.pixelformat,
pix.colorspace, pix.ycbcr_enc, pix.quantization)
> test VIDIOC_G_FMT: FAIL
Setting colorspace in v4l2_pix_format to V4L2_COLORSPACE_SRGB.
> fail: v4l2-compliance.cpp(365): doioctl(node, VIDIOC_G_PRIORITY, &prio)
> test VIDIOC_G/S_PRIORITY: FAIL
Don't know how to fix this - does this mean VIDIOC_G/S_PRIORITY _must_
be implemented?
> fail: v4l2-test-buffers.cpp(500): q.has_expbuf(node)
> test VIDIOC_EXPBUF: FAIL
Also not clear how to fix this one.
Could you give some hints on the last two?
Thanks & best regards, Florian
--
SENT FROM MY DEC VT50 TERMINAL
signature.asc
Description: OpenPGP digital signature
[RFC] [Patch] implement video driver for sur40
Hello everyone,
as promised, I've finally implemented the missing raw video feature for
the SUR40 touchscreen. Since this is a bit of a weird hybrid device
(multitouch input as well as video), I'm hoping for comments from both
communities (linux-input and linux-media). I'm also attaching the full
source code for the moment (not yet a proper patch submission) so it's
perhaps easier to get a view of the whole thing.
There's definitely some obvious cleanup still to be done (e.g. endpoint
selection), but I'd like to ask for feedback early so I can get most
issues fixed before really submitting a patch.
Thanks & best regards, Florian
--
SENT FROM MY DEC VT50 TERMINAL
/*
* Surface2.0/SUR40/PixelSense input driver
*
* Copyright (c) 2013 by Florian 'floe' Echtler
*
* Derived from the USB Skeleton driver 1.1,
* Copyright (c) 2003 Greg Kroah-Hartman (g...@kroah.com)
*
* and from the Apple USB BCM5974 multitouch driver,
* Copyright (c) 2008 Henrik Rydberg (rydb...@euromail.se)
*
* and from the generic hid-multitouch driver,
* Copyright (c) 2010-2012 Stephane Chatty
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
/* read 512 bytes from endpoint 0x86 -> get header + blobs */
struct sur40_header {
__le16 type; /* always 0x0001 */
__le16 count; /* count of blobs (if 0: continue prev. packet) */
__le32 packet_id; /* unique ID for all packets in one frame */
__le32 timestamp; /* milliseconds (inc. by 16 or 17 each frame) */
__le32 unknown;/* "epoch?" always 02/03 00 00 00 */
} __packed;
struct sur40_blob {
__le16 blob_id;
u8 action; /* 0x02 = enter/exit, 0x03 = update (?) */
u8 unknown;/* always 0x01 or 0x02 (no idea what this is?) */
__le16 bb_pos_x; /* upper left corner of bounding box */
__le16 bb_pos_y;
__le16 bb_size_x; /* size of bounding box */
__le16 bb_size_y;
__le16 pos_x; /* finger tip position */
__le16 pos_y;
__le16 ctr_x; /* centroid position */
__le16 ctr_y;
__le16 axis_x; /* somehow related to major/minor axis, mostly: */
__le16 axis_y; /* axis_x == bb_size_y && axis_y == bb_size_x */
__le32 angle; /* orientation in radians relative to x axis -
actually an IEEE754 float, don't use in kernel */
__le32 area; /* size in pixels/pressure (?) */
u8 padding[32];
} __packed;
/* combined header/blob data */
struct sur40_data {
struct sur40_header header;
struct sur40_blob blobs[];
} __packed;
/* read 512 bytes from endpoint 0x82 -> get header below
* continue reading 16k blocks until header.size bytes read */
struct sur40_image_header {
__le32 magic; /* "SUBF" */
__le32 packet_id;
__le32 size; /* always 0x0007e900 = 960x540 */
__le32 timestamp; /* milliseconds (increases by 16 or 17 each frame) */
__le32 unknown; /* "epoch?" always 02/03 00 00 00 */
} __packed;
/* version information */
#define DRIVER_SHORT "sur40"
#define DRIVER_LONG"Samsung SUR40"
#define DRIVER_AUTHOR "Florian 'floe' Echtler "
#define DRIVER_DESC"Surface2.0/SUR40/PixelSense input driver"
/* vendor and device IDs */
#define ID_MICROSOFT 0x045e
#define ID_SUR40 0x0775
/* sensor resolution */
#define SENSOR_RES_X 1920
#define SENSOR_RES_Y 1080
/* touch data endpoint */
#define TOUCH_ENDPOINT 0x86
/* video data endpoint */
#define VIDEO_ENDPOINT 0x82
/* video header fields */
#define VIDEO_HEADER_MAGIC 0x46425553
#define VIDEO_PACKET_SIZE 16384
/* polling interval (ms) */
#define POLL_INTERVAL 10
/* maximum number of contacts FIXME: this is a guess? */
#define MAX_CONTACTS 64
/* control commands */
#define SUR40_GET_VERSION 0xb0 /* 12 bytes string*/
#define SUR40_UNKNOWN10xb3 /* 5 bytes */
#define SUR40_UNKNOWN20xc1 /* 24 bytes */
#define SUR40_GET_STATE 0xc5 /* 4 bytes state (?) */
#define SUR40_GET_SENSORS 0xb1 /* 8 bytes sensors */
/*
* Note: an earlier, non-public version of this driver used USB_RECIP_ENDPOINT
* here by mistake which is very likely to have corrupted the firmware EEPROM
* on two separate SUR40 devices. Thanks to Alan Stern who spotted this bug.
* Should you ever run into a similar problem, the background story to this
* incident and instructions on how to fix the corrupted EEPROM are available
* at https://floe.butterbrot.org/matrix/hacking/surface/brick.html
*/
struct sur40_state {
struct usb_device *usbdev;
struct device *dev;
struct input_polled_dev *input;
struct v4l2_device v4l2;
struct video_device vdev;
struct mutex lock;
struct vb2_queue queue;
struct vb2_alloc_ctx *alloc_ctx;
struct list_he
Re: [RFC] video support for Samsung SUR40
On 15.12.2014 23:34, Hans Verkuil wrote: > On 12/15/2014 11:15 PM, Florian Echtler wrote: >> On 15.12.2014 17:01, Hans Verkuil wrote: >>> On 12/15/2014 04:47 PM, Florian Echtler wrote: >>> Why on earth is sur40_poll doing anything with video buffers? That's >>> all handled by vb2. As far as I can tell you can just delete everything >>> from '// deal with video data here' until the end of the poll function. >> Right now, the code doesn't do anything, but I'm planning to add the >> actual data retrieval at this point later. I'd like to use the >> input_polldev thread for this, as a) the video data should be fetched >> synchronously with the input device data and b) the thread will be >> running continuously anyway. > Ah, now I see it. One additional question you might be able to answer: if I use vb2_dma_contig_init_ctx for the allocator context, will usb_bulk_msg with a vb2_buffer then automatically use DMA? I want to avoid unnecessary memcpy operations, so ideally the USB host controller should directly put the data into the buffer which is then passed to userspace. Does this require any additional setup? >>> But, as I said, that code doesn't belong there at all, so just remove it. >> See above - that was actually intentional. It's kind of a hackish >> solution, but for the moment, I'd just like to get a video stream with >> minimal overhead, so I'm reusing the polldev thread. > OK. If you are planning to upstream this driver, then this probably needs > another look. Once I get it working, I'll submit a patch for further discussion. Best, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
Re: [RFC] video support for Samsung SUR40
Hello Hans, On 15.12.2014 17:01, Hans Verkuil wrote: > On 12/15/2014 04:47 PM, Florian Echtler wrote: >> However, I'm running into an issue I have a hard time understanding. In >> particular, as soon as I load the kernel module, I'm getting a kernel >> oops (NULL pointer dereference) in line 354 or 355 of the attached >> source code. The reason is probably that the previous check (in line >> 350) doesn't abort - even though I didn't actually provide a buffer, so >> the list_head should be empty. As no user space program has actually >> opened the video device yet, there shouldn't be any buffers queued, >> right? (AFAICT the list is initialized properly in line 490). >> I'd be quite grateful if somebody with more experience can look over the >> code and tell me what mistakes I made :-) First of all, thanks for the quick feedback. > Why on earth is sur40_poll doing anything with video buffers? That's > all handled by vb2. As far as I can tell you can just delete everything > from '// deal with video data here' until the end of the poll function. Right now, the code doesn't do anything, but I'm planning to add the actual data retrieval at this point later. I'd like to use the input_polldev thread for this, as a) the video data should be fetched synchronously with the input device data and b) the thread will be running continuously anyway. > The probably cause of the crash here is that the input device node is > created before the 'INIT_LIST_HEAD(&sur40->buf_list);' call, and since > udevd (I think) opens new devices immediately after they are created > it is likely that sur40_poll is called before buf_list is initialized. OK, that sounds plausible, will test that tomorrow. > But, as I said, that code doesn't belong there at all, so just remove it. See above - that was actually intentional. It's kind of a hackish solution, but for the moment, I'd just like to get a video stream with minimal overhead, so I'm reusing the polldev thread. Best regards, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
[RFC] video support for Samsung SUR40
Hi everyone,
I'm currently working on adding raw sensor video support for the Samsung
SUR40 touchscreen. I've finally found some useful documentation about
videobuf2, and added the required functions to the driver (without
actually delivering data so far, I just wanted to try and stream empty
frames for starters).
However, I'm running into an issue I have a hard time understanding. In
particular, as soon as I load the kernel module, I'm getting a kernel
oops (NULL pointer dereference) in line 354 or 355 of the attached
source code. The reason is probably that the previous check (in line
350) doesn't abort - even though I didn't actually provide a buffer, so
the list_head should be empty. As no user space program has actually
opened the video device yet, there shouldn't be any buffers queued,
right? (AFAICT the list is initialized properly in line 490).
I'd be quite grateful if somebody with more experience can look over the
code and tell me what mistakes I made :-)
Thanks & best regards, Florian
P.S. The SUR40 is a quite peculiar touchscreen device which does
on-board image processing to provide touch data, but also allows to
retrieve the raw video image. Unfortunately, it's a single USB device
with two endpoints for the different data types, so everything (input &
video) needs to be squeezed into one driver.
--
SENT FROM MY DEC VT50 TERMINAL
/*
* Surface2.0/SUR40/PixelSense input driver
*
* Copyright (c) 2013 by Florian 'floe' Echtler
*
* Derived from the USB Skeleton driver 1.1,
* Copyright (c) 2003 Greg Kroah-Hartman (g...@kroah.com)
*
* and from the Apple USB BCM5974 multitouch driver,
* Copyright (c) 2008 Henrik Rydberg (rydb...@euromail.se)
*
* and from the generic hid-multitouch driver,
* Copyright (c) 2010-2012 Stephane Chatty
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
* the License, or (at your option) any later version.
*/
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
/* read 512 bytes from endpoint 0x86 -> get header + blobs */
struct sur40_header {
__le16 type; /* always 0x0001 */
__le16 count; /* count of blobs (if 0: continue prev. packet) */
__le32 packet_id; /* unique ID for all packets in one frame */
__le32 timestamp; /* milliseconds (inc. by 16 or 17 each frame) */
__le32 unknown;/* "epoch?" always 02/03 00 00 00 */
} __packed;
struct sur40_blob {
__le16 blob_id;
u8 action; /* 0x02 = enter/exit, 0x03 = update (?) */
u8 unknown;/* always 0x01 or 0x02 (no idea what this is?) */
__le16 bb_pos_x; /* upper left corner of bounding box */
__le16 bb_pos_y;
__le16 bb_size_x; /* size of bounding box */
__le16 bb_size_y;
__le16 pos_x; /* finger tip position */
__le16 pos_y;
__le16 ctr_x; /* centroid position */
__le16 ctr_y;
__le16 axis_x; /* somehow related to major/minor axis, mostly: */
__le16 axis_y; /* axis_x == bb_size_y && axis_y == bb_size_x */
__le32 angle; /* orientation in radians relative to x axis -
actually an IEEE754 float, don't use in kernel */
__le32 area; /* size in pixels/pressure (?) */
u8 padding[32];
} __packed;
/* combined header/blob data */
struct sur40_data {
struct sur40_header header;
struct sur40_blob blobs[];
} __packed;
/* version information */
#define DRIVER_SHORT "sur40"
#define DRIVER_LONG"Samsung SUR40"
#define DRIVER_AUTHOR "Florian 'floe' Echtler "
#define DRIVER_DESC"Surface2.0/SUR40/PixelSense input driver"
/* vendor and device IDs */
#define ID_MICROSOFT 0x045e
#define ID_SUR40 0x0775
/* sensor resolution */
#define SENSOR_RES_X 1920
#define SENSOR_RES_Y 1080
/* touch data endpoint */
#define TOUCH_ENDPOINT 0x86
/* video data endpoint */
#define VIDEO_ENDPOINT 0x82
/* polling interval (ms) */
#define POLL_INTERVAL 10
/* maximum number of contacts FIXME: this is a guess? */
#define MAX_CONTACTS 64
/* control commands */
#define SUR40_GET_VERSION 0xb0 /* 12 bytes string*/
#define SUR40_UNKNOWN10xb3 /* 5 bytes */
#define SUR40_UNKNOWN20xc1 /* 24 bytes */
#define SUR40_GET_STATE 0xc5 /* 4 bytes state (?) */
#define SUR40_GET_SENSORS 0xb1 /* 8 bytes sensors */
/*
* Note: an earlier, non-public version of this driver used USB_RECIP_ENDPOINT
* here by mistake which is very likely to have corrupted the firmware EEPROM
* on two separate SUR40 devices. Thanks to Alan Stern who spotted this bug.
* Should you ever run into a similar problem, the background story to this
* incident and instructions on how to fix the corrupted EEPROM are available
* at https://floe.butterbrot.org/matrix/hacking/surface/brick.html
*/
struct sur40_state {
struct usb_device *usbdev
[sur40] videobuf2 and/or DMA?
Hello everyone, I'm preparing to finally add support for the raw sensor video stream to my driver for the SUR40 touchscreen. However, after an extensive amount of Googling, I'm still not clear on the relationship between DMA transfers, the USB core and the videobuf2 framework. Specifically, I'd like to know: - Can I always use DMA on the USB side (for bulk transfers), or does this in any way require support from the USB device's hardware? (I'm guessing no, but a definite answer would be great.) - Regardless of the USB side of things, can I use the videobuf2 framework without _having_ to use DMA? That way, I could get a basic driver running without DMA and switch later when it's convenient and/or the speedup is justified. Thanks & best regards, Florian -- SENT FROM MY DEC VT50 TERMINAL signature.asc Description: OpenPGP digital signature
gspca_vc032x: Sensor MI1320 in Samsung Q1 Ultra not working
Hello everyone, I've installed the latest & greatest v4l drivers from http://linuxtv.org/hg/~jfrancois/gspca/ and tried to use the camera on a Samsung Q1 Ultra with them. The camera reports as Bus 001 Device 005: ID 0ac8:c301 Z-Star Microelectronics Corp. and the gspca_vc032x driver recognizes it - dmesg shows: [ 703.298585] Linux video capture interface: v2.00 [ 703.313857] gspca: main v2.7.0 registered [ 703.321625] gspca: probing 0ac8:c301 [ 703.322554] vc032x: check sensor header 20 [ 703.509321] vc032x: Sensor ID 148c (14) [ 703.509334] vc032x: Find Sensor MI1320_SOC [ 703.511699] gspca: probe ok [ 703.511764] usbcore: registered new interface driver vc032x [ 703.511775] vc032x: registered However, no video tool works. cheese always reports "libv4l2: error dequeuing buf: Input/output error" and the svv tool from the linuxtv website just shows a green screen, nothing else. At one point, I've also seen an error message in the log along the lines of "frame overflow 616416 > 614400". Does anybody have a hint for me how to fix this? Thanks, Yours, Florian -- 0666 - Filemode of the Beast signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
