On Fri, Dec 03, 2010 at 05:41:59PM -0800, Ping Cheng wrote: > On Thu, Dec 2, 2010 at 7:37 AM, Daniel Stone <[email protected]> wrote: > > On Thu, Dec 02, 2010 at 10:34:44AM -0500, Chase Douglas wrote: > >> On 12/02/2010 10:28 AM, Daniel Stone wrote: > >> > On Thu, Dec 02, 2010 at 10:06:01AM -0500, Chase Douglas wrote: > >> >> Instead, we could create separate input devices for the strip and the > >> >> touchscreen. The strip would be a dependent device, and would usually be > >> >> attached to the same MD as the touch screen. However, it could also be > >> >> attached to a different MD, allowing for more interesting mixing and > >> >> matching of input devices. > >> > > >> > We could make the mode in the touch class a bitmask of direct and > >> > dependent, and let the driver tell us at touch creation time whether the > >> > touch should be direct or dependent? > >> > >> That doesn't resolve the issue of sending two separate touch events from > >> two separate "devices" through one XI device. What if the intuos had > >> another touch strip? The touch event would have to distinguish between > >> the two strips somehow. I think the only way to do that would be through > >> a valuator, which would just be fitting a square peg into a round hole. > > > > Indeed. If we need to distinguish between the different touch strips, > > then the only option is having multiple devices, and at that stage I > > think we should really revisit the idea of a deeper device hierachy > > (e.g. MD #1 -> Wacom tablet #1 -> {Pen, Eraser, touch strip #1, touch > > strip #2}). > > I think we don't need to consider each touch strip as an independent > device. They can be grouped together as one device, called pad in > xf86-input-wacom now. The two strip data are then reported through two > axes of the pad. The problem is that pad does not sent motion events > since it is not a true pointer device. The events that invoked by the > strips are posted to wherever the current cursor is. In order to use > the XInput 1.0 design, we had to set pad to relative mode so it won't > move the cursor to (0.0).
That's an X server bug that IIRC has been fixed with 1.9. Cheers, Peter > But, clients would like to have those strip data in absolute value. > > As Chase pointed out above, potentially, there is another approach for > us: attaching the strips as an extra feature to the tool that is on > the tablet. The tool can be a stylus/eraser/mouse or a touch depending > on which tool the strip data are reported with. This idea was > suggested by Dmitry at linux-input mailing list recently. However, > even with this approach, we still need to deal with the strips as an > independent device when no tool is on the tablet for strips to attach > to. The need of per-axis based mode mask stays. (x,y) will always be > in the same mode, I guess. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
