Touch Screen Miniport Driver

Shreshth_Luthra · October 11, 2006, 2:01pm

Hi All,

One of our client has asked us to think on a miniport driver for a touch
screen which is going to reside between the Mouse Class Driver and the COM
Port Driver on the WinXP Professional Machine.
COM port of PC is connected via a RS232 interface to a third party interface
which on the other side is having a Microcontroller or Win XP Embedded(Touch
Panel + SVGA Touch Screen + Microcontroller).

As per the diagram, which is the only input i am having at present, it works
like this.
Whenever there is a click or activity on the Touch Panel, the third Party
interface picks up the the signal ( mouse depressed or released ) and send
it to the WinXP machine which after doing some calibrations and mappings as
per the Resolution of the Touch Screen sends this signal back to the third
party which then affects the output on the Screen and thus the
microcontroller.

Conceptually the thing look fine, but i am having a few doubts related to
it.

As per my understanding, the Touch Screen Miniport driver that we are going
to write is itself going to be a Mouse Driver, then what is the role of
Mouse Driver on the other side (which he is saying that is needed for
emulation of co-ordinates of Touch Panel).
If not a Mouse type driver what is the Miniport driver going to be.

For a Touch Screen Miniport driver is there a standard set of signals
(packets) that the Third Party Interface is going to send/recieve to/from
COM Port Driver or it could be anything (Because this needs to be
interpreted by the Miniport Driver that we may be writing).

Except for communication with COM Port, calibraion and emulation, is there
anything else that my Miniport Driver might have to take care of.

Thanks for your reply.

Thanks and Regards,
Shreshth

Ray_Trent · October 11, 2006, 2:38pm

This sounds like a very confused design.

Let me see if I understand:

The main machine is running XP. It wants to receive input from a
TouchScreen. It wants to control its own cursor (i.e. the TouchScreen is
the primary screen connected to the host) and it wants to control it in
an absolute position sense.

If that’s all the case, then yes, you need a mouse driver. It don’t know
that I would call it a mini-port driver, exactly, because it’s just a
serial mouse driver. Look at the WDK’s sermouse sample for examples of
using the com port from the kernel. In terms of mapping the absolute
position, you just need to make your calculations (be careful about
using floating point) and report the position using the MOUCLASS
interface that’s documented (passing in the flag that says its an
absolute coordinate). The OS and display driver should take care of
putting the cursor on the display.

I’ll also point out that in a lot of situations, you don’t even need to
write a driver to do this. If your environment is one where you can have
a user-mode application running, it can just open the COM port, do it’s
calculations (with no worries about floating point and full math
libraries), and then call SendInput to control the cursor.

If, on the other hand, you’re trying to do something weird like having 2
cursors on 2 different screens, or you’re trying to operating another
computer’s monitor’s cursor or something, very different solutions will
be needed (and the 2 cursor solution will probably be impossible in the
general case, but that’s another story). Please clarify.

Shreshth Luthra wrote:

Hi All,

One of our client has asked us to think on a miniport driver for a touch
screen which is going to reside between the Mouse Class Driver and the
COM Port Driver on the WinXP Professional Machine.
COM port of PC is connected via a RS232 interface to a third party
interface which on the other side is having a Microcontroller or Win XP
Embedded(Touch Panel + SVGA Touch Screen + Microcontroller).

As per the diagram, which is the only input i am having at present, it
works like this.
Whenever there is a click or activity on the Touch Panel, the third
Party interface picks up the the signal ( mouse depressed or released )
and send it to the WinXP machine which after doing some calibrations and
mappings as per the Resolution of the Touch Screen sends this signal
back to the third party which then affects the output on the Screen and
thus the microcontroller.

Conceptually the thing look fine, but i am having a few doubts related
to it.

As per my understanding, the Touch Screen Miniport driver that we are
going to write is itself going to be a Mouse Driver, then what is the
role of Mouse Driver on the other side (which he is saying that is
needed for emulation of co-ordinates of Touch Panel).
If not a Mouse type driver what is the Miniport driver going to be.

For a Touch Screen Miniport driver is there a standard set of signals
(packets) that the Third Party Interface is going to send/recieve
to/from COM Port Driver or it could be anything (Because this needs to
be interpreted by the Miniport Driver that we may be writing).

Except for communication with COM Port, calibraion and emulation, is
there anything else that my Miniport Driver might have to take care of.

Thanks for your reply.

Thanks and Regards,
Shreshth

–
Ray
(If you want to reply to me off list, please remove “spamblock.” from my
email address)

Shreshth_Luthra · October 11, 2006, 3:14pm

Hi Ray,

First of all thanks for your reply.
I think, i having rather confused the things.

See, even i am not having full information. It is just based on the things
avaiable with me.

Take an example of an Third Party Interface ‘TPI’ which is understanding the
Touch Panel’s Voltage signals.
On one side of TPI is a MicroController having 3 parts:

a Touch Panel (1024 x 1024). You can assume a sort of Finger Mouse.
a LCD Display (800 X480)
and ofcourse the core Microcontroller which is displaying the things onto
the Display Screen (as per the clicks on Touch Panel)

Now suppose the we clicked on the co-ordinate (10,20) of our Touch Panel.
The signal of Left Click would be sent to the Third Party Interface TPI
(along with co-ordinates) which will then communicate with COM port of PC
and further with our MiniPort Driver.

The MniPort Driver will in turn, map the co-ordinates as per the resolution
of LCD Display and after doing calibrations, will send the signal back to
the TPI, which in turn will be provided it to the the MicroController.
The MicroController will then show that Mouse Pointer on the LCD Display at
the co-ordinates corresponding to (10,20) of 1024x1024.
e.g. X= 10/1024 x 800
Y = 20/1024 x 480

The only signals the TPI is going to recieve from MicroController are Single
Click, Double Click and Drag (all of them along with the co-ordinates)

I hope things will be better clear to you now.

Now i want to know what all will be there in the Scope of TouchPanel
MiniPort Driver, responsiblew for emulation and Calibrations.
And how to go about it (e.g. start with a Mouse Class Driver)

Also i would like to tell that the Mouse Class Driver above our TouchPanel
MiniPort Driver already exists.

Thanks alot.

Regards,
Shreshth

On 10/12/06, Ray Trent wrote:
>
> This sounds like a very confused design.
>
> Let me see if I understand:
>
> The main machine is running XP. It wants to receive input from a
> TouchScreen. It wants to control its own cursor (i.e. the TouchScreen is
> the primary screen connected to the host) and it wants to control it in
> an absolute position sense.
>
> If that’s all the case, then yes, you need a mouse driver. It don’t know
> that I would call it a mini-port driver, exactly, because it’s just a
> serial mouse driver. Look at the WDK’s sermouse sample for examples of
> using the com port from the kernel. In terms of mapping the absolute
> position, you just need to make your calculations (be careful about
> using floating point) and report the position using the MOUCLASS
> interface that’s documented (passing in the flag that says its an
> absolute coordinate). The OS and display driver should take care of
> putting the cursor on the display.
>
> I’ll also point out that in a lot of situations, you don’t even need to
> write a driver to do this. If your environment is one where you can have
> a user-mode application running, it can just open the COM port, do it’s
> calculations (with no worries about floating point and full math
> libraries), and then call SendInput to control the cursor.
>
> If, on the other hand, you’re trying to do something weird like having 2
> cursors on 2 different screens, or you’re trying to operating another
> computer’s monitor’s cursor or something, very different solutions will
> be needed (and the 2 cursor solution will probably be impossible in the
> general case, but that’s another story). Please clarify.
>
> Shreshth Luthra wrote:
> > Hi All,
> >
> >
> > One of our client has asked us to think on a miniport driver for a touch
> > screen which is going to reside between the Mouse Class Driver and the
> > COM Port Driver on the WinXP Professional Machine.
> > COM port of PC is connected via a RS232 interface to a third party
> > interface which on the other side is having a Microcontroller or Win XP
> > Embedded(Touch Panel + SVGA Touch Screen + Microcontroller).
> >
> > As per the diagram, which is the only input i am having at present, it
> > works like this.
> > Whenever there is a click or activity on the Touch Panel, the third
> > Party interface picks up the the signal ( mouse depressed or released )
> > and send it to the WinXP machine which after doing some calibrations and
> > mappings as per the Resolution of the Touch Screen sends this signal
> > back to the third party which then affects the output on the Screen and
> > thus the microcontroller.
> >
> > Conceptually the thing look fine, but i am having a few doubts related
> > to it.
> >
> > As per my understanding, the Touch Screen Miniport driver that we are
> > going to write is itself going to be a Mouse Driver, then what is the
> > role of Mouse Driver on the other side (which he is saying that is
> > needed for emulation of co-ordinates of Touch Panel).
> > If not a Mouse type driver what is the Miniport driver going to be.
> >
> > For a Touch Screen Miniport driver is there a standard set of signals
> > (packets) that the Third Party Interface is going to send/recieve
> > to/from COM Port Driver or it could be anything (Because this needs to
> > be interpreted by the Miniport Driver that we may be writing).
> >
> > Except for communication with COM Port, calibraion and emulation, is
> > there anything else that my Miniport Driver might have to take care of.
> >
> >
> > Thanks for your reply.
> >
> > Thanks and Regards,
> > Shreshth
>
> –
> Ray
> (If you want to reply to me off list, please remove “spamblock.” from my
> email address)
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

Tim_Roberts · October 11, 2006, 4:10pm

Shreshth Luthra wrote:

Take an example of an Third Party Interface ‘TPI’ which
is understanding the Touch Panel’s Voltage signals.
On one side of TPI is a MicroController having 3 parts:

a Touch Panel (1024 x 1024). You can assume a sort of Finger Mouse.

a LCD Display (800 X480)

and ofcourse the core Microcontroller which is displaying the
things onto the Display Screen (as per the clicks on Touch Panel)

Why is the microcontroller displaying anything on the screen? Is the
panel not the system’s main output device? If so, then won’t the
Windows display driver be doing all of the drawing on the LCD panel?

Now suppose the we clicked on the co-ordinate (10,20) of our Touch
Panel. The signal of Left Click would be sent to the Third Party
Interface TPI (along with co-ordinates) which will then communicate
with COM port of PC and further with our MiniPort Driver.

The MniPort Driver will in turn, map the co-ordinates as per the
resolution of LCD Display and after doing calibrations, will send the
signal back to the TPI, which in turn will be provided it to the the
MicroController.
The MicroController will then show that Mouse Pointer on the LCD
Display at the co-ordinates corresponding to (10,20) of 1024x1024.
e.g. X= 10/1024 x 800
Y = 20/1024 x 480

If I had to wager, I’d wager that the microcontroller is not the thing
that is showing the mouse pointer on the LCD display. Rather, the mouse
pointer will be drawn or managed by the display driver running in the XP
system as part of its normal duties.

