New API and X option UseFBDev

New API and X option UseFBDev

[Jim Hague]

I've been moving the pm2fb driver to the new API (currently working under
2.6.0-test3). I've got it working unaccelerated; still need to add acceleration
and option handling and tidy up.

I have a problem when I try and run X (Debian 4.2.1-11 20030829103906). My
config uses the Glint driver with UseFBDev true, and works fine on 2.4.22. It
fails on 2.6 like this:

(II) Setting vga for screen 0.
(**) GLINT(0): Depth 16, (--) framebuffer bpp 16
(==) GLINT(0): RGB weight 565
(==) GLINT(0): Default visual is TrueColor
(==) GLINT(0): Using gamma correction (1.0, 1.0, 1.0)
(**) GLINT(0): Option "UseFBDev" "true"
(==) GLINT(0): Using HW cursor
(II) Loading sub module "fbdevhw"
(II) LoadModule: "fbdevhw"
(II) Loading /usr/X11R6/lib/modules/linux/libfbdevhw.a
(II) Module fbdevhw: vendor="The XFree86 Project"
        compiled for 4.2.1.1, module version = 0.0.2
        ABI class: XFree86 Video Driver, version 0.5
(**) GLINT(0): Using Linux framebuffer device
(--) GLINT(0): Chipset: "ti_pm2"
(--) GLINT(0): Linear framebuffer at 0xCE800000
(--) GLINT(0): MMIO registers at 0xCFFE0000
(EE) GLINT(0): mmap mmio: Invalid argument
(EE) GLINT(0): mmap mmio: Invalid argument
 
Fatal server error:
Caught signal 11.  Server aborting

The lfb and MMIO addresses are correct. Now, I've new to this game and may have
missed filling out a structure field somewhere. But I'm dammed if I can see
what.

It's occurred to me that maybe this just doesn't work and I need an updated
fbdevhw. Do I? Or should it really Just Work?

-- 
Jim Hague - jim.hague@acm.org          Never trust a computer you can't lift.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: New API and X option UseFBDev

[Michel Dänzer]

On Tue, 2003-09-09 at 08:49, Jim Hague wrote:
> 
> I have a problem when I try and run X (Debian 4.2.1-11 20030829103906). My
> config uses the Glint driver with UseFBDev true, and works fine on 2.4.22. It
> fails on 2.6 like this:
> 
> (II) Setting vga for screen 0.
> (**) GLINT(0): Depth 16, (--) framebuffer bpp 16
> (==) GLINT(0): RGB weight 565
> (==) GLINT(0): Default visual is TrueColor
> (==) GLINT(0): Using gamma correction (1.0, 1.0, 1.0)
> (**) GLINT(0): Option "UseFBDev" "true"
> (==) GLINT(0): Using HW cursor
> (II) Loading sub module "fbdevhw"
> (II) LoadModule: "fbdevhw"
> (II) Loading /usr/X11R6/lib/modules/linux/libfbdevhw.a
> (II) Module fbdevhw: vendor="The XFree86 Project"
>         compiled for 4.2.1.1, module version = 0.0.2
>         ABI class: XFree86 Video Driver, version 0.5
> (**) GLINT(0): Using Linux framebuffer device
> (--) GLINT(0): Chipset: "ti_pm2"
> (--) GLINT(0): Linear framebuffer at 0xCE800000
> (--) GLINT(0): MMIO registers at 0xCFFE0000
> (EE) GLINT(0): mmap mmio: Invalid argument
> (EE) GLINT(0): mmap mmio: Invalid argument
>  
> Fatal server error:
> Caught signal 11.  Server aborting
> 
> The lfb and MMIO addresses are correct. Now, I've new to this game and may have
> missed filling out a structure field somewhere. But I'm dammed if I can see
> what.
> 
> It's occurred to me that maybe this just doesn't work and I need an updated
> fbdevhw. Do I? Or should it really Just Work?

