Default timings in vga16fb driver

Default timings in vga16fb driver

[Martin Wilck]

Hello,

I am wondering about the standard mode timings for the 640x480@60 mode 
in vga16fb driver (vga16fb_defined):

	.pixclock	= 39721,
	.left_margin	= 48,
	.right_margin	= 16,
	.upper_margin	= 39,
	.lower_margin	= 8,
	.hsync_len 	= 96,
	.vsync_len	= 2,
	.vmode		= FB_VMODE_NONINTERLACED,

IMO this corresponds to a total screen height of 529 which is different 
from the value 525 which is normally used (eg in X Windows). What is the 
reason for this? Is it possible that the value for "upper_margin" should 
be 35 rather than 39?

I am asking because we have encountered a video device that obviously 
has problems displaying the standard mode of the vga16fb driver.

More detail:

Unless I'm  mistaken, the above translates into an XFree86 modeline
   ModeLine "640x480" 25.175 640 656 752 800 480 488 490 529

The standard XFree86 modeline for this mode, however, looks like this:
(same in drivers/video/modedb.c)
   ModeLine "640x480" 25.175 640 664 760 800 480 491 493 525

The description at http://www.epanorama.net/documents/pc/vga_timing.html.
would suggest:
   ModeLine "640x480" 25.175 640 656 752 800 480 490 492 525

I apologize if I'm overlooking something.

Best regards,
Martin

--
Martin Wilck                Phone: +49 5251 8 15113
Fujitsu Siemens Computers   Fax:   +49 5251 8 20409
Heinz-Nixdorf-Ring 1        mailto:Martin.Wilck@Fujitsu-Siemens.com
D-33106 Paderborn           http://www.fujitsu-siemens.com/primergy



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Default timings in vga16fb driver

[Antonino A. Daplas]

On Wednesday 24 November 2004 01:04, Martin Wilck wrote:
> Hello,
>
> I am wondering about the standard mode timings for the 640x480@60 mode
> in vga16fb driver (vga16fb_defined):
>
> 	.pixclock	= 39721,
> 	.left_margin	= 48,
> 	.right_margin	= 16,
> 	.upper_margin	= 39,
> 	.lower_margin	= 8,
> 	.hsync_len 	= 96,
> 	.vsync_len	= 2,
> 	.vmode		= FB_VMODE_NONINTERLACED,
>
> IMO this corresponds to a total screen height of 529 which is different
> from the value 525 which is normally used (eg in X Windows). What is the
> reason for this? Is it possible that the value for "upper_margin" should

Possibly, because nobody really complained that the modeline is slightly
off.  Most users have variable sync displays and should have no problem
display a slightly off modeline.

>
> be 35 rather than 39?
> I am asking because we have encountered a video device that obviously
> has problems displaying the standard mode of the vga16fb driver.
>

Did the device work correctly after changing the modeline?

> More detail:
>
> Unless I'm  mistaken, the above translates into an XFree86 modeline
>    ModeLine "640x480" 25.175 640 656 752 800 480 488 490 529

Yes, the above does give a slightly off vert refresh rate of 59.49
(800*529)/25175000

>
> The standard XFree86 modeline for this mode, however, looks like this:
> (same in drivers/video/modedb.c)
>    ModeLine "640x480" 25.175 640 664 760 800 480 491 493 525

This one gives a refresh rate of 59.94 which is the closest we can get to a
60 Hz refresh. 

>
> The description at http://www.epanorama.net/documents/pc/vga_timing.html.
> would suggest:
>    ModeLine "640x480" 25.175 640 656 752 800 480 490 492 525

And this one too.

>
> I apologize if I'm overlooking something.

I don't think you overlooked anything. The default modeline of vga16fb
should be corrected.

Tony




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Default timings in vga16fb driver

[Martin Wilck]

