[SOLVED] Which format should I expect in output of the buffer address from fbset.c?

Didier Spaier · 07-18-2014, 07:09 AM

Not sure if that's the good place to ask, so please let me know a better one case occurring.

Context: the program fbset shipped in thee a/bin Slackware package.

I need to check in a shell script the output of "fbset -i", especially the usability of the start of the buffer address returned after "Address: "

Here is the code snippet from fbset.c (that's on Slackware-14.1 but hasn't changed since years):

Code:

 printf("    Address     : %p\n", fix->smem_start);

And the definition of *smem_start in included header fb.h

Code:

struct fb_fix_screeninfo {
    char id[16];            /* identification string eg "TT Builtin" */
    char *smem_start;        /* Start of frame buffer mem */
                    /* (physical address) */
    __u32 smem_len;            /* Length of frame buffer mem */
<deleted>
};

I need to rule out unusable buffer addresses before possibly starting an FbTerm, as I want to start it only in case of an usable frame buffer device.

I already noticed a value of (nil) in one case, obviously unacceptable. I have also read that someone found "0" (zero), also unacceptable.

More generally, my question is: can I assume that a "good" address will always be of the form "0X<hexadecimal digits>"?

I ask because I've read somewhere about %p that "The value of the pointer is converted to a sequence of printing characters, in an implementation-defined manner." Alas, I don't know how that manner is defined in this case (C program in Slackware Linux, on an x86 architecture). Maybe the headers included could give a clue, but only to someone more knowledgeable than me.

phenixia2003 · 07-18-2014, 09:12 AM

Hello,

null, nil and 0 are common constants used to indicate an unassigned pointer. So, any address that matches one of the following patterns is, probably, invalid :

Code:

nil
NIL
null
NULL
0
0x0
0+
0x0+

--
SeB

Didier Spaier · 07-19-2014, 08:34 AM

Thanks SeB. Marking this thread as [SOLVED].

tronayne · 07-19-2014, 08:59 AM

For starters, you can look at

Code:

ls -l /dev/fb*
crw-rw---- 1 root video 29, 0 Jul 17 07:00 /dev/fb0

I don't really know, but I'd bet that if you have more than one frame buffer device and one of them is not accessible, the file mode will indicate that? Maybe see what the one you have that shows NULL?

You can bet farm that if fbset -i -v does not display an address for a frame buffer device it's not available. A "good" display looks like

Code:

fbset -i -v
Linux Frame Buffer Device Configuration Version 2.1 (23/06/1999)
(C) Copyright 1995-1999 by Geert Uytterhoeven

Opening frame buffer device `/dev/fb0'
Using current video mode from `/dev/fb0'

mode "1920x1080"
    geometry 1920 1080 1920 1080 32
    timings 0 0 0 0 0 0 0
    accel true
    rgba 8/16,8/8,8/0,0/0
endmode

Getting further frame buffer information
Frame buffer device information:
    Name        : inteldrmfb
    Address     : 0xe0046000
    Size        : 8294400
    Type        : PACKED PIXELS
    Visual      : TRUECOLOR
    XPanStep    : 1
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 7680
    Accelerator : No