If that is true, then the ONLY thing you need to provide is a way to
intercept the touch panel’s signals and feed them up to the standard
mouse port driver.

Now i want to know what all will be there in the Scope of TouchPanel
MiniPort Driver, responsiblew for emulation and Calibrations.

Usually, this is done by a standalone user-mode application. Many
Windows CE devices do this.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Ray_Trent · October 11, 2006, 4:28pm

Hmmm. Still not entirely sure I understand this setup, but it sounds
like the touchscreen is not actually a display on the computer your
driver would be running on, but it merely a display being controlled by
some other system/controller/computer/something.

In that case, it doesn’t make sense for your driver to be a mouse
driver, because those control the cursor on displays being controlled by
the host running the driver.

In fact, it doesn’t sound to me like you need a driver at all. A
user-mode service would be quite adequate. If it’s a captured vertical
application system like a kiosk or something, you might even be able to
get away with a user-mode app running normally on the system.

All you have to do is open the COM port, read from it and write to it,
right? No driver is needed to do those things. You only need a driver to
move the real Windows pointer on a real Windows display.

Shreshth Luthra wrote:

Hi Ray,

First of all thanks for your reply.
I think, i having rather confused the things.

See, even i am not having full information. It is just based on the
things avaiable with me.

Take an example of an Third Party Interface ‘TPI’ which is understanding
the Touch Panel’s Voltage signals.
On one side of TPI is a MicroController having 3 parts:

a Touch Panel (1024 x 1024). You can assume a sort of Finger Mouse.

a LCD Display (800 X480)

and ofcourse the core Microcontroller which is displaying the things
onto the Display Screen (as per the clicks on Touch Panel)

Now suppose the we clicked on the co-ordinate (10,20) of our Touch
Panel. The signal of Left Click would be sent to the Third Party
Interface TPI (along with co-ordinates) which will then communicate with
COM port of PC and further with our MiniPort Driver.

The MniPort Driver will in turn, map the co-ordinates as per the
resolution of LCD Display and after doing calibrations, will send the
signal back to the TPI, which in turn will be provided it to the the
MicroController.
The MicroController will then show that Mouse Pointer on the LCD Display
at the co-ordinates corresponding to (10,20) of 1024x1024.
e.g. X= 10/1024 x 800
Y = 20/1024 x 480

The only signals the TPI is going to recieve from MicroController are
Single Click, Double Click and Drag (all of them along with the
co-ordinates)

I hope things will be better clear to you now.

Now i want to know what all will be there in the Scope of TouchPanel
MiniPort Driver, responsiblew for emulation and Calibrations.
And how to go about it (e.g. start with a Mouse Class Driver)

Also i would like to tell that the Mouse Class Driver above our
TouchPanel MiniPort Driver already exists.

Thanks alot.

Regards,
Shreshth

On 10/12/06, *Ray Trent* > mailto:xxxxx> wrote:
>
> This sounds like a very confused design.
>
> Let me see if I understand:
>
> The main machine is running XP. It wants to receive input from a
> TouchScreen. It wants to control its own cursor (i.e. the TouchScreen is
> the primary screen connected to the host) and it wants to control it in
> an absolute position sense.
>
> If that’s all the case, then yes, you need a mouse driver. It don’t
> know
> that I would call it a mini-port driver, exactly, because it’s just a
> serial mouse driver. Look at the WDK’s sermouse sample for examples of
> using the com port from the kernel. In terms of mapping the absolute
> position, you just need to make your calculations (be careful about
> using floating point) and report the position using the MOUCLASS
> interface that’s documented (passing in the flag that says its an
> absolute coordinate). The OS and display driver should take care of
> putting the cursor on the display.
>
> I’ll also point out that in a lot of situations, you don’t even need to
> write a driver to do this. If your environment is one where you can have
> a user-mode application running, it can just open the COM port, do it’s
> calculations (with no worries about floating point and full math
> libraries), and then call SendInput to control the cursor.
>
> If, on the other hand, you’re trying to do something weird like having 2
> cursors on 2 different screens, or you’re trying to operating another
> computer’s monitor’s cursor or something, very different solutions will
> be needed (and the 2 cursor solution will probably be impossible in the
> general case, but that’s another story). Please clarify.
>
> Shreshth Luthra wrote:
> > Hi All,
> >
> >
> > One of our client has asked us to think on a miniport driver for
> a touch
> > screen which is going to reside between the Mouse Class Driver
> and the
> > COM Port Driver on the WinXP Professional Machine.
> > COM port of PC is connected via a RS232 interface to a third party
> > interface which on the other side is having a Microcontroller or
> Win XP
> > Embedded(Touch Panel + SVGA Touch Screen + Microcontroller).
> >
> > As per the diagram, which is the only input i am having at
> present, it
> > works like this.
> > Whenever there is a click or activity on the Touch Panel, the third
> > Party interface picks up the the signal ( mouse depressed or
> released )
> > and send it to the WinXP machine which after doing some
> calibrations and
> > mappings as per the Resolution of the Touch Screen sends this signal
> > back to the third party which then affects the output on the
> Screen and
> > thus the microcontroller.
> >
> > Conceptually the thing look fine, but i am having a few doubts
> related
> > to it.
> >
> > As per my understanding, the Touch Screen Miniport driver that we
> are
> > going to write is itself going to be a Mouse Driver, then what is the
> > role of Mouse Driver on the other side (which he is saying that is
> > needed for emulation of co-ordinates of Touch Panel).
> > If not a Mouse type driver what is the Miniport driver going to be.
> >
> > For a Touch Screen Miniport driver is there a standard set of signals
> > (packets) that the Third Party Interface is going to send/recieve
> > to/from COM Port Driver or it could be anything (Because this
> needs to
> > be interpreted by the Miniport Driver that we may be writing).
> >
> > Except for communication with COM Port, calibraion and emulation, is
> > there anything else that my Miniport Driver might have to take
> care of.
> >
> >
> > Thanks for your reply.
> >
> > Thanks and Regards,
> > Shreshth
>
> –
> Ray
> (If you want to reply to me off list, please remove “spamblock.” from my
> email address)
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>

–
Ray
(If you want to reply to me off list, please remove “spamblock.” from my
email address)</mailto:xxxxx>

OSR_Community_User · October 12, 2006, 4:46am

Incase you receive multiple touch or release information from the
Controller, you should be able to consider only one or average of the
positions in those. Otherwise you might be generating multiple double-clicks
for a single user touch.
You will have to support callibration which SENSES the user intended
co-ordinates and not the actual co-ordinates. For ex, u can ask the user to
touch at 4 given co-ordinates on the screen, see how the difference varies
between the intended point and ‘user touched point’(what he thinks the
actual co-ordinates are!)
Regarding mapping the co-ordinates on to the screen co-ordinates,
MOUSE_INPUT_DATA comes handy
When it comes to writing a driver , you will have to write a driver which
can talk to serial driver by opening appropriate device object corresponding
to the COM port and send read/write requests, set baud rate etc.
You have to layer your driver below mouclass.sys. RIT (Raw Input Thread)
talks to mouclass.sys to get the mouse-click actions.

-Giri.

On 10/12/06, Ray Trent wrote:
>
> Hmmm. Still not entirely sure I understand this setup, but it sounds
> like the touchscreen is not actually a display on the computer your
> driver would be running on, but it merely a display being controlled by
> some other system/controller/computer/something.
>
> In that case, it doesn’t make sense for your driver to be a mouse
> driver, because those control the cursor on displays being controlled by
> the host running the driver.
>
> In fact, it doesn’t sound to me like you need a driver at all. A
> user-mode service would be quite adequate. If it’s a captured vertical
> application system like a kiosk or something, you might even be able to
> get away with a user-mode app running normally on the system.
>
> All you have to do is open the COM port, read from it and write to it,
> right? No driver is needed to do those things. You only need a driver to
> move the real Windows pointer on a real Windows display.
>
> Shreshth Luthra wrote:
> > Hi Ray,
> >
> > First of all thanks for your reply.
> > I think, i having rather confused the things.
> >
> > See, even i am not having full information. It is just based on the
> > things avaiable with me.
> >
> > Take an example of an Third Party Interface ‘TPI’ which is understanding
> > the Touch Panel’s Voltage signals.
> > On one side of TPI is a MicroController having 3 parts:
> > 1) a Touch Panel (1024 x 1024). You can assume a sort of Finger Mouse.
> > 2) a LCD Display (800 X480)
> > 3) and ofcourse the core Microcontroller which is displaying the things
> > onto the Display Screen (as per the clicks on Touch Panel)
> >
> > Now suppose the we clicked on the co-ordinate (10,20) of our Touch
> > Panel. The signal of Left Click would be sent to the Third Party
> > Interface TPI (along with co-ordinates) which will then communicate with
> > COM port of PC and further with our MiniPort Driver.
> >
> > The MniPort Driver will in turn, map the co-ordinates as per the
> > resolution of LCD Display and after doing calibrations, will send the
> > signal back to the TPI, which in turn will be provided it to the the
> > MicroController.
> > The MicroController will then show that Mouse Pointer on the LCD Display
> > at the co-ordinates corresponding to (10,20) of 1024x1024.
> > e.g. X= 10/1024 x 800
> > Y = 20/1024 x 480
> >
> > The only signals the TPI is going to recieve from MicroController are
> > Single Click, Double Click and Drag (all of them along with the
> > co-ordinates)
> >
> > I hope things will be better clear to you now.
> >
> > Now i want to know what all will be there in the Scope of TouchPanel
> > MiniPort Driver, responsiblew for emulation and Calibrations.
> > And how to go about it (e.g. start with a Mouse Class Driver)
> >
> > Also i would like to tell that the Mouse Class Driver above our
> > TouchPanel MiniPort Driver already exists.
> >
> > Thanks alot.
> >
> > Regards,
> > Shreshth
> >
> >
> >
> > On 10/12/06, Ray Trent > > mailto:xxxxx> wrote:
> >
> > This sounds like a very confused design.
> >
> > Let me see if I understand:
> >
> > The main machine is running XP. It wants to receive input from a
> > TouchScreen. It wants to control its own cursor (i.e. the
> TouchScreen is
> > the primary screen connected to the host) and it wants to control it
> in
> > an absolute position sense.
> >
> > If that’s all the case, then yes, you need a mouse driver. It don’t
> > know
> > that I would call it a mini-port driver, exactly, because it’s just
> a
> > serial mouse driver. Look at the WDK’s sermouse sample for examples
> of
> > using the com port from the kernel. In terms of mapping the absolute
> > position, you just need to make your calculations (be careful about
> > using floating point) and report the position using the MOUCLASS
> > interface that’s documented (passing in the flag that says its an
> > absolute coordinate). The OS and display driver should take care of
> > putting the cursor on the display.
> >
> > I’ll also point out that in a lot of situations, you don’t even need
> to
> > write a driver to do this. If your environment is one where you can
> have
> > a user-mode application running, it can just open the COM port, do
> it’s
> > calculations (with no worries about floating point and full math
> > libraries), and then call SendInput to control the cursor.
> >
> > If, on the other hand, you’re trying to do something weird like
> having 2
> > cursors on 2 different screens, or you’re trying to operating
> another
> > computer’s monitor’s cursor or something, very different solutions
> will
> > be needed (and the 2 cursor solution will probably be impossible in
> the
> > general case, but that’s another story). Please clarify.
> >
> > Shreshth Luthra wrote:
> > > Hi All,
> > >
> > >
> > > One of our client has asked us to think on a miniport driver for
> > a touch
> > > screen which is going to reside between the Mouse Class Driver
> > and the
> > > COM Port Driver on the WinXP Professional Machine.
> > > COM port of PC is connected via a RS232 interface to a third
> party
> > > interface which on the other side is having a Microcontroller or
> > Win XP
> > > Embedded(Touch Panel + SVGA Touch Screen + Microcontroller).
> > >
> > > As per the diagram, which is the only input i am having at
> > present, it
> > > works like this.
> > > Whenever there is a click or activity on the Touch Panel, the
> third
> > > Party interface picks up the the signal ( mouse depressed or
> > released )
> > > and send it to the WinXP machine which after doing some
> > calibrations and
> > > mappings as per the Resolution of the Touch Screen sends this
> signal
> > > back to the third party which then affects the output on the
> > Screen and
> > > thus the microcontroller.
> > >
> > > Conceptually the thing look fine, but i am having a few doubts
> > related
> > > to it.
> > >
> > > As per my understanding, the Touch Screen Miniport driver that we
> > are
> > > going to write is itself going to be a Mouse Driver, then what is
> the
> > > role of Mouse Driver on the other side (which he is saying that
> is
> > > needed for emulation of co-ordinates of Touch Panel).
> > > If not a Mouse type driver what is the Miniport driver going to
> be.
> > >
> > > For a Touch Screen Miniport driver is there a standard set of
> signals
> > > (packets) that the Third Party Interface is going to send/recieve
> > > to/from COM Port Driver or it could be anything (Because this
> > needs to
> > > be interpreted by the Miniport Driver that we may be writing).
> > >
> > > Except for communication with COM Port, calibraion and emulation,
> is
> > > there anything else that my Miniport Driver might have to take
> > care of.
> > >
> > >
> > > Thanks for your reply.
> > >
> > > Thanks and Regards,
> > > Shreshth
> >
> > –
> > Ray
> > (If you want to reply to me off list, please remove “spamblock.”
> from my
> > email address)
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > To unsubscribe, visit the List Server section of OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >
> >
>
> –
> Ray
> (If you want to reply to me off list, please remove “spamblock.” from my
> email address)
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
></mailto:xxxxx>

