From: Jim Hague <hidden> Date: 2003-09-09 06:50:00
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
From: Michel Dänzer <hidden> Date: 2003-09-09 09:22:13
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
From: Sven Luther <hidden> Date: 2003-09-09 10:09:25
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
From: Jim Hague <hidden> Date: 2003-09-09 13:53:14
On 09-Sep-2003 Michel Dänzer wrote:
On Tue, 2003-09-09 at 08:49, Jim Hague wrote:
quoted
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
From: Jim Hague <hidden> Date: 2003-09-09 13:58:02
On 09-Sep-2003 Sven Luther wrote:
On Tue, Sep 09, 2003 at 07:49:55AM +0100, Jim Hague wrote:
quoted
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
From: Sven Luther <hidden> Date: 2003-09-09 16:41:09
On Tue, Sep 09, 2003 at 02:57:58PM +0100, Jim Hague wrote:
On 09-Sep-2003 Sven Luther wrote:
quoted
On Tue, Sep 09, 2003 at 07:49:55AM +0100, Jim Hague wrote:
quoted
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
From: Jim Hague <hidden> Date: 2003-09-09 22:59:57
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
From: Sven Luther <hidden> Date: 2003-09-10 04:53:00
On Tue, Sep 09, 2003 at 11:59:53PM +0100, Jim Hague wrote:
On 09-Sep-2003 Sven Luther wrote:
quoted
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 :
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
From: Jim Hague <hidden> Date: 2003-09-10 09:52:20
On 09-Sep-2003 Jim Hague wrote:
On 09-Sep-2003 Sven Luther wrote:
quoted
(--) 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
From: Sven Luther <hidden> Date: 2003-09-10 09:59:12
On Wed, Sep 10, 2003 at 10:52:15AM +0100, Jim Hague wrote:
On 09-Sep-2003 Jim Hague wrote:
quoted
On 09-Sep-2003 Sven Luther wrote:
quoted
(--) 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
From: Jim Hague <hidden> Date: 2003-09-10 10:49:03
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
From: Sven Luther <hidden> Date: 2003-09-10 10:56:09
On Wed, Sep 10, 2003 at 11:48:59AM +0100, Jim Hague wrote:
On 10-Sep-2003 Sven Luther wrote:
quoted
:))) 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
From: James Simmons <hidden> Date: 2003-09-12 18:17:03
On 09-Sep-2003 Jim Hague wrote:
quoted
On 09-Sep-2003 Sven Luther wrote:
quoted
(--) 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