hi there,
I took the opportunity to check in some code that had been idling
in my machine:
I fixed the evdev input to provide the necessary meta data to be
able to understand intput events. I tested it with the inputdump
tool and my wacom intuo.
I committed the ipc target. This isn't complete, but since nothing
depends on it it doesn't hurt either :)
Here is what it should eventually do:
shm provides the means for two processes to exchange visual and input
data. That much was already working with the memory target. What was
not working is a minimal synchronization mechanism. The new target
implements the 'ggiFlush' function such that some data is sent
over a (unix) socket to the peer to inform it about the update.
The peer can poll on that socket and then use the data.
A semaphore is provided to serialize access to the memory. It's not
yet clear (to me) how to do that correctly. For it to work transparently,
each ggi call would need to lock the memory, draw, then unlock, which
appears to be quite some overhead. On the other hand, if one wants to
lock a whole batch of ggi calls, we'd need to explicitely do that, i.e.
the application would need to know that it is using the ipc target,
which is equally wrong.
Any feedback is most welcome...
Stefan
PS: Steve: let me know if you want to work on this. You may even force me
into writing some docs...:)