Shreshth_Luthra · October 12, 2006, 6:59am

Hi Giri,

First of all tell me one thing, is it OK to create MOUSE_INPUT_DATA packets
of our own.
Because the input my PC is going to get are the packets in the form,

*X-co-ordinate,Y-co-ordinate, F*

Here F is the flag signifying whether it has been depressed or released.
I need to emulate it to the form of Mouse Left Click and Double Click.

Also it would be helpful if you can provide some link which speaks more
about it or some similar example.

Thanks and Regards,
Shreshth

On 10/12/06, giri wrote:
>
> 1) Incase you receive multiple touch or release information from the
> Controller, you should be able to consider only one or average of the
> positions in those. Otherwise you might be generating multiple double-clicks
> for a single user touch.
> 2) You will have to support callibration which SENSES the user intended
> co-ordinates and not the actual co-ordinates. For ex, u can ask the user to
> touch at 4 given co-ordinates on the screen, see how the difference varies
> between the intended point and ‘user touched point’(what he thinks the
> actual co-ordinates are!)
> 3) Regarding mapping the co-ordinates on to the screen co-ordinates,
> MOUSE_INPUT_DATA comes handy
> 4) When it comes to writing a driver , you will have to write a driver
> which can talk to serial driver by opening appropriate device object
> corresponding to the COM port and send read/write requests, set baud rate
> etc.
> 5) You have to layer your driver below mouclass.sys. RIT (Raw Input
> Thread) talks to mouclass.sys to get the mouse-click actions.
>
> -Giri.
>
> On 10/12/06, Ray Trent wrote:
>
> > Hmmm. Still not entirely sure I understand this setup, but it sounds
> > like the touchscreen is not actually a display on the computer your
> > driver would be running on, but it merely a display being controlled by
> > some other system/controller/computer/something.
> >
> > In that case, it doesn’t make sense for your driver to be a mouse
> > driver, because those control the cursor on displays being controlled by
> >
> > the host running the driver.
> >
> > In fact, it doesn’t sound to me like you need a driver at all. A
> > user-mode service would be quite adequate. If it’s a captured vertical
> > application system like a kiosk or something, you might even be able to
> > get away with a user-mode app running normally on the system.
> >
> > All you have to do is open the COM port, read from it and write to it,
> > right? No driver is needed to do those things. You only need a driver to
> > move the real Windows pointer on a real Windows display.
> >
> > Shreshth Luthra wrote:
> > > Hi Ray,
> > >
> > > First of all thanks for your reply.
> > > I think, i having rather confused the things.
> > >
> > > See, even i am not having full information. It is just based on the
> > > things avaiable with me.
> > >
> > > Take an example of an Third Party Interface ‘TPI’ which is
> > understanding
> > > the Touch Panel’s Voltage signals.
> > > On one side of TPI is a MicroController having 3 parts:
> > > 1) a Touch Panel (1024 x 1024). You can assume a sort of Finger Mouse.
> > > 2) a LCD Display (800 X480)
> > > 3) and ofcourse the core Microcontroller which is displaying the
> > things
> > > onto the Display Screen (as per the clicks on Touch Panel)
> > >
> > > Now suppose the we clicked on the co-ordinate (10,20) of our Touch
> > > Panel. The signal of Left Click would be sent to the Third Party
> > > Interface TPI (along with co-ordinates) which will then communicate
> > with
> > > COM port of PC and further with our MiniPort Driver.
> > >
> > > The MniPort Driver will in turn, map the co-ordinates as per the
> > > resolution of LCD Display and after doing calibrations, will send the
> > > signal back to the TPI, which in turn will be provided it to the the
> > > MicroController.
> > > The MicroController will then show that Mouse Pointer on the LCD
> > Display
> > > at the co-ordinates corresponding to (10,20) of 1024x1024.
> > > e.g. X= 10/1024 x 800
> > > Y = 20/1024 x 480
> > >
> > > The only signals the TPI is going to recieve from MicroController are
> > > Single Click, Double Click and Drag (all of them along with the
> > > co-ordinates)
> > >
> > > I hope things will be better clear to you now.
> > >
> > > Now i want to know what all will be there in the Scope of TouchPanel
> > > MiniPort Driver, responsiblew for emulation and Calibrations.
> > > And how to go about it (e.g. start with a Mouse Class Driver)
> > >
> > > Also i would like to tell that the Mouse Class Driver above our
> > > TouchPanel MiniPort Driver already exists.
> > >
> > > Thanks alot.
> > >
> > > Regards,
> > > Shreshth
> > >
> > >
> > >
> > > On 10/12/06, Ray Trent > > > <mailto: xxxxx>> wrote:
> > >
> > > This sounds like a very confused design.
> > >
> > > Let me see if I understand:
> > >
> > > The main machine is running XP. It wants to receive input from a
> > > TouchScreen. It wants to control its own cursor (i.e. the
> > TouchScreen is
> > > the primary screen connected to the host) and it wants to control
> > it in
> > > an absolute position sense.
> > >
> > > If that’s all the case, then yes, you need a mouse driver. It
> > don’t
> > > know
> > > that I would call it a mini-port driver, exactly, because it’s
> > just a
> > > serial mouse driver. Look at the WDK’s sermouse sample for
> > examples of
> > > using the com port from the kernel. In terms of mapping the
> > absolute
> > > position, you just need to make your calculations (be careful
> > about
> > > using floating point) and report the position using the MOUCLASS
> > > interface that’s documented (passing in the flag that says its an
> > > absolute coordinate). The OS and display driver should take care
> > of
> > > putting the cursor on the display.
> > >
> > > I’ll also point out that in a lot of situations, you don’t even
> > need to
> > > write a driver to do this. If your environment is one where you
> > can have
> > > a user-mode application running, it can just open the COM port, do
> > it’s
> > > calculations (with no worries about floating point and full math
> > > libraries), and then call SendInput to control the cursor.
> > >
> > > If, on the other hand, you’re trying to do something weird like
> > having 2
> > > cursors on 2 different screens, or you’re trying to operating
> > another
> > > computer’s monitor’s cursor or something, very different solutions
> > will
> > > be needed (and the 2 cursor solution will probably be impossible
> > in the
> > > general case, but that’s another story). Please clarify.
> > >
> > > Shreshth Luthra wrote:
> > > > Hi All,
> > > >
> > > >
> > > > One of our client has asked us to think on a miniport driver
> > for
> > > a touch
> > > > screen which is going to reside between the Mouse Class Driver
> > > and the
> > > > COM Port Driver on the WinXP Professional Machine.
> > > > COM port of PC is connected via a RS232 interface to a third
> > party
> > > > interface which on the other side is having a Microcontroller
> > or
> > > Win XP
> > > > Embedded(Touch Panel + SVGA Touch Screen + Microcontroller).
> > > >
> > > > As per the diagram, which is the only input i am having at
> > > present, it
> > > > works like this.
> > > > Whenever there is a click or activity on the Touch Panel, the
> > third
> > > > Party interface picks up the the signal ( mouse depressed or
> > > released )
> > > > and send it to the WinXP machine which after doing some
> > > calibrations and
> > > > mappings as per the Resolution of the Touch Screen sends this
> > signal
> > > > back to the third party which then affects the output on the
> > > Screen and
> > > > thus the microcontroller.
> > > >
> > > > Conceptually the thing look fine, but i am having a few doubts
> > > related
> > > > to it.
> > > >
> > > > As per my understanding, the Touch Screen Miniport driver that
> > we
> > > are
> > > > going to write is itself going to be a Mouse Driver, then what
> > is the
> > > > role of Mouse Driver on the other side (which he is saying that
> > is
> > > > needed for emulation of co-ordinates of Touch Panel).
> > > > If not a Mouse type driver what is the Miniport driver going to
> > be.
> > > >
> > > > For a Touch Screen Miniport driver is there a standard set of
> > signals
> > > > (packets) that the Third Party Interface is going to
> > send/recieve
> > > > to/from COM Port Driver or it could be anything (Because this
> > > needs to
> > > > be interpreted by the Miniport Driver that we may be writing).
> > > >
> > > > Except for communication with COM Port, calibraion and
> > emulation, is
> > > > there anything else that my Miniport Driver might have to take
> > > care of.
> > > >
> > > >
> > > > Thanks for your reply.
> > > >
> > > > Thanks and Regards,
> > > > Shreshth
> > >
> > > –
> > > Ray
> > > (If you want to reply to me off list, please remove “spamblock.”
> > from my
> > > email address)
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > To unsubscribe, visit the List Server section of OSR Online at
> > > http://www.osronline.com/page.cfm?name=ListServer
> > >
> > >
> >
> > –
> > Ray
> > (If you want to reply to me off list, please remove “spamblock.” from my
> > email address)
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> >
> > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> >
> >
>
> — Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
> Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer</mailto:>

