Alas it's not that simple. I had looked at implementing just that.

The display is used as a memory mapped device, not a simple character device as the IR port is. This means that a driver (presumably kernel mode) has to intercept this and provide fake mappings then move those over to the real thing at the appropriate time.

That's not impossible though a kernel mode driver means rebuilding the kernel since modules appear not to be supported on the empeg kernel. (Quite reasonably BTW.)

The sticky problem is that the display can also interact with the DSP or some other device and provides real time synchronization. I do not know if or to what extent the current code uses this.

The approach I was toying with for my own purposes was to change the empeg display driver (since the empeg folks are good enough to supply source for that) to allow multiple opens of /dev/display and allow an app to control which of the opens is allowed to use the display at any time.

Nothing major there but still quite a PITA.

I was hoping to see something from empeg about the speculated/rumored visuals plug-in architecture. That would address my needs.

If I don't see something soon and I find the time I'll hack up the display driver.

Cheers,

Rex.