Input driver configuration and use in L4Re

[Paul Boddie]

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
> mag.

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 
rather frustrating.

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 
this presentation:

http://os.inf.tu-dresden.de/~doebel/downloads/02-MemoryAndIPC.pdf

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 
message") condition.

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.

Paul