Menu
▾
▴
linux-fbdev-devel
|
From: Russell K. <rm...@ar...> - 2002-07-05 17:58:08
|
On Fri, Jul 05, 2002 at 10:14:12AM -0700, James Simmons wrote:
> > First, I detest the idea of "fix", "var", "par" and "info". Specifically
> > the "par" crap. Intensely.
>
> Why? Should each driver have their own structs that are completely
> different then? In this case you would be better off doing something like
> newport_con.c.
>
> We pretty much have this today. Each driver has so much excess code
> because they want to create their own special structs. Lost of bloat for
> no reason! I will NOT put up with that anymore!!!! Sorry!
James, you're OTT here. Look at what the structure contains. You will
notice that it's very specific to the driver. Drivers have the implicit
right to define what data they need to maintain their internal state;
the core has no right to define that.
If you're going to be this hard headed about this, YOU can take over
complete maintainence of ALL framebuffer drivers. I'll direct ALL
problems to you to solve.
It's part of the deal. Either you allow driver writers to cleanly code
the way they see fit, or you take over maintainence of those drivers.
You break it, you fix it. What's it to be?
> > "par" and "info" should be combined IMO,
> > which my framebuffer drivers do.
>
> No!!!! This is one of the reasons we have the mess we have!! Look at how
> much code that could be removed from the standard drivers into fbmem.c and
> fbcon.c.
sa1100fb was already cleaned up in the way YOU wanted to remove most of
the junk back in the 2.4 days. I consider it to be extremely clean. Or
used to be. All that now remains in there has very little commonality
between the drivers.
When there is ONE and only ONE framebuffer device possible, it makes
sense to try to combine structures as much as possible, especially
when:
1. allocation of structures has overhead.
2. you can get some performance advantage from combining such structures.
3. you're running on an embedded platform and are trying not to waste
ANY resources.
> > Secondly, I think you're completely confused above. lccr0 and lccr3 have
> > nothing to do with some "generic struct fb_info". They hold the base
> > register values for two of the SA1100 control registers.
> >
> > Thirdly, you didn't delete them. You _moved_ them within the structure.
> > They therefore served zero functional purpose.
>
> If you could send me a patch I would be happy.
Patch for what? I _really_ don't understand your request here.
> > Fourthly, nothing but the sa1100fb driver has any business accessing the
> > elements around these two both before and after the move.
>
> True which is why things like that go into par.
Then why are you trying to share the par between others (as you said in
a previous message)?
--
Russell King (rm...@ar...) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
|
|
From: James S. <jsi...@tr...> - 2002-07-05 18:33:00
|
> > We pretty much have this today. Each driver has so much excess code > > because they want to create their own special structs. Lost of bloat for > > no reason! I will NOT put up with that anymore!!!! Sorry! > > James, you're OTT here. I apologize I'm sorry. I did get upset. Its just this has been discussed time and time again. It gets annoying after awhile and it stopped me from completing the fbdev changes in the last development series. I don't want that again. > It's part of the deal. Either you allow driver writers to cleanly code > the way they see fit, or you take over maintainence of those drivers. > You break it, you fix it. What's it to be? I'm not going to fight with you about it. I can revert the changes back to the way you had it before if you want. |
|
From: Russell K. <rm...@ar...> - 2002-07-05 18:39:34
|
On Fri, Jul 05, 2002 at 11:32:51AM -0700, James Simmons wrote:
> > James, you're OTT here.
>
> I apologize I'm sorry. I did get upset. Its just this has been discussed
> time and time again. It gets annoying after awhile and it stopped me from
> completing the fbdev changes in the last development series. I don't want
> that again.
Rubbish. You posted a fbdev interface change to linux-kernel when the
kernel was supposed to be stabilising. I converted several of my drivers
to the new interface the best I could. The drivers are coded in such a
way to make the final stages of your changes as trivial as possible. I
did find a few bugs with the interface several months later, and had to
undo some of the changes. However, all work on the new interface appeared
to have stopped.
_I_ didn't stop your fbdev changes. You stopped them yourself when other
driver maintainers didn't comply with your ill-timed request. That caused
me to have to back out some of the changes.
And that's the situation today. If you want to carry on this slagging
match... but its not getting either of us anywhere.
--
Russell King (rm...@ar...) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
|
|
From: James S. <jsi...@tr...> - 2002-07-05 19:00:45
|
> On Fri, Jul 05, 2002 at 11:32:51AM -0700, James Simmons wrote: > > > James, you're OTT here. > > > > I apologize I'm sorry. I did get upset. Its just this has been discussed > > time and time again. It gets annoying after awhile and it stopped me from > > completing the fbdev changes in the last development series. I don't want > > that again. > _I_ didn't stop your fbdev changes. I know that. In fact you where one of my best supporters of my ideas. You defended my ideas against the others who where against it. This I am most grateful for. > You stopped them yourself when other > driver maintainers didn't comply with your ill-timed request. I didn't want to break their drivers. I still don't. I like to avoid it as much as possible. > And that's the situation today. If you want to carry on this slagging > match... but its not getting either of us anywhere. No I don't either. I'm claimed down and I'm thinking straight again. Unfortunely email doesn't show this. Sorry about the misunderstanding here. All I want to do is seperate out the console code and redundent stuff. To make fbdev work without fbcon. You can see the bonus here. This is the first step. Once that is out of the way I like to see the internals AND externals change for fbdev. I'm no big fan of var and fix being seperate. Plus there is abunch of other things. But this is for the next developement tree. So once 2.6 comes out I like to start on these changes right away. Since I see you have a strong opinon (which is a good thing) I want to here your input on how the next generation of fbdev/dri drivers should be. |
|
From: Ani J. <aj...@sh...> - 2002-07-05 19:16:06
|
Hi James, On Fri, 5 Jul 2002, James Simmons wrote: > > It's part of the deal. Either you allow driver writers to cleanly code > > the way they see fit, or you take over maintainence of those drivers. > > You break it, you fix it. What's it to be? > > I'm not going to fight with you about it. I can revert the changes back to > the way you had it before if you want. If you are going to back out the changes you did to RK's drivers could you please also back out the changes you made to my drivers? Specifically I noticed several changes done to rivafb which introduce a riva_par, which I also don't like to use in my drivers. My drivers share a very common structure and I'd like to keep it that way. I'm not sure if you have done any changes to the other drivers (radeonfb or aty128fb) but if you could please backout your changes to rivafb that would be nice. I will try my best to free up some time next week and fixup the drivers to go along with this new API. The reason I haven't done so yet is that it seems from the traffic on the list, this "new API" its somewhat of a changing theory so far and its not yet defined well. I haven't noticed any other driver maintainers updating their drivers to this new API (if they are, perhaps I'm looking at the wrong places) so I am hessitant to do this as it seems its still 'iffy' if this work will actually go into the mainline kernel. Could someone please clear up the confusion about this? Thank you, ani |
|
From: James S. <jsi...@tr...> - 2002-07-05 19:33:08
|
> If you are going to back out the changes you did to RK's drivers could you > please also back out the changes you made to my drivers? Specifically I > noticed several changes done to rivafb which introduce a riva_par, which I > also don't like to use in my drivers. My drivers share a very common > structure and I'd like to keep it that way. I'm not sure if you have done > any changes to the other drivers (radeonfb or aty128fb) but if you could > please backout your changes to rivafb that would be nice. I will try my > best to free up some time next week and fixup the drivers to go along with > this new API. I did change aty128fb.c. Okay I will revert all the changes I have done. No more lower level drivers for me. > The reason I haven't done so yet is that it seems from the traffic on > the list, this "new API" its somewhat of a changing theory so far and its > not yet defined well. It has been in the works for over a year. In CVS, has been tested and even documented. Been discussed on the mailing list. I haven't noticed any other driver maintainers > updating their drivers to this new API (if they are, perhaps I'm looking > at the wrong places) so I am hessitant to do this as it seems its still > 'iffy' if this work will actually go into the mainline kernel. Could > someone please clear up the confusion about this? It is and has started to got into the mainline kernel. The thing was I was bending over backwards to not break peoples drivers. |
|
From: Ani J. <aj...@sh...> - 2002-07-05 19:39:59
|
On Fri, 5 Jul 2002, James Simmons wrote: > It is and has started to got into the mainline kernel. The thing was I was > bending over backwards to not break peoples drivers. Ok thanks, sorry for the confusion. I will try my best to get the few drivers I maintain to go along with the new API as soon as possible. Thanks for the work you've done. ani |
|
From: Russell K. <rm...@ar...> - 2002-07-05 19:41:19
|
On Fri, Jul 05, 2002 at 12:32:57PM -0700, James Simmons wrote:
> It is and has started to got into the mainline kernel. The thing was I was
> bending over backwards to not break peoples drivers.
If it's something small, then driver people don't mind having their
drivers fixed.
However, if its something large, just break them and let the driver people
fix up the pieces (assuming you've got adequate documentation either in
code or elsewhere for people to see both the reasons for the breakage,
the direction you're heading in, and an example driver to follow.)
Chances are that they'll know their driver better than anyone else. If
it stays broken through the next stable series, then start considering
dropping the driver.
That's how it works in the other subsystems.
(FYI, you'll probably find that most people who didn't use the fbgen layer
decided not to use it because of the fix <-> par <-> var mess it forced
into the driver design.)
--
Russell King (rm...@ar...) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
|
|
From: James S. <jsi...@tr...> - 2002-07-05 19:57:40
|
> > It is and has started to got into the mainline kernel. The thing was I was
> > bending over backwards to not break peoples drivers.
>
> If it's something small, then driver people don't mind having their
> drivers fixed.
>
> However, if its something large, just break them and let the driver people
> fix up the pieces (assuming you've got adequate documentation either in
> code or elsewhere for people to see both the reasons for the breakage,
> the direction you're heading in, and an example driver to follow.)
> Chances are that they'll know their driver better than anyone else. If
> it stays broken through the next stable series, then start considering
> dropping the driver.
>
> That's how it works in the other subsystems.
Thinking about it I realized I did the wrong approach. Should I back out
all fbdev driver changes I did or leave some? In this case next week I
will start breaking the upper layer. First to go is the old fbgen code.
Then fields in struct display will start going away. Then get_fix and
stuff will go away.
> (FYI, you'll probably find that most people who didn't use the fbgen layer
> decided not to use it because of the fix <-> par <-> var mess it forced
> into the driver design.)
I don't like it much either but at the same time I don't want to
break userland. I hate the converting back and forth. I want to make
it better.
The idea was to make the drivers focused on a par but still generate
a var and fix and update struct fb_info for the upper layer to use. Par is
the main focus and it can be anything. Fix,var and struct fb_info are
only things to generate for the upper layer. We still want some kind of
data struct independent of the driver so we have a common code base for
fbcon. That was the whole idea.
|
|
From: Ani J. <aj...@sh...> - 2002-07-05 19:41:57
|
On Fri, 5 Jul 2002, James Simmons wrote: > It is and has started to got into the mainline kernel. The thing was I was > bending over backwards to not break peoples drivers. I forgot to ask another question, the patch you post on your website dir "fbdev.diff.gz", what exactly is that diffed against? I tried patching against 2.5.24 but it failed miserably. Can you tell me the exact version for which this was diffed against? Thanks, ani |
|
From: James S. <jsi...@tr...> - 2002-07-05 19:58:25
|
> > It is and has started to got into the mainline kernel. The thing was I was > > bending over backwards to not break peoples drivers. > > I forgot to ask another question, the patch you post on your website dir > "fbdev.diff.gz", what exactly is that diffed against? I tried patching > against 2.5.24 but it failed miserably. Can you tell me the exact version > for which this was diffed against? Ug. It is against Linus latest BK tree. |
|
From: Ani J. <aj...@sh...> - 2002-07-05 20:07:31
|
On Fri, 5 Jul 2002, James Simmons wrote: > Ug. It is against Linus latest BK tree. Ahh, I don't use BK and I don't wish to use programs which make you subsribe to silly mailing lists to use their software (but thats another issue). Could you please make a diff against 2.5.24 (or whatever the current 2.5 release is) if possible? Or is the cvs at sourceforget still current or did you change over to only BK now? A patch against a kernel.org tree would be quite helpful, thanks! ani |
|
From: James S. <jsi...@tr...> - 2002-07-05 20:09:14
|
> Ahh, I don't use BK and I don't wish to use programs which make you > subsribe to silly mailing lists to use their software (but thats another > issue). Okay. > Could you please make a diff against 2.5.24 (or whatever the > current 2.5 release is) if possible? Or is the cvs at sourceforget still > current or did you change over to only BK now? Of course I can do that. The CVS still exist. My policy is to have a BK and CVS tree to make everyone happy. > A patch against a kernel.org tree would be quite helpful, thanks! Okay. Thanks. |
|
From: James S. <jsi...@tr...> - 2002-07-05 20:34:49
|
http://www.transvirtual.com/~jsimmons/fbdev.diff.gz Its against 2.5.24 |
|
From: James S. <jsi...@tr...> - 2002-07-08 21:24:04
|
Here is the updates to the fbdev layer. I removed a few driver modification for the authors that requested. Please note I removed th eold fbgen code. It will break some drivers. They are responsible for updating the drivers. Here are changes against the latest Linus BK tree. Updates to several drivers form the m68k platform and removal of the PPC VT excess code. Documentation/fb/README-sstfb.txt | 87 + arch/i386/boot/compressed/vmlinux.bin.gz |binary arch/ppc/Config.help | 6 arch/ppc/config.in | 3 drivers/char/vt.c | 66 - drivers/video/Config.help | 22 drivers/video/Config.in | 80 - drivers/video/Makefile | 15 drivers/video/S3triofb.c | 19 drivers/video/amifb.c | 81 - drivers/video/atafb.c | 376 ++++---- drivers/video/aty/atyfb.h | 18 drivers/video/aty/atyfb_base.c | 348 ++----- drivers/video/aty/mach64.h | 1158 ------------------------- drivers/video/aty/mach64_accel.c | 2 drivers/video/aty/mach64_ct.c | 4 drivers/video/aty/mach64_cursor.c | 12 drivers/video/aty/mach64_gx.c | 2 drivers/video/aty128.h | 352 ------- drivers/video/aty128fb.c | 32 drivers/video/chipsfb.c | 29 drivers/video/controlfb.c | 21 drivers/video/dnfb.c | 19 drivers/video/fbcon-mac.c | 483 ---------- drivers/video/fbcon-vga.c | 213 ---- drivers/video/fbgen.c | 347 ------- drivers/video/fbmem.c | 2 drivers/video/fm2fb.c | 3 drivers/video/fonts.c | 4 drivers/video/hpfb.c | 3 drivers/video/imsttfb.c | 56 - drivers/video/macfb.c | 463 ++-------- drivers/video/macmodes.c | 171 --- drivers/video/matrox/matroxfb_base.c | 27 drivers/video/matrox/matroxfb_base.h | 6 drivers/video/modedb.c | 4 drivers/video/neofb.c | 7 drivers/video/offb.c | 1130 +++++++++--------------- drivers/video/platinumfb.c | 26 drivers/video/q40fb.c | 8 drivers/video/retz3fb.c | 4 drivers/video/sgivwfb.c | 1432 +++++++++++++------------------ drivers/video/sgivwfb.h | 660 -------------- drivers/video/sstfb.c | 958 +++++++++++--------- drivers/video/sstfb.h | 73 + drivers/video/tdfxfb.c | 55 - drivers/video/tx3912fb.c | 2 drivers/video/valkyriefb.c | 26 drivers/video/vesafb.c | 12 drivers/video/vfb.c | 4 include/asm-ppc/vc_ioctl.h | 46 include/asm-ppc64/vc_ioctl.h | 50 - include/linux/pci_ids.h | 1 include/linux/tty.h | 3 include/video/aty128.h | 419 +++++++++ include/video/mach64.h | 1158 +++++++++++++++++++++++++ include/video/sgivw.h | 660 ++++++++++++++ 58 files changed, 4571 insertions(+), 6697 deletions(-) BK: http://fbdev-2.5.bkbits.net/fbdev-2.5 diff: http://www.transvirtual.com/~jsimmons/fbdev.diff.gz . --- |o_o | |:_/ | Give Micro$oft the Bird!!!! // \ \ Use Linux!!!! (| | ) /'\_ _/`\ \___)=(___/ |
|
From: James S. <jsi...@tr...> - 2002-07-24 05:22:32
|
Hi! This changeset includes updates from the m68k group and removal of the obsolete XPMAC code for the PPC platform. A few bug fixes as well. http://fbdev.bkbits.net/fbdev-2.5 . --- |o_o | |:_/ | Give Micro$oft the Bird!!!! // \ \ Use Linux!!!! (| | ) /'\_ _/`\ \___)=(___/ |
|
From: James S. <jsi...@in...> - 2002-08-13 16:29:53
|
Hi! Please pull the fbdev BK repository. It has many bug fixes as well as updates. http://fbdev.bkbits.net/fbdev-2.5 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 [jsi...@us...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: James S. <jsi...@in...> - 2002-10-13 20:40:17
|
This is nearly the last of the fbdev api changes (90% of them). Alot of driver fixes as well. The console related stuff in each fbdev driver is nearly gone!!! Please do a pull. Thank you. bk://fbdev.bkbits.net/fbdev-2.5 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 [jsi...@us...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: Geert U. <ge...@li...> - 2002-10-14 10:11:32
|
On Sun, 13 Oct 2002, James Simmons wrote: > This is nearly the last of the fbdev api changes (90% of them). Alot of > driver fixes as well. The console related stuff in each fbdev driver > is nearly gone!!! Please do a pull. Thank you. > > bk://fbdev.bkbits.net/fbdev-2.5 Please add the output of diffstat, so we know which files you changed. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... 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 |
|
From: Geert U. <ge...@li...> - 2002-10-15 08:39:21
|
On Mon, 14 Oct 2002, James Simmons wrote: > > On Sun, 13 Oct 2002, James Simmons wrote: > > > This is nearly the last of the fbdev api changes (90% of them). Alot of > > > driver fixes as well. The console related stuff in each fbdev driver > > > is nearly gone!!! Please do a pull. Thank you. > > > > > > bk://fbdev.bkbits.net/fbdev-2.5 > > > > Please add the output of diffstat, so we know which files you changed. > > Better yet here is the BK patch via email. > @@ -220,12 +218,7 @@ > bool ' Advanced low level driver options' CONFIG_FBCON_ADVANCED > if [ "$CONFIG_FBCON_ADVANCED" = "y" ]; then > tristate ' Monochrome support' CONFIG_FBCON_MFB CONFIG_FBCON_MFB can be deleted, because of this change to the Makefile: > -obj-$(CONFIG_FBCON_MFB) += fbcon-mfb.o > # tristate ' Atari interleaved bitplanes (16 planes) support' CONFIG_FBCON_IPLAN2P16 FBCON_IPLAN2P16 can be deleted, since it doesn't exist. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... 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 |
|
From: James S. <jsi...@in...> - 2002-10-18 16:54:43
|
Done. 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 [jsi...@us...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net On Tue, 15 Oct 2002, Geert Uytterhoeven wrote: > On Mon, 14 Oct 2002, James Simmons wrote: > > > On Sun, 13 Oct 2002, James Simmons wrote: > > > > This is nearly the last of the fbdev api changes (90% of them). Alot of > > > > driver fixes as well. The console related stuff in each fbdev driver > > > > is nearly gone!!! Please do a pull. Thank you. > > > > > > > > bk://fbdev.bkbits.net/fbdev-2.5 > > > > > > Please add the output of diffstat, so we know which files you changed. > > > > Better yet here is the BK patch via email. > > @@ -220,12 +218,7 @@ > > bool ' Advanced low level driver options' CONFIG_FBCON_ADVANCED > > if [ "$CONFIG_FBCON_ADVANCED" = "y" ]; then > > tristate ' Monochrome support' CONFIG_FBCON_MFB > > CONFIG_FBCON_MFB can be deleted, because of this change to the Makefile: > > > -obj-$(CONFIG_FBCON_MFB) += fbcon-mfb.o > > > # tristate ' Atari interleaved bitplanes (16 planes) support' CONFIG_FBCON_IPLAN2P16 > > FBCON_IPLAN2P16 can be deleted, since it doesn't exist. > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li... > > 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 > > |
|
From: Russell K. <rm...@ar...> - 2002-10-15 09:00:41
|
On Mon, Oct 14, 2002 at 09:39:31AM -0700, James Simmons wrote:
> drivers/video/clps711xfb.c | 2
Ok, this won't clash with the updates Linus pulled recently from me
that actually allow this driver to build again in 2.5.42.
> diff -Nru a/drivers/video/clps711xfb.c b/drivers/video/clps711xfb.c
> --- a/drivers/video/clps711xfb.c Mon Oct 14 09:36:34 2002
> +++ b/drivers/video/clps711xfb.c Mon Oct 14 09:36:34 2002
> @@ -194,7 +194,6 @@
> .owner = THIS_MODULE,
> .fb_check_var = clps7111fb_check_var,
> .fb_set_par = clps7111fb_set_par,
> - .fb_set_var = gen_set_var,
> .fb_setcolreg = clps7111fb_setcolreg,
> .fb_blank = clps7111fb_blank,
> .fb_fillrect = cfb_fillrect,
> @@ -322,7 +321,6 @@
> clps_writeb(clps_readb(PDDR) | EDB_PD3_LCDBL, PDDR);
> }
>
> - gen_set_var(&cfb->var, -1, cfb);
> err = register_framebuffer(cfb);
>
> out: return err;
I'm not sure this "set var" business has been thought out as much as it
should be.
If can_soft_blank is not set, the driver will never, ever receive any
calls to perform blanking via the fb_blank callback. Even the power
management blanking calls are blocked, and fbcon clears the screen
instead. This in itself is fine.
However, since the set_var method has gone, drivers are now unable to
set can_soft_blank according to their capabilities because
fbgen.c:gen_set_disp will do it for them thusly:
if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR ||
info->fix.visual == FB_VISUAL_DIRECTCOLOR) {
display->can_soft_blank = info->fbops->fb_blank ? 1 : 0;
display->dispsw_data = NULL;
} else {
display->can_soft_blank = 0;
display->dispsw_data = info->pseudo_palette;
}
This sucks on devices where blanking can be performed by hardware means.
For example, on embedded devices, you can turn off the LCD controller
and LCD panel (and thereby save power). There's no point in having both
these powered/running when the display is not in use, draining valuable
battery power.
This is also true of most, if not all VGA cards when VESA blanking is in
effect. As the code currently stands, if the console is in pseudo colour
or direct colour mode, everything works as expected. However, if it isn't,
you can't even power down your monitor when the screen blanks.
In 2.5.42, there is a work around possible - it is possible to intercept
the call to gen_set_var, and set con_soft_blank according to your driver
capabilities. However, with the fb_set_var method going away, this is no
longer possible.
--
Russell King (rm...@ar...) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
|
|
From: Geert U. <ge...@li...> - 2002-10-15 09:15:41
|
On Tue, 15 Oct 2002, Russell King wrote:
> I'm not sure this "set var" business has been thought out as much as it
> should be.
>
> If can_soft_blank is not set, the driver will never, ever receive any
> calls to perform blanking via the fb_blank callback. Even the power
> management blanking calls are blocked, and fbcon clears the screen
> instead. This in itself is fine.
>
> However, since the set_var method has gone, drivers are now unable to
> set can_soft_blank according to their capabilities because
> fbgen.c:gen_set_disp will do it for them thusly:
>
> if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR ||
> info->fix.visual == FB_VISUAL_DIRECTCOLOR) {
> display->can_soft_blank = info->fbops->fb_blank ? 1 : 0;
> display->dispsw_data = NULL;
> } else {
> display->can_soft_blank = 0;
> display->dispsw_data = info->pseudo_palette;
> }
>
> This sucks on devices where blanking can be performed by hardware means.
> For example, on embedded devices, you can turn off the LCD controller
> and LCD panel (and thereby save power). There's no point in having both
> these powered/running when the display is not in use, draining valuable
> battery power.
>
> This is also true of most, if not all VGA cards when VESA blanking is in
> effect. As the code currently stands, if the console is in pseudo colour
> or direct colour mode, everything works as expected. However, if it isn't,
> you can't even power down your monitor when the screen blanks.
>
> In 2.5.42, there is a work around possible - it is possible to intercept
> the call to gen_set_var, and set con_soft_blank according to your driver
> capabilities. However, with the fb_set_var method going away, this is no
> longer possible.
So the generic part of the code should behave like this:
if (info->fbops->fb_blank && info->fbops->fb_blank(blank_flag)) {
/* use hardware blanking */
} else if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR ||
info->fix.visual == FB_VISUAL_DIRECTCOLOR) {
/* use software blanking */
} else {
/* no blanking possible, except for filling the screen with black, which
is not appropriate (unless we save/restore the contents?) */
}
Is that OK for you?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
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
|
|
From: Russell K. <rm...@ar...> - 2002-10-15 09:38:42
|
On Tue, Oct 15, 2002 at 11:14:03AM +0200, Geert Uytterhoeven wrote:
> So the generic part of the code should behave like this:
>
> if (info->fbops->fb_blank && info->fbops->fb_blank(blank_flag)) {
> /* use hardware blanking */
> } else if (info->fix.visual == FB_VISUAL_PSEUDOCOLOR ||
> info->fix.visual == FB_VISUAL_DIRECTCOLOR) {
> /* use software blanking */
> } else {
> /* no blanking possible, except for filling the screen with black, which
> is not appropriate (unless we save/restore the contents?) */
> }
>
> Is that OK for you?
That's fine for me, but I'd expect other people to find problems with it.
Would it not be better to allow drivers to decide which type of blanking
they want to use depending on the current parameters set via the set_par
callback? Only the drivers themselves know what their fb_blank method is
capable of performing.
I think with the above you'll inadvertently encourage drivers to mundge
the fb_blank function pointer in their set_par method.
There is also the argument about wanting soft blanking, but hardware power
saving.
--
Russell King (rm...@ar...) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
|
|
From: James S. <jsi...@in...> - 2002-10-18 17:34:44
|
> That's fine for me, but I'd expect other people to find problems with it. > > Would it not be better to allow drivers to decide which type of blanking > they want to use depending on the current parameters set via the set_par > callback? Only the drivers themselves know what their fb_blank method is > capable of performing. Yes the drivers should always have priority. The other stuff is there only if the drivers have no power management of any kind. I leave it up to the driver write to implement a fb_blank function that handles different cases. > I think with the above you'll inadvertently encourage drivers to mundge > the fb_blank function pointer in their set_par method. Why would you have to mess around with the function pointer. Couldn't you just set a flag or fill in a hardware dependent struct that defines what states are possible for hardware power management. Then when fb_blank is called it uses the information to decide which action to take. I think this approach is much more powerful than using a single can_soft_blank flag. I like to get ride of can_soft_blank and allow the driver to decide on this stuff itself. > There is also the argument about wanting soft blanking, but hardware power > saving. Hm. True unfortunely the fbdev layer lacks handling details like that. The console system is even worse. This is why a single flag like can_soft_blank can actually be a limitation. |
Thanks for helping keep SourceForge clean.
X