AnsweredAssumed Answered

mmap fails for /dev/fb0

Question asked by skstrobel on Feb 8, 2012
Latest reply on Feb 15, 2012 by skstrobel

I am trying to get the Qt graphics library to run with the Linux virtual framebuffer.  I enabled the virtual framebuffer in the build and started the kernel with the video=vfb: option.  fbset seems to think the framebuffer is OK:

 

    fbset -g 320 240 320 240 8

     fbset

    mode "320x240-181"

        # D: 25.176 MHz, H: 52.449 kHz, V: 180.859 Hz

        geometry 320 240 320 240 8

        timings 39721 40 24 39 9 96 2

        accel false

        rgba 8/0,8/0,8/0,0/0

    endmode

 

When I run my application (using the -qws option) it does a stack dump with a bunch of mmap stuff in it, then the kernel panics.  Running it with strace shows that the offending call is "mmap2(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE, 8, 0   0)".  Stepping into the Qt library code shows that the QLinuxFbScreen::connect() function opens /dev/fb0 (to get the fd of 8).  The size of 1048576 comes from an ioctl call to get FBIOGET_FSCREENINFO (I also tried manually changing the size requested from mmap to 131072 with the debugger with the same result).

 

Why is the call to mmap() failing?  Does it have something to do with the lack of virtual memory?  It seems the Qt accounts for that, as it conditionally uses MAP_PRIVATE rather than MAP_SHARED for builds like this with QT_LINUX_NOMMU defined.  What about the bug in remap_pfn_range() that is mentioned in http://ez.analog.com/thread/11434?  I am using Linux-2.6.28.10-ADI-2009R1.1.

 

I haven't yet set up the source paths for the debugger to see the source of mmap itself, but I wanted to make sure the problem wasn't obvious to someone before I dug in that deep.  Thanks for any suggestions.

 

Steve

Outcomes