Shreshth_Luthra · October 12, 2006, 2:43pm

Hi All,

Again getting to the similar reference, is it possible to call *
MouseClassServiceCallback* <mref_8e9e.htm> at anytime so as to supply
MOUSE_INPUT_DATA to the class driver.
If so, there something on OSR or somewhere else which speaks on complexity
of doing so.

Ray / Tim,

You people were telling about doing the same thing by means of a User mode
application. Can you please throw some pointers which can lead me to similar
work in a User Application and how closely this application be Platform
Independent.

Thanks alot for your reply.

Regards,
Shreshth

On 10/12/06, Shreshth Luthra wrote:
>
> Hi Giri,
>
> First of all tell me one thing, is it OK to create MOUSE_INPUT_DATA
> packets of our own.
> Because the input my PC is going to get are the packets in the form,
>
> X-co-ordinate,Y-co-ordinate, F
>
> Here F is the flag signifying whether it has been depressed or released.
> I need to emulate it to the form of Mouse Left Click and Double Click.
>
> Also it would be helpful if you can provide some link which speaks more
> about it or some similar example.
>
> Thanks and Regards,
> Shreshth
>
> On 10/12/06, giri wrote:
> >
> > 1) Incase you receive multiple touch or release information from the
> > Controller, you should be able to consider only one or average of the
> > positions in those. Otherwise you might be generating multiple double-clicks
> > for a single user touch.
> > 2) You will have to support callibration which SENSES the user intended
> > co-ordinates and not the actual co-ordinates. For ex, u can ask the user to
> > touch at 4 given co-ordinates on the screen, see how the difference varies
> > between the intended point and ‘user touched point’(what he thinks the
> > actual co-ordinates are!)
> > 3) Regarding mapping the co-ordinates on to the screen co-ordinates,
> > MOUSE_INPUT_DATA comes handy
> > 4) When it comes to writing a driver , you will have to write a driver
> > which can talk to serial driver by opening appropriate device object
> > corresponding to the COM port and send read/write requests, set baud rate
> > etc.
> > 5) You have to layer your driver below mouclass.sys. RIT (Raw Input
> > Thread) talks to mouclass.sys to get the mouse-click actions.
> >
> > -Giri.
> >
> > On 10/12/06, Ray Trent < xxxxx@synaptics.spamblock.com> wrote:
> >
> > > Hmmm. Still not entirely sure I understand this setup, but it sounds
> > > like the touchscreen is not actually a display on the computer your
> > > driver would be running on, but it merely a display being controlled
> > > by
> > > some other system/controller/computer/something.
> > >
> > > In that case, it doesn’t make sense for your driver to be a mouse
> > > driver, because those control the cursor on displays being controlled
> > > by
> > > the host running the driver.
> > >
> > > In fact, it doesn’t sound to me like you need a driver at all. A
> > > user-mode service would be quite adequate. If it’s a captured vertical
> > > application system like a kiosk or something, you might even be able
> > > to
> > > get away with a user-mode app running normally on the system.
> > >
> > > All you have to do is open the COM port, read from it and write to it,
> > > right? No driver is needed to do those things. You only need a driver
> > > to
> > > move the real Windows pointer on a real Windows display.
> > >
> > > Shreshth Luthra wrote:
> > > > Hi Ray,
> > > >
> > > > First of all thanks for your reply.
> > > > I think, i having rather confused the things.
> > > >
> > > > See, even i am not having full information. It is just based on the
> > > > things avaiable with me.
> > > >
> > > > Take an example of an Third Party Interface ‘TPI’ which is
> > > understanding
> > > > the Touch Panel’s Voltage signals.
> > > > On one side of TPI is a MicroController having 3 parts:
> > > > 1) a Touch Panel (1024 x 1024). You can assume a sort of Finger
> > > Mouse.
> > > > 2) a LCD Display (800 X480)
> > > > 3) and ofcourse the core Microcontroller which is displaying the
> > > things
> > > > onto the Display Screen (as per the clicks on Touch Panel)
> > > >
> > > > Now suppose the we clicked on the co-ordinate (10,20) of our Touch
> > > > Panel. The signal of Left Click would be sent to the Third Party
> > > > Interface TPI (along with co-ordinates) which will then communicate
> > > with
> > > > COM port of PC and further with our MiniPort Driver.
> > > >
> > > > The MniPort Driver will in turn, map the co-ordinates as per the
> > > > resolution of LCD Display and after doing calibrations, will send
> > > the
> > > > signal back to the TPI, which in turn will be provided it to the the
> > > > MicroController.
> > > > The MicroController will then show that Mouse Pointer on the LCD
> > > Display
> > > > at the co-ordinates corresponding to (10,20) of 1024x1024.
> > > > e.g. X= 10/1024 x 800
> > > > Y = 20/1024 x 480
> > > >
> > > > The only signals the TPI is going to recieve from MicroController
> > > are
> > > > Single Click, Double Click and Drag (all of them along with the
> > > > co-ordinates)
> > > >
> > > > I hope things will be better clear to you now.
> > > >
> > > > Now i want to know what all will be there in the Scope of TouchPanel
> > > > MiniPort Driver, responsiblew for emulation and Calibrations.
> > > > And how to go about it (e.g. start with a Mouse Class Driver)
> > > >
> > > > Also i would like to tell that the Mouse Class Driver above our
> > > > TouchPanel MiniPort Driver already exists.
> > > >
> > > > Thanks alot.
> > > >
> > > > Regards,
> > > > Shreshth
> > > >
> > > >
> > > >
> > > > On 10/12/06, Ray Trent < xxxxx@synaptics.spamblock.com
> > > > <mailto: xxxxx>> wrote:
> > > >
> > > > This sounds like a very confused design.
> > > >
> > > > Let me see if I understand:
> > > >
> > > > The main machine is running XP. It wants to receive input from a
> > >
> > > > TouchScreen. It wants to control its own cursor (i.e. the
> > > TouchScreen is
> > > > the primary screen connected to the host) and it wants to
> > > control it in
> > > > an absolute position sense.
> > > >
> > > > If that’s all the case, then yes, you need a mouse driver. It
> > > don’t
> > > > know
> > > > that I would call it a mini-port driver, exactly, because it’s
> > > just a
> > > > serial mouse driver. Look at the WDK’s sermouse sample for
> > > examples of
> > > > using the com port from the kernel. In terms of mapping the
> > > absolute
> > > > position, you just need to make your calculations (be careful
> > > about
> > > > using floating point) and report the position using the MOUCLASS
> > >
> > > > interface that’s documented (passing in the flag that says its
> > > an
> > > > absolute coordinate). The OS and display driver should take care
> > > of
> > > > putting the cursor on the display.
> > > >
> > > > I’ll also point out that in a lot of situations, you don’t even
> > > need to
> > > > write a driver to do this. If your environment is one where you
> > > can have
> > > > a user-mode application running, it can just open the COM port,
> > > do it’s
> > > > calculations (with no worries about floating point and full math
> > >
> > > > libraries), and then call SendInput to control the cursor.
> > > >
> > > > If, on the other hand, you’re trying to do something weird like
> > > having 2
> > > > cursors on 2 different screens, or you’re trying to operating
> > > another
> > > > computer’s monitor’s cursor or something, very different
> > > solutions will
> > > > be needed (and the 2 cursor solution will probably be impossible
> > > in the
> > > > general case, but that’s another story). Please clarify.
> > > >
> > > > Shreshth Luthra wrote:
> > > > > Hi All,
> > > > >
> > > > >
> > > > > One of our client has asked us to think on a miniport driver
> > > for
> > > > a touch
> > > > > screen which is going to reside between the Mouse Class
> > > Driver
> > > > and the
> > > > > COM Port Driver on the WinXP Professional Machine.
> > > > > COM port of PC is connected via a RS232 interface to a third
> > > party
> > > > > interface which on the other side is having a Microcontroller
> > > or
> > > > Win XP
> > > > > Embedded(Touch Panel + SVGA Touch Screen + Microcontroller).
> > > > >
> > > > > As per the diagram, which is the only input i am having at
> > > > present, it
> > > > > works like this.
> > > > > Whenever there is a click or activity on the Touch Panel, the
> > > third
> > > > > Party interface picks up the the signal ( mouse depressed or
> > > > released )
> > > > > and send it to the WinXP machine which after doing some
> > > > calibrations and
> > > > > mappings as per the Resolution of the Touch Screen sends this
> > > signal
> > > > > back to the third party which then affects the output on the
> > > > Screen and
> > > > > thus the microcontroller.
> > > > >
> > > > > Conceptually the thing look fine, but i am having a few
> > > doubts
> > > > related
> > > > > to it.
> > > > >
> > > > > As per my understanding, the Touch Screen Miniport driver
> > > that we
> > > > are
> > > > > going to write is itself going to be a Mouse Driver, then
> > > what is the
> > > > > role of Mouse Driver on the other side (which he is saying
> > > that is
> > > > > needed for emulation of co-ordinates of Touch Panel).
> > > > > If not a Mouse type driver what is the Miniport driver going
> > > to be.
> > > > >
> > > > > For a Touch Screen Miniport driver is there a standard set of
> > > signals
> > > > > (packets) that the Third Party Interface is going to
> > > send/recieve
> > > > > to/from COM Port Driver or it could be anything (Because this
> > > > needs to
> > > > > be interpreted by the Miniport Driver that we may be
> > > writing).
> > > > >
> > > > > Except for communication with COM Port, calibraion and
> > > emulation, is
> > > > > there anything else that my Miniport Driver might have to
> > > take
> > > > care of.
> > > > >
> > > > >
> > > > > Thanks for your reply.
> > > > >
> > > > > Thanks and Regards,
> > > > > Shreshth
> > > >
> > > > –
> > > > Ray
> > > > (If you want to reply to me off list, please remove “spamblock.”
> > > from my
> > > > email address)
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > To unsubscribe, visit the List Server section of OSR Online at
> > > > http://www.osronline.com/page.cfm?name=ListServer
> > > >
> > > >
> > >
> > > –
> > > Ray
> > > (If you want to reply to me off list, please remove “spamblock.” from
> > > my
> > > email address)
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> > >
> > >
> >
> > — Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
> > List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> >
>
>
></mailto:></mref_8e9e.htm>

