This is a request for comments and suggestions regarding
support for new pointer devices.
I've completed changes to support a new pointer device, the
USAR/Semtech ScreenCoder, which is designed to generate relative
or absolution position information from a touch screen, as
well as merge positioning information from an external pointer.
My specific implementation is for the ViewSonic ViewPad 1000,
which has a remote keyboard with two buttons and "integrated"
pointing control (a button with x & y tilt).
Because the ScreenCoder behaves like a PS/2 device, I've chosen
to fold changes into .../xfree86/input/mouse/mouse.c source.
As a matter of fact, the touch screen works just fine with no
changes to X11...if you're willing to accept relative cursor
motion information from the screen. Unfortunately, that doesn't
help if one wants to "tap" on screen icons.
My changes add a new protocol, PROT_SCPS2, which has its own
initialization string to enable absolute position from the
screen. When this initialization is complete, there appears a
2nd packet format in the data stream, distinguished by a pattern
in the first byte (bit 3 is zero). When the new protocol
handler in MouseReadInput deals with this second format, it sets
a distinguishing bit "MSE_ABSOLUTE_POSN" (which I defined as
(1<<MSE_MAXBUTTONS) in .../xfree86/os-support/xf86OSmouse.h)
in "buttons" to indicate dx and dy are absolute positions.
Based on this flag, a modified MouseDoPostEvent calls
xf86PostMotionEvent with its 2nd argument set to 1.
My issues/concerns/questions are as follows:
(1) The initialization sequence contains four steps: "set
sample rate", "set sample rate", "set sample rate", and "read
device type". The fourth of which calls for a response byte to
be read. I've hacked initPs2 to recognize and deal with this
special case, but I'd like a cleaner solution. (Boring details:
I've changed the block of code in the "#ifdef EXTMOUSEDEBUG"
just below "if (paramlen > 0)" to check for a value "255",
so it is interpreted as "don't write, just read and discard".)
Does anyone have any suggestions on how to do this better?
(2) Since writing the driver, I've acquired the proper spec from
Semtech and have found the screen can also be configured to emit
Intellimouse PS/2 or Intellimouse Explorer PS/2 packets. In one
sense, I had coded for the ViewPad 1000, not the ScreenCoder,
because I assumed the second source is a simple PS/2, not some
other varient.
This new understanding may force me to add at least two more
varient protocols. I haven't received a reply from Semtech
on this morning's note, but I don't see how the manufacturer
could constrain the type of external pointer to be plugged into
the ScreenCoder, so it appears that almost any kind of device
could be plugged in as the external pointer. This leads to
the question:
Has there been any discussion on how to handle two devices
in a single byte stream?
At first blush, it seems necessary to add new protocols for
each combination of ScreenCoder and external pointer device
protocol, but I've got an idea I'd like to be reviewed by
others with more experience.
When I put the ScreenCoder into absolute mode from the start,
I can disambiguate the packets, and dispatch the relative
packets to an interpretation routine specified by an entry
in the mousePriv table.
In broad terms, I propose changing MouseReadInput along
these lines,
dz = dw = 0;
switch (pMse->protocolID) {
to
dz = dw = 0;
tmpProto = pMse->protocolID;
if (tmpProto == PROT_SCPS2) {
if (pBuf[0] & 0x08){
/* it belongs to the external pointer */
tmpProto = pMse->mousePriv.extendedProtID:
}else{
/* deal with absolute positioning information */
tmpProto = PROT_SKIP;
...
}
}
switch (tmpProto) {
case PROT_SKIP:
break;
or perhaps
dz = dw = 0;
tmpProto = pMse->protocolID;
switch (tmpProto) {
case PROT_SCPS2:
if (pBuf[0] & 0x08){
/* it belongs to the external pointer */
tmpProto = pMse->mousePriv.extendedProtID:
}else{
/* deal with absolute positioning information */
...
tmpProto = PROT_SKIP;
}
break;
}
switch (tmpProto) {
case PROT_SKIP:
break;
with corresponding changes elsewhere to support this.
Is this reasonable?
(3) The "proto" table has entries which are used to validata
the data stream. Is it reasonable to do something similar
to the above change to validate the two different packet
formats?
Other newbie questions:
(4) I notice comments in the source such as "* [KAZU-030897]"
Is there some way to map this to a person or e-mail address?
(5) Once I've finished, what is the process to get this
code included in future releases of XFree86?
Randoph Bentson
[EMAIL PROTECTED]
_______________________________________________
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
