[okl4-developer] Starting with graphic output

[Remy Gottschalk]

Hi all,


> > > 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.
> 

I guess I wasn't clear, in fact the check pass meaning mmap is asking
write ability (prot&PROT_WRITE) but the file isn't wasn't open with
write mode !(file->f_mode&FMODE_WRITE) witch return an EACCES error.


> 
> > 
> > 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?
 
To point out the problem more precisely I wrote a little test : 
> cat test_write.c
#include <fcntl.h>
#include <stdlib.h>
#include <stdio.h>

int main()
{
  int	fd;
  
  fd = open("./test", O_RDWR);

  if (fd == -1) 
    perror("open");
  else
    printf ("open RDWR success\n");

  if (write(fd, "test", 4) == -1)
    perror ("write RDWR");
  else
    printf ("write RDWR success\n");

  close(fd);
  
  fd = open("./test", O_WRONLY);

  if (fd == -1) 
    perror("open");
  else
    printf ("open WRONLY success\n");
 
 if (write(fd, "test", 4) == -1)
    perror ("write WRONLY");
  else
    printf ("write WRONLY success\n");

  close(fd);
}

With a nice Makefile and SConscript to make it compile as a Linux
application. 

Compiled with framework 2.1 running in wonbat under qemu :
/ # touch test
/ # test_write 
open RDWR success
write RDWR: Bad file descriptor
open WRONLY success
write WRONLY success
  
Compiled with framework 2.1 running on my box :
> touch test
> ./linux/apps/test_write/test_write 
open RDWR success
write RDWR: Bad file descriptor
open WRONLY success
write WRONLY success

Compiled with framework 1.5.2 running in wombat under qemu :
> touch test
> test_write 
open RDWR success
write RDWR success
open WRONLY success
write WRONLY success

Compiled with framework 1.5.2 running on my box :
> touch test
> ./linux/apps/test_write /test_write 
open RDWR success
write RDWR success
open WRONLY success
write WRONLY success

Hand compiled (cc test_write.c -o test_write)
> touch test
> test_write
open RDWR success
write RDWR success
open WRONLY success
write WRONLY success

So it seems that when compiled with 2.1 framework opening a file  with 
O_RDWR doesn't give writing right even if the file is opened successfully.
Since it behave the same on okl4 environment and on my box I'd accuse the
libc.
Since it may be a setup problem on my side could you please perform this test ?
Also if you got any clue about what is happening feel free to tell.

Regards,


-- 
Remy Gottschalk - rgottschalk at linagora.com
Ingénieur informatique embarquée
Groupe LINAGORA - http://www.linagora.com
Tél.: +33(0)1 58 18 68 28 - Fax : +33(0)1 58 18 68 29