GSoC <Generic input device layer> project community intro and sync

[thIOretic]

Hi, hackers.

I'm working on 'Generic input device layer' GSoC2007 project (http://wiki.freebsd.org/SummerOfCode2007). This mail is actually to introduce my ideas and to synchronize it with current community efforts.

--Intro--

The project addresses input devices handling and multiplexing. The proposal with raw design is located at http://wiki.freebsd.org/GenericInputDeviceLayer. It also includes current state overview.
In brief, the proposal suggests to implement input handling via usermode drivers stacks. Usermode stage is handled by usermode drivers framework. The device class specific data is specified by 'exporters'.

--Sync--

I would like to get info from everyone, who may take similar efforts in FreeBSD input handling. I'm aware of
* newpsm framework
* KGI/KII
* vtc(4) was mentioned, but its code seems to do nothing from my project thesis perspective. Or I've missed something?
Maybe we will find some optimal design that will unify our efforts.

--Generic input handling ... even more generic layer--

I will appreciate any ideas from people, who may find the usermode drivers approach useful for their projects. Any useful discussion may result in some more generic design, that will fit more needs.
E.g. one of generalization ways is to allow exporters to specify drivers interface.

P.S. please 'reply all', so that all CC'd people receive their copy.

Thanks,

- Maxim

[Marcel Moolenaar]

Post by thIOretic
I would like to get info from everyone, who may take similar
efforts in FreeBSD input handling. I'm aware of
* newpsm framework
* KGI/KII
* vtc(4) was mentioned, but its code seems to do nothing from my
project thesis perspective. Or I've missed something?

As for vtc(4): I've not been working on input devices because of the
lack of a generic layer. Note that vtc(4) deals with the low-level
console as much as it deals with user-visible terminals, so from that
point of view, a user space stack will not address the need for having
console input when there's no (functional) user space -- this includes
early boot, the kernel debugger and single-user mode. I therefore doubt
that it will sufficiently (or at all) solve problems we already have.

Also, while multiplexing is an important feature I think that de-
multiplexing is important too. With USB and multi-head or multiple
graphics cards it's conceptually easy to turn a PC into a multi-
user workstation, having multiple independent terminals. This implies
that input devices need to be tied to output devices, which together
form one or more terminals.

In short: We do need a generic input framework, but I think we need
it in the kernel, not in user space. I also think that a generic
input layer should be capable of handling both focussed and non-
focussed input devices to lay the foundation for configurations
that do not include keyboards.

[Marcel Moolenaar]

Thanks for detailed useful reply.

Post by Marcel Moolenaar
As for vtc(4): I've not been working on input devices because of the
lack of a generic layer. Note that vtc(4) deals with the low-level
console as much as it deals with user-visible terminals, so from that
point of view, a user space stack will not address the need for
having
console input when there's no (functional) user space -- this
includes
early boot, the kernel debugger and single-user mode. I therefore
doubt
that it will sufficiently (or at all) solve problems we already have.

Yup. That's what I'm thinking about right now.
One of possible decisions is to move stacking into the kernel and have
an optional usermode part 'stacked' through a 2 'stub' drivers.

That's a possibility. I think it's reasonable to not provide a
fully-fledged stack when there's no user space. For example,
while i18n and l10n are important, I think that an english-only
or a Latin-only fallback mode makes matters simpler in case of
an emergency. The user interacting with the boot process or
working in single user mode is not an average user and can be
expected to adjust to the more limited fallback mode.

The question becomes to what extend the stack would live in
kernel space and to what extend there will be duplication or
control from user space.

Post by Marcel Moolenaar
Also, while multiplexing is an important feature I think that de-
multiplexing is important too.

I guess, demux can be done by 'top' driver or by drivers layout. There
are several ways, that have little impact on the total design.

Unfortunately, this goes beyond just input-stack only. A terminal
consists typically of input and output devices and can even include
audio devices for the historical beeps, keyclicks and other audible
cues. There needs to be a higher entity, like vtc(4), that manages
terminals and that will be in control of bundling devices into a
functional terminal. This would imply that any logic to control the
bundling would be part of that higher entity and not of the input
stack itself. This would significantly alter the design of the input
stack if the design of the input stack incorporates such control
(as I think is the case here).

Not to worry, I'm going to ask you to change your design :-)
Just think of it as food for thought.

[Maxim Zhuravlev]

2007/4/17, Marcel Moolenaar <***@mac.com>:

Thanks for detailed useful reply.

Post by Marcel Moolenaar
As for vtc(4): I've not been working on input devices because of the
lack of a generic layer. Note that vtc(4) deals with the low-level
console as much as it deals with user-visible terminals, so from that
point of view, a user space stack will not address the need for having
console input when there's no (functional) user space -- this includes
early boot, the kernel debugger and single-user mode. I therefore doubt
that it will sufficiently (or at all) solve problems we already have.

Yup. That's what I'm thinking about right now.
One of possible decisions is to move stacking into the kernel and have
an optional usermode part 'stacked' through a 2 'stub' drivers.

Post by Marcel Moolenaar
Also, while multiplexing is an important feature I think that de-
multiplexing is important too.

I guess, demux can be done by 'top' driver or by drivers layout. There
are several ways, that have little impact on the total design.

Thanks,

- Maxim

[Hans Petter Selasky]

Hi,

My input in this regard is:

1) The new stack must be detach safe. I.E. no race conditions at detatch.

2) The stack must be able to take an arbitrary mutex, that is provided by the
low level device driver, and not just Giant.

--HPS