It should just work, certainly does here with the radeon driver and
radeonfb. I'd add some debugging output to the framebuffer device and/or
fbdevHW.


-- 
Earthling Michel Dänzer   \  Debian (powerpc), XFree86 and DRI developer
Software libre enthusiast  \     http://svcs.affero.net/rm.php?r=daenzer



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: New API and X option UseFBDev

[Sven Luther]

On Tue, Sep 09, 2003 at 07:49:55AM +0100, Jim Hague wrote:
> I've been moving the pm2fb driver to the new API (currently working under
> 2.6.0-test3). I've got it working unaccelerated; still need to add acceleration
> and option handling and tidy up.
> 
> I have a problem when I try and run X (Debian 4.2.1-11 20030829103906). My
> config uses the Glint driver with UseFBDev true, and works fine on 2.4.22. It
> fails on 2.6 like this:
> 
> (II) Setting vga for screen 0.
> (**) GLINT(0): Depth 16, (--) framebuffer bpp 16
> (==) GLINT(0): RGB weight 565
> (==) GLINT(0): Default visual is TrueColor
> (==) GLINT(0): Using gamma correction (1.0, 1.0, 1.0)
> (**) GLINT(0): Option "UseFBDev" "true"
> (==) GLINT(0): Using HW cursor
> (II) Loading sub module "fbdevhw"
> (II) LoadModule: "fbdevhw"
> (II) Loading /usr/X11R6/lib/modules/linux/libfbdevhw.a
> (II) Module fbdevhw: vendor="The XFree86 Project"
>         compiled for 4.2.1.1, module version = 0.0.2
>         ABI class: XFree86 Video Driver, version 0.5
> (**) GLINT(0): Using Linux framebuffer device
> (--) GLINT(0): Chipset: "ti_pm2"
> (--) GLINT(0): Linear framebuffer at 0xCE800000
> (--) GLINT(0): MMIO registers at 0xCFFE0000
> (EE) GLINT(0): mmap mmio: Invalid argument
> (EE) GLINT(0): mmap mmio: Invalid argument
>  
> Fatal server error:
> Caught signal 11.  Server aborting
> 
> The lfb and MMIO addresses are correct. Now, I've new to this game and may have
> missed filling out a structure field somewhere. But I'm dammed if I can see
> what.
> 
> It's occurred to me that maybe this just doesn't work and I need an updated
> fbdevhw. Do I? Or should it really Just Work?

I think the glint driver is hardcoded to expect amiga hardware when
using pm2 with fbdev. Just don't use the usefbdev option, and everything
should be fine.

the glint driver does not really support usefbdev anyway, only as a
hacky workaround for amigas with cybervision/bvision graphic board.

Friendly,

Sven Luther


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: New API and X option UseFBDev

[Jim Hague]

On 09-Sep-2003 Michel Dänzer wrote:
> On Tue, 2003-09-09 at 08:49, Jim Hague wrote:
>> I have a problem when I try and run X (Debian 4.2.1-11 20030829103906). My
>> config uses the Glint driver with UseFBDev true, and works fine on 2.4.22.
>> [...]
>> It's occurred to me that maybe this just doesn't work and I need an updated
>> fbdevhw. Do I? Or should it really Just Work?
> 
> It should just work, certainly does here with the radeon driver and
> radeonfb. I'd add some debugging output to the framebuffer device and/or
> fbdevHW.

Thanks for that. I'll keep digging into this, and cross-check with the radeon
driver for clues.

-- 
Jim Hague - jim.hague@acm.org          Never trust a computer you can't lift.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: New API and X option UseFBDev

[Jim Hague]

