From: Holzrichter, Bruce <hidden> Date: 2002-10-03 19:49:56
James,
In a blast from the past, not sure if your still interested, but I have not
had a whole lot of time to look at these, due to my job/life, etc,etc...
If I apply the latest bk to it, I get the following compile error. As I
said, I haven't even had time to grep through the thing to even begin to
look, but wanted to report them anyways...
fbmem.c: In function `fbmem_read_proc':
fbmem.c:380: structure has no member named `modename'
make[2]: *** [fbmem.o] Error 1
make[2]: Leaving directory `/home/bruce/sparctest/drivers/video'
make[1]: *** [video] Error 2
make[1]: Leaving directory `/home/bruce/sparctest/drivers'
make: *** [drivers] Error 2
Bruce H..
-----Original Message-----
From: James Simmons [mailto:jsimmons@infradead.org]
Sent: Thursday, August 22, 2002 3:22 PM
To: Holzrichter, Bruce
Cc: linux-fbdev-devel@lists.sourceforge.net
Subject: RE: [Linux-fbdev-devel] 2.5 atyfb on Sparc question
quoted
quoted
Oops. Fixed now.
Whoa, that was neat! ;o)
Can you try the latest changes in my BK tree.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
From: James Simmons <hidden> Date: 2002-10-13 20:14:35
Sorry I have been going threw alot of chabnges recently. Try my lastest
tree. I just updated it and I'm nearly done change the api.
MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.
James Simmons [jsimmons@users.sf.net] ____/|
fbdev/console/gfx developer \ o.O|
http://www.linux-fbdev.org =(_)=
http://linuxgfx.sourceforge.net U
http://linuxconsole.sourceforge.net
On Thu, 3 Oct 2002, Holzrichter, Bruce wrote:
James,
In a blast from the past, not sure if your still interested, but I have not
had a whole lot of time to look at these, due to my job/life, etc,etc...
If I apply the latest bk to it, I get the following compile error. As I
said, I haven't even had time to grep through the thing to even begin to
look, but wanted to report them anyways...
fbmem.c: In function `fbmem_read_proc':
fbmem.c:380: structure has no member named `modename'
make[2]: *** [fbmem.o] Error 1
make[2]: Leaving directory `/home/bruce/sparctest/drivers/video'
make[1]: *** [video] Error 2
make[1]: Leaving directory `/home/bruce/sparctest/drivers'
make: *** [drivers] Error 2
Bruce H..
quoted
-----Original Message-----
From: James Simmons [mailto:jsimmons@infradead.org]
Sent: Thursday, August 22, 2002 3:22 PM
To: Holzrichter, Bruce
Cc: linux-fbdev-devel@lists.sourceforge.net
Subject: RE: [Linux-fbdev-devel] 2.5 atyfb on Sparc question
quoted
quoted
Oops. Fixed now.
Whoa, that was neat! ;o)
Can you try the latest changes in my BK tree.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
From: Sven LUTHER <hidden> Date: 2002-10-14 09:55:28
On Sun, Oct 13, 2002 at 01:08:08PM -0700, James Simmons wrote:
Sorry I have been going threw alot of chabnges recently. Try my lastest
tree. I just updated it and I'm nearly done change the api.
BTW, i tried this WE to look at porting the pm3fb driver to the new API,
doing a complete rewrite (well, basically starting again from tridentff,
tdfxfb and skeletonfb, and getting the code as needed from current
pm3fb, which has a lot of unneeded stuff in it). I have not much time
though, so it will go slowly.
I thought i may as well write a little HOWTO or something such on the
way of doing this. Since i have not much fbdev writing experience, maybe
i am a good candidate for writing such a thing.
I wanted, in the first step, to do just a basic unaccelerated fbdev
driver, without mode changes and anything fancy, and once this works,
add things incrementally. I believe this approach will be good for
future fbdev driver writters.
Anyway, now for my question.
skeletonfb says that check_var, set_par, setcolreg, pan_display and
blank functions are optional or not required. Is that true, and in case
i don't want to provide them, whay do i put in the fb_ops structure ?
Later, in the fb_ops structure, only set_par, blank and pan_display are
labeled as optional.
Friendly,
Sven Luther
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
From: James Simmons <hidden> Date: 2002-10-18 18:20:35
I thought i may as well write a little HOWTO or something such on the
way of doing this. Since i have not much fbdev writing experience, maybe
i am a good candidate for writing such a thing.
Wow that would be great.
I wanted, in the first step, to do just a basic unaccelerated fbdev
driver, without mode changes and anything fancy, and once this works,
add things incrementally. I believe this approach will be good for
future fbdev driver writters.
Good approach to doing this.
Anyway, now for my question.
skeletonfb says that check_var, set_par, setcolreg, pan_display and
blank functions are optional or not required. Is that true, and in case
i don't want to provide them, whay do i put in the fb_ops structure ?
All the functions are optional. They are needed when:
fb_open: We need special things done when we open or close /dev/fb
fb_release:
fb_read: When we have a strange framebuffer that doesn't allow
fb_write: linear writes. A good example is the Epson1385 chipset at
16 bpp mode.
fb_check_var: When we can change the resolution of the display.
fb_set_par:
fb_setcolreg: Have a programable color palette.
fb_blank: Have hardware support for power management of some kind.
fb_pan_display: Hardware scrolling
fb_cursor: Hardware cursor.
fb_poll: Want to use interrupts such as VLB.
fb_sync: To sync the accel engine and framebuffer memory.
fb_ioctl: Extra functions you want to support.
fb_mmap: Have special memory needs when exposing to userland.
fb_rastering: I don't know if we are going to keep this one?
The only ones require are the accel functions for drawing on the console.
Later, in the fb_ops structure, only set_par, blank and pan_display are
labeled as optional.
That is a mistake.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
fb_rastering: I don't know if we are going to keep this one?
AFAIK these are used by the SPARC people only, to switch the graphics hardware
to frame buffer mode so the logo can be drawn. All other operations are done
using the accel engine on the cards that need fb_rasterimg().
So yes, once the logo is drawn by fb_imageblit(), fb_rasterimg() can be
eliminated by moving its functionality inside the fbdev-specific
fb_imageblit().
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
This sf.net emial is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote