Input driver configuration and use in L4Re
paul at boddie.org.uk
Wed May 16 00:37:32 CEST 2018
On Monday 14. May 2018 21.25.40 Adam Lackorzynski wrote:
> On Mon Apr 23, 2018 at 01:28:59 +0200, Paul Boddie wrote:
> > Is it possible to integrate my input drivers to things like Mag, which
> > seems to use input events, or to fbterminal or other things? I haven't
> > seen any documentation or code that demonstrates this, but I suppose
> > that I may have missed something somewhere.
> > Thanks for any help that is offered!
> Mag uses libinput (or may use) for getting input devices. That's more or
> less the common approach. The drivers in pkg/drivers/input are a loose
> end currently, i.e. they're not used by anyone else. However, I believe
> you should be able to hook them into
> mag/plugins/input_libinput/input_libinput.cc to get some input working for
This is good timing! I've been looking at writing some standalone drivers, but
I need to interoperate with the event framework, and that is proving to be
Much of the frustration is centred on the IPC mechanisms and my attempts to
figure out how to formulate my server classes and how to perform the necessary
IPC transfers. So far, when implementing servers, I've avoided problems by
using the rather simple approach involving deriving classes from
L4::Server_object_t and implementing the dispatch method myself, featured in
What I already have are libraries similar to the existing input drivers. These
monitor the keyboard/keypad and produce key events that can then be delivered
via a callback function. But what I want to do now is to allow these events to
be posted via a capability to other programs.
So, what I understand is that an event or input driver - as a standalone
program, not a library - will export a data space that it and any clients will
access via an Event_buffer instance. I already have programs which manage to
export a data space without problems. And wrapping a data space in an
Event_buffer seems to be easy enough to understand.
In addition, it seems beneficial to provide an interrupt so that new events
will notify the clients. I think I understand this fairly well: an interrupt
object is created (by the client or server); the client and server allocate a
capability and make sure they each reference the interrupt; the client then
binds the interrupt to a thread; the server triggers the interrupt and this
condition is made available at the client.
I have successfully got a server to create an interrupt and got a client
request a reference to it, using a Small_buf instance with the IPC stream
abstraction. (This is how the data space exporting is done.) I can get the
server to then trigger the interrupt and wake up the client doing a receive on
the interrupt capability.
But I cannot figure out how to have the client create the interrupt and send
it to the server, which would be a prerequisite for implementing the necessary
interrupt mechanism for events, as far as I can tell. Presenting a capability
instance (L4::Cap<L4::Irq>) to the IPC stream, which should then result in a
Snd_fpage instance being queued, just causes the L4_IPC_SEMSGCUT ("Cut send
Further along, I also have to consider how to formulate a server class that
implements the L4Re::Event interface and also the L4::Icu interface. I saw
that Mag_goos does something like this, but I haven't been able to distill the
essence of it down to something that seems to work.
So what seemed to be a straightforward task seems to be rather complicated,
and the APIs seem to obscure the mechanisms but do not seem to offer enough
convenience in compensation, at least if I consider things like CORBA and
related technologies for those of us old enough to remember using them. It
would be nice to improve things, but I don't have the confidence to seriously
consider doing so yet.
More information about the l4-hackers