On 09-Sep-2003 Sven Luther wrote:
> On Tue, Sep 09, 2003 at 07:49:55AM +0100, Jim Hague wrote:
>> I have a problem when I try and run X (Debian 4.2.1-11 20030829103906). My
>> config uses the Glint driver with UseFBDev true, and works fine on 2.4.22.
>> [....]
>> It's occurred to me that maybe this just doesn't work and I need an updated
>> fbdevhw. Do I? Or should it really Just Work?
> 
> I think the glint driver is hardcoded to expect amiga hardware when
> using pm2 with fbdev. Just don't use the usefbdev option, and everything
> should be fine.
> 
> the glint driver does not really support usefbdev anyway, only as a
> hacky workaround for amigas with cybervision/bvision graphic board.

Unfortunately, I do rather think I need to use UseFBDev. Hardware is
Graphics Exxtreme, x86, BTW. Without, things just don't work properly -
something isn't quite right with the mode set by X, and you can't switch back
to the console. Well, you can try, but it seems to hang the kernel.

I'm currently using UseFBDev on 2.4, for the same reasons. I will keep on
digging.

-- 
Jim Hague - jim.hague@acm.org          Never trust a computer you can't lift.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: New API and X option UseFBDev

[Sven Luther]

On Tue, Sep 09, 2003 at 02:57:58PM +0100, Jim Hague wrote:
> On 09-Sep-2003 Sven Luther wrote:
> > On Tue, Sep 09, 2003 at 07:49:55AM +0100, Jim Hague wrote:
> >> I have a problem when I try and run X (Debian 4.2.1-11 20030829103906). My
> >> config uses the Glint driver with UseFBDev true, and works fine on 2.4.22.
> >> [....]
> >> It's occurred to me that maybe this just doesn't work and I need an updated
> >> fbdevhw. Do I? Or should it really Just Work?
> > 
> > I think the glint driver is hardcoded to expect amiga hardware when
> > using pm2 with fbdev. Just don't use the usefbdev option, and everything
> > should be fine.
> > 
> > the glint driver does not really support usefbdev anyway, only as a
> > hacky workaround for amigas with cybervision/bvision graphic board.
> 
> Unfortunately, I do rather think I need to use UseFBDev. Hardware is

Ok, i was wrong, it has been some time since i looked at the glint
driver for fbdev stuff, altough i am kind of the default maintainer of
the glint driver now, or at least part-wise with Alan Hourihane. After
looking at it, i saw that the fbdev code is hardcoded to use a ti_pm2,
and will not work with other graphic chips. But the pm3 X driver i wrote
worked perfectly well without it.

> Graphics Exxtreme, x86, BTW. Without, things just don't work properly -
> something isn't quite right with the mode set by X, and you can't switch back
> to the console. Well, you can try, but it seems to hang the kernel.
> 
> I'm currently using UseFBDev on 2.4, for the same reasons. I will keep on
> digging.

Mmm, notice that the :

(--) GLINT(0): Linear framebuffer at 0xCE800000
(--) GLINT(0): MMIO registers at 0xCFFE0000
(EE) GLINT(0): mmap mmio: Invalid argument
(EE) GLINT(0): mmap mmio: Invalid argument

means that the linear framebuffer and mmio registers, values given to
you by pm2fb, are correct (but check this fact with lspci). GLINTMapMem
should call fbdevHWMapVidmem, so i suppose the message you see are from
fbdevhw. Try enabling the DEBUG #define in glint_driver.c to get a bit
more context. 

Friendly,

Sven Luther


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: New API and X option UseFBDev

[Jim Hague]

On 09-Sep-2003 Sven Luther wrote:
> Mmm, notice that the :
> 
> (--) GLINT(0): Linear framebuffer at 0xCE800000
> (--) GLINT(0): MMIO registers at 0xCFFE0000
> (EE) GLINT(0): mmap mmio: Invalid argument
> (EE) GLINT(0): mmap mmio: Invalid argument
> 
> means that the linear framebuffer and mmio registers, values given to
> you by pm2fb, are correct (but check this fact with lspci). GLINTMapMem
> should call fbdevHWMapVidmem, so i suppose the message you see are from
> fbdevhw. Try enabling the DEBUG #define in glint_driver.c to get a bit
> more context. 

