From: Sven LUTHER <hidden> Date: 2002-08-01 15:25:02
Hello James.
I did give a quick try at adapting pm3fb to the new api, but without
much success.
I did look at skeletonfb.c as you suggested (the one in the 2.5.29
kernel) and after some work to make it build, it only gave me a segfault
when inserting the module.
Looking a bit more to into this, and comparing skeletonfb to both neofb
and matroxfb, it seems to me that the skeletonfb that ships with the
2.5.29 kernel is severly outdated.
Is there a new version of skeletonfb around, or maybe should we rather
look at one of the drivers you did adapt (that's why i looked at neofb).
In this case, which driver would you suggest i look at ? And is there
other documentation about the new api around.
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-08-02 15:46:43
Hello James.
I did give a quick try at adapting pm3fb to the new api, but without
much success.
I did look at skeletonfb.c as you suggested (the one in the 2.5.29
kernel) and after some work to make it build, it only gave me a segfault
when inserting the module.
skeletonfb is meant for only a example. I never expected to work.
Looking a bit more to into this, and comparing skeletonfb to both neofb
and matroxfb, it seems to me that the skeletonfb that ships with the
2.5.29 kernel is severly outdated.
No skeletonfb is pretty much up to data. The driver to look at is the 3Dfx
driver. Its is the best new api driver.
In this case, which driver would you suggest i look at ? And is there
other documentation about the new api around.
Not yet.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
From: Sven LUTHER <hidden> Date: 2002-08-04 13:53:45
On Fri, Aug 02, 2002 at 08:46:39AM -0700, James Simmons wrote:
quoted
Hello James.
I did give a quick try at adapting pm3fb to the new api, but without
much success.
I did look at skeletonfb.c as you suggested (the one in the 2.5.29
kernel) and after some work to make it build, it only gave me a segfault
when inserting the module.
skeletonfb is meant for only a example. I never expected to work.
Not as a skeleton from which you can build up a new driver ?
quoted
Looking a bit more to into this, and comparing skeletonfb to both neofb
and matroxfb, it seems to me that the skeletonfb that ships with the
2.5.29 kernel is severly outdated.
No skeletonfb is pretty much up to data. The driver to look at is the 3Dfx
driver. Its is the best new api driver.
Ok i will look at the 3Dfx driver.
BTW, the main difference i see between skeletonfb and the other driver
is about the _init function. if contains lot of stuff to initialize the
fb_info structure and such.
But when i look at the neofb for example, but it is the same in
matroxfb, i see that pci_register_driver is called with a structure
containing the neofb_probe function, which is something absolutely not
present in the skeletonfb.
quoted
In this case, which driver would you suggest i look at ? And is there
other documentation about the new api around.
Not yet.
Too bad, ...
I would have been nice to have such a thing before you remove the
backward compatibility from the new kernels.
Anyway, thanks for your help, i will look at the existing drivers then.
Friendly,
Sven Luther
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
From: Jani Monoses <hidden> Date: 2002-08-05 06:13:33
quoted
No skeletonfb is pretty much up to data. The driver to look at is the 3Dfx
driver. Its is the best new api driver.
Ok i will look at the 3Dfx driver.
I started porting tridentfb this weekend and to me too tdfx seemed the best example to use.
But when i look at the neofb for example, but it is the same in
matroxfb, i see that pci_register_driver is called with a structure
containing the neofb_probe function, which is something absolutely not
present in the skeletonfb.
that's unrelated to the new fb API.It's the 'new' PCI API which is in 2.4 too
and lets you detect the PCI cards your driver knows about without calling
pci_find_devices & co by instead supplying the probe/remove functions and a PCI id table.
It also help with power management..
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
From: Sven LUTHER <hidden> Date: 2002-08-05 09:16:41
On Mon, Aug 05, 2002 at 09:13:25AM +0000, Jani Monoses wrote:
quoted
quoted
No skeletonfb is pretty much up to data. The driver to look at is the 3Dfx
driver. Its is the best new api driver.
Ok i will look at the 3Dfx driver.
I started porting tridentfb this weekend and to me too tdfx seemed the best example to use.
Ok (altough it seems romain will have a look at this, so i will probably
let him do it, since i am busy anyway).
quoted
But when i look at the neofb for example, but it is the same in
matroxfb, i see that pci_register_driver is called with a structure
containing the neofb_probe function, which is something absolutely not
present in the skeletonfb.
that's unrelated to the new fb API.It's the 'new' PCI API which is in 2.4 too
and lets you detect the PCI cards your driver knows about without calling
pci_find_devices & co by instead supplying the probe/remove functions and a PCI id table.
It also help with power management..
Well, but i thought the skeletonfb was to be used as a model/skeleton/guide
to creating a new framebuffer device.
So it should include this as well, should it not ?
Especially as there is no other documentation around.
Friendly,
Sven Luther
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Ok (altough it seems romain will have a look at this, so i will probably
let him do it, since i am busy anyway).
I will try to port pm3fb, but the problem is the same
as last month and last year: no usable 2.5.x on my
box, so there's not much I can do ATM.
--
DOLBEAU Romain | For a hill, men would kill,
ENS Cachan / Ker Lann | Why ? They do not know.
Thesard IRISA / CAPS | -- Metallica,
dolbeaur@club-internet.fr | 'For Whom The Bell Tolls'
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
From: Sven LUTHER <hidden> Date: 2002-08-05 11:54:36
On Mon, Aug 05, 2002 at 01:19:37PM +0200, Romain Dolbeau wrote:
Sven LUTHER wrote:
quoted
Ok (altough it seems romain will have a look at this, so i will probably
let him do it, since i am busy anyway).
I will try to port pm3fb, but the problem is the same
as last month and last year: no usable 2.5.x on my
box, so there's not much I can do ATM.
I thought michel did send you a working 2.5.x tree, but then maybe this
one didn't work either ?
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-08-06 06:26:44
quoted
It also help with power management..
Well, but i thought the skeletonfb was to be used as
a model/skeleton/guide
to creating a new framebuffer device.
It is but it is a very primitive model. Especially for
pci based cards. Alot of extra code is needed.
So it should include this as well, should it not ?
The reason I didn't included it was because alot of
fbdev drivers are not PCI based. Maybe I should add
this pseudo code?
__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf