nanogui: Thread: Microwindows and non zero screenbase


[<<] [<] Page 1 of 1 [>] [>>]
Subject: Microwindows and non zero screenbase
From: Fabrice Gautier ####@####.####
Date: 25 Mar 2002 21:13:25 -0000
Message-Id: <B1F6452C89AFD411AE0800A0CC734C239DBB9D@EMAIL1>

Hi,

In the framebuffer driver (scr_fb.c) the framebuffer is mapped with :

psd->addr = mmap(NULL, psd->size, PROT_READ|PROT_WRITE,MAP_SHARED,fb,0);

In my case the video buffer doesnt start on a page boundary so the mmaped
memory start a few bytes earlier. In the linux framebuffer driver this
information is stored in screen_base in an fb_info struct, however it seems
that microwindows doesnt have this information so that when it want to draw
something on the screen, it start at offset 0 (which in my specific case is
not a pixel but something else)

I'm looking for a solution to this problem, any insight on this?

Thank you

-- 
Fabrice Gautier, 
####@####.####
Subject: Re: [nanogui] Microwindows and non zero screenbase
From: "Greg Haerr" ####@####.####
Date: 27 Mar 2002 02:39:15 -0000
Message-Id: <052001c1d537$a67249f0$6401a8c0@gregnewport>

> psd->addr = mmap(NULL, psd->size, PROT_READ|PROT_WRITE,MAP_SHARED,fb,0);
>
> In my case the video buffer doesnt start on a page boundary so the mmaped
> memory start a few bytes earlier. In the linux framebuffer driver this
> information is stored in screen_base in an fb_info struct, however it
seems
> that microwindows doesnt have this information so that when it want to
draw
> something on the screen, it start at offset 0 (which in my specific case
is
> not a pixel but something else)

You should be able to just add in your offset to psd->addr:
psd->addr += fb_info.screen_base;
Microwindows doesn't assume anything about psd->addr
except that it's the start of the drawable hw framebuffer.

Regards,

Greg




>
> I'm looking for a solution to this problem, any insight on this?
>
> Thank you
>
> --
> Fabrice Gautier,
> ####@####.####
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>

Subject: RE: [nanogui] Microwindows and non zero screenbase
From: Fabrice Gautier ####@####.####
Date: 27 Mar 2002 03:03:54 -0000
Message-Id: <B1F6452C89AFD411AE0800A0CC734C239DBB9F@EMAIL1>

> -----Original Message-----
> From: Greg Haerr ####@####.####
> Sent: Tuesday, March 26, 2002 6:33 PM
> To: Fabrice Gautier; Nanogui (E-mail)
> Subject: Re: [nanogui] Microwindows and non zero screenbase
> 
> 
> > psd->addr = mmap(NULL, psd->size, 
> > PROT_READ|PROT_WRITE,MAP_SHARED,fb,0);
> >
> > In my case the video buffer doesnt start on a page boundary 
> > so the mmaped memory start a few bytes earlier. In the linux
> > framebuffer driver this information is stored in screen_base
> > in an fb_info struct, 
> 
> You should be able to just add in your offset to psd->addr:
> psd->addr += fb_info.screen_base;
> Microwindows doesn't assume anything about psd->addr
> except that it's the start of the drawable hw framebuffer.

Actually this is a bot more complicated, because:

1/ There's no way to get an fb_info struct from the driver.
2/ The only thing you can get is the _physical_ address of the drawable
buffer, so that in order to get the offset you have to play with PAGE_MASK.
3/ When you munmap, you also have to find a way to give the same address
that you get from mmap (and not the drawable buffer)

I tried to do that but it didnt work at the first try, so instead i fixed
the kernel framebuffer driver so that only the drawable buffer is mmap (this
is much better anyway)

The thing is that X handled this case pretty well so the problem was not
aparent at first.

Thanks


[<<] [<] Page 1 of 1 [>] [>>]


Powered by ezmlm-browse 0.20.