I'd notice that. The code in question is in fbdevhw.c.

I've abstracted the problem out into the test program below. It mimics what
fbdehhw.c does, namely open the frame buffer device, get the fix screen info
and (I'm assuming) mmap() the io (I haven't delved through the detail
of /dev/fb0).

I've run this on 2.4.22-pre6-ac1 and it works fine, and by implication, since
X via UseFBDev has worked since then, since early 2.4. Here's the output:

PAGE_MASK 0xfffff000, ~PAGE_MASK 0xfff
smem_start 0xcf000000 smem_len 0x400000, mmio_start 0xcffe0000, mmio_len 0x10000
fb_off 0x0 fb_len 0x400000, mmio_off 0x0, mmio_len 0x10000
mmap(NULL, 0x10000, PROT_READ | PROT_WRITE, MAP_SHARED, 3, 0x400000)
Worked - map 0x40016000

On 2.6.0-test3 and 2.6.0-test5 the mmap() fails with EINVAL. Again, the output:

PAGE_MASK 0xfffff000, ~PAGE_MASK 0xfff
smem_start 0xcf000000 smem_len 0x400000, mmio_start 0xcffe0000, mmio_len 0x10000
fb_off 0x0 fb_len 0x400000, mmio_off 0x0, mmio_len 0x10000
mmap(NULL, 0x10000, PROT_READ | PROT_WRITE, MAP_SHARED, 3, 0x400000)
mmap mmio: Invalid argument (22)

As you see, the parameters to mmap() are identical. The problem is fb_len -
reduce this to, say, 0x3f0000 and mmap() works.

Any suggestions as to where to look next?

Jim

Test prog:

#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/mman.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>

#include <linux/fb.h>
#include <asm/page.h>

#define FRAMEBUFFER     "/dev/fb0"

int main(int ac, char *av[])
{
    struct fb_fix_screeninfo fix;
    int fd = open(FRAMEBUFFER, O_RDWR, 0);
    size_t mmio_len, fb_len;
    unsigned long mmio_off, fb_off;
    off_t offset;
    int prot, flags;
    void* map;

    if ( fd < 0  )
    {
        printf("Can't open " FRAMEBUFFER "\n");
        exit(1);
    }

    if ( ioctl(fd, FBIOGET_FSCREENINFO, &fix) < 0 )
        printf("IOCTL failed\n");
    else
    {
        printf("PAGE_MASK 0x%x, ~PAGE_MASK 0x%x\n", PAGE_MASK, ~PAGE_MASK);
        
        printf("smem_start 0x%x smem_len 0x%x, "
               "mmio_start 0x%x, mmio_len 0x%x\n",
               fix.smem_start, fix.smem_len, fix.mmio_start, fix.mmio_len);

        mmio_off = (unsigned long) fix.mmio_start & ~PAGE_MASK;
        mmio_len = (mmio_off + fix.mmio_len + ~PAGE_MASK) & PAGE_MASK;
        fb_off = (unsigned long) fix.smem_start & ~PAGE_MASK;
        fb_len = (fb_off + fix.smem_len + ~PAGE_MASK) & PAGE_MASK;
        
        printf("fb_off 0x%x fb_len 0x%x, "
               "mmio_off 0x%x, mmio_len 0x%x\n",
               fb_off, fb_len, mmio_off, mmio_len);

        printf("mmap(NULL, 0x%x, PROT_READ | PROT_WRITE, "
                        "MAP_SHARED, %d, 0x%x)\n",
                        mmio_len, fd, fb_len);
        map = mmap(NULL, mmio_len, PROT_READ | PROT_WRITE, MAP_SHARED,
                   fd, fb_len);
        if ( -1 == (long) map )
            printf("mmap mmio: %s (%d)\n", strerror(errno), errno);
        else
        {
            printf("Worked - map 0x%x\n", map);
            munmap(map, mmio_len);
        }
    }

    close(fd);
    exit(0);
}


