All of lore.kernel.org
 help / color / mirror / Atom feed
* Dual touchscreen implementation
@ 2010-08-10 23:16 Arce, Abraham
  2010-08-13  7:50 ` Dmitry Torokhov
  0 siblings, 1 reply; 5+ messages in thread
From: Arce, Abraham @ 2010-08-10 23:16 UTC (permalink / raw)
  To: linux-input

Hi,

I am working in a board with dual display/touchscreen. I have searched within drivers/input/touchscreen for some examples on how to implement the functionality to configure driver and behave as a single touchscreen if 2 sensors are present, no specific example found

My idea is to create an attribute "virtualized" to enable/disable virtualization in the second touchscreen

+ static DEVICE_ATTR(virtualized, S_IRUGO | S_IWUSR,
+ 		   syn_show_attr_virtualized, syn_store_attr_virtualized);


In the function which reports the values to input subsystem we can then decide to make the second one as an extension of the first touchscreen if

* virtualized is set to 1
* and touchscreen sensor is the second one


 + if (ts->virtualized && dev_name(&sensor->dev == '2')
 +	data->x = ts->touch_caps.max_x + d->x;
 [..]
 + input_report_abs(idev, ABS_x, data->x);


I'd appreciate any comments on this approach...

Best Regards
Abraham


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Dual touchscreen implementation
  2010-08-10 23:16 Dual touchscreen implementation Arce, Abraham
@ 2010-08-13  7:50 ` Dmitry Torokhov
  2010-08-13  8:40   ` Arce, Abraham
  0 siblings, 1 reply; 5+ messages in thread
From: Dmitry Torokhov @ 2010-08-13  7:50 UTC (permalink / raw)
  To: Arce, Abraham; +Cc: linux-input

Hi,

On Tue, Aug 10, 2010 at 06:16:27PM -0500, Arce, Abraham wrote:
> Hi,
> 
> I am working in a board with dual display/touchscreen. I have searched within drivers/input/touchscreen for some examples on how to implement the functionality to configure driver and behave as a single touchscreen if 2 sensors are present, no specific example found
> 
> My idea is to create an attribute "virtualized" to enable/disable virtualization in the second touchscreen
> 
> + static DEVICE_ATTR(virtualized, S_IRUGO | S_IWUSR,
> + 		   syn_show_attr_virtualized, syn_store_attr_virtualized);
> 
> 
> In the function which reports the values to input subsystem we can then decide to make the second one as an extension of the first touchscreen if
> 
> * virtualized is set to 1
> * and touchscreen sensor is the second one
> 
> 
>  + if (ts->virtualized && dev_name(&sensor->dev == '2')
>  +	data->x = ts->touch_caps.max_x + d->x;
>  [..]
>  + input_report_abs(idev, ABS_x, data->x);
> 
> 
> I'd appreciate any comments on this approach...
> 

Does the kernel have to do that? I'd say it is userspace task to
[re]interpret events.

-- 
Dmitry

^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: Dual touchscreen implementation
  2010-08-13  7:50 ` Dmitry Torokhov
@ 2010-08-13  8:40   ` Arce, Abraham
  2010-08-17 14:06     ` Murphy, Dan
  0 siblings, 1 reply; 5+ messages in thread
From: Arce, Abraham @ 2010-08-13  8:40 UTC (permalink / raw)
  To: Dmitry Torokhov; +Cc: linux-input

Hi Dmitry,

> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> 
> > I am working in a board with dual display/touchscreen. I have searched
> within drivers/input/touchscreen for some examples on how to implement the
> functionality to configure driver and behave as a single touchscreen if 2
> sensors are present, no specific example found
> >
> > My idea is to create an attribute "virtualized" to enable/disable
> virtualization in the second touchscreen
> >
> > + static DEVICE_ATTR(virtualized, S_IRUGO | S_IWUSR,
> > + 		   syn_show_attr_virtualized, syn_store_attr_virtualized);
> >
> >
> > In the function which reports the values to input subsystem we can then
> decide to make the second one as an extension of the first touchscreen if
> >
> > * virtualized is set to 1
> > * and touchscreen sensor is the second one
> >
> >
> >  + if (ts->virtualized && dev_name(&sensor->dev == '2')
> >  +	data->x = ts->touch_caps.max_x + d->x;
> >  [..]
> >  + input_report_abs(idev, ABS_x, data->x);
> >
> >
> > I'd appreciate any comments on this approach...
> >
> 
> Does the kernel have to do that? I'd say it is userspace task to
> [re]interpret events.

That was a first thinking however your point makes more sense. I'll explore and get more information on how Ubuntu or Android may implement it and get back with final resolution.

Thanks a lot!

Best Regards
Abraham


^ permalink raw reply	[flat|nested] 5+ messages in thread

* RE: Dual touchscreen implementation
  2010-08-13  8:40   ` Arce, Abraham
@ 2010-08-17 14:06     ` Murphy, Dan
  2010-08-20  5:01       ` Dmitry Torokhov
  0 siblings, 1 reply; 5+ messages in thread
From: Murphy, Dan @ 2010-08-17 14:06 UTC (permalink / raw)
  To: Arce, Abraham, Dmitry Torokhov; +Cc: linux-input

Abraham
	My thoughts would be similar to Dmitry's.  We should let the user space figure it out.  Then the application itself can combine and render the touches as a contiguous touch screen or as an independent touch.

But we would probably need a way for the kernel driver to identify which touch controller that the information came from.

For multi touch we may be able to use ABS_MT_TRACKING_ID for passing up the controller ID but there is not really a good code for the standard ABS axes.  Maybe we can make one called ABS_TRACKING_ID to keep with the theme.

This way the user space and use that to know where it came from.

Or Dmitry if you have any patches or thoughts let me know.

Dan

-----Original Message-----
From: linux-input-owner@vger.kernel.org [mailto:linux-input-owner@vger.kernel.org] On Behalf Of Arce, Abraham
Sent: Friday, August 13, 2010 3:40 AM
To: Dmitry Torokhov
Cc: linux-input@vger.kernel.org
Subject: RE: Dual touchscreen implementation

Hi Dmitry,

> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> 
> > I am working in a board with dual display/touchscreen. I have searched
> within drivers/input/touchscreen for some examples on how to implement the
> functionality to configure driver and behave as a single touchscreen if 2
> sensors are present, no specific example found
> >
> > My idea is to create an attribute "virtualized" to enable/disable
> virtualization in the second touchscreen
> >
> > + static DEVICE_ATTR(virtualized, S_IRUGO | S_IWUSR,
> > + 		   syn_show_attr_virtualized, syn_store_attr_virtualized);
> >
> >
> > In the function which reports the values to input subsystem we can then
> decide to make the second one as an extension of the first touchscreen if
> >
> > * virtualized is set to 1
> > * and touchscreen sensor is the second one
> >
> >
> >  + if (ts->virtualized && dev_name(&sensor->dev == '2')
> >  +	data->x = ts->touch_caps.max_x + d->x;
> >  [..]
> >  + input_report_abs(idev, ABS_x, data->x);
> >
> >
> > I'd appreciate any comments on this approach...
> >
> 
> Does the kernel have to do that? I'd say it is userspace task to
> [re]interpret events.

That was a first thinking however your point makes more sense. I'll explore and get more information on how Ubuntu or Android may implement it and get back with final resolution.

Thanks a lot!

Best Regards
Abraham

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Dual touchscreen implementation
  2010-08-17 14:06     ` Murphy, Dan
@ 2010-08-20  5:01       ` Dmitry Torokhov
  0 siblings, 0 replies; 5+ messages in thread
From: Dmitry Torokhov @ 2010-08-20  5:01 UTC (permalink / raw)
  To: Murphy, Dan; +Cc: Arce, Abraham, linux-input

Hi Dan,

On Tue, Aug 17, 2010 at 09:06:00AM -0500, Murphy, Dan wrote:
> Abraham
>
> My thoughts would be similar to Dmitry's.  We should let the user
> space figure it out.  Then the application itself can combine and
> render the touches as a contiguous touch screen or as an independent
> touch.
> 
> But we would probably need a way for the kernel driver to identify
> which touch controller that the information came from.
> 
> For multi touch we may be able to use ABS_MT_TRACKING_ID for passing
> up the controller ID but there is not really a good code for the
> standard ABS axes.  Maybe we can make one called ABS_TRACKING_ID to
> keep with the theme.
> 
> This way the user space and use that to know where it came from.
> 
> Or Dmitry if you have any patches or thoughts let me know.
> 

I am confused - you should have 2 device nodes for each pf your
controllers and so you should be able to figure out what device
particular event is coming from. What am I missing here?

Thanks.

-- 
Dmitry

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2010-08-20  5:01 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-08-10 23:16 Dual touchscreen implementation Arce, Abraham
2010-08-13  7:50 ` Dmitry Torokhov
2010-08-13  8:40   ` Arce, Abraham
2010-08-17 14:06     ` Murphy, Dan
2010-08-20  5:01       ` Dmitry Torokhov

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.