OSR_Community_User · October 12, 2006, 3:38pm

Speaking of user mode solutions, have you considered just using the SendInput Windows API? If you just want to read some COM port traffic and inject mouse events to the Windows Input queue, you could use this. It would be a lot easier than doing anything in the kernel.

Tim_Roberts · October 12, 2006, 4:10pm

Shreshth Luthra wrote:

Again getting to the similar reference, is it possible to call
*MouseClassServiceCallback* <mref_8e9e.htm> at anytime so as to supply
> MOUSE_INPUT_DATA to the class driver.
> If so, there something on OSR or somewhere else which speaks on
> complexity of doing so.

I am still not clear on the environment. Is this panel going to be
displaying your Windows desktop, and is the touchpad going to be your
system mouse? Or are you just using Windows XP to translate the
coordinates for a completely separate subsystem?

> You people were telling about doing the same thing by means of a User
> mode application. Can you please throw some pointers which can lead me
> to similar work in a User Application and how closely this application
> be Platform Independent.

I was talking about doing the calibration in a user-mode app. I believe
the Windows CE distribution actually includes such a thing. It shows
you 5 different target points (center and all 4 corners), and asks you
to touch there. It uses the feedback to construct its calibration.

I/O stuff is never going to be platform-independent. What other
platform would you want to support?

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.</mref_8e9e.htm>

Ray_Trent · October 12, 2006, 6:25pm

Shreshth Luthra wrote:

Again getting to the similar reference, is it possible to call
*MouseClassServiceCallback* <mref_8e9e.htm> at anytime so as to supply

Last time I checked, you have to be running at DISPATCH_LEVEL to call
the MouseClassServiceCallback, but that might have changed in Vista. Of
course, you can call KeRaiseIrql at any time to satisfy this requirement
(just make sure to lower it afterwards :-).

> If so, there something on OSR or somewhere else which speaks on
> complexity of doing so.

Look at the moufiltr sample in the DDK.

> You people were telling about doing the same thing by means of a User
> mode application. Can you please throw some pointers which can lead me
> to similar work in a User Application and how closely this application
> be Platform Independent.

It depends so much on exactly what you’re trying to do, and I can’t tell
what that is from your description.

But… if you’re environment is one where this is feasible, you can just
write a user mode app that starts up (perhaps from the user’s Run key),
opens the COM port, does ReadFile and WriteFile calls on the COM port to
get/send your data, and then when it wants to post a mouse message to
the OS, calls SendInput.

One caveat on Vista: From what I’ve heard, applications can’t send mouse
data to UAC dialogs. Only “the hardware” (i.e. a mouse driver) can do that.

But again, maybe your application doesn’t need that… I can’t tell…
–
Ray
(If you want to reply to me off list, please remove “spamblock.” from my
email address)</mref_8e9e.htm>

OSR_Community_User · October 13, 2006, 3:05pm

Hi Sresht,
MOUSE_INPUT_DATA maps (xmin,xmax,ymin,ymax) to screen resolution for ex,
(0,1024,0,768). Your touch screen Controller might give you (x1,x2,y1,y2).
All you have to do is map your touch screen co-ordinates to
(xmin,xmax,ymin,ymax) said above.
I dont remember the exact details but I do remember that I took help from
Doron regarding how Raw Input Thread(RIT) issues READ Irps to mouclass.
When you report of the presence of one more mouse-like device to
mouclass.sys, it sends you an INTERNAL_DEVICE_IO_CONTROL, which contains a
callback, which you need to be called when you have new touch/release
co-ordinates. Upon your call to the mouclass callback, mouclass.sys finishes
off existing READ Irp and RIT sends a new one.
That should give you enough details.
I think Doron is not checking his ntdev mails

-Giri

On 10/12/06, Shreshth Luthra wrote:
>
> Hi Giri,
>
> First of all tell me one thing, is it OK to create MOUSE_INPUT_DATA
> packets of our own.
> Because the input my PC is going to get are the packets in the form,
>
> X-co-ordinate,Y-co-ordinate, F
>
> Here F is the flag signifying whether it has been depressed or released.
> I need to emulate it to the form of Mouse Left Click and Double Click.
>
> Also it would be helpful if you can provide some link which speaks more
> about it or some similar example.
>
> Thanks and Regards,
> Shreshth
>
> On 10/12/06, giri wrote:
> >
> > 1) Incase you receive multiple touch or release information from the
> > Controller, you should be able to consider only one or average of the
> > positions in those. Otherwise you might be generating multiple double-clicks
> > for a single user touch.
> > 2) You will have to support callibration which SENSES the user intended
> > co-ordinates and not the actual co-ordinates. For ex, u can ask the user to
> > touch at 4 given co-ordinates on the screen, see how the difference varies
> > between the intended point and ‘user touched point’(what he thinks the
> > actual co-ordinates are!)
> > 3) Regarding mapping the co-ordinates on to the screen co-ordinates,
> > MOUSE_INPUT_DATA comes handy
> > 4) When it comes to writing a driver , you will have to write a driver
> > which can talk to serial driver by opening appropriate device object
> > corresponding to the COM port and send read/write requests, set baud rate
> > etc.
> > 5) You have to layer your driver below mouclass.sys. RIT (Raw Input
> > Thread) talks to mouclass.sys to get the mouse-click actions.
> >
> > -Giri.
> >
> > On 10/12/06, Ray Trent < xxxxx@synaptics.spamblock.com> wrote:
> >
> > > Hmmm. Still not entirely sure I understand this setup, but it sounds
> > > like the touchscreen is not actually a display on the computer your
> > > driver would be running on, but it merely a display being controlled
> > > by
> > > some other system/controller/computer/something.
> > >
> > > In that case, it doesn’t make sense for your driver to be a mouse
> > > driver, because those control the cursor on displays being controlled
> > > by
> > > the host running the driver.
> > >
> > > In fact, it doesn’t sound to me like you need a driver at all. A
> > > user-mode service would be quite adequate. If it’s a captured vertical
> > > application system like a kiosk or something, you might even be able
> > > to
> > > get away with a user-mode app running normally on the system.
> > >
> > > All you have to do is open the COM port, read from it and write to it,
> > > right? No driver is needed to do those things. You only need a driver
> > > to
> > > move the real Windows pointer on a real Windows display.
> > >
> > > Shreshth Luthra wrote:
> > > > Hi Ray,
> > > >
> > > > First of all thanks for your reply.
> > > > I think, i having rather confused the things.
> > > >
> > > > See, even i am not having full information. It is just based on the
> > > > things avaiable with me.
> > > >
> > > > Take an example of an Third Party Interface ‘TPI’ which is
> > > understanding
> > > > the Touch Panel’s Voltage signals.
> > > > On one side of TPI is a MicroController having 3 parts:
> > > > 1) a Touch Panel (1024 x 1024). You can assume a sort of Finger
> > > Mouse.
> > > > 2) a LCD Display (800 X480)
> > > > 3) and ofcourse the core Microcontroller which is displaying the
> > > things
> > > > onto the Display Screen (as per the clicks on Touch Panel)
> > > >
> > > > Now suppose the we clicked on the co-ordinate (10,20) of our Touch
> > > > Panel. The signal of Left Click would be sent to the Third Party
> > > > Interface TPI (along with co-ordinates) which will then communicate
> > > with
> > > > COM port of PC and further with our MiniPort Driver.
> > > >
> > > > The MniPort Driver will in turn, map the co-ordinates as per the
> > > > resolution of LCD Display and after doing calibrations, will send
> > > the
> > > > signal back to the TPI, which in turn will be provided it to the the
> > > > MicroController.
> > > > The MicroController will then show that Mouse Pointer on the LCD
> > > Display
> > > > at the co-ordinates corresponding to (10,20) of 1024x1024.
> > > > e.g. X= 10/1024 x 800
> > > > Y = 20/1024 x 480
> > > >
> > > > The only signals the TPI is going to recieve from MicroController
> > > are
> > > > Single Click, Double Click and Drag (all of them along with the
> > > > co-ordinates)
> > > >
> > > > I hope things will be better clear to you now.
> > > >
> > > > Now i want to know what all will be there in the Scope of TouchPanel
> > > > MiniPort Driver, responsiblew for emulation and Calibrations.
> > > > And how to go about it (e.g. start with a Mouse Class Driver)
> > > >
> > > > Also i would like to tell that the Mouse Class Driver above our
> > > > TouchPanel MiniPort Driver already exists.
> > > >
> > > > Thanks alot.
> > > >
> > > > Regards,
> > > > Shreshth
> > > >
> > > >
> > > >
> > > > On 10/12/06, Ray Trent < xxxxx@synaptics.spamblock.com
> > > > <mailto: xxxxx>> wrote:
> > > >
> > > > This sounds like a very confused design.
> > > >
> > > > Let me see if I understand:
> > > >
> > > > The main machine is running XP. It wants to receive input from a
> > >
> > > > TouchScreen. It wants to control its own cursor (i.e. the
> > > TouchScreen is
> > > > the primary screen connected to the host) and it wants to
> > > control it in
> > > > an absolute position sense.
> > > >
> > > > If that’s all the case, then yes, you need a mouse driver. It
> > > don’t
> > > > know
> > > > that I would call it a mini-port driver, exactly, because it’s
> > > just a
> > > > serial mouse driver. Look at the WDK’s sermouse sample for
> > > examples of
> > > > using the com port from the kernel. In terms of mapping the
> > > absolute
> > > > position, you just need to make your calculations (be careful
> > > about
> > > > using floating point) and report the position using the MOUCLASS
> > >
> > > > interface that’s documented (passing in the flag that says its
> > > an
> > > > absolute coordinate). The OS and display driver should take care
> > > of
> > > > putting the cursor on the display.
> > > >
> > > > I’ll also point out that in a lot of situations, you don’t even
> > > need to
> > > > write a driver to do this. If your environment is one where you
> > > can have
> > > > a user-mode application running, it can just open the COM port,
> > > do it’s
> > > > calculations (with no worries about floating point and full math
> > >
> > > > libraries), and then call SendInput to control the cursor.
> > > >
> > > > If, on the other hand, you’re trying to do something weird like
> > > having 2
> > > > cursors on 2 different screens, or you’re trying to operating
> > > another
> > > > computer’s monitor’s cursor or something, very different
> > > solutions will
> > > > be needed (and the 2 cursor solution will probably be impossible
> > > in the
> > > > general case, but that’s another story). Please clarify.
> > > >
> > > > Shreshth Luthra wrote:
> > > > > Hi All,
> > > > >
> > > > >
> > > > > One of our client has asked us to think on a miniport driver
> > > for
> > > > a touch
> > > > > screen which is going to reside between the Mouse Class
> > > Driver
> > > > and the
> > > > > COM Port Driver on the WinXP Professional Machine.
> > > > > COM port of PC is connected via a RS232 interface to a third
> > > party
> > > > > interface which on the other side is having a Microcontroller
> > > or
> > > > Win XP
> > > > > Embedded(Touch Panel + SVGA Touch Screen + Microcontroller).
> > > > >
> > > > > As per the diagram, which is the only input i am having at
> > > > present, it
> > > > > works like this.
> > > > > Whenever there is a click or activity on the Touch Panel, the
> > > third
> > > > > Party interface picks up the the signal ( mouse depressed or
> > > > released )
> > > > > and send it to the WinXP machine which after doing some
> > > > calibrations and
> > > > > mappings as per the Resolution of the Touch Screen sends this
> > > signal
> > > > > back to the third party which then affects the output on the
> > > > Screen and
> > > > > thus the microcontroller.
> > > > >
> > > > > Conceptually the thing look fine, but i am having a few
> > > doubts
> > > > related
> > > > > to it.
> > > > >
> > > > > As per my understanding, the Touch Screen Miniport driver
> > > that we
> > > > are
> > > > > going to write is itself going to be a Mouse Driver, then
> > > what is the
> > > > > role of Mouse Driver on the other side (which he is saying
> > > that is
> > > > > needed for emulation of co-ordinates of Touch Panel).
> > > > > If not a Mouse type driver what is the Miniport driver going
> > > to be.
> > > > >
> > > > > For a Touch Screen Miniport driver is there a standard set of
> > > signals
> > > > > (packets) that the Third Party Interface is going to
> > > send/recieve
> > > > > to/from COM Port Driver or it could be anything (Because this
> > > > needs to
> > > > > be interpreted by the Miniport Driver that we may be
> > > writing).
> > > > >
> > > > > Except for communication with COM Port, calibraion and
> > > emulation, is
> > > > > there anything else that my Miniport Driver might have to
> > > take
> > > > care of.
> > > > >
> > > > >
> > > > > Thanks for your reply.
> > > > >
> > > > > Thanks and Regards,
> > > > > Shreshth
> > > >
> > > > –
> > > > Ray
> > > > (If you want to reply to me off list, please remove “spamblock.”
> > > from my
> > > > email address)
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > To unsubscribe, visit the List Server section of OSR Online at
> > > > http://www.osronline.com/page.cfm?name=ListServer
> > > >
> > > >
> > >
> > > –
> > > Ray
> > > (If you want to reply to me off list, please remove “spamblock.” from
> > > my
> > > email address)
> > >
> > > —
> > > Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256
> > >
> > > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> > >
> > >
> >
> > — Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
> > List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> >
>
>
> — Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
> Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer</mailto:>

OSR_Community_User · October 13, 2006, 3:08pm

How good is an user application using SendInput calls to send user events
like mouse clicks? Shouldn’t the response to the user be real-time?

On 10/13/06, Shreshth Luthra wrote:
>
> Hi All,
>
> Again getting to the similar reference, is it possible to call
> MouseClassServiceCallback http:</http:> at anytime so as to
> supply MOUSE_INPUT_DATA to the class driver.
> If so, there something on OSR or somewhere else which speaks on complexity
> of doing so.
>
> Ray / Tim,
>
> You people were telling about doing the same thing by means of a User mode
> application. Can you please throw some pointers which can lead me to similar
> work in a User Application and how closely this application be Platform
> Independent.
>
>
> Thanks alot for your reply.
>
> Regards,
> Shreshth
>
> On 10/12/06, Shreshth Luthra wrote:
> >
> > Hi Giri,
> >
> > First of all tell me one thing, is it OK to create MOUSE_INPUT_DATA
> > packets of our own.
> > Because the input my PC is going to get are the packets in the form,
> >
> > X-co-ordinate,Y-co-ordinate, F
> >
> > Here F is the flag signifying whether it has been depressed or released.
> > I need to emulate it to the form of Mouse Left Click and Double Click.
> >
> > Also it would be helpful if you can provide some link which speaks more
> > about it or some similar example.
> >
> > Thanks and Regards,
> > Shreshth
> >
> > On 10/12/06, giri < xxxxx@gmail.com> wrote:
> > >
> > > 1) Incase you receive multiple touch or release information from the
> > > Controller, you should be able to consider only one or average of the
> > > positions in those. Otherwise you might be generating multiple double-clicks
> > > for a single user touch.
> > > 2) You will have to support callibration which SENSES the user
> > > intended co-ordinates and not the actual co-ordinates. For ex, u can ask the
> > > user to touch at 4 given co-ordinates on the screen, see how the difference
> > > varies between the intended point and ‘user touched point’(what he
> > > thinks the actual co-ordinates are!)
> > > 3) Regarding mapping the co-ordinates on to the screen co-ordinates,
> > > MOUSE_INPUT_DATA comes handy
> > > 4) When it comes to writing a driver , you will have to write a driver
> > > which can talk to serial driver by opening appropriate device object
> > > corresponding to the COM port and send read/write requests, set baud rate
> > > etc.
> > > 5) You have to layer your driver below mouclass.sys. RIT (Raw Input
> > > Thread) talks to mouclass.sys to get the mouse-click actions.
> > >
> > > -Giri.
> > >
> > > On 10/12/06, Ray Trent < xxxxx@synaptics.spamblock.com> wrote:
> > >
> > > > Hmmm. Still not entirely sure I understand this setup, but it
> > > > sounds
> > > > like the touchscreen is not actually a display on the computer your
> > > > driver would be running on, but it merely a display being controlled
> > > > by
> > > > some other system/controller/computer/something.
> > > >
> > > > In that case, it doesn’t make sense for your driver to be a mouse
> > > > driver, because those control the cursor on displays being
> > > > controlled by
> > > > the host running the driver.
> > > >
> > > > In fact, it doesn’t sound to me like you need a driver at all. A
> > > > user-mode service would be quite adequate. If it’s a captured
> > > > vertical
> > > > application system like a kiosk or something, you might even be able
> > > > to
> > > > get away with a user-mode app running normally on the system.
> > > >
> > > > All you have to do is open the COM port, read from it and write to
> > > > it,
> > > > right? No driver is needed to do those things. You only need a
> > > > driver to
> > > > move the real Windows pointer on a real Windows display.
> > > >
> > > > Shreshth Luthra wrote:
> > > > > Hi Ray,
> > > > >
> > > > > First of all thanks for your reply.
> > > > > I think, i having rather confused the things.
> > > > >
> > > > > See, even i am not having full information. It is just based on
> > > > the
> > > > > things avaiable with me.
> > > > >
> > > > > Take an example of an Third Party Interface ‘TPI’ which is
> > > > understanding
> > > > > the Touch Panel’s Voltage signals.
> > > > > On one side of TPI is a MicroController having 3 parts:
> > > > > 1) a Touch Panel (1024 x 1024). You can assume a sort of Finger
> > > > Mouse.
> > > > > 2) a LCD Display (800 X480)
> > > > > 3) and ofcourse the core Microcontroller which is displaying the
> > > > things
> > > > > onto the Display Screen (as per the clicks on Touch Panel)
> > > > >
> > > > > Now suppose the we clicked on the co-ordinate (10,20) of our Touch
> > > > > Panel. The signal of Left Click would be sent to the Third Party
> > > > > Interface TPI (along with co-ordinates) which will then
> > > > communicate with
> > > > > COM port of PC and further with our MiniPort Driver.
> > > > >
> > > > > The MniPort Driver will in turn, map the co-ordinates as per the
> > > > > resolution of LCD Display and after doing calibrations, will send
> > > > the
> > > > > signal back to the TPI, which in turn will be provided it to the
> > > > the
> > > > > MicroController.
> > > > > The MicroController will then show that Mouse Pointer on the LCD
> > > > Display
> > > > > at the co-ordinates corresponding to (10,20) of 1024x1024.
> > > > > e.g. X= 10/1024 x 800
> > > > > Y = 20/1024 x 480
> > > > >
> > > > > The only signals the TPI is going to recieve from MicroController
> > > > are
> > > > > Single Click, Double Click and Drag (all of them along with the
> > > > > co-ordinates)
> > > > >
> > > > > I hope things will be better clear to you now.
> > > > >
> > > > > Now i want to know what all will be there in the Scope of
> > > > TouchPanel
> > > > > MiniPort Driver, responsiblew for emulation and Calibrations.
> > > > > And how to go about it (e.g. start with a Mouse Class Driver)
> > > > >
> > > > > Also i would like to tell that the Mouse Class Driver above our
> > > > > TouchPanel MiniPort Driver already exists.
> > > > >
> > > > > Thanks alot.
> > > > >
> > > > > Regards,
> > > > > Shreshth
> > > > >
> > > > >
> > > > >
> > > > > On 10/12/06, Ray Trent < xxxxx@synaptics.spamblock.com
> > > > > <mailto: xxxxx>> wrote:
> > > > >
> > > > > This sounds like a very confused design.
> > > > >
> > > > > Let me see if I understand:
> > > > >
> > > > > The main machine is running XP. It wants to receive input from
> > > > a
> > > > > TouchScreen. It wants to control its own cursor (i.e. the
> > > > TouchScreen is
> > > > > the primary screen connected to the host) and it wants to
> > > > control it in
> > > > > an absolute position sense.
> > > > >
> > > > > If that’s all the case, then yes, you need a mouse driver. It
> > > > don’t
> > > > > know
> > > > > that I would call it a mini-port driver, exactly, because it’s
> > > > just a
> > > > > serial mouse driver. Look at the WDK’s sermouse sample for
> > > > examples of
> > > > > using the com port from the kernel. In terms of mapping the
> > > > absolute
> > > > > position, you just need to make your calculations (be careful
> > > > about
> > > > > using floating point) and report the position using the
> > > > MOUCLASS
> > > > > interface that’s documented (passing in the flag that says its
> > > > an
> > > > > absolute coordinate). The OS and display driver should take
> > > > care of
> > > > > putting the cursor on the display.
> > > > >
> > > > > I’ll also point out that in a lot of situations, you don’t
> > > > even need to
> > > > > write a driver to do this. If your environment is one where
> > > > you can have
> > > > > a user-mode application running, it can just open the COM
> > > > port, do it’s
> > > > > calculations (with no worries about floating point and full
> > > > math
> > > > > libraries), and then call SendInput to control the cursor.
> > > > >
> > > > > If, on the other hand, you’re trying to do something weird
> > > > like having 2
> > > > > cursors on 2 different screens, or you’re trying to operating
> > > > another
> > > > > computer’s monitor’s cursor or something, very different
> > > > solutions will
> > > > > be needed (and the 2 cursor solution will probably be
> > > > impossible in the
> > > > > general case, but that’s another story). Please clarify.
> > > > >
> > > > > Shreshth Luthra wrote:
> > > > > > Hi All,
> > > > > >
> > > > > >
> > > > > > One of our client has asked us to think on a miniport
> > > > driver for
> > > > > a touch
> > > > > > screen which is going to reside between the Mouse Class
> > > > Driver
> > > > > and the
> > > > > > COM Port Driver on the WinXP Professional Machine.
> > > > > > COM port of PC is connected via a RS232 interface to a
> > > > third party
> > > > > > interface which on the other side is having a
> > > > Microcontroller or
> > > > > Win XP
> > > > > > Embedded(Touch Panel + SVGA Touch Screen +
> > > > Microcontroller).
> > > > > >
> > > > > > As per the diagram, which is the only input i am having at
> > > > > present, it
> > > > > > works like this.
> > > > > > Whenever there is a click or activity on the Touch Panel,
> > > > the third
> > > > > > Party interface picks up the the signal ( mouse depressed
> > > > or
> > > > > released )
> > > > > > and send it to the WinXP machine which after doing some
> > > > > calibrations and
> > > > > > mappings as per the Resolution of the Touch Screen sends
> > > > this signal
> > > > > > back to the third party which then affects the output on
> > > > the
> > > > > Screen and
> > > > > > thus the microcontroller.
> > > > > >
> > > > > > Conceptually the thing look fine, but i am having a few
> > > > doubts
> > > > > related
> > > > > > to it.
> > > > > >
> > > > > > As per my understanding, the Touch Screen Miniport driver
> > > > that we
> > > > > are
> > > > > > going to write is itself going to be a Mouse Driver, then
> > > > what is the
> > > > > > role of Mouse Driver on the other side (which he is saying
> > > > that is
> > > > > > needed for emulation of co-ordinates of Touch Panel).
> > > > > > If not a Mouse type driver what is the Miniport driver
> > > > going to be.
> > > > > >
> > > > > > For a Touch Screen Miniport driver is there a standard set
> > > > of signals
> > > > > > (packets) that the Third Party Interface is going to
> > > > send/recieve
> > > > > > to/from COM Port Driver or it could be anything (Because
> > > > this
> > > > > needs to
> > > > > > be interpreted by the Miniport Driver that we may be
> > > > writing).
> > > > > >
> > > > > > Except for communication with COM Port, calibraion and
> > > > emulation, is
> > > > > > there anything else that my Miniport Driver might have to
> > > > take
> > > > > care of.
> > > > > >
> > > > > >
> > > > > > Thanks for your reply.
> > > > > >
> > > > > > Thanks and Regards,
> > > > > > Shreshth
> > > > >
> > > > > –
> > > > > Ray
> > > > > (If you want to reply to me off list, please remove
> > > > “spamblock.” from my
> > > > > email address)
> > > > >
> > > > > —
> > > > > Questions? First check the Kernel Driver FAQ at
> > > > > http://www.osronline.com/article.cfm?id=256
> > > > >
> > > > > To unsubscribe, visit the List Server section of OSR Online at
> > > > > http://www.osronline.com/page.cfm?name=ListServer
> > > > >
> > > > >
> > > >
> > > > –
> > > > Ray
> > > > (If you want to reply to me off list, please remove “spamblock.”
> > > > from my
> > > > email address)
> > > >
> > > > —
> > > > Questions? First check the Kernel Driver FAQ at
> > > > http://www.osronline.com/article.cfm?id=256
> > > >
> > > > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> > > >
> > > >
> > >
> > > — Questions? First check the Kernel Driver FAQ at
> > > http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the
> > > List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> > >
> >
> >
> >
> — Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit the List
> Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
></mailto:>