-- 
Jim Hague - jim.hague@acm.org          Never trust a computer you can't lift.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: New API and X option UseFBDev

[Sven Luther]

On Tue, Sep 09, 2003 at 11:59:53PM +0100, Jim Hague wrote:
> On 09-Sep-2003 Sven Luther wrote:
> > Mmm, notice that the :
> > 
> > (--) GLINT(0): Linear framebuffer at 0xCE800000
> > (--) GLINT(0): MMIO registers at 0xCFFE0000
> > (EE) GLINT(0): mmap mmio: Invalid argument
> > (EE) GLINT(0): mmap mmio: Invalid argument
> > 
> > means that the linear framebuffer and mmio registers, values given to
> > you by pm2fb, are correct (but check this fact with lspci). GLINTMapMem
> > should call fbdevHWMapVidmem, so i suppose the message you see are from
> > fbdevhw. Try enabling the DEBUG #define in glint_driver.c to get a bit
> > more context. 
> 
> I'd notice that. The code in question is in fbdevhw.c.

Ok.

> I've abstracted the problem out into the test program below. It mimics what
> fbdehhw.c does, namely open the frame buffer device, get the fix screen info
> and (I'm assuming) mmap() the io (I haven't delved through the detail
> of /dev/fb0).
> 
> I've run this on 2.4.22-pre6-ac1 and it works fine, and by implication, since
> X via UseFBDev has worked since then, since early 2.4. Here's the output:
> 
> PAGE_MASK 0xfffff000, ~PAGE_MASK 0xfff
> smem_start 0xcf000000 smem_len 0x400000, mmio_start 0xcffe0000, mmio_len 0x10000
> fb_off 0x0 fb_len 0x400000, mmio_off 0x0, mmio_len 0x10000
> mmap(NULL, 0x10000, PROT_READ | PROT_WRITE, MAP_SHARED, 3, 0x400000)
> Worked - map 0x40016000
> 
> On 2.6.0-test3 and 2.6.0-test5 the mmap() fails with EINVAL. Again, the output:
> 
> PAGE_MASK 0xfffff000, ~PAGE_MASK 0xfff
> smem_start 0xcf000000 smem_len 0x400000, mmio_start 0xcffe0000, mmio_len 0x10000
> fb_off 0x0 fb_len 0x400000, mmio_off 0x0, mmio_len 0x10000
> mmap(NULL, 0x10000, PROT_READ | PROT_WRITE, MAP_SHARED, 3, 0x400000)
> mmap mmio: Invalid argument (22)
> 
> As you see, the parameters to mmap() are identical. The problem is fb_len -
> reduce this to, say, 0x3f0000 and mmap() works.
> 
> Any suggestions as to where to look next?

It sounds like a kernel problem, and i can't help you more about this.
Still, and sorry if i am speaking non-sense, but it is early morning,
but in the :

>         map = mmap(NULL, mmio_len, PROT_READ | PROT_WRITE, MAP_SHARED,
>                    fd, fb_len);

Code, i see nowhere that you make mention of the corresponding offsets.
In a small program i did myself for accessing my graphic card by hand, i
did :

      base = mmap((caddr_t)0, Size, PROT_READ|PROT_WRITE,
	          MAP_SHARED|MAP_LOCKED, fd, (off_t)Base);

so your fb_len should maybe have been mmio_start, i think.

Friendly,

Sven Luther


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: New API and X option UseFBDev

[Jim Hague]

On 09-Sep-2003 Jim Hague wrote:
> On 09-Sep-2003 Sven Luther wrote:
>> (--) GLINT(0): Linear framebuffer at 0xCE800000
>> (--) GLINT(0): MMIO registers at 0xCFFE0000
>> (EE) GLINT(0): mmap mmio: Invalid argument
>> (EE) GLINT(0): mmap mmio: Invalid argument
>> 
>> means that the linear framebuffer and mmio registers, values given to
>> you by pm2fb, are correct (but check this fact with lspci).

