Page 1 of 1

input architecture

Posted: Fri Mar 24, 2006 12:52 pm
by proxy
So I'm trying to work out how I want to setup my input system. First let me preface the question by letting you know that I plan to have a "Device VFS" basically the idea is that if you do:

open("Device://mice");

you should get a file object which is an opaque handle to the mouse device. Ontop of this, I plan to be able to emulate the unix style /dev dir by mounting "Device://" to "/dev/" and such.

So, here's my question, One I have some true multitasking going on and all that, I'm gonna have a mouse device. Now i want the GUI application (I want this user space) to be able to open "Device://mice" to read the next mouse event...but at the same time, I would expect a second application to be able to also read this same device and see the same events.

This idea is demonstratable in linux, (in X you can do "cat /dev/input/mice" and see the char data associated with your mouse events, and your mouse still moves).

What is the best way handle this, if I have a single mouse event buffer, if one app reads an event, the others wont see it. The best I can think of is implementing some sort of "observer/observable" pattern. Like when an application does an open, that File object would register with the mouse driver saying "i want you to send me a copy of all mouse events and I'll queue em up myself". And of course when you close the file, it'll unregister itself.

The only real problem I can see with this, is if an application does an open, and doesn't do any reads for a while, it'll get a lot of old events (do I care?).

So anyway, I was wondering if this is the "correct" solution or is there some other ideas others have implemented..

proxy

Re:input architecture

Posted: Fri Mar 24, 2006 1:13 pm
by paulbarker
A simple solution would be to store all mouse events in a queue and associate each reader of the file with a position in the queue. Events can be removed from the queue once all readers have moved beyond the event. This avoids having to keep many copies of the queue.

Re:input architecture

Posted: Sat Mar 25, 2006 12:00 pm
by zloba
I think device events should only be read directly by the GUI engine, and routed to whatever application's window(s) the mouse moves across (or if an application has the mouse grab, or explicitly subscribes, etc.).

An application just receives events; it can also ask the GUI engine about the current coordinates, grab or subscribe to the events regardless (an app like X-Eyes could use this).

(Unless you only have one app in full control of the screen and input devices, with its own GUI engine. Then, anything goes - you can have only one app on the screen at a time, in full grab mode - it can be done by passing exclusive control of the devices)