[-- Attachment #1: Type: text/plain, Size: 482 bytes --]

Antonino A. Daplas wrote:

> I don't think you overlooked anything. The default modeline of vga16fb
> should be corrected.

OK, so here's the patch (using the timings from /etc/fb.modes). Should I 
send it to linux-kernel, too?

Martin

-- 
Martin Wilck                Phone: +49 5251 8 15113
Fujitsu Siemens Computers   Fax:   +49 5251 8 20409
Heinz-Nixdorf-Ring 1        mailto:Martin.Wilck@Fujitsu-Siemens.com
D-33106 Paderborn           http://www.fujitsu-siemens.com/primergy


[-- Attachment #2: vga16.diff --]
[-- Type: text/x-patch, Size: 1008 bytes --]

Patch:	Fix default timings in vga16fb.c

Author: Martin Wilck <Martin.Wilck@Fujitsu-Siemens.com>
Signed-off-by: Martin Wilck <Martin.Wilck@Fujitsu-Siemens.com>

This patch adapts the timings of the default mode in vga16fb.c
to the 640x480-60 timings in /etc/fb.modes. 

In particular, the total screen height is fixed to be 525 pixels 
rather than 529. The height of 529 was causing trouble on some LCD displays.

(Note: To make the mode 100% identical to the one in /etc/fb.modes,
the pixclock must be set to 39722, too; I didn't want to do that here).

--- linux-2.6.5-7.111/drivers/video/vga16fb.c.orig	2004-11-25 15:38:11.000000000 +0100
+++ linux-2.6.5-7.111/drivers/video/vga16fb.c	2004-11-25 15:45:54.000000000 +0100
@@ -91,8 +91,8 @@ static struct fb_var_screeninfo vga16fb_
 	.pixclock	= 39721,
 	.left_margin	= 48,
 	.right_margin	= 16,
-	.upper_margin	= 39,
-	.lower_margin	= 8,
+	.upper_margin	= 33,
+	.lower_margin	= 10,
 	.hsync_len 	= 96,
 	.vsync_len	= 2,
 	.vmode		= FB_VMODE_NONINTERLACED,

Re: Default timings in vga16fb driver

[Antonino A. Daplas]

On Thursday 25 November 2004 22:55, Martin Wilck wrote:
> Antonino A. Daplas wrote:
> > I don't think you overlooked anything. The default modeline of vga16fb
> > should be corrected.
>
> OK, so here's the patch (using the timings from /etc/fb.modes). Should I
> send it to linux-kernel, too?

No, I'll take care of this.

Tony




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: Default timings in vga16fb driver

[Geert Uytterhoeven]

On Fri, 26 Nov 2004, Antonino A. Daplas wrote:
> On Thursday 25 November 2004 22:55, Martin Wilck wrote:
> > Antonino A. Daplas wrote:
> > > I don't think you overlooked anything. The default modeline of vga16fb
> > > should be corrected.
> >
> > OK, so here's the patch (using the timings from /etc/fb.modes). Should I
> > send it to linux-kernel, too?
> 
> No, I'll take care of this.

BTW, can't vga16fb just use modedb, with the default mode being 640x480-4@60?

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


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

FB_EVENT (blank and unblank?)

[Richard Purdie]

I've been looking at ways to solve a couple of code interdepencies I don't 
like with w100fb and its backlight  and touch screen drivers.

I have two places where they need to talk. The first is for the touch screen 
to query the x resolution (and to know if the screen is blanked)[1]. The 
second is to turn the backlight off when the console is blanked.

On solution I've been looking at is to use fb_register_client. I could then 
hook into mode changes and that solves one problem. There is currently no 
FB_EVENT_BLANK and  FB_EVENT_UNBLANK however. Would it be acceptable to add 
these events with appropriate hooks in fbmem.c and to use fb_register_client 
in these drivers to obtain this information?

Or can anyone see an alternative other than global variables?

[1] Presumably for interference reasons, it only queries the touchscreen 
after a hsync. The hysnc pulse can be obtained from the IO lines but to get 
the timing right, xres also needs to be known. If the screen is blank, these 
delays can be disabled...

-- 
Richard 



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: FB_EVENT (blank and unblank?)

[Antonino A. Daplas]

On Saturday 27 November 2004 22:53, Richard Purdie wrote:
> I've been looking at ways to solve a couple of code interdepencies I don't
> like with w100fb and its backlight  and touch screen drivers.
>
> I have two places where they need to talk. The first is for the touch
> screen to query the x resolution (and to know if the screen is blanked)[1].
> The second is to turn the backlight off when the console is blanked.

Can you adopt the backlight support infrastructure in powermacs?  See
arch/ppc/platforms/pmac_backlight.c  Currently, it's PPC-specific, but it
can be extended to other platforms.  A few drivers use this, rivafb is one of
them (drivers/video/fbdev.c), and aty.

Tony




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: FB_EVENT (blank and unblank?)

[Richard Purdie]

Antonino A. Daplas:
> On Saturday 27 November 2004 22:53, Richard Purdie wrote:
>> I have two places where they need to talk. The first is for the touch
>> screen to query the x resolution (and to know if the screen is 
>> blanked)[1].
>> The second is to turn the backlight off when the console is blanked.
>
> Can you adopt the backlight support infrastructure in powermacs?  See
> arch/ppc/platforms/pmac_backlight.c  Currently, it's PPC-specific, but it
> can be extended to other platforms.  A few drivers use this, rivafb is one 
> of
> them (drivers/video/fbdev.c), and aty.

There are two issues here and this addresses the wrong one.

My Issue: I have a backlight driver that shares no code with the framebuffer 
driver - the hardware is totally separate. I have there written them as two 
spate drivers which seems to make sense. The problem is that there is no 
method to communicate blanking to the external backlight driver (which is 
all it needs to know about). Obviously I can add links between them but I 
feel that's ugly. Adding a couple of extra events to the fb_register_client 
system would be much neater.

The Other Issue: There is no common method to access and control backlight 
levels within the kernel. My feeling on this is that they should appear in 
sysfs as their own class. I need to look into this as I know there has been 
discussion in the past and I don't know what the issues are. I'd welcome any 
comments on this though.

-- 
Richard



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: FB_EVENT (blank and unblank?)

[Antonino A. Daplas]

On Sunday 28 November 2004 07:59, Richard Purdie wrote:
> Antonino A. Daplas:
> > On Saturday 27 November 2004 22:53, Richard Purdie wrote:
> >> I have two places where they need to talk. The first is for the touch
> >> screen to query the x resolution (and to know if the screen is
> >> blanked)[1].
> >> The second is to turn the backlight off when the console is blanked.
> >
> > Can you adopt the backlight support infrastructure in powermacs?  See
> > arch/ppc/platforms/pmac_backlight.c  Currently, it's PPC-specific, but it
> > can be extended to other platforms.  A few drivers use this, rivafb is
> > one of
> > them (drivers/video/fbdev.c), and aty.
>
> There are two issues here and this addresses the wrong one.
>
> My Issue: I have a backlight driver that shares no code with the
> framebuffer driver - the hardware is totally separate. I have there written
> them as two spate drivers which seems to make sense. The problem is that
> there is no method to communicate blanking to the external backlight driver
> (which is all it needs to know about). Obviously I can add links between

Of course there is.  Your backlight driver does a
register_backlight_controllers().  Then your fb driver does a
set_backlight_enable(!blank) in its xxxfb_blank implementation.

> them but I feel that's ugly. Adding a couple of extra events to the
> fb_register_client system would be much neater.
>
> The Other Issue: There is no common method to access and control backlight

Not yet, but if the powermac backlight support is extended, then we suddenly
have a common method.  Right now, pmac's backlight support has this as
exportable symbols:

set_backlight_enable()
get_backlight_enable()
set_backlight_level()
get_backlight_level()

And all of the above calls specific hooks to the backlight driver.

> levels within the kernel. My feeling on this is that they should appear in
> sysfs as their own class. I need to look into this as I know there has been
> discussion in the past and I don't know what the issues are. I'd welcome
> any comments on this though.

We don't have a common architecture yet for backlight control, and I don't
know where this is really going.  Anyone here have more info?

Tony





-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: FB_EVENT (blank and unblank?)

[Richard Purdie]

Antonino A. Daplas:
>> My Issue: I have a backlight driver that shares no code with the
>> framebuffer driver - the hardware is totally separate. I have there 
>> written
>> them as two spate drivers which seems to make sense. The problem is that
>> there is no method to communicate blanking to the external backlight 
>> driver
>> (which is all it needs to know about). Obviously I can add links between
>
> Of course there is.  Your backlight driver does a
> register_backlight_controllers().  Then your fb driver does a
> set_backlight_enable(!blank) in its xxxfb_blank implementation.

Yes, you could do that. I was trying to look for a method than meant no 
specific action by the framebuffer driver was required. It shouldn't have to 
care if a backlight is present or not...

On the other hand, the console system shouldn't have to either. Hence the 
suggestion that blank and unblank events are added. It may be there's a 
layer of backlight glue added to the drivers/video directory 
drivers/video/backlight? that catches those events and calls 
set_backlight_enable(!blank) and provides functions  like 
register_backlight_controllers().

>> The Other Issue: There is no common method to access and control 
>> backlight
>
> Not yet, but if the powermac backlight support is extended, then we 
> suddenly
> have a common method.  Right now, pmac's backlight support has this as
> exportable symbols:
>
> set_backlight_enable()
> get_backlight_enable()
> set_backlight_level()
> get_backlight_level()
>
> And all of the above calls specific hooks to the backlight driver.

I agree that would go part of the way towards a common method (the other 
part being a sysfs representation or similar). That sysfs representation 
could even be provided by backlight "core" in drivers/video/backlight?.

> We don't have a common architecture yet for backlight control, and I don't
> know where this is really going.  Anyone here have more info?

I'd be interested to know the current position...

Richard 



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: FB_EVENT (blank and unblank?)

[Antonino A. Daplas]

On Sunday 28 November 2004 08:59, Richard Purdie wrote:
> Antonino A. Daplas:
> >> My Issue: I have a backlight driver that shares no code with the
> >> framebuffer driver - the hardware is totally separate. I have there
> >> written
> >> them as two spate drivers which seems to make sense. The problem is that
> >> there is no method to communicate blanking to the external backlight
> >> driver
> >> (which is all it needs to know about). Obviously I can add links between
> >
> > Of course there is.  Your backlight driver does a
> > register_backlight_controllers().  Then your fb driver does a
> > set_backlight_enable(!blank) in its xxxfb_blank implementation.
>
> Yes, you could do that. I was trying to look for a method than meant no
> specific action by the framebuffer driver was required. It shouldn't have
> to care if a backlight is present or not...

Ah, when you explained it like that, then it does sound very reasonable.
Okay, I think that can be added.  I think we will need only 1 event
FB_EVENT_BLANK, then in fb_event.data, the blanking level.

We can do it similarly with the mode switch event, differentiate if the
request is coming from userspace or the kernel.

Tony





-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

fbdev: Add FB_EVENT_BLANK to notify listeners of a blanking status change

[Richard Purdie]

Add FB_EVENT_BLANK to notify listeners of a blanking status change. This 
allows backlight drivers to be implemented completely separately from any 
framebuffer driver. The new blanking mode is passed in event.data.

Signed-off-by: Richard Purdie <rpurdie@rpsys.net>

--- linux-2.6.10-rc2/drivers/video/fbmem.c~fb_blank
+++ linux-2.6.10-rc2/drivers/video/fbmem.c
@@ -744,9 +744,14 @@
 fb_blank(struct fb_info *info, int blank)
 {
  int err = -EINVAL;
+ struct fb_event event;

   if (blank > FB_BLANK_POWERDOWN)
    blank = FB_BLANK_POWERDOWN;
+
+ event.info = info;
+ event.data = &blank;
+ notifier_call_chain(&fb_notifier_list, FB_EVENT_BLANK, &event);

  if (info->fbops->fb_blank)
    err = info->fbops->fb_blank(blank, info);
--- linux-2.6.10-rc2/include/linux/fb.h~fb_blank
+++ linux-2.6.10-rc2/include/linux/fb.h
@@ -488,6 +488,8 @@
 #define FB_EVENT_GET_CONSOLE_MAP        0x06
 /*      set console to framebuffer mapping */
 #define FB_EVENT_SET_CONSOLE_MAP        0x07
+/*      Blanking on the display on this fb_info has changed */
+#define FB_EVENT_BLANK                  0x08


 struct fb_event {
--- linux-2.6.10-rc2/drivers/video/console/fbcon.c~fb_blank
+++ linux-2.6.10-rc2/drivers/video/console/fbcon.c
@@ -2063,8 +2063,7 @@
    fbcon_cursor(vc, blank ? CM_ERASE : CM_DRAW);
    ops->cursor_flash = (!blank);

-   if (info->fbops->fb_blank)
-    ret = info->fbops->fb_blank(blank, info);
+  ret = fb_blank(info, blank);

    if (ret)
     fbcon_generic_blank(vc, info, blank);




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

Re: fbdev: Add FB_EVENT_BLANK to notify listeners of a blanking status change

[Antonino A. Daplas]

On Tuesday 30 November 2004 06:36, Richard Purdie wrote:
> Add FB_EVENT_BLANK to notify listeners of a blanking status change. This
> allows backlight drivers to be implemented completely separately from any
> framebuffer driver. The new blanking mode is passed in event.data.

Almost.  Note that my intent is to notify the console of the blank status
_and_ do something about it, so we also need to do
'do_blank_screen/do_unblank_screen' at the fbcon level.

I already have a patch in my tree, and will submit it after 2.6.10 comes
out. But for now and for your own use, this will do just fine.

Tony




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/

cursor color changes

[ramprasad]

Hi All,
    I am using epson S1D13506 CRT controller along with  PXA 
2.4.19-rmk7-pxa1 kernel. I am seeing the  tux logo on my CRT also i am 
seeing some vertical lines at some constant distance.My cursor is 
showing some junk colors while blinking.What could be worng. why am i 
not getting white  blinking cursor.. when i connect USB key board to 
login system hangs.


Any help
Thanks in advance,
Ramprasad



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/