I'm looking around at the Beta 12b kernel code out of boredom, and have come across some notes from the people at empeg that suggest features for the future.

One is in empeg_power.c. There is notes talking about the use of the power pic keeping track of the powerup counter in the car. Basicially, if it's the first time it's powered up in the car, it could ask for a PIN. After that, it won't ask for a PIN again until removed and put back into the car. This has some other unique uses as well. Just thought I'd point that out to any developers who wern't aware of it. The power state seems to be more complex, also giving programs other uses as well. It now also has information on the first boot in car, the state of the accessory line, the status of the cell phone mute, and light sense.

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?

Also, it looks like the startup code looks for the "empg" ID tag to display user graphics. So, any program that is made to customise and turn off the customized graphics simply has to modify the ID tag.

In the Beta 12b notes, Mike talked about the page where user logos are stored being able to hold 8k before running into other code. User logos only take 4k (2k for AC, 2k for DC), so that leaves 4k for other uses. What about using the spare 4 k for PIN logo data. Also, on PIN's, all the code and numbers should be stored in the kernel flash space somewhere, so that simply replacing the drives will not get around the security.

Anyhow, it definitly looks like some neat features and posibilities are in the works.

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

We're aware of the problems with running other apps concurrently with the player: we are going to work something out on this front. It's unlikely they'll actually share the same screen space (though I admit having other apps being able to bring up dialogs, etc, would be great) but we'll have some way of hotkeying between running apps (much like alt-tab on windows).

Toby has done some bits on the visual API, yes. Toby's joining empeg next month, working on visuals and UI - so there will be more manpower in that department :)

Hugo

Toby's joining empeg next month


Henno
mk2 nr 6

It's unlikely they'll actually share the same screen space (though I admit having other apps being able to bring up dialogs, etc, would be great) but we'll have some way of hotkeying between running apps (much like alt-tab on windows).

Couldn't you theoretically create some kind of API or pseudo-API where the third-party app put its stuff into its own little frame buffer with some window coordinates, but you handled the blitting of that window into your frame buffer?

Nah, nevermind. Next thing you know we'll be asking you to port DirectDraw to the Empeg, and nobody wants that.

Toby's joining empeg next month, working on visuals and UI

Congratulations to both Toby and Empeg. Definintely a mutually-beneficial arrangement.

___________
Tony Fabris