Hello again,
I have been implementing input drivers for the keypad/keyboard provided by the Ben NanoNote and Letux 400 notebook computer, and although I appear to have implemented something that works (tested using specialised example code), using the existing OMAP3 keypad code as a guide (in pkg/drivers/input), I wondered whether it is possible to connect such drivers to other components in a convenient way.
I see that the input package is the thing that provides the device registry that I use when employing the arm_input_register macro, and in that package is a framework that supposedly exports input drivers as serial I/O devices using the "l4drv" driver. But I can't find anything obvious that uses the connect operation which would need to occur to probe, enable, and attach my driver to this framework.
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!
Paul
On Mon Apr 23, 2018 at 01:28:59 +0200, Paul Boddie wrote:
Hello again,
I have been implementing input drivers for the keypad/keyboard provided by the Ben NanoNote and Letux 400 notebook computer, and although I appear to have implemented something that works (tested using specialised example code), using the existing OMAP3 keypad code as a guide (in pkg/drivers/input), I wondered whether it is possible to connect such drivers to other components in a convenient way.
I see that the input package is the thing that provides the device registry that I use when employing the arm_input_register macro, and in that package is a framework that supposedly exports input drivers as serial I/O devices using the "l4drv" driver. But I can't find anything obvious that uses the connect operation which would need to occur to probe, enable, and attach my driver to this framework.
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.
Adam
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::CapL4::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
On Wednesday 16. May 2018 00.37.32 Paul Boddie wrote:
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::CapL4::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.
I think I figured out what causes this particular error condition: the Registry_server class needs parameterising with Br_manager_hooks instead of the default hooks. Providing a parameterised Demand_t class amongst the template parameters for Kobject_t seems to then allocate space for an incoming capability. These two details are in some examples, but their purposes aren't clearly stated.
Unfortunately, I can't get the sent capability to be recognised. Reading a Snd_fpage instance from the IPC stream seems successful, but the item is not considered valid. I'm wondering if I need to declare something somewhere else, here, and perhaps pkg/examples/sys/map_irq holds the key to this, but I don't really follow the mechanism.
Paul
On Wednesday 23. May 2018 00.21.23 Paul Boddie wrote:
[L4_IPC_SEMSGCUT ("Cut send message") condition]
I think I figured out what causes this particular error condition: the Registry_server class needs parameterising with Br_manager_hooks instead of the default hooks. Providing a parameterised Demand_t class amongst the template parameters for Kobject_t seems to then allocate space for an incoming capability. These two details are in some examples, but their purposes aren't clearly stated.
Unfortunately, I can't get the sent capability to be recognised. Reading a Snd_fpage instance from the IPC stream seems successful, but the item is not considered valid. I'm wondering if I need to declare something somewhere else, here, and perhaps pkg/examples/sys/map_irq holds the key to this, but I don't really follow the mechanism.
I figured this out eventually as well. It turns out that the Iostream classes don't support reading sent items from the stream using the operators (and perhaps not even using "normal" methods). So, as soon as all the words have been read from the message registers, only "null" items are returned.
Of course, the sent items are present in the message registers, and so it becomes necessary to inquire about the number of words and items, then the data can be read out and presented to the L4::Ipc::Snd_item constructor. Assignment to a L4::Ipc::Snd_fpage reference makes the sent capability available, and the rcv_cap and realloc_rcv_cap dance that is apparently necessary can then be performed. (This latter act needs the support of Br_manager_hooks, it would seem.)
I guess the more fancy RPC mechanisms automate this somehow, but I don't find the code very easy to follow. Since there is an operator method for obtaining Snd_item values from input streams, I would have thought that this would have worked and that the other mechanisms would have been using it, too, but I guess this isn't the case.
Paul
l4-hackers@os.inf.tu-dresden.de