nanogui: Thread: open("/dev/fb0") by two programs

Hello all,
	Just a quick question, I am writing an mpeg player for nano-X, and
I want to be able to dump the video straight to the framebuffer. I was just
wondering if it is bad to have the nano-X server have the framebuffer device
open at the same time as my application?

Peter Hartshorn
####@####.####

####@####.#### wrote:

> I want to be able to dump the video straight to the framebuffer. I was just
> wondering if it is bad to have the nano-X server have the framebuffer device
> open at the same time as my application?

At this time it appears you can have it open twice. However, you have to
coordinate the access to the fb. When Nano-x redraws the screen is it
going to clobber your video?

It also looks like they are going to disallow multiple open's of the
same fb in 2.5.  See the thread in linux-fbdev 

	http://sourceforge.net/mail/?group_id=908

-- 
Scott A. McConnell

Bad is a relative term here.  You're not going to core dump your kernel or 
anything, but unless you are super careful, you will see synchronization 
problems between the server and your application (which is then multiplied 
when you toss a window manager into the mix).  For example, say you have a 
MPEG stream running on the framebuffer, and then you move the window for some 
reason.   The window may move, but the actual video image may not move with 
it.    

That's because the Nano-X server doesn't have any clue about the stream, so 
it cannot manage it.    Of course, you can always go fullscreen to avoid 
these issues, but a 320x200 MPEG stream goes a tad slow sometimes.

The best solution is to have the graphics engine provide a memory window so 
the client can write directly to the framebuffer.   Hopefully a future 
version of Microwindows will have this ability.

Jordan

On Wednesday 11 July 2001 23:35, ####@####.#### mentioned:
> Hello all,
> 	Just a quick question, I am writing an mpeg player for nano-X, and
> I want to be able to dump the video straight to the framebuffer. I was just
> wondering if it is bad to have the nano-X server have the framebuffer
> device open at the same time as my application?
>
> Peter Hartshorn
> ####@####.####
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

: The best solution is to have the graphics engine provide a memory window
so
: the client can write directly to the framebuffer.   Hopefully a future
: version of Microwindows will have this ability.

It isn't bad to have the client open framebuffer at the same time
as the Nano-X server, providing it's managed properly.  This is
the technique that I use in pre8 that allows super-fast MPEG
video drawing using the "client-side direct framebuffer mapping."
I have added some a new client library call, as well as enhanced
some structure members so that the client can know exactly what the
framebuffer looks like without writing a bunch of non-portable
code.

WRT window synchronization, I am working on a semaphore
technique that will allow direct client-side framebuffer programs
to receive events when the framebuffer is moved.


: It also looks like they are going to disallow multiple open's of the
:: same fb in 2.5.  See the thread in linux-fbdev

: http://sourceforge.net/mail/?group_id=908

This is bad news.  We need the dual-open capability in order to
make fast video work.  Alan - what do you think about this,
is there another preferred method?

Regards,

Greg






:
: Jordan
:
: On Wednesday 11 July 2001 23:35, ####@####.#### mentioned:
: > Hello all,
: > Just a quick question, I am writing an mpeg player for nano-X, and
: > I want to be able to dump the video straight to the framebuffer. I was
just
: > wondering if it is bad to have the nano-X server have the framebuffer
: > device open at the same time as my application?
: >
: > Peter Hartshorn
: > ####@####.####
: >
: >
: > ---------------------------------------------------------------------
: > To unsubscribe, e-mail: ####@####.####
: > For additional commands, e-mail: ####@####.####
:
:
: ---------------------------------------------------------------------
: To unsubscribe, e-mail: ####@####.####
: For additional commands, e-mail: ####@####.####
:

Thankyou all for the response,
	I am not concerned with "corruption" as I have found a simple way
around it. That is to create a new nano-X window that covers the screen, and
leave it there while I play the mpeg, when I finish, I destroy the window,
and all the other windows are refreshed.

BTW: without sound, I get about 12-15 fps 320x240 for mpeg1 which is quite
watchable.

Again, thanks

: I am not concerned with "corruption" as I have found a simple way
: around it. That is to create a new nano-X window that covers the screen, and
: leave it there while I play the mpeg, when I finish, I destroy the window,
: and all the other windows are refreshed.

The best way to do this isn't to cover the whole screen, but instead
create the window (GrNewWindowEx) using GR_WM_PROPS_NOBACKGROUND.
In this way, Nano-X won't ever draw on the window, leaving it only
for your use, but will still refresh areas underneath it if/when the window
becomes unmapped or destroyed.

: 
: BTW: without sound, I get about 12-15 fps 320x240 for mpeg1 which is quite
: watchable.

Which player are you "playing" with?

Regards,

Greg