Hello,

It seems to me that the guys@empeg is working on a multi-application-thingy for the empeg. Rob has mentioned that he would prefer a "quit the player and launch an app" strategy because of the disc-spinning up and down problems.

I think there is another much better way to do this.

Now, Im not the big Linux expert, but I saw the hack that was made to intercept the infrared-data, by mv-ing the /dev/infrared to /dev/infrared-original and monitoring the original.

Something similar must be possible with /dev/display, and this would make the car-player write to /dev/display, which we now monitor and send the display to /dev/display-original.

So the application takes over one key on the remote which changes the flips through the screens. It should have one screen for itself, where you can launch other applications.

Where are the keys on the front registered - also in /dev/infrared with some special codes?

Is this possible?


Lars Karlslund

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.

Hm, if we both had the same idea seperately, it must be right :-)

I don't understand your point about the display communicating with the DSP. It must be the player that finds out when to update the screen, and does an ioctl to the /dev/display.

You say that the /dev/dísplay is used as a memory-mapped device. But the device is accesed like a file, wouldn't it be possible to mimic this behaviour in a daemon of some sort. I should monitor /dev/display1 for contents, and when a program does an ioctl to this 'file' it should copy the contents to /dev/display and repeat the ioclt (presumed that we want to display this screen).

So the question would be, is it required that the /dev/display0 is monitored by a kernel device driver, or could this be done in a daemon?

Also, is there any special requirements for a file to be mapped into memory?


Lars Karlslund

As it's memory mapped, the display is *not* accessed like a file. The display becomes part of user-space memory. You could "intercept" it by having another display device in kernel.

The display device is also synchronised to audio in the kernel: there are multiple display buffers and the display is flipped by teh audio DMA requests in kernel (the player doesn't get involved). This may change in the future though, there are other plans afoot...

Hugo

Hugo,

You tease ...

What is planned? (I won't tell anyone ;)

Any rough time-estimate?

I have several ideas for smallish programmes for the empeg, and it would be nice not having to start all over coding them.

So, is it worth waiting for? ;)


Lars

>there are other plans afoot...

even though i have almost no idea what you guys are talking about, i hate it when you guys do that:)! geez! i'm still biting my nails wondering whats coming in 1.1, and hugo is already posting cryptic messages about "other plans afoot". kinda like when you are little and you know your parents got you something incredibly cool for christmas, but you can't find out what it is for another few weeks.

jeremy

12 gig, green...

But the device is accessed like a file...

Not exactly. It is opened and closed like a file but from there on it is mmaped and prodded with IOCTLs, neither of which are file accesses.

I don't think you can handle IOCTLs or mmaps from a user mode daemon. I think these have to be done from kernel mode. (I'm happy to be corrected, I'm a kernel driver guy and don't get out to user mode much.)

I think a hack to the existing driver is the 'easiest' approach here. Unless Hugo tells us what he has up his sleeve...

Cheers,

Rex.