OK, found the problem. I've been following tdfxfb.c and had copied it in
setting var->accel_flags = FB_ACCELF_TEXT. Having accel_flags at anything other
than 0 stops the mmap() from working.

On my 2.4 setup, accel_flags looks like it ought to be set to FB_ACCELF_TEXT
but isn't. So mmap() works.

-- 
Jim Hague - jim.hague@acm.org          Never trust a computer you can't lift.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: New API and X option UseFBDev

[Sven Luther]

On Wed, Sep 10, 2003 at 10:52:15AM +0100, Jim Hague wrote:
> On 09-Sep-2003 Jim Hague wrote:
> > On 09-Sep-2003 Sven Luther wrote:
> >> (--) GLINT(0): Linear framebuffer at 0xCE800000
> >> (--) GLINT(0): MMIO registers at 0xCFFE0000
> >> (EE) GLINT(0): mmap mmio: Invalid argument
> >> (EE) GLINT(0): mmap mmio: Invalid argument
> >> 
> >> means that the linear framebuffer and mmio registers, values given to
> >> you by pm2fb, are correct (but check this fact with lspci).
> 
> OK, found the problem. I've been following tdfxfb.c and had copied it in
> setting var->accel_flags = FB_ACCELF_TEXT. Having accel_flags at anything other
> than 0 stops the mmap() from working.
> 
> On my 2.4 setup, accel_flags looks like it ought to be set to FB_ACCELF_TEXT
> but isn't. So mmap() works.

:))) Once you are finished, i may be willing to add pm3fb support to
your code, would that be ok for you ?

Friendly,

Sven Luther


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: New API and X option UseFBDev

[Jim Hague]

On 10-Sep-2003 Sven Luther wrote:
>:))) Once you are finished, i may be willing to add pm3fb support to
> your code, would that be ok for you ?

Of course. Apart from anything else, I'd welcome someone who knows what they
are doing looking at the code. ;-)

-- 
Jim Hague - jim.hague@acm.org          Never trust a computer you can't lift.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: New API and X option UseFBDev

[Sven Luther]

On Wed, Sep 10, 2003 at 11:48:59AM +0100, Jim Hague wrote:
> On 10-Sep-2003 Sven Luther wrote:
> >:))) Once you are finished, i may be willing to add pm3fb support to
> > your code, would that be ok for you ?
> 
> Of course. Apart from anything else, I'd welcome someone who knows what they
> are doing looking at the code. ;-)

ok, if you want, just send me the code with only the mode setting stuff
and i will try to look at it, and try to add pm3 support also, altough i
don't have a mainboard in which to plug my pm3 board anymore, thanks to
agp8x dropping backward compatibility.

Friendly,

Sven Luther


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: New API and X option UseFBDev

[James Simmons]

> On 09-Sep-2003 Jim Hague wrote:
> > On 09-Sep-2003 Sven Luther wrote:
> >> (--) GLINT(0): Linear framebuffer at 0xCE800000
> >> (--) GLINT(0): MMIO registers at 0xCFFE0000
> >> (EE) GLINT(0): mmap mmio: Invalid argument
> >> (EE) GLINT(0): mmap mmio: Invalid argument
> >> 
> >> means that the linear framebuffer and mmio registers, values given to
> >> you by pm2fb, are correct (but check this fact with lspci).
> 
> OK, found the problem. I've been following tdfxfb.c and had copied it in
> setting var->accel_flags = FB_ACCELF_TEXT. Having accel_flags at anything other
> than 0 stops the mmap() from working.
> 
> On my 2.4 setup, accel_flags looks like it ought to be set to FB_ACCELF_TEXT
> but isn't. So mmap() works.

Really cool that we have working Permiedia driver now :-) The reason for 
the FB_ACCELF_TEXT is to prevent userland from using the accel engine at 
the same time as fbcon.




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf