[okl4-developer] Starting with graphic output

[Geoffrey Lee]

On Fri, Apr 25, 2008 at 05:26:35PM +0000, Remy Gottschalk wrote:

Hi Remy

> > 
> > How are you mmaping the device?  mmaping memory in userspace should arrive at 
> > eas_map(), this suggests to me that it is failing some check earlier on.  
> > I suggest using printk() or similar to trace the execution to find 
> > out where and why exaclty the mmap() call is failing.
> > 
> > 	-gl
> > 
> 
> I did what you suggested and tracked down where the mmap call fail and
> what I found is pretty unexpected.
> So if I open the framebuffer with RW rights.
> fb_fd = open("/dev/fb0", O_RDWR);
> When i mmap it 
> fb_p = (char *)mmap(0, screensize, PROT_READ | PROT_WRITE, MAP_SHARED,
>                    fb_fd, 0);
> 
> My mmap call goes its way to do_mmap_pgoff in mm/mmap.c and fail at a
> basic check :
> if ((prot&PROT_WRITE) && !(file->f_mode&FMODE_WRITE))
> 	return -EACCES;
> This check only verify if when asking a mapping with write access the
> file is open with write right.

It is failing some fail check.  Which check it is failing on
would be quite easy to verify.  Just looking at it I am guessing
the second, but I could be wrong.


> 
> And when I open the device with writing right only (witch is sufficient
> after all since i just want to get my framebuffer uggly :) ) it all goes
> fine and I get the good old roottask pagefault at 0x18.
> 
> By the way the open goes fine and return no error. Furthermore I can
> achieve successful ioctls on the device such as blank screen and
> retrieving information structures.
> 
> I didn't dig in more for now but it seems that there some problem with
> file rights.
> 
> I guess I will wait a little before playing with framebuffer or use it a
> different way.

I am not aware of anything that may change the behavior in OK Linux.
Have you tried this program Linux 2.6.23 on raw hardware?


> 
> Regards,

	-gl