Menu
▾
▴
linux-fbdev-devel — linux-fbdev mailing list for project developers
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
(1) |
Apr
(104) |
May
(81) |
Jun
(248) |
Jul
(133) |
Aug
(33) |
Sep
(53) |
Oct
(82) |
Nov
(166) |
Dec
(71) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(121) |
Feb
(42) |
Mar
(39) |
Apr
(84) |
May
(87) |
Jun
(58) |
Jul
(97) |
Aug
(130) |
Sep
(32) |
Oct
(139) |
Nov
(108) |
Dec
(216) |
| 2003 |
Jan
(299) |
Feb
(136) |
Mar
(392) |
Apr
(141) |
May
(137) |
Jun
(107) |
Jul
(94) |
Aug
(262) |
Sep
(300) |
Oct
(216) |
Nov
(72) |
Dec
(94) |
| 2004 |
Jan
(174) |
Feb
(192) |
Mar
(215) |
Apr
(314) |
May
(319) |
Jun
(293) |
Jul
(205) |
Aug
(161) |
Sep
(192) |
Oct
(226) |
Nov
(308) |
Dec
(89) |
| 2005 |
Jan
(127) |
Feb
(269) |
Mar
(588) |
Apr
(106) |
May
(77) |
Jun
(77) |
Jul
(161) |
Aug
(239) |
Sep
(86) |
Oct
(112) |
Nov
(153) |
Dec
(145) |
| 2006 |
Jan
(87) |
Feb
(57) |
Mar
(129) |
Apr
(109) |
May
(102) |
Jun
(232) |
Jul
(97) |
Aug
(69) |
Sep
(67) |
Oct
(69) |
Nov
(214) |
Dec
(82) |
| 2007 |
Jan
(133) |
Feb
(307) |
Mar
(121) |
Apr
(171) |
May
(229) |
Jun
(156) |
Jul
(185) |
Aug
(160) |
Sep
(122) |
Oct
(130) |
Nov
(78) |
Dec
(27) |
| 2008 |
Jan
(105) |
Feb
(137) |
Mar
(146) |
Apr
(148) |
May
(239) |
Jun
(208) |
Jul
(157) |
Aug
(244) |
Sep
(119) |
Oct
(125) |
Nov
(189) |
Dec
(225) |
| 2009 |
Jan
(157) |
Feb
(139) |
Mar
(106) |
Apr
(130) |
May
(246) |
Jun
(189) |
Jul
(128) |
Aug
(127) |
Sep
(88) |
Oct
(86) |
Nov
(216) |
Dec
(9) |
| 2010 |
Jan
(5) |
Feb
|
Mar
(11) |
Apr
(31) |
May
(3) |
Jun
|
Jul
(7) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: James S. <cap...@ya...> - 2002-08-06 06:30:16
|
--- Louis Garcia <lou...@be...> wrote: > Is the radeonfb driver going to have support for the > dvi port any time soon. > I'm talking about the 2.4.x kernels. You have to ask Ani Joshi. I doubt it tho. __________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com |
|
From: James S. <cap...@ya...> - 2002-08-06 06:26:44
|
> > 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 |
|
From: James S. <jsi...@tr...> - 2002-08-06 04:48:55
|
Due to the company I was working for going under my email address has changed. My permanent address is jsi...@us.... This will go where ever I read my email from. My personal private account is cap...@ya.... Please DONT email me at transvirtual.com any more. Sorry about the inconvince. Thank you. . --- |o_o | |:_/ | Give Micro$oft the Bird!!!! // \ \ Use Linux!!!! (| | ) /'\_ _/`\ \___)=(___/ |
|
From: Louis G. <lou...@be...> - 2002-08-06 02:47:29
|
Is the radeonfb driver going to have support for the dvi port any time soon. I'm talking about the 2.4.x kernels. --Lou |
|
From: Louis G. <lou...@be...> - 2002-08-06 01:20:32
|
Has their been any talk on porting the fb drivers to devicefs? --Lou |
|
From: Antonino D. <ad...@po...> - 2002-08-05 22:00:41
|
With fbcon-accel and the new drawing functions in linux-2.5, console performance degraded compared to the linux-2.4 implementation. This is because putcs() has to to do 1 fb_imageblit() per character to be drawn. This can be optimized by letting putcs() initially construct the row of text to be drawn into an offscreen buffer, then do a single fb_imageblit() in the end. Performance wil increase for several reasons: 1. Drawing can be done in "bursts" instead of "trickles" 2. For drivers that support accelerated drawing functions, the offscreen buffer can be optionally placed in graphics (or AGP) memory, which is better suited for most hardware that can only do blit's from video memory to video memory. 3. Some level of asynchronicity can be achieved, ie, the hardware can be blitting while fbcon-accel is constructing bitmaps. This would require "walking" the offscreen buffer, and support for hardware graphics sync'ing on demand. I have included a patch for 2.5.27 that implements it in fbcon-accel. It's preliminary, but I have tested it with cfb_imageblit and with hardware imageblit, with buffers in System or Video memory. The code is also present for hardware syncing on demand, though unimplemented. For drivers that uses cfb_imageblit or similar, a code such as the one below can be inserted during initialization: info->pixmap.addr = (unsigned long) kmalloc(BUFFER_SIZE, GFP_KERNEL); info->pixmap.size = BUFFER_SIZE; info->pixmap.offset = 0; info->pixmap.buf_align = 1; info->pixmap.scan_align = 1; Some benchmarks: time cat /usr/src/linux/MAINTAINERS (40K text file) mode: 1024x768@8bpp, y-panning disabled. cfb_imageblit - no offscreen buffer (default) real 0m13.586s user 0m0.001s sys 0m13.585s cfb_imageblit - with offscreen buffer in system memory real 0m10.708s user 0m0.001s sys 0m10.707s hardware imageblit - no offscreen buffer real 0m6.036s user 0m0.001s sys 0m6.035s hardware imageblit - with offscreen buffer in graphics memory real 0m3.160s user 0m0.001s sys 0m3.160s hardware imageblit - graphics offscreen buffer + hardware sync on demand real 0m1.843s user 0m0.000s sys 0m1.843s Tony |
|
From: Sven L. <lu...@dp...> - 2002-08-05 11:54:38
|
On Mon, Aug 05, 2002 at 01:19:37PM +0200, Romain Dolbeau wrote: > Sven LUTHER wrote: > > > 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 |
|
From: Michel <mi...@da...> - 2002-08-05 11:22:38
|
On Mon, 2002-08-05 at 13:16, Romain Dolbeau wrote: > Michel D=E4nzer wrote: > >=20 > > On Fri, 2002-07-05 at 10:32, Romain Dolbeau wrote: > >=20 > > > Well, I'm still waiting for an accessible, ppc-usable > > > 2.5.[something big enough] before I can port pm3fb. > >=20 > > For accessibility, try rsync source.mvista.com::linuxppc-2.5 . >=20 > It's the one I tried, last time I checked (around 2.5.23), > it was still in 2.5.8pre3 (i.e., w/o the new framebuffer layer). It's at 2.5.30 now at least. --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
|
From: Romain D. <do...@ir...> - 2002-08-05 11:19:47
|
Sven LUTHER wrote: > 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, dol...@cl... | 'For Whom The Bell Tolls' |
|
From: Romain D. <do...@ir...> - 2002-08-05 11:17:07
|
Michel D=E4nzer wrote: >=20 > On Fri, 2002-07-05 at 10:32, Romain Dolbeau wrote: >=20 > > Well, I'm still waiting for an accessible, ppc-usable > > 2.5.[something big enough] before I can port pm3fb. >=20 > For accessibility, try rsync source.mvista.com::linuxppc-2.5 . It's the one I tried, last time I checked (around 2.5.23), it was still in 2.5.8pre3 (i.e., w/o the new framebuffer layer). Thanks for the tip anyway, I'll try it again, just in case. --=20 DOLBEAU Romain | For a hill, men would kill, =20 ENS Cachan / Ker Lann | Why ? They do not know. =20 Thesard IRISA / CAPS | -- Metallica, =20 dol...@cl... | 'For Whom The Bell Tolls' |
|
From: Sven L. <lu...@dp...> - 2002-08-05 09:16:43
|
On Mon, Aug 05, 2002 at 09:13:25AM +0000, Jani Monoses wrote: > > > > > > > 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). > > 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 |
|
From: Jani M. <ja...@iv...> - 2002-08-05 06:13:35
|
> > > > 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.. |
|
From: Sven L. <lu...@dp...> - 2002-08-04 13:53:46
|
On Fri, Aug 02, 2002 at 08:46:39AM -0700, James Simmons wrote: > > > 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 ? > > 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. > > 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 |
|
From: Michel <mi...@da...> - 2002-08-04 13:00:34
|
On Fri, 2002-07-05 at 10:32, Romain Dolbeau wrote: > Well, I'm still waiting for an accessible, ppc-usable > 2.5.[something big enough] before I can port pm3fb. For accessibility, try rsync source.mvista.com::linuxppc-2.5 . Don't know about usability yet though. :) --=20 Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast |
|
From: James S. <jsi...@tr...> - 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. |
|
From: Sven L. <lu...@dp...> - 2002-08-01 15:25:04
|
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 |
|
From: Benjamin H. <be...@ke...> - 2002-07-31 18:18:33
|
Ok, now it's really weird. If I fix the memset, I get my old crash. However, it seems that it's r4 that is NULL in cfb_imageblit, which would mean the "image" paremeter is NULL. The stack shows the caller beeing fbcon_accel_putcs, so that make no sense as image is on the stack... I'll have to investigate more. Ben. |
|
From: Benjamin H. <be...@ke...> - 2002-07-31 18:06:49
|
>- info = >- kmalloc(sizeof(struct fb_info) + sizeof(struct display) + >- sizeof(u32) * 17, GFP_ATOMIC); >+ size = sizeof(struct fb_info) + sizeof(struct display) + sizeof(u32) * 17; >+ >+ info = kmalloc(size, GFP_ATOMIC); Ok, I fixed that in my tree as well, but didn't yet test with CONFIG_FBCON_ACCEL _and_ that fix. I'll do that now. Ben. |
|
From: James S. <jsi...@tr...> - 2002-07-31 18:00:25
|
> I have fixed that for a long time or it wouldn't link anyway...
I have teh fix to push to linus soon.
> So if I don't have CONFIG_FBCON_ACCEL, it dies in fbcon_setup because
> dispsw is not set,
Correct. I should have it set to fbcon_dummy instead. Added fix to BK
repository.
> if I have CONFIG_FBCON_ACCEL set, it dies in cfb_imageblt,
> I think it's display->fb_info that is null, but I have to dbl check.
I think it might be a memset issue. Try this patch.
--- /usr/src/linus-2.5/drivers/video/offb.c Tue Jul 30 22:55:24 2002
+++ offb.c Wed Jul 31 10:43:33 2002
@@ -82,17 +82,15 @@
unsigned long address, struct device_node *dp);
static struct fb_ops offb_ops = {
- owner: THIS_MODULE,
- fb_get_fix: gen_get_fix,
- fb_get_var: gen_get_var,
- fb_set_var: gen_set_var,
- fb_get_cmap: gen_get_cmap,
- fb_set_cmap: gen_set_cmap,
- fb_setcolreg: offb_setcolreg,
- fb_blank: offb_blank,
- fb_fillrect: cfb_fillrect,
- fb_copyarea: cfb_copyarea,
- fb_imageblit: cfb_imageblit,
+ .owner = THIS_MODULE,
+ .fb_set_var = gen_set_var,
+ .fb_get_cmap = gen_get_cmap,
+ .fb_set_cmap = gen_set_cmap,
+ .fb_setcolreg = offb_setcolreg,
+ .fb_blank = offb_blank,
+ .fb_fillrect = cfb_fillrect,
+ .fb_copyarea = cfb_copyarea,
+ .fb_imageblit = cfb_imageblit,
};
/*
@@ -399,7 +397,7 @@
struct fb_fix_screeninfo *fix;
struct fb_var_screeninfo *var;
struct fb_info *info;
- int i;
+ int size, i;
if (!request_mem_region(res_start, res_size, "offb"))
return;
@@ -414,14 +412,15 @@
return;
}
- info =
- kmalloc(sizeof(struct fb_info) + sizeof(struct display) +
- sizeof(u32) * 17, GFP_ATOMIC);
+ size = sizeof(struct fb_info) + sizeof(struct display) + sizeof(u32) * 17;
+
+ info = kmalloc(size, GFP_ATOMIC);
+
if (info == 0) {
release_mem_region(res_start, res_size);
return;
}
- memset(info, 0, sizeof(*info));
+ memset(info, 0, size);
fix = &info->fix;
var = &info->var;
> Why would you kill the fbcon-cfg stuffs ? That would mean making
> CONFIG_FBCON_ACCEL not to be an option then. Or simple framebuffers like
> offb wouldn't work.
The goal is to eventually move fbcon_accel into the upper framebuffer
console layer. What we want to do is move all the console code out of
every fbdev driver into fbcon.c. This will allow fbdev to exist without
fbcon. This will be allow for smaller kernels which is needed by resource
constrant handheld devices.
The problem is that over the years the limitations of the console system
have been handled on the drivers side. Now I reworking the upper layers so
the low end drivers can be really really simple. You can see the
difference with the tdfx driver or example. It had 60% code size
reduction. 60% !!!!!
|
|
From: Benjamin H. <be...@ke...> - 2002-07-31 17:42:34
|
> >Sorry I have been away for some time. I'm looking for work :-( > >> What is the correct fix ? Changing back offb to set dispsw or >> changing gen_set_disp() to set dispsw for all bit depth ? > >I found what the problem was. The soft accel files cfb*.c where not being >linked into off.c. Try this patch and tell me if everything works. BTW you >need to have CONFIG_FBCON_ACCEL set. Eventually all the fbcon-cfb* stuff >will go away. I have fixed that for a long time or it wouldn't link anyway... So if I don't have CONFIG_FBCON_ACCEL, it dies in fbcon_setup because dispsw is not set, if I have CONFIG_FBCON_ACCEL set, it dies in cfb_imageblt, I think it's display->fb_info that is null, but I have to dbl check. Why would you kill the fbcon-cfg stuffs ? That would mean making CONFIG_FBCON_ACCEL not to be an option then. Or simple framebuffers like offb wouldn't work. >> Also, when code in fbcon_accel.c is calling things like >> cfb_imageblit, it uses the "fb_info" field of structure >> struct display. Where is this supposed to be initialized ? >> It doesn't seem it's done in the drivers themselves (surely >> not in offb). > >The upper fbcon code sets that. See fbcon_init in fbcon.c. |
|
From: James S. <jsi...@tr...> - 2002-07-31 17:18:49
|
Oops. Here is the patch. Let me know if it works. --- /usr/src/linus-2.5/drivers/video/Makefile Tue Jul 30 22:55:21 2002 +++ Makefile Wed Jul 31 10:08:02 2002 @@ -60,7 +60,7 @@ obj-$(CONFIG_FB_3DFX) += tdfxfb.o obj-$(CONFIG_FB_MAC) += macfb.o macmodes.o cfbfillrect.o cfbcopyarea.o cfbimgblt.o obj-$(CONFIG_FB_HP300) += hpfb.o cfbfillrect.o cfbimgblt.o -obj-$(CONFIG_FB_OF) += offb.o +obj-$(CONFIG_FB_OF) += offb.o cfbfillrect.o cfbimgblit.o cfbcopyarea.o obj-$(CONFIG_FB_IMSTT) += imsttfb.o obj-$(CONFIG_FB_RETINAZ3) += retz3fb.o obj-$(CONFIG_FB_CLGEN) += clgenfb.o |
|
From: James S. <jsi...@tr...> - 2002-07-31 17:18:18
|
Sorry I have been away for some time. I'm looking for work :-( > What is the correct fix ? Changing back offb to set dispsw or > changing gen_set_disp() to set dispsw for all bit depth ? I found what the problem was. The soft accel files cfb*.c where not being linked into off.c. Try this patch and tell me if everything works. BTW you need to have CONFIG_FBCON_ACCEL set. Eventually all the fbcon-cfb* stuff will go away. > Also, when code in fbcon_accel.c is calling things like > cfb_imageblit, it uses the "fb_info" field of structure > struct display. Where is this supposed to be initialized ? > It doesn't seem it's done in the drivers themselves (surely > not in offb). The upper fbcon code sets that. See fbcon_init in fbcon.c. . --- |o_o | |:_/ | Give Micro$oft the Bird!!!! // \ \ Use Linux!!!! (| | ) /'\_ _/`\ \___)=(___/ |
|
From: Benjamin H. <be...@ke...> - 2002-07-31 12:49:15
|
Hi ! I've investigated a bit why offb dies on boot with current 2.5. It appears that dispsw is never set. You removed the code setting it for the various bit depth. It seems the gen_set_disp() call is supposed to do that instead. However, gen_set_disp() only does it for var.bits_per_pixel == 24, not for the other bit depths. In my case, offb boots at 8bpp, thus dispsw is never set, causing fbcon_setup to die when trying to call set_font(). That is without the accel in config. If I enable accel support, then it dies later, in cfbimgblt, apparently due to cfb_imageblit() beeing called with a NULL argument. What is the correct fix ? Changing back offb to set dispsw or changing gen_set_disp() to set dispsw for all bit depth ? Also, when code in fbcon_accel.c is calling things like cfb_imageblit, it uses the "fb_info" field of structure struct display. Where is this supposed to be initialized ? It doesn't seem it's done in the drivers themselves (surely not in offb). Regards, Ben. |
|
From: James S. <jsi...@tr...> - 2002-07-27 20:10:37
|
> Hi ! > > Does somebody plans to update 2.5 with versions of these drivers that > at least build ? They have been broken for ages now. > > If not, then I'll do my own fixing and submit that. Sorry about that. Pretty soon, next few days, I'm going to be submitting changes to the fbdev layer which breaks any driver not converted over to the new fbdev api. It needs to be done. P.S Since the console system can use IRQ/DMA based modes for graphics cards it would be nice to the ati 128 card converted over to use the CCE engine :-) |
|
From: Ani J. <aj...@un...> - 2002-07-27 19:49:48
|
I believe aty128fb is updated to the new API, and I'll get around to radeonfb soon, I have to merge a large chunk of code into it and 2.4 at the same time. ani On Sat, 27 Jul 2002, Benjamin Herrenschmidt wrote: > Hi ! > > Does somebody plans to update 2.5 with versions of these drivers that > at least build ? They have been broken for ages now. > > If not, then I'll do my own fixing and submit that. > > Regards, > Ben. > > |
754 messages has been excluded from this view by a project administrator.