This suggests that a combination of grep, cut and ${#parameter} might be useful. I'm sorry that I only use KornShell, but suspect that BASH has the same or similar parameter expansion function for getting string length: the address field is 10 characters long and anything less than that will be an invalid address, so grep for 'Address', pipe that into cut and test the length of the third field with parameter expansion. Can't imagine that BASH doesn't have such a function but I haven't a clue what it might be, sorry.

I did look on a headless server (no display attached) with ssh:

Code:

fbset -i -v
Linux Frame Buffer Device Configuration Version 2.1 (23/06/1999)
(C) Copyright 1995-1999 by Geert Uytterhoeven

Opening frame buffer device `/dev/fb0'
Using current video mode from `/dev/fb0'

mode "1024x768"
    geometry 1024 768 1024 768 32
    timings 0 0 0 0 0 0 0
    accel true
    rgba 8/16,8/8,8/0,0/0
endmode

Getting further frame buffer information
Frame buffer device information:
    Name        : radeondrmfb
    Address     : 0xd00c0000
    Size        : 3145728
    Type        : PACKED PIXELS
    Visual      : TRUECOLOR
    XPanStep    : 1
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 4096
    Accelerator : No

This looks like the frame buffer device depends upon the card, not on an active display attached to it.

The first frame buffer display up top is a 64-bit box, the one immediately above is a 32-bit, both are Slackware 14.1 if that matters.

Anyway, I'd look at /dev/fb*, look at the file mode (is it readable and writable, owner, group, stuff like that) and then I'd look at the output of fbset -i -v and see what there is to see. I don't have anything with more than one graphics card so I can't really tell what you get for multiple devices so this entire discussion might be moot (and there may be a better, quicker way, say multiple patten matching but I think looking at the length of the Address might be a good start).

Hope this helps some.

phenixia2003 · 07-19-2014, 11:17 AM

Hello,

I found this page with a small c code to test if the framebuffer is setup correctly. I guess, it could help you to identify if a framebuffer is valid or not. When the framebuffer is ok, it returns 0, otherwise a non 0 value is returned. I slightly modified the code so that, you can pass a framebuffer device in argument (ex checkfb /dev/fb1). Without any argument the new code open /dev/fb0. I also removed the code that draw a gradient on screen. You will find the modified source in attachment. To compile it :

Code:

$ gcc -x c -Wall -o checkfb checkfb.c.txt

--
SeB

Didier Spaier · 07-19-2014, 05:13 PM

@Sébastien:

Well, this is embarrassing: I've found a case (in a vmplayer VM) where, though the address reported by "fbset -i" be (nil), checkfb reports "The framebuffer device was mapped to memory successfully.". And that seems to be true as not only can I launch fbterm but also exit from it without a hitch.

In another case (in a qemu VM with a Cirrus video card emulated), the address is still (nil) but checkfb reports "Error: failed to map framebuffer device to memory: Invalid argument." In the latter case I still can launch fbterm, but typing exit leads to a black screen.

So I'm tempted to think that your checkfb gives more accurate information than "fbterm -i" on that respect, and use it. In addition, it is not heavy (8461 bytes for the 32 bit version) and gives directly the resolution that I can then use to set the font size in the fbterm command, instead of relying on fbset (incidentally, to use fbset in the installer I had to copy the binary from Slackware as the busybox binary lacks the -i option).

From this page I assume that I should make your source file available, mentioning that it was initially written by Trolltech and you modified it. It would be great if you could write the relevant legal statement on top of the source file. As this source file is not heavy maybe I can just ship it in the ISO image itself?

In any case, thanks a lot.

@tronayne: thanks for your input.

I already check that /proc/fb be not empty and /dev/fb exists before making other tests. As for the length of the address, I like the idea but as stated above I eventually found a case where though it didn't look good there was no issue using the frame buffer.

For the records, before trying last suggestion from phenixia2003 and following his previous one, I wrote this test:

Code:

if [ ! "`/usr/sbin/fbset -i|grep Address|grep -E "nil|NIL|null|NULL|\<0+\>|\<0x0+\>"`" = "" ]; then
  echo "n">/tmp/fbt
fi

Oh, and about ${#parameter}, yes it works in bash (fortunately as it's specified in POSIX).

PS Out of curiosity I tried the legacy vga16fb driver (to do that, just include vga=normal in the command line to disable vesafb, then "modprobe vga16fb"). Unfortunately, this one is reported as bad as well by checkfb and here is the output of "fbset -i":

Code:

mode "640x480-60"
    # D: 25.176 MHz, H: 31.469 kHz, V: 59.942 Hz
    geometry 640 480 640 480 4
    timings 39721 48 16 33 10 96 2
    rgba 6/0,6/0,6/0,0/0
endmode

Frame buffer device information:
    Name        : VGA16 VGA
    Address     : 0xa0000
    Size        : 65536
    Type        : VGA 16 colors in 4 planes
    Visual      : PSEUDOCOLOR
    XPanStep    : 8
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 80
    Accelerator : No

So, vga16fb can't be used as a fall back...

phenixia2003 · 07-20-2014, 05:22 AM

Quote:

Originally Posted by Didier Spaier

From this page I assume that I should make your source file available, mentioning that it was initially written by Trolltech and you modified it. It would be great if you could write the relevant legal statement on top of the source file. As this source file is not heavy maybe I can just ship it in the ISO image itself?

You will find a version with legal statement in the attached file checkfb.c.txt

On other hand, I found a more recent version in qt source (here). This version is in examples/qws/framebuffer, is under BSD license, and works as below :

Code:

$ framebuffer [nographicsmodeswitch] [framebuffer-device]

The original version writes information, performs some speed test and draws 3 rectangle on the screen. I slightly changed the code (moved one if statement) so that the speed and draw test are not performed when nographicsmodeswitch is passed (attached file checkfb2.c.txt). To compile it :

Code:

$ gcc -Wall -x c -o checkfb2 checkfb2.c.txt

Sample usage of checkfb2 :

Code:

./checkfb2 nographicsmodeswitch /dev/fb0
The framebuffer device was opened successfully.

Fixed screen info:
        id:          VESA VGA
        smem_start:  0xf1000000
        smem_len:    6291456
        type:        0
        type_aux:    0
        visual:      2
        xpanstep:    0
        ypanstep:    0
        ywrapstep:   0
        line_length: 4096
        mmio_start:  0x0
        mmio_len:    0
        accel:       0

The framebuffer device was mapped to memory successfully.

Variable screen info:
        xres:           1024
        yres:           768
        xres_virtual:   1024
        yres_virtual:   768
        yoffset:        0
        xoffset:        0
        bits_per_pixel: 32
        grayscale: 0
        red:    offset: 16, length:  8, msb_right:  0
        green:  offset:  8, length:  8, msb_right:  0
        blue:   offset:  0, length:  8, msb_right:  0
        transp: offset: 24, length:  8, msb_right:  0
        nonstd:       0
        activate:     0
        height:       -1
        width:        -1
        accel_flags:  0x0
        pixclock:     12714
        left_margin:  128
        right_margin: 32
        upper_margin: 16
        lower_margin: 4
        hsync_len:    128
        vsync_len:    4
        sync:         0
        vmode:        0

Note: checkfb2 is larger than checkfb :

Code:

            checkfb (64-bit)  checkfb2 (64-bit)
unstripped    11652             21187
stripped       6680             14944

--
SeB

Didier Spaier · 07-20-2014, 02:35 PM

Thanks again Sébastien!

Even if we won't use all features of checkfb2 in Slint installers, I think that we can afford the extra payload.

Also, I checked that fbset relies on a very old header fb.h shipped in the source tarball (dating back 23/06/1999) that of course ignore all more recent video cards. In contrast checkfb and checkfb2 rely on the header in /usr/include/linux. That's one more reason to use one of these, IMO.

A small detail: in the "old" fb.h, the start of the frame buffer mem is defined as char *smem_start, but in the recent ones as a unsigned long smem_start. I don't know if that matters though.

I think that checkfb2 would deserve to be contributed to http://slackbuilds.org. If you want to do that yourself that's great, if you prefer that I do it just let me know.

It would just need to get a small --help option displaying the usage, and maybe the option name nographicsmodeswitch could be shorter

phenixia2003 · 07-21-2014, 03:48 AM

Hello,

Quote:

Originally Posted by Didier Spaier

Even if we won't use all features of checkfb2 in Slint installers, I think that we can afford the extra payload.

If you don't need/want the graphic tests, I can remove the code and checkfb2 will be smaller. Furthermore, it would be better to rename checkfb2 to checkfb.

Quote:

Originally Posted by Didier Spaier

A small detail: in the "old" fb.h, the start of the frame buffer mem is defined as char *smem_start, but in the recent ones as a unsigned long smem_start. I don't know if that matters though.

No. The first use a pointer to *reference* an address, while the second use a unsigned long integer to *store* an address. In my point of view, the second form is less ambiguous and less error prone.

Quote:

Originally Posted by Didier Spaier

I think that checkfb2 would deserve to be contributed to http://slackbuilds.org. If you want to do that yourself that's great, if you prefer that I do it just let me know.

I prefer that you do it.

Quote:

Originally Posted by Didier Spaier

It would just need to get a small --help option displaying the usage, and maybe the option name nographicsmodeswitch could be shorter

I will add an -h|--help option and, unless you want to remove the graphic tests, I will change nographicsmodeswitch. Which one do you want ?

Code:

-n|--no-graphics 
-n|--no-mode-switch 
-n|--nomodeset

--
SeB

Didier Spaier · 07-21-2014, 11:17 AM

In Slint installers I'll keep the "small" checkfb, as its features suffice for this use case and the reported errors are the same in both programs.

Instead, I'll propose build material for the "big" program to http://slackbuilds.org. So:

Quote:

Originally Posted by phenixia2003

If you don't need/want the graphic tests, I can remove the code and checkfb2 will be smaller.

No, please keep all its features.

Quote:

Originally Posted by phenixia2003

Furthermore, it would be better to rename checkfb2 to checkfb.

Yes.

Quote:

Originally Posted by phenixia2003

I prefer that you do it.

I will.

Quote:

Originally Posted by phenixia2003

I will add an -h|--help option and, unless you want to remove the graphic tests, I will change nographicsmodeswitch. Which one do you want ?

Code:

-n|--no-graphics 
-n|--no-mode-switch 
-n|--nomodeset

no-graphics seems me to be the most relevant.

Also, maybe you could suggest in the help text this usage:

Code:

checkfb [-n | --no-graphics] [/dev/fb<n>] 1>results 2>errors

(not to loose parts of the results going back to text mode).

Thanks,

phenixia2003 · 07-21-2014, 11:54 AM

Hello,

checkfb.c.txt in attachment with help and no-graphics options.

Code:

$ ./checkfb -h
Usage: checkfb [ -h|--help ] [-n|--no-graphics ] [ /dev/fb<n> ] 

-h|--help      : 
    display this help and exit.

-n|--no-graphics: 
    disables the performance and drawing tests.

/dev/fb<n>     : 
    the frame buffer device to check (/dev/fb0 by default). 

Important:
  When performance and drawing tests are enabled, the results can be lost when 
  going back to text mode. To workaround this, it is advised to run checkfb as 
  below :

    checkfb [ /dev/fb<n>] 1>results 2>errors

This version only accept /dev/fb<.*> as framebuffer device, otherwise it throw an error :

Code:

$ ./checkfb /dev/sdb1
(ERROR) unexpected argument '/dev/sdb1'. Run checkfb --help for usage.

To build it :

Code:

$ gcc -Wall -x c -o checkfb checkfb.c.txt

If you have trouble, let me know.

--
SeB

Didier Spaier · 07-21-2014, 11:58 AM

Wow, that was fast!