I'll only be needing support for X initially, yes.
The docs on writing drivers for X make it seem like quite a bit of work. Apparently, although you do have (wrapped) access to some standard lib calls, there are a lot of restrictions, which is the way it should be I suppose. Having discovered the joys of coding kernel modules a few months back, I'd really rather avoid more frustration with a similar system.
At the minute, I'm looking at using a daemon to run a named fifo with a standard mouse/touchscreen protocol and add it to the core events list that X watches for pointer input. Another fifo or other ipc interface would let my (GUI) vision/tracking system tell the daemon what to tell X. I think it should work pretty nicely (and with minimum coder stress!), but it seems a clumsy way to do it.
The reason for the daemon loop is that, as far as I can tell, my input system would have to be running when X starts up. This might be an assumption - my laptop uses the trackpoint and an external usb mouse. Until I started using udev, X would only pick up the usb mouse if it was plugged in before X started/restarted - if I plugged it in with X running, I'd have to restart X to get it working. Since the machine I'm testing my system on runs a 2.4 kernel, I assume that if I fire up my software and start talking to the input fifo after X has loaded, it will ignore the pointer input. Hopefully I can get around this by running the daemon to keep X interested while it starts up, then start my tracking software and feed the input to X through the daemon.
Am I right in thinking that X will ignore the fifo if it's dead on startup?
Also, finding good documentation for these protocols is proving difficult, since I'm not even sure which one I want to use. It needs abslute positioning, so I guess touchscreens are the thing to investigate...
|