This is G o o g l e's cache of http://bedriven.be-in.org/articles/input_server/II_035-an%20introduction%20to%20the%20input%20server.html.
G o o g l e's cache is the snapshot that we took of the page as we crawled the web.
The page may have changed since that time. Click here for the current page without highlighting.
Google is not affiliated with the authors of this page nor responsible for its content.

These search terms have been highlighted: | hiroshi | lockheimer

These terms only appear in links pointing to this page: input_server

Be Newsletter, Volume II, Issue 35; September 2, 1998

BE ENGINEERING INSIGHTS:

An Introduction to the Input Server

By Hiroshi Lockheimer hiroshi@be.com

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 "input." 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.

Managing Input Devices

The Input Server is a pretty dumb piece of software. (Cue to Alex: roll your eyes and say, "What do you expect Hiroshi, you wrote it.") On its own, the server doesn't know how a keyboard or a mouse works; it relies on `BInputServerDevice` add-ons to tell it.

`BInputServerDevice` 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 `InitCheck()`, `Start()`, `Stop()`, and `Control()`. The common sequence of the life of an input device is this:

1. The Input Server loads an add-on and constructs its ``BInputServerDevice``-derived object.

2. The Input Server calls `InitCheck()` on the object. The object determines whether it is capable of doing its job -- that is, generating input events.

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

4. At some point in time, someone will tell the input devices registered with the Input Server to `Start()`. The system automatically starts keyboards and mice at boot time. Any other type of device (an "undefined" 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.

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

Generating Input Events

Once a `BInputServerDevice`-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 `B_KEY_DOWN` and `B_KEY_UP` messages. Similarly, a mouse input device will probably generate `B_MOUSE_UP`, `B_MOUSE_DOWN`, and `B_MOUSE_MOVED` events.

There is nothing that prevents an input device from putting arbitrary data in any of the `BMessages` 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 `BMessages` is delivered unmolested by the input server.

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

The Input Event Stream

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 `BInputServerFilter`. Like `BInputServerDevice`, `BInputServerFilter` is a base class for input filter add-ons to the Input Server.

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 `BMessageFilter`, but much more low-level. A `BInputServerFilter` sees all events that exist in the system; `BMessageFilters` are associated with a specific `BLooper` and thus see only the events targeted to its `BLooper`. 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.

Conclusion

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.