In empeg_display.c, theres some notes about making the display non-cachable, so that any process and the kernel see the same things. This could potentially be used for a program to overlay something on the display. Odd thing is that the code below the comment about this is commented out. (I am seeing both // and /* */ to comment things out in the code, do a few people at empeg use one way, and the others the other method?) Am I right in understanding the non-caching display method is currently disabled, and is there any plan to reimplement this soon?

As I've understood, when different applications mmap() the display, they all get pointer to the same memory space - therefore, writing to the same back buffer, so to say. Still, there is atleast two problems involving multiple processses using the display concurrently. First, there's no way of defining the draw order for different processes, if you access the mmap()'ed display, there's no way to know whether some other process has already drawn to it in this frame. Secondly, there should be only one shared place which actually blits the stuff to the screen (i.e. calls display_blat()). Now it's triggered by an ioctl() but again wouldn't be in sync with the other processes.

In general, a third-party developer is able to do basically anything with empeg when the application is running alone. I've been even quite lucky running programs concurrently with the player, but without access to display, audio and consumer ir from my own program.

Actually, at this point, it would be nice to hear what are empeg's plans for this in the future? Some while ago there was talk about Toby@Prolux doing some sort of API for users developing their own visualization - any update on this?

In theory, it shouldn't be too hard to implement some functionality for the player to share the devices (display, audio & consumer ir) with other processes. This would greatly enhance the third-party developer possibilities to make things run concurrently with the player.

empeg, any thoughts?

Kim