[vox-tech] Receiving an interrupt from a parallel port using xlib

[Jeff Newmiller]

On Tue, 16 Mar 2004, Bill Kendrick wrote:

> On Tue, Mar 16, 2004 at 02:58:29PM +1100, Julie Russell wrote:
> > Hi everyone,
> > 
> > I have written an application in xlib that currently takes an xevent and
> > processes it from the keyboard. Due to changes in hardware constraints I now
> > have to take that event from a parallel port by receiving an interrupt. Does
> > anyone know how if you can receive this signal using x libraries, or the
> > best way to talk to the port via x?
> 
> This is beyond the scope of Xlib itself.  X doesn't go much further than
> your mouse/keyboard/videocard.  :^)
> 
> Of course, that's not stopping you from using some /other/ libraries to
> talk to the parallel port within the same (Xlib-based) application. :^)
> 
> Unfortunately, I've never done parallel port code, so I wouldn't know where
> to begin, except I guess you want to talk to "/dev/lp0" or "/dev/lp1".

I have never used it, but freshmeat.net showed a library called
"parapin" to simplify parallel port interfacing.

> > I would like to implement this without
> > making too many changes to the event handler and the architecture of the
> > application.
> 
> Been a while since I did straight Xlib, but I suppose it could be possible
> to have your own 'user-specified' events come in (and get handled by your
> main event loop, just like the keyboard events that X gives you directly),
> and have some code that 'pushes' events into the queue when parallel port
> action happens.
> 
> I'm sure someone else here can explain all this better than I. ;^)

I am _not_ an X programmer, but I do know about interrupt programming...
be sure you understand that direct handling of a hardware interrupt should
in most normal Linux programs (including X programs) be handled by the
kernel, and the activation of the interrupt should be propagated through a
driver to userspace code that could concievably react to it by injecting a
message into your X message queue.  This is a _long_ way away from
"real-time" but you would have to change your architecture significantly
to get "real-time" response.

---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil@dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...2k
---------------------------------------------------------------------------