From: Paul Mackerras <hidden> Date: 2002-08-15 23:18:18
James Simmons writes:
That was done to push people to port there drivers to the new api.
Well, what _is_ the new API?
Anyway, you could apply this patch, for a start. I wish you would be
a bit more careful about details.
Paul.
diff -urN linux-2.5/drivers/video/Makefile pmac-2.5/drivers/video/Makefile
--- linux-2.5/drivers/video/Makefile Wed Aug 14 09:15:02 2002+++ pmac-2.5/drivers/video/Makefile Fri Aug 16 09:08:34 2002
From: James Simmons <hidden> Date: 2002-08-22 17:25:30
quoted
That was done to push people to port there drivers to the new api.
Well, what _is_ the new API?
From the details in skeletonfb.c.
* I have started rewriting this driver as a example of the upcoming new API
* The primary goal is to remove the console code from fbdev and place it
* into fbcon.c. This reduces the code and makes writing a new fbdev driver
* easy since the author doesn't need to worry about console internals. It
* also allows the ability to run fbdev without a console/tty system on top
* of it.
*
* First the roles of struct fb_info and struct display have changed. Struct
* display will go away. The way the the new framebuffer console code will
* work is that it will act to translate data about the tty/console in
* struct vc_data to data in a device independent way in struct fb_info. Then
* various functions in struct fb_ops will be called to store the device
* dependent state in the par field in struct fb_info and to change the
* hardware to that state. This allows a very clean seperation of the fbdev
* layer from the console layer. It also allows one to use fbdev on its own
* which is a bounus for embedded devices. The reason this approach works is
* for each framebuffer device when used as a tty/console device is allocated
* a set of virtual terminals to it. Only one virtual terminal can be active
* per framebuffer device. We already have all the data we need in struct
* vc_data so why store a bunch of colormaps and other fbdev specific data
* per virtual terminal.
* As you can see doing this makes the con parameter pretty much useless
* for struct fb_ops functions, as it should be. Also having struct
* fb_var_screeninfo and other data in fb_info pretty much eliminates the
* need for get_fix and get_var. Once all drivers use the fix, var, and cmap
* fbcon can be written around these fields. This will also eliminate the
* need to regenerate struct fb_var_screeninfo, struct fb_fix_screeninfo
* struct fb_cmap every time get_var, get_fix, get_cmap functions are called
* as many drivers do now.
See skeletonfb.c for further details.
Anyway, you could apply this patch, for a start. I wish you would be
a bit more careful about details.
Done. Well the good news is I have aquired more hardware for different
platforms to test my work on :-)
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
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
Anyway, you could apply this patch, for a start. I wish you would be
a bit more careful about details.
Done. Well the good news is I have aquired more hardware for different
platforms to test my work on :-)
You don't need more hardware to protect yourself against such typos. A
cross-compiler (or sometimes even your native gcc) is sufficient ;-)
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 email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
From: James Simmons <hidden> Date: 2002-08-22 18:17:38
quoted
quoted
Anyway, you could apply this patch, for a start. I wish you would be
a bit more careful about details.
Done. Well the good news is I have aquired more hardware for different
platforms to test my work on :-)
You don't need more hardware to protect yourself against such typos. A
cross-compiler (or sometimes even your native gcc) is sufficient ;-)
That I also lack except for ARM and mips. Do you know where I can get a
developement kit for for ppc and m68k?
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
Anyway, you could apply this patch, for a start. I wish you would be
a bit more careful about details.
Done. Well the good news is I have aquired more hardware for different
platforms to test my work on :-)
You don't need more hardware to protect yourself against such typos. A
cross-compiler (or sometimes even your native gcc) is sufficient ;-)
That I also lack except for ARM and mips. Do you know where I can get a
developement kit for for ppc and m68k?
The usual rules for creating cross-{binutils,gcc} apply here.
If you run Debian, check out the toolchain-source package.
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 email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390