<BASE HREF="http://bedriven.be-in.org/articles/input_server/II_035-an%20introduction%20to%20the%20input%20server.html"><table border=1 width=100%><tr><td><table border=1 bgcolor=#ffffff cellpadding=10 cellspacing=0 width=100% color=#ffffff><tr><td><font face=arial,sans-serif color=black size=-1>This is <b><font color=#0039b6>G</font> <font color=#c41200>o</font> <font color=#f3c518>o</font> <font color=#0039b6>g</font> <font color=#30a72f>l</font> <font color=#c41200>e</font></b>'s <a href="http://www.google.com/help/features.html#cached"><font color=blue>cache</font></a> of <A HREF="http://bedriven.be-in.org/articles/input_server/II_035-an%20introduction%20to%20the%20input%20server.html"><font color=blue>http://bedriven.be-in.org/articles/input_server/II_035-an%20introduction%20to%20the%20input%20server.html</font></a>.<br>
<b><font color=#0039b6>G</font> <font color=#c41200>o</font> <font color=#f3c518>o</font> <font color=#0039b6>g</font> <font color=#30a72f>l</font> <font color=#c41200>e</font></b>'s cache is the snapshot that we took of the page as we crawled the web.<br>
The page may have changed since that time.  Click here for the <A HREF="http://bedriven.be-in.org/articles/input_server/II_035-an%20introduction%20to%20the%20input%20server.html"><font color=blue>current page</font></a> without highlighting.</font><br><br><center><font size=-2><i>Google is not affiliated with the authors of this page nor responsible for its content.</i></font></center></td></tr>
<tr><td>
<table border=0 cellpadding=0 cellspacing=0><tr><td><font face=arial,sans-serif color=black size=-1>These search terms have been highlighted:&nbsp;</font></td><td bgcolor=#ffff66><B><font face=arial,sans-serif color=black size=-1>hiroshi&nbsp;</font></B></td><td bgcolor=#A0FFFF><B><font face=arial,sans-serif color=black size=-1>lockheimer&nbsp;</font></B></td></tr></table>
<font face=arial,sans-serif color=black size=-1>These terms only appear in links pointing to this page: <B>input_server </B></font>
</td></tr></table></td></tr></table>
<hr>
<HTML>
<HEAD><TITLE>Be Newsletter, Volume II, Issue 35</TITLE></HEAD>
<BODY BGCOLOR="#FFFFFF">

<HR><Center><B>Be Newsletter, Volume II, Issue 35;  September 2, 1998</B></CENTER><HR>
            
      
<FONT SIZE=+1><B><A NAME="Insight"></A>BE ENGINEERING INSIGHTS: <p>An Introduction to the Input Server</B></FONT>
<br><B>By <B style="color:black;background-color:#ffff66">Hiroshi </B><B style="color:black;background-color:#A0FFFF">Lockheimer</B> <A HREF="mailto:hiroshi@be.com"><B style="color:black;background-color:#ffff66">hiroshi</B>@be.com</A></B>
<P>One of the many upcoming changes in the BeOS is in the world
of input devices and events. The Input Server, slated to
debut in R4, is a server that deals with all things &quot;input.&quot;
Specifically, it serves three functions: manages input
devices such as keyboards and mice; hosts a stream of events
that those devices generate; and dispatches those events
that make it through the stream.


<P>
<b>Managing Input Devices</b>


<P>The Input Server is a pretty dumb piece of software. (Cue to
Alex: roll your eyes and say, &quot;What do you expect <B style="color:black;background-color:#ffff66">Hiroshi</B>,
you wrote it.&quot;) On its own, the server doesn't know how a
keyboard or a mouse works; it relies on <CODE>BInputServerDevice</CODE>
add-ons to tell it.


<P><CODE>BInputServerDevice</CODE> is a base class from which all input
device add-ons must derive. It provides the basic framework
of virtual hook functions and non-virtual member functions
that the Input Server uses to communicate with an add-on,
and that the add-on can use to talk back to the server. To
give a sneak peak of the API, some of the virtuals include
<CODE>InitCheck()</CODE>, <CODE>Start()</CODE>, <CODE>Stop()</CODE>, and <CODE>Control()</CODE>. The common
sequence of the life of an input device is this:

<ol>

<li> The Input Server loads an add-on and constructs its
   <CODE><CODE>BInputServerDevice</CODE></CODE>-derived object.


<P><li> The Input Server calls <CODE>InitCheck()</CODE> on the object. The
   object determines whether it is capable of doing its job
   -- that is, generating input events.


<P><li>  This task may involve the object sniffing around for
   hardware it can drive, or looking for a kernel device
   driver in <CODE>/dev</CODE>. If the object is happy, it registers with
   the Input Server any input device(s) it finds, and
   returns <CODE>B_NO_ERROR</CODE>. An error return causes the Input
   Server to promptly destruct the object and unload the
   add-on.


<P><li> At some point in time, someone will tell the input
   devices registered with the Input Server to <CODE>Start()</CODE>. The
   system automatically starts keyboards and mice at boot
   time. Any other type of device (an &quot;undefined&quot; input
   device that the system doesn't have any special knowledge
   about) can be started by an application using new API in
   the Interface Kit.


<P><li> A registered device, whether it has been started or
   not, may be <CODE>Control()</CODE>-ed at any time. Think of Control()
   as the <CODE>ioctl()</CODE> equivalent in input device parlance.
   Examples of system-defined control messages include
   keymap changes and mouse speed changes.
</ol>

<P>
<b>Generating Input Events</b>


<P>Once a <CODE>BInputServerDevice</CODE>-derived object's input device is
up and running, its primary task is to generate input
events. These events are expressed as BMessages. For
example, a keyboard input device will most likely generate
<CODE>B_KEY_DOWN</CODE> and <CODE>B_KEY_UP</CODE> messages. Similarly, a mouse input
device will probably generate <CODE>B_MOUSE_UP</CODE>, <CODE>B_MOUSE_DOWN</CODE>, and
<CODE>B_MOUSE_MOVED</CODE> events.


<P>There is nothing that prevents an input device from putting
arbitrary data in any of the <CODE>BMessages</CODE> it generates. So, for
example, a tablet may generate the aforementioned mouse
events with extra data such as pressure and proximity. Any
information packed into the <CODE>BMessages</CODE> is delivered
unmolested by the input server.


<P>When an event is ready to be shipped off, an input device
enqueues it into the Input Server's event stream. Some
<CODE>BHandler</CODE> (most likely a <CODE>BView</CODE>) down the line eventually
receives the event by way of the usual hook functions such
as <CODE>KeyDown()</CODE>, <CODE>MouseDown()</CODE>, and <CODE>MouseMoved()</CODE>.


<P>
<b>The Input Event Stream</b>


<P>The Input Server's event stream is open for inspection and
alteration by anyone in the system. This is achieved through
another set of add-ons called <CODE>BInputServerFilter</CODE>. Like
<CODE>BInputServerDevice</CODE>, <CODE>BInputServerFilter</CODE> is a base class for input filter add-ons to the Input Server.


<P>An input filter add-on is privy to all the events that pass
through the Input Server's event stream. A filter may
inspect, alter, generate, or completely drop input events.
It's similar in some ways to the Interface Kit's
<CODE>BMessageFilter</CODE>, but much more low-level. A
<CODE>BInputServerFilter</CODE> sees all events that exist in the system;
<CODE>BMessageFilters</CODE> are associated with a specific <CODE>BLooper</CODE> and
thus see only the events targeted to its <CODE>BLooper</CODE>. Also,
filters in the Input Server can generate additional events
in place of, or in addition to, the original input event
that it was invoked with.


<P>
<b>Conclusion</b>


<P>With the introduction of loadable input device objects, the
Input Server enables the BeOS to be used with a wide variety
of input devices (and more than one of them at once too).
And with the advent of input filters, the Input Server opens
the door to a new class of tricks, hacks, and (gulp) pranks
for the creative developer. It's going to be fun.


<P>

</BODY>
</HTML>
