This may have been asked before, but I wasn't able to find anything about it, so here goes. The player (obviously) uses the display device. Is there any way for a user program, or perhaps the kernel, to control a small portion of the display in parallel to the player using the rest of it? Like, the display would be clipped in one certain portion to allow something from a user program to be output there.

My gut feeling is "no" due to the synchronization and fast refresh of the display, but I thought I'd ask if there were any creative ways to implement this. I somehow doubt that sharing of the display device is allowed, but if it was, it would open up a lot of cool ideas for user programs.



-Tony
MkII #554

This came up a while back, and so far I don't think anything has progressed for user programs to use the display while the player is running.

Is there any way for a user program, or perhaps the kernel, to control a small portion of the display in parallel to the player using the rest of it? Like, the display would be clipped in one certain portion to allow something from a user program to be output there.

Not with the standard player and kernel, but it's possible with a kernel hack.

Borislav

Oh yeah? I have been toying with the kernel lately. What kind of hack would it take? Have you had success with this yourself?

-Tony
MkII #554

Have you had success with this yourself?

No, I haven't done this myself. Here's how I'd go about it:

First, the quick and dirty way. Look at display_queue_add() in arch/arm/special/empeg_display.c - all screen updates go through there. After the final memcpy in that function you can modify the destination buffer to overlay your own image over whatever the player is displaying.

You'll need to watch out for palette changes - the correspondance between values in memory and colours on the screen can be changed by the EMPEG_DISPLAY_WRITE_PALETTE ioctl. It's probably easiest to keep two copies of your overlay image (one for the standard and one for Toby's palette), then switch between them when the above ioctl is issued.

That leaves the question of how do you get your image into the kernel. You can't use the mmaped buffer as the player is already using that. You can add a new ioctl that copies your image from user memory into a static kernel buffer - not as fast as mmap but should be OK if your image is small and you don't do it too often.

If you want to do this properly, you need first to come up with some reasonable semantics for a shared display buffer that remains compatible with the way the player is currently using it. For example, you can allow any number of application to open the device, all but one (the player) with some special flag. The player can do whatever it can do now. All the others can mmap the device but get their private buffer. They also provide a layer number and a overlay template. That template describes how to combine pixels from different layers (e.g. which pixel are transparent, which pixels to xor, etc.). The only allowed ioctl for the additional display users is the "refresh", that just tells to kernel to make a private copy of the current contents of the buffer.

The actual refresh of the screen is still controlled by the player. On each frame, after the player's buffer is copied in display_queue_add(), the driver would go through the layers in order and combine them according to the template rules.

On the driver side, you can use the private_data pointer of each struct file (you get a fresh one each time you open the device) to store the private buffer of that application. You can keep these in a linked list so that you can iterate over them in display_queue_add().

Yup, a lot of work if you just have one application in mind...

Sorry if this is a bit vague, I'd be happy to help with actual code if you can tell me more about what you want to do.

Good luck,
Borislav

Hmm. What you're suggesting does sound feasible. I don't have a specific application in mind, but I think a little "ticker" that could display information from a background application would be nice. This is something I'll probably chew on for a while, it's certainly not as easy of a hack as I first thought.

-Tony
MkII #554

What about during the blank-screen visual? Technically, you could write data to the screen while the screen is blanked, right?
-mark

...proud to have owned an Empeg since 00287

What about during the blank-screen visual? Technically, you could write data to the screen while the screen is blanked, right?

Yes, that might work, if the player doesn't refresh the blank screen until you switch to something else.

Borislav

This may have been asked before, but I wasn't able to find anything about it, so here goes. The player (obviously) uses the display device. Is there any way for a user program, or perhaps the kernel, to control a small portion of the display in parallel to the player using the rest of it? Like, the display would be clipped in one certain portion to allow something from a user program to be output there.

My gut feeling is "no" due to the synchronization and fast refresh of the display, but I thought I'd ask if there were any creative ways to implement this. I somehow doubt that sharing of the display device is allowed, but if it was, it would open up a lot of cool ideas for user programs.

See the attachment for simple kernel modification to allow other applications to share the display. It should work with the V1.02 kernel source tree.

The idea here is that your application opens /dev/display with special flags which after you can normally blit to the screen buffer using the display queue, whichafter kernel will mix the two frame buffers together before actually blitting the data to screen. The attached example will use the lowest eight pixel rows from the screen buffer to mix with the player screen buffer. The player screen buffers gets roughly scaled from 32 pixel rows to 24 pixel rows.

Here's a simple guide:

Open /dev/display from your application:
m_fd = open( "/dev/display", O_RDWR | O_SYNC );

Blit your stuff to the screen (to the display queue):
ioctl( m_fd, _IO( 'd', 6 ) );

Enable/disable display overlaying:
ioctl( m_fd, _IOW( 'd', 12, int ), &m_iOverlayType ); (m_iOverlayType being 0 or 1)

Kim

Cooooooooooooooool. Looks very promising. I can't try it out now because I'm at work, but I'll be hacking with this later on tonight.

-Tony
MkII #554

Wow, this is very cool! However, I can't exactly get it working. Applied the patch fine, compiled it fine, but I'm having trouble getting the blitted output to show up. Here's where I am...

First I wrote a simple "changedisp" program to send the display type ioctl(). Works great. "changedisp 0" turns off the overlay, "changedisp 1" turns it on.

So, with overlay enabled, I see the "normal" screen window shrink to 3/4 size, but when I try to blit stuff using the special ioctl for the overlay, nothing appears in the bottom part of the screen. When I use the regular blit ioctl(), the top 3/4 gets replaced by the blit buffer. When I use yours, nothing happens.

Could you arm me with a small test program that writes to that bottom section? I gotta figure out what I'm doing wrong here.

I hope I can get this working, it looks like GREAT work so far.


-Tony
MkII #554

Could you arm me with a small test program that writes to that bottom section? I gotta figure out what I'm doing wrong here.

See the attachment for a crappy demonstration how it should work. I'm running a bit more modifed kernel than the diff file I previously posted, but it should work still. Note, that when you are blitting stuff in the overlay mode, it's only the 1/4 bottom of the screen buffer which actually gets blitted into the screen.

When you run the attachment with the kernel mod, it should blit garbled random image into the screen every second for 15 seconds. If you want to test this with the player, you can do this:

overlay_display &
/empeg/bin/player

And if the player is not in stand-by mode you should see some random dots to flicker in the bottom part of the screen approximately every second (for 15 seconds, till the program exits).

Let me know if you still have problems and I can try to make a better example or to explain it more.

Kim

Naw, doesn't work. It shows the introductory thing "this program..." and nothing gets blitted to the screen anywhere. 15 seconds later it shows the exitting program printf(). It's not in standby mode, and running the player simultaneously shows the player in the scrunched up 3/4 section, but nothing in the bottom 1/4. So I think there's something missing from your diff. Would you be able to atttach your whole empeg_display.c or maybe a diff that is more complete? Maybe I messed something up on the patch... Thanks again.

-Tony
MkII #554

Naw, doesn't work.

Strange. I'll attach the full empeg_display_overlay.c file, try with that, and if it still doesn't work, then I'll revert my other changes from my kernel and build the kernel also with that file and see what is wrong.

Kim

Cool. It works now. Works exactly as advertised... Now the fun begins. :) Thanks much.

-Tony
MkII #554