| PCKBPORT(9) | Kernel Developer's Manual | PCKBPORT(9) |
pckbport,
pckbport_attach,
pckbport_attach_slot,
pckbport_cnattach,
pckbportintr,
pckbport_set_inputhandler,
pckbport_flush,
pckbport_poll_cmd,
pckbport_enqueue_cmd,
pckbport_poll_data,
pckbport_set_poll,
pckbport_xt_translation,
pckbport_slot_enable — PC
keyboard port interface
#include
<dev/pckbport/pckbportvar.h>
pckbport_tag_t
pckbport_attach(void
*, struct
pckbport_accessops const *);
struct device *
pckbport_attach_slot(struct
device *,
pckbport_tag_t,
pckbport_slot_t);
int
pckbport_cnattach(void
*, struct
pckbport_accessops const *,
pckbport_slot_t);
void
pckbportintr(pckbport_tag_t,
pckbport_slot_t,
int);
void
pckbport_set_inputhandler(pckbport_tag_t,
pckbport_slot_t,
pckbport_inputfcn,
void *,
char *);
void
pckbport_flush(pckbport_tag_t,
pckbport_slot_t);
int
pckbport_poll_cmd(pckbport_tag_t,
pckbport_slot_t,
u_char *,
int,
int,
u_char *,
int);
int
pckbport_enqueue_cmd(pckbport_tag_t,
pckbport_slot_t,
u_char *,
int,
int,
int,
u_char *);
int
pckbport_poll_data(pckbport_tag_t,
pckbport_slot_t);
void
pckbport_set_poll(pckbport_tag_t,
pckbport_slot_t,
int);
int
pckbport_xt_translation(pckbport_tag_t,
pckbport_slot_t,
int);
void
pckbport_slot_enable(pckbport_tag_t,
pckbport_slot_t,
int);
The machine-independent pckbport subsystem
provides an interface layer corresponding to the serial keyboard and mouse
interface used on the IBM PS/2 and many other machines. It interfaces a
controller driver such as
pckbc(4) to device drivers such
as pckbd(4) and
pms(4).
A single controller can have up to two ports (known as
“slots”), and these are identified by values of type
pckbport_slot_t. The values
PCKBPORT_KBD_SLOT and
PCKBPORT_AUX_SLOT should be used for keyboard and
mouse ports respectively. Each controller is identified by an opaque value
of type pckbport_tag_t.
A PC keyboard controller registers itself by calling
pckbport_attach(cookie,
ops), with ops being a pointer
to a struct pckbport_accessops containing pointers to
functions for driving the controller, which will all be called with
cookie as their first argument.
pckbport_attach() returns the
pckbport_tag_t assigned to the controller. The
controller is then expected to call
pckbport_attach_slot()
for each slot with which it is equipped, passing the struct
device * corresponding to the controller. This function returns a
pointer to the child device attached to the slot, or
NULL if no such device was attached.
The elements of struct
pckbport_accessops each take as their first two arguments the
cookie passed to
pckbport_attach()
and the slot in question. The elements are:
(*t_xt_translation)(void
*cookie, pckbport_slot_t slot,
int on)(*t_send_devcmd)(void *cookie,
pckbport_slot_t slot, u_char
byte)(*t_poll_data1)(void *cookie,
pckbport_slot_t slot)(*t_set_poll)() has been used to put the slot in
polling mode. If no data are forthcoming from the device after about
100ms, return -1.(*t_slot_enable)(void *cookie,
pckbport_slot_t slot, int
on)(*t_intr_establish)(void
*cookie, pckbport_slot_t slot)(*t_set_poll)(void *cookie,
pckbport_slot_t slot, int
on)(*t_poll_data1)() and not passed
to
pckbportintr(),
whether or not interrupts are enabled. In non-polling mode, data from the
device are expected to cause interrupts. The controller interrupt handler
should call
pckbportintr(tag,
slot, byte) once for each
byte received from the device. When first attached,
a port should be in non-polling mode.Devices that attach to pckbport
controllers do so using the normal
autoconf(9) mechanism. Their
(*ca_match)() and
(*ca_attach)() functions get passed a
struct pckbport_attach_args which contains the
controller and slot number where the device was found. Device drivers can
use the following functions to communicate with the controller. Each takes
tag and slot arguments to
specify the slot to be acted on.
pckbport_set_inputhandler(tag,
slot, fn,
arg, name)spltty().pckbport_flush(tag,
slot)pckbport_poll_cmd(tag,
slot, cmd,
len, responselen,
respbuf, slow)pckbport_poll_cmd() handles getting an
acknowledgement from the device and retrying the command if necessary.
Returns 0 on success, and an error value on failure. This function should
only be called during autoconfiguration or when the slot has been placed
into polling mode by
pckbport_set_poll().pckbport_enqueue_cmd(tag,
slot, cmd,
len, responselen,
sync, respbuf)pckbport_enqueue_cmd() waits for the command to
complete before returning, otherwise it returns immediately. It is not
safe to set sync when calling from an interrupt
context. The pckbport layer handles getting an
acknowledgement from the device and retrying the command if necessary.
Returns 0 on success, and an error value on failure.pckbport_poll_data(tag,
slot)pckbport_enqueue_command().pckbport_set_poll(tag,
slot, on)pckbport_poll_cmd()
can be used to issue commands and
pckbport_poll_data() to read unsolicited data,
without enabling interrupts. In non-polling mode, commands should be
issued using pckbport_enqueue_cmd(), unsolicited
data are handled by the input function, and disabling interrupts will
suspend pckbport operation.pckbport_xt_translation(tag,
slot, on)(*t_xt_translation)() (see
above).pckbport_slot(enable,
tag, slot,
on)(*t_slot_enable)() (see
above).On systems that can attach consoles through
pckbport, the controller's console attachment
function (called very early in autoconfiguration) calls
pckbport_cnattach(cookie,
ops, slot). The first two
arguments are the same as for pckbport_attach(),
while the third indicates which slot the console keyboard is attached to.
pckbport_cnattach() either calls
pckbd_cnattach(),
if it is available, or
pckbport_machdep_cnattach().
The latter allows machine-dependent keyboard drivers to attach themselves,
but it is only called if a device with the
‘pckbport_machdep_cnattach’ attribute
is configured into the system. pckbport_cnattach()
returns 0 on success and an error value on failure.
pckbport_machdep_cnattach() is expected to do the
same.
The pckbport code, and the
pckbd(4) and
pms(4) device drivers are in
sys/dev/pckbport.
The pckbport system appeared in
NetBSD 2.0. Before that,
pckbd(4) and
pms(4) attached directly to
pckbc(4) without any sensible
way of using a different controller.
| August 5, 2004 | NetBSD 11.0 |