Ray_Trent · October 13, 2006, 3:44pm

It works pretty well, actually. The priority boost that you get when the
ReadFile completes keeps there from being too much latency, among other
things. Actually, that’s BS, the real truth is that PCs are so damn fast
that you can’t really notice any delays. If you find the app not
responding fast enough, it can always raise its priority, too.

giri wrote:

How good is an user application using SendInput calls to send user
events like mouse clicks? Shouldn’t the response to the user be real-time?

On 10/13/06, *Shreshth Luthra* > mailto:xxxxx> wrote:
>
> Hi All,
>
> Again getting to the similar reference, is it possible to call
> MouseClassServiceCallback http:</http:> at anytime so as
> to supply MOUSE_INPUT_DATA to the class driver.
> If so, there something on OSR or somewhere else which speaks on
> complexity of doing so.
>
> Ray / Tim,
>
> You people were telling about doing the same thing by means of a
> User mode application. Can you please throw some pointers which can
> lead me to similar work in a User Application and how closely this
> application be Platform Independent.
>
>
> Thanks alot for your reply.
>
> Regards,
> Shreshth
>
>
> On 10/12/06, Shreshth Luthra > mailto:xxxxx> wrote:
>
> Hi Giri,
>
> First of all tell me one thing, is it OK to create
> MOUSE_INPUT_DATA packets of our own.
> Because the input my PC is going to get are the packets in the
> form,
>
> X-co-ordinate,Y-co-ordinate, F
>
> Here F is the flag signifying whether it has been depressed or
> released.
> I need to emulate it to the form of Mouse Left Click and Double
> Click.
>
> Also it would be helpful if you can provide some link which
> speaks more about it or some similar example.
>
> Thanks and Regards,
> Shreshth
>
> On 10/12/06, giri < xxxxx@gmail.com
> mailto:xxxxx> wrote:
>
> 1) Incase you receive multiple touch or release information
> from the Controller, you should be able to consider only one
> or average of the positions in those. Otherwise you might be
> generating multiple double-clicks for a single user touch.
> 2) You will have to support callibration which SENSES the
> user intended co-ordinates and not the actual co-ordinates.
> For ex, u can ask the user to touch at 4 given co-ordinates
> on the screen, see how the difference varies between the
> intended point and ‘user touched point’(what he thinks the
> actual co-ordinates are!)
> 3) Regarding mapping the co-ordinates on to the screen
> co-ordinates, MOUSE_INPUT_DATA comes handy
> 4) When it comes to writing a driver , you will have to
> write a driver which can talk to serial driver by opening
> appropriate device object corresponding to the COM port and
> send read/write requests, set baud rate etc.
> 5) You have to layer your driver below mouclass.sys. RIT
> (Raw Input Thread) talks to mouclass.sys to get the
> mouse-click actions.
>
> -Giri.
>
> On 10/12/06, Ray Trent < xxxxx@synaptics.spamblock.com
> mailto:xxxxx> wrote:
>
> Hmmm. Still not entirely sure I understand this setup,
> but it sounds
> like the touchscreen is not actually a display on the
> computer your
> driver would be running on, but it merely a display
> being controlled by
> some other system/controller/computer/something.
>
> In that case, it doesn’t make sense for your driver to
> be a mouse
> driver, because those control the cursor on displays
> being controlled by
> the host running the driver.
>
> In fact, it doesn’t sound to me like you need a driver
> at all. A
> user-mode service would be quite adequate. If it’s a
> captured vertical
> application system like a kiosk or something, you might
> even be able to
> get away with a user-mode app running normally on the
> system.
>
> All you have to do is open the COM port, read from it
> and write to it,
> right? No driver is needed to do those things. You only
> need a driver to
> move the real Windows pointer on a real Windows display.
>
> Shreshth Luthra wrote:
> > Hi Ray,
> >
> > First of all thanks for your reply.
> > I think, i having rather confused the things.
> >
> > See, even i am not having full information. It is just
> based on the
> > things avaiable with me.
> >
> > Take an example of an Third Party Interface ‘TPI’
> which is understanding
> > the Touch Panel’s Voltage signals.
> > On one side of TPI is a MicroController having 3 parts:
> > 1) a Touch Panel (1024 x 1024). You can assume a sort
> of Finger Mouse.
> > 2) a LCD Display (800 X480)
> > 3) and ofcourse the core Microcontroller which is
> displaying the things
> > onto the Display Screen (as per the clicks on Touch
> Panel)
> >
> > Now suppose the we clicked on the co-ordinate (10,20)
> of our Touch
> > Panel. The signal of Left Click would be sent to the
> Third Party
> > Interface TPI (along with co-ordinates) which will
> then communicate with
> > COM port of PC and further with our MiniPort Driver.
> >
> > The MniPort Driver will in turn, map the co-ordinates
> as per the
> > resolution of LCD Display and after doing
> calibrations, will send the
> > signal back to the TPI, which in turn will be provided
> it to the the
> > MicroController.
> > The MicroController will then show that Mouse Pointer
> on the LCD Display
> > at the co-ordinates corresponding to (10,20) of
> 1024x1024.
> > e.g. X= 10/1024 x 800
> > Y = 20/1024 x 480
> >
> > The only signals the TPI is going to recieve from
> MicroController are
> > Single Click, Double Click and Drag (all of them along
> with the
> > co-ordinates)
> >
> > I hope things will be better clear to you now.
> >
> > Now i want to know what all will be there in the Scope
> of TouchPanel
> > MiniPort Driver, responsiblew for emulation and
> Calibrations.
> > And how to go about it (e.g. start with a Mouse Class
> Driver)
> >
> > Also i would like to tell that the Mouse Class Driver
> above our
> > TouchPanel MiniPort Driver already exists.
> >
> > Thanks alot.
> >
> > Regards,
> > Shreshth
> >
> >
> >
> > On 10/12/06, Ray Trent < xxxxx@synaptics.spamblock.com
> mailto:xxxxx
> > <mailto: xxxxx>> mailto:xxxxx>> wrote:
> >
> > This sounds like a very confused design.
> >
> > Let me see if I understand:
> >
> > The main machine is running XP. It wants to receive
> input from a
> > TouchScreen. It wants to control its own cursor (
> i.e. the TouchScreen is
> > the primary screen connected to the host) and it
> wants to control it in
> > an absolute position sense.
> >
> > If that’s all the case, then yes, you need a mouse
> driver. It don’t
> > know
> > that I would call it a mini-port driver, exactly,
> because it’s just a
> > serial mouse driver. Look at the WDK’s sermouse
> sample for examples of
> > using the com port from the kernel. In terms of
> mapping the absolute
> > position, you just need to make your calculations
> (be careful about
> > using floating point) and report the position using
> the MOUCLASS
> > interface that’s documented (passing in the flag
> that says its an
> > absolute coordinate). The OS and display driver
> should take care of
> > putting the cursor on the display.
> >
> > I’ll also point out that in a lot of situations,
> you don’t even need to
> > write a driver to do this. If your environment is
> one where you can have
> > a user-mode application running, it can just open
> the COM port, do it’s
> > calculations (with no worries about floating point
> and full math
> > libraries), and then call SendInput to control the
> cursor.
> >
> > If, on the other hand, you’re trying to do
> something weird like having 2
> > cursors on 2 different screens, or you’re trying to
> operating another
> > computer’s monitor’s cursor or something, very
> different solutions will
> > be needed (and the 2 cursor solution will probably
> be impossible in the
> > general case, but that’s another story). Please
> clarify.
> >
> > Shreshth Luthra wrote:
> > > Hi All,
> > >
> > >
> > > One of our client has asked us to think on a
> miniport driver for
> > a touch
> > > screen which is going to reside between the
> Mouse Class Driver
> > and the
> > > COM Port Driver on the WinXP Professional Machine.
> > > COM port of PC is connected via a RS232
> interface to a third party
> > > interface which on the other side is having a
> Microcontroller or
> > Win XP
> > > Embedded(Touch Panel + SVGA Touch Screen +
> Microcontroller).
> > >
> > > As per the diagram, which is the only input i am
> having at
> > present, it
> > > works like this.
> > > Whenever there is a click or activity on the
> Touch Panel, the third
> > > Party interface picks up the the signal ( mouse
> depressed or
> > released )
> > > and send it to the WinXP machine which after
> doing some
> > calibrations and
> > > mappings as per the Resolution of the Touch
> Screen sends this signal
> > > back to the third party which then affects the
> output on the
> > Screen and
> > > thus the microcontroller.
> > >
> > > Conceptually the thing look fine, but i am
> having a few doubts
> > related
> > > to it.
> > >
> > > As per my understanding, the Touch Screen
> Miniport driver that we
> > are
> > > going to write is itself going to be a Mouse
> Driver, then what is the
> > > role of Mouse Driver on the other side (which he
> is saying that is
> > > needed for emulation of co-ordinates of Touch
> Panel).
> > > If not a Mouse type driver what is the Miniport
> driver going to be.
> > >
> > > For a Touch Screen Miniport driver is there a
> standard set of signals
> > > (packets) that the Third Party Interface is
> going to send/recieve
> > > to/from COM Port Driver or it could be anything
> (Because this
> > needs to
> > > be interpreted by the Miniport Driver that we
> may be writing).
> > >
> > > Except for communication with COM Port,
> calibraion and emulation, is
> > > there anything else that my Miniport Driver
> might have to take
> > care of.
> > >
> > >
> > > Thanks for your reply.
> > >
> > > Thanks and Regards,
> > > Shreshth
> >
> > –
> > Ray
> > (If you want to reply to me off list, please remove
> “spamblock.” from my
> > email address)
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> > http://www.osronline.com/article.cfm?id=256
> http:
> >
> > To unsubscribe, visit the List Server section of
> OSR Online at
> > http://www.osronline.com/page.cfm?name=ListServer
> >
> >
>
> –
> Ray
> (If you want to reply to me off list, please remove
> “spamblock.” from my
> email address)
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR
> Online at
> http://www.osronline.com/page.cfm?name=ListServer
> http:
>
>
> — Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> http: To
> unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
> http:
>
>
>
> — Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256 To unsubscribe, visit
> the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>
>

–
Ray
(If you want to reply to me off list, please remove “spamblock.” from my
email address)</http:></http:></http:></http:></mailto:xxxxx></mailto:></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>

Shreshth_Luthra · October 14, 2006, 2:45pm

Hi All,

Thanks for all your replies regarding my queries.
Actually i got the first document clarifying the things from the customer.
Till now i onlny had just a diagram on the basis of which i was speaking.
But now, the thinkgs do not look that complicated.
Its a simple combination of a touch screen and a LCD (having different
resolutions), with Touch Panel being connected to a Touch Panel Controller.
My scope of work in only a Driver (for mouse emulation and calibration)
which is going to interact with COM Port and the MouClass.sys.

Now, i am having one more query (Probably the last one before i start
actually working on it). I tried to convince the client that this thing can
be done in UserMode application (Using SendInput API and reading COM Port).
But he is still saying that he wants a Driver Only.
His major argument was that things when ported onto WinXP Embedded might now
work in case it is a User App (even after modification as per that
environment).
So, can anyone please tell me how different it is going to be in case of
WinXP Embedded (A user Application).

Once again thanks for all your answers.

Regards,
Shreshth

Maxim_S_Shatskih · October 14, 2006, 9:55pm

In fact, the driver will not be different from the serial mouse a lot. Just
a bit another protocol - but also under mouclass and above serenum. I hope the
tablet responds to serial PnP transactions properly.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Shreshth Luthra”
To: “Windows System Software Devs Interest List”
Sent: Saturday, October 14, 2006 10:45 PM
Subject: Re: [ntdev] Touch Screen Miniport Driver

> Hi All,
>
> Thanks for all your replies regarding my queries.
> Actually i got the first document clarifying the things from the customer.
> Till now i onlny had just a diagram on the basis of which i was speaking.
> But now, the thinkgs do not look that complicated.
> Its a simple combination of a touch screen and a LCD (having different
> resolutions), with Touch Panel being connected to a Touch Panel Controller.
> My scope of work in only a Driver (for mouse emulation and calibration)
> which is going to interact with COM Port and the MouClass.sys.
>
> Now, i am having one more query (Probably the last one before i start
> actually working on it). I tried to convince the client that this thing can
> be done in UserMode application (Using SendInput API and reading COM Port).
> But he is still saying that he wants a Driver Only.
> His major argument was that things when ported onto WinXP Embedded might now
> work in case it is a User App (even after modification as per that
> environment).
> So, can anyone please tell me how different it is going to be in case of
> WinXP Embedded (A user Application).
>
> Once again thanks for all your answers.
>
> Regards,
> Shreshth
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Ray_Trent · October 16, 2006, 2:03pm

The main questions to ask to determine whether a user-mode application
will be acceptable is whether or not the TouchPanel has to be active
before any user is logged on. If not, the app can be in the HKLM run key
and it should work fine in either XP or XPE or any other OS version
(again, modulo the concern about posting messages to higher privilege
apps in Vista). Also, there are complications involved if there might be
multiple users logged in (via fast user switching).

If it has to work on the login screen, user-mode is still possible, but
it would have to be a service, which adds extra complications (such as
having to deal with multiple sessions explicitly). I don’t know whether
a service will be able to post mouse messages that the UAC dialogs will
be able to see. Probably, at least with some effort, but I’m not sure.

A driver is the most certain to work in all situations, and the DDK’s
sermouse example is really close to what you would need in this case.
Modifying it to do what you want is probably the easiest solution if you
aren’t sure about the above issues.

You’ll still need a user-mode application to do the calibration and any
other GUI controls, but it can store the scaling, etc., parameters in
the registry and (if needed) trigger the driver to reread them when they
change. Make sure your calibration algorithm considers all the ways the
calibration could be wrong in your situation (or at least all the ways
that you want to handle). E.g. rotation, inversion, translation,
scaling, trapezoid or pincushioning (not likely for an LCD :-), etc.

Shreshth Luthra wrote:

Hi All,

Thanks for all your replies regarding my queries.
Actually i got the first document clarifying the things from the customer.
Till now i onlny had just a diagram on the basis of which i was speaking.
But now, the thinkgs do not look that complicated.
Its a simple combination of a touch screen and a LCD (having different
resolutions), with Touch Panel being connected to a Touch Panel Controller.
My scope of work in only a Driver (for mouse emulation and calibration)
which is going to interact with COM Port and the MouClass.sys.

Now, i am having one more query (Probably the last one before i start
actually working on it). I tried to convince the client that this thing
can be done in UserMode application (Using SendInput API and reading COM
Port).
But he is still saying that he wants a Driver Only.
His major argument was that things when ported onto WinXP Embedded might
now work in case it is a User App (even after modification as per that
environment).
So, can anyone please tell me how different it is going to be in case of
WinXP Embedded (A user Application).

Once again thanks for all your answers.

Regards,
Shreshth

–
Ray
(If you want to reply to me off list, please remove “spamblock.” from my
email address)

Tim_Roberts · October 16, 2006, 2:46pm

Shreshth Luthra wrote:

Thanks for all your replies regarding my queries.
Actually i got the first document clarifying the things from the customer.
Till now i onlny had just a diagram on the basis of which i was speaking.
But now, the thinkgs do not look that complicated.
Its a simple combination of a touch screen and a LCD (having different
resolutions), with Touch Panel being connected to a Touch Panel
Controller.
My scope of work in only a Driver (for mouse emulation and
calibration) which is going to interact with COM Port and the
MouClass.sys.

Now, i am having one more query (Probably the last one before i start
actually working on it). I tried to convince the client that this
thing can be done in UserMode application (Using SendInput API
and reading COM Port).
But he is still saying that he wants a Driver Only.
His major argument was that things when ported onto WinXP Embedded
might now work in case it is a User App (even after modification as
per that environment).
So, can anyone please tell me how different it is going to be in case
of WinXP Embedded (A user Application).

That’s interesting. If I were the manager, my concerns would be exactly
the opposite – that filter drivers would be less likely to be portable
than an application.

Either one will work in either system. The user-mode app is going to be
a lot easier to debug and support.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Shreshth_Luthra · October 17, 2006, 8:31am

Thanks alot Ray, Tim, Giri for all your replies.
I will let the team going to work on it, know about all these things.

Once again thanks.

Regards,
Shreshth

On 10/17/06, Tim Roberts wrote:
>
> Shreshth Luthra wrote:
>
> >
> > Thanks for all your replies regarding my queries.
> > Actually i got the first document clarifying the things from the
> customer.
> > Till now i onlny had just a diagram on the basis of which i was
> speaking.
> > But now, the thinkgs do not look that complicated.
> > Its a simple combination of a touch screen and a LCD (having different
> > resolutions), with Touch Panel being connected to a Touch Panel
> > Controller.
> > My scope of work in only a Driver (for mouse emulation and
> > calibration) which is going to interact with COM Port and the
> > MouClass.sys.
> >
> > Now, i am having one more query (Probably the last one before i start
> > actually working on it). I tried to convince the client that this
> > thing can be done in UserMode application (Using SendInput API
> > and reading COM Port).
> > But he is still saying that he wants a Driver Only.
> > His major argument was that things when ported onto WinXP Embedded
> > might now work in case it is a User App (even after modification as
> > per that environment).
> > So, can anyone please tell me how different it is going to be in case
> > of WinXP Embedded (A user Application).
>
>
> That’s interesting. If I were the manager, my concerns would be exactly
> the opposite – that filter drivers would be less likely to be portable
> than an application.
>
> Either one will work in either system. The user-mode app is going to be
> a lot easier to debug and support.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>