From: Martin Wilck <hidden> Date: 2004-11-23 17:04:44
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/
From: Antonino A. Daplas <hidden> Date: 2004-11-24 16:17:42
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.
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/
From: Martin Wilck <hidden> Date: 2004-11-25 14:55:21
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
From: Antonino A. Daplas <hidden> Date: 2004-11-25 19:53:17
On Thursday 25 November 2004 22:55, Martin Wilck wrote:
Antonino A. Daplas wrote:
quoted
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/
On Thursday 25 November 2004 22:55, Martin Wilck wrote:
quoted
Antonino A. Daplas wrote:
quoted
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/
From: Richard Purdie <hidden> Date: 2004-11-27 14:53:59
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/
From: Richard Purdie <hidden> Date: 2004-11-27 23:59:21
Antonino A. Daplas:
On Saturday 27 November 2004 22:53, Richard Purdie wrote:
quoted
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/
From: Antonino A. Daplas <hidden> Date: 2004-11-28 00:24:49
On Sunday 28 November 2004 07:59, Richard Purdie wrote:
Antonino A. Daplas:
quoted
On Saturday 27 November 2004 22:53, Richard Purdie wrote:
quoted
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/
From: Antonino A. Daplas <hidden> Date: 2004-11-28 00:58:59
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/
From: Richard Purdie <hidden> Date: 2004-11-28 00:59:12
Antonino A. Daplas:
quoted
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().
quoted
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/
From: Antonino A. Daplas <hidden> Date: 2004-11-28 01:26:46
On Sunday 28 November 2004 08:59, Richard Purdie wrote:
Antonino A. Daplas:
quoted
quoted
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/
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/
From: Richard Purdie <hidden> Date: 2004-11-29 22:39:58
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 <redacted>
@@ -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 0x08structfb_event{---linux-2.6.10-rc2/drivers/video/console/fbcon.c~fb_blank+++linux-2.6.10-rc2/drivers/video/console/fbcon.c
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/
From: Antonino A. Daplas <hidden> Date: 2004-11-29 23:29:35
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/