LinuxQuestions.org
Did you know LQ has a Linux Hardware Compatibility List?
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 07-18-2014, 07:09 AM   #1
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad T61 6457-4XG
Posts: 4,388

Rep: Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090
Which format should I expect in output of the buffer address from fbset.c?


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.

Last edited by Didier Spaier; 07-19-2014 at 08:34 AM. Reason: Title edited.
 
Old 07-18-2014, 09:12 AM   #2
phenixia2003
Member
 
Registered: May 2006
Location: France
Distribution: Slackware
Posts: 293

Rep: Reputation: 166Reputation: 166
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
 
1 members found this post helpful.
Old 07-19-2014, 08:34 AM   #3
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad T61 6457-4XG
Posts: 4,388

Original Poster
Rep: Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090
Thanks SeB. Marking this thread as [SOLVED].

Last edited by Didier Spaier; 07-19-2014 at 08:43 AM.
 
Old 07-19-2014, 08:59 AM   #4
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,079

Rep: Reputation: 794Reputation: 794Reputation: 794Reputation: 794Reputation: 794Reputation: 794Reputation: 794
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.
 
1 members found this post helpful.
Old 07-19-2014, 11:17 AM   #5
phenixia2003
Member
 
Registered: May 2006
Location: France
Distribution: Slackware
Posts: 293

Rep: Reputation: 166Reputation: 166
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
Attached Files
File Type: txt checkfb.c.txt (1.5 KB, 8 views)
 
1 members found this post helpful.
Old 07-19-2014, 05:13 PM   #6
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad T61 6457-4XG
Posts: 4,388

Original Poster
Rep: Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090
@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...

Last edited by Didier Spaier; 07-22-2014 at 01:05 AM.
 
Old 07-20-2014, 05:22 AM   #7
phenixia2003
Member
 
Registered: May 2006
Location: France
Distribution: Slackware
Posts: 293

Rep: Reputation: 166Reputation: 166
Quote:
Originally Posted by Didier Spaier View Post
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
Attached Files
File Type: txt checkfb.c.txt (1.8 KB, 3 views)
File Type: txt checkfb2.c.txt (16.7 KB, 4 views)

Last edited by phenixia2003; 07-20-2014 at 05:33 AM.
 
1 members found this post helpful.
Old 07-20-2014, 02:35 PM   #8
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad T61 6457-4XG
Posts: 4,388

Original Poster
Rep: Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090
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
 
Old 07-21-2014, 03:48 AM   #9
phenixia2003
Member
 
Registered: May 2006
Location: France
Distribution: Slackware
Posts: 293

Rep: Reputation: 166Reputation: 166
Hello,

Quote:
Originally Posted by Didier Spaier View Post
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 View Post
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 View Post
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 View Post
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
 
Old 07-21-2014, 11:17 AM   #10
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad T61 6457-4XG
Posts: 4,388

Original Poster
Rep: Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090
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 View Post
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 View Post
Furthermore, it would be better to rename checkfb2 to checkfb.
Yes.
Quote:
Originally Posted by phenixia2003 View Post
I prefer that you do it.
I will.
Quote:
Originally Posted by phenixia2003 View Post
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,

Last edited by Didier Spaier; 07-21-2014 at 11:20 AM.
 
Old 07-21-2014, 11:54 AM   #11
phenixia2003
Member
 
Registered: May 2006
Location: France
Distribution: Slackware
Posts: 293

Rep: Reputation: 166Reputation: 166
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
Attached Files
File Type: txt checkfb.c.txt (18.0 KB, 4 views)
 
2 members found this post helpful.
Old 07-21-2014, 11:58 AM   #12
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad T61 6457-4XG
Posts: 4,388

Original Poster
Rep: Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090Reputation: 1090
Wow, that was fast!
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Using SED with EXPECT to trim a string from buffer h4rri Linux - Newbie 11 11-10-2013 07:59 AM
Best video format for YouTube upload and can Recordmydesktop output that format? linus72 Linux - Software 6 12-21-2009 03:53 PM
expect script output don___quixote Linux - Newbie 5 07-06-2009 09:24 AM
expect script output saltydog4791 Programming 1 05-27-2008 08:01 AM
mplayer and fglrx [gl] Could not aquire buffer for dr Expect a _major_ speed penalty Debian_Poland Linux - Software 1 04-07-2006 04:58 PM


All times are GMT -5. The time now is 12:55 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration