Re: [GIT PULL] Remove the use of magic macros for boot_params/screen_info
On Tue, 2007-10-16 at 23:56 -0700, H. Peter Anvin wrote: > Hi Linus, > > Please pull: > > git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup.git > master > > This patch removes all uses of magic macros to access the former > zeropage, now the boot_params structure, as well as the screen_info > structure. The equivalent (pre-x86-merge) of the boot_params patch > has been in -mm since shortly after 2.6.22. > > A minor note: the video mode number 0x6A was officially assigned by > VESA; the only VESA standard 7-bit video mode number ever assigned. > > H. Peter Anvin (2): > [x86] remove uses of magic macros for boot_params access > Remove magic macros for screen_info structure members > > drivers/video/console/dummycon.c |4 +- > drivers/video/console/vgacon.c | 51 ++- > drivers/video/intelfb/intelfbdrv.c | 5 ++- > drivers/video/vga16fb.c|2 +- Acked-by: Antonino A. Daplas <[EMAIL PROTECTED]> with respect to the drivers/video portion. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Remove the use of magic macros for boot_params/screen_info
On Tue, 2007-10-16 at 23:56 -0700, H. Peter Anvin wrote: Hi Linus, Please pull: git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup.git master This patch removes all uses of magic macros to access the former zeropage, now the boot_params structure, as well as the screen_info structure. The equivalent (pre-x86-merge) of the boot_params patch has been in -mm since shortly after 2.6.22. A minor note: the video mode number 0x6A was officially assigned by VESA; the only VESA standard 7-bit video mode number ever assigned. H. Peter Anvin (2): [x86] remove uses of magic macros for boot_params access Remove magic macros for screen_info structure members drivers/video/console/dummycon.c |4 +- drivers/video/console/vgacon.c | 51 ++- drivers/video/intelfb/intelfbdrv.c |5 ++- drivers/video/vga16fb.c|2 +- Acked-by: Antonino A. Daplas [EMAIL PROTECTED] with respect to the drivers/video portion. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23: No text consoles with FRAMEBUFFER_CONSOLE_DETECT_PRIMARY
On Sat, 2007-10-13 at 20:13 +0200, Frans Pop wrote: > I could solve this issue in two ways: > - boot with VGA=791 parameter (initial boot was without VGA= parameter) > - compile kernel without FRAMEBUFFER_CONSOLE_DETECT_PRIMARY set (I also > unset FB_VIRTUAL, but without its boot param that should be a no-op) After looking at vfb.c again, it seems the default is for vfb to be enabled and you have to actively disable vfb either with video=vfb:disable or video=vfb:off I have to change this behavior. In the meantime, try one of the above options. (I was also under the impression that vfb must be explicitly enabled with a boot option...I remember now, the option vfb_enable defaults to false when compiled as a module, and to true if compiled statically.) Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23: No text consoles with FRAMEBUFFER_CONSOLE_DETECT_PRIMARY
On Sat, 2007-10-13 at 20:13 +0200, Frans Pop wrote: > While running a test with current Linus' git tree, I ran into the following > issue. The issue is also present in stable 2.6.23. > > System x86_64; Pentium D; Intel 82945G/GZ on-board graphics > > After initial boot messages all output to console stops. The last visible > messages are: > checking if image is initramfs...<6>Switched to high resolution mode on CPU 1 > Switched to high resolution mode on CPU 0 > > After that, nothing until XOrg starts up and graphical login/desktop on VT7 > are displayed normal. > Switching back to VT1-VT5 gives nothing: no login prompts, just nothing. > Can you also post your dmesg and /proc/cdmline? Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23: No text consoles with FRAMEBUFFER_CONSOLE_DETECT_PRIMARY
On Sat, 2007-10-13 at 20:13 +0200, Frans Pop wrote: While running a test with current Linus' git tree, I ran into the following issue. The issue is also present in stable 2.6.23. System x86_64; Pentium D; Intel 82945G/GZ on-board graphics After initial boot messages all output to console stops. The last visible messages are: checking if image is initramfs...6Switched to high resolution mode on CPU 1 Switched to high resolution mode on CPU 0 After that, nothing until XOrg starts up and graphical login/desktop on VT7 are displayed normal. Switching back to VT1-VT5 gives nothing: no login prompts, just nothing. Can you also post your dmesg and /proc/cdmline? Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23: No text consoles with FRAMEBUFFER_CONSOLE_DETECT_PRIMARY
On Sat, 2007-10-13 at 20:13 +0200, Frans Pop wrote: I could solve this issue in two ways: - boot with VGA=791 parameter (initial boot was without VGA= parameter) - compile kernel without FRAMEBUFFER_CONSOLE_DETECT_PRIMARY set (I also unset FB_VIRTUAL, but without its boot param that should be a no-op) After looking at vfb.c again, it seems the default is for vfb to be enabled and you have to actively disable vfb either with video=vfb:disable or video=vfb:off I have to change this behavior. In the meantime, try one of the above options. (I was also under the impression that vfb must be explicitly enabled with a boot option...I remember now, the option vfb_enable defaults to false when compiled as a module, and to true if compiled statically.) Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH 0/6] Patch series to add of_platform binding to xilinxfb
On Tue, 2007-10-09 at 11:39 -0600, Grant Likely wrote: > On 10/8/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote: > > On Mon, 2007-10-08 at 22:43 -0600, Grant Likely wrote: > > > BTW, what path do framebuffer patches take to get into Linus' tree? > > > Does he pull your tree directly, or do they go through someone else's > > > tree? > > > > They all go to -mm tree, unless it's a needed fix, then to Linus's. > > > > Tony > > Ah, okay. > > Since the XilinxFB is a powerpc-only device, is it okay with you if I > get Paul Mackerras to merge them into his tree instead (that way the > changes go in with the platform code which requires these changes) Fine with me. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH 0/6] Patch series to add of_platform binding to xilinxfb
On Tue, 2007-10-09 at 11:39 -0600, Grant Likely wrote: On 10/8/07, Antonino A. Daplas [EMAIL PROTECTED] wrote: On Mon, 2007-10-08 at 22:43 -0600, Grant Likely wrote: BTW, what path do framebuffer patches take to get into Linus' tree? Does he pull your tree directly, or do they go through someone else's tree? They all go to -mm tree, unless it's a needed fix, then to Linus's. Tony Ah, okay. Since the XilinxFB is a powerpc-only device, is it okay with you if I get Paul Mackerras to merge them into his tree instead (that way the changes go in with the platform code which requires these changes) Fine with me. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH 0/6] Patch series to add of_platform binding to xilinxfb
On Mon, 2007-10-08 at 22:43 -0600, Grant Likely wrote: > On 10/2/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote: > > On Mon, 2007-10-01 at 09:57 -0600, Grant Likely wrote: > > > Assuming there are no major issues, I'd like to get this patch series > > > queued up for inclusion in 2.6.24. > > > > Okay. > > > > Tony > > BTW, what path do framebuffer patches take to get into Linus' tree? > Does he pull your tree directly, or do they go through someone else's > tree? They all go to -mm tree, unless it's a needed fix, then to Linus's. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sleepy linux 2.6.23-rc9
On Tue, 2007-10-09 at 00:05 +0200, Pavel Machek wrote: > Hi! > > I played with powertop a bit, and found a fairly interesting failure > mode. If I boot init=/bin/bash vga=1, I get ~2 wakeups a second, nice. > > When I boot init=/bin/bash vga=791 (vesa framebuffer), most wakeups > are caused by cursor painting (I should fix that some day, I > guess). But... the cursor blinking does not even work properly! > > It blinks at normal speed, then (randomly) it blinks slowly, then gets > back to normal speed, then inserts longer delay. > > The effect is so nice that I thought about youtube ;-). Thinkpad > x60.. question is, how to debug it? The cursor blinking is done by software via a timer. It's in drivers/video/console/fbcon.c. With the latest -rc kernel you can turn off the blinking with echo 0 > /sys/class/graphics/fbcon/cursor_blink Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Colored kernel output (run3)
On Tue, 2007-10-09 at 01:31 +0200, Jan Engelhardt wrote: > On Oct 9 2007 07:12, Antonino A. Daplas wrote: > >> > >> References: http://lkml.org/lkml/2007/4/1/162 > >>http://lkml.org/lkml/2007/10/5/199 > > > >This is quite a long thread :-) > > It was a patch series after all. But as Greg puts it, be persistent. > > >> +config VT_PRINTK_COLOR > >> + hex "Colored kernel message output" > >> + range 0x00 0xFF > >> + depends on VT_CKO > >> + default 0x07 > >> + ---help--- > >> + This option defines with which color kernel messages will be > >> + printed to the console. > >> + > >> + The value you need to enter here is the value is composed > > > >The more correct term for "The value" is probably "The attribute". > > "The value for this kconfig entry" it should read in the minds. > > >> + (Foreground colors 0x08 to 0x0F do not work when a VGA > >> + console font with 512 glyphs is used.) > > > >You might have to include a warning that those values or attributes are > >interpreted differently depending on the driver used, and the above is > >mostly true for 16-color console drivers only. > > Are there any other drivers besides vgacon and fbcon that use vt.c? All drivers under drivers/video/console. That would be: vgacon dummycon fbcon newport_con sticon promcon mdacon There are perhaps a few more drivers outside this directory, such as sisusbcon or something. > >You may want to leave out the blink attribute (0x80) from this part. > >Otherwise setterm -blink on|off will produce the opposite effect. > > But 0x80 might be interpreted in a different fashion for some othercon, > yielding for example superbold rather than blinking. That's right. But setting the blink attribute is done with an XOR (^). So 'setterm -blink' on will unset the blink attribute (0x80 ^ 0x80). > I'll have to try this, because usually, setterm operates on TTYs > rather than VCs. Yes, but if the tty driver type is a virtual console, then vt.c is still affected. Well the blink attribute is ignored by most drivers, if I'm not mistaken. So you generally won't see the effect :-). But with fbcon, the blink attribute is interpreted as "change background color from black to light gray". Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Colored kernel output (run3)
On Sat, 2007-10-06 at 22:09 +0200, Jan Engelhardt wrote:
> Colored kernel message output (1/2)
>
> This patch makes it possible to give kernel messages a selectable
> color. It can be chosen at compile time, overridden at boot time,
> and changed at run time.
>
> References: http://lkml.org/lkml/2007/4/1/162
> http://lkml.org/lkml/2007/10/5/199
This is quite a long thread :-)
>
> Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]>
>
> ---
> drivers/char/Kconfig | 42 ++
> drivers/char/vt.c| 23 +++
> 2 files changed, 65 insertions(+)
>
> Index: linux-2.6.23/drivers/char/Kconfig
> ===
> --- linux-2.6.23.orig/drivers/char/Kconfig
> +++ linux-2.6.23/drivers/char/Kconfig
> @@ -58,6 +58,48 @@ config VT_CONSOLE
>
> If unsure, say Y.
>
> +config VT_CKO
> + bool "Colored kernel message output"
> + depends on VT_CONSOLE
> + ---help---
> + This option enables kernel messages to be emitted in
> + colors other than the default.
> +
> + If unsure, say N.
> +
> +config VT_PRINTK_COLOR
> + hex "Colored kernel message output"
> + range 0x00 0xFF
> + depends on VT_CKO
> + default 0x07
> + ---help---
> + This option defines with which color kernel messages will be
> + printed to the console.
> +
> + The value you need to enter here is the value is composed
The more correct term for "The value" is probably "The attribute".
> + (OR-ed) of a foreground and a background color.
> +
> + Foreground:
> + 0x00 = black, 0x08 = dark gray,
> + 0x01 = red, 0x09 = light red,
> + 0x02 = green, 0x0A = light green,
> + 0x03 = brown, 0x0B = yellow,
> + 0x04 = blue,0x0C = light blue,
> + 0x05 = magenta, 0x0D = light magenta,
> + 0x06 = cyan,0x0E = light cyan,
> + 0x07 = gray,0x0F = white,
> +
> + (Foreground colors 0x08 to 0x0F do not work when a VGA
> + console font with 512 glyphs is used.)
You might have to include a warning that those values or attributes are
interpreted differently depending on the driver used, and the above is
mostly true for 16-color console drivers only.
For 2-colors (we still have quite a few of them) only bit 0 is true for
color (0x00 and 0x01). The rest of the bits are interpreted as
attributes:
0x02 - italic
0x04 - underline
0x08 - bold
0x80 - blink
The italic, underline and bold attributes will show up in a 2-color
framebuffer console. The blink attribute is ignored.
With a 4-color fb console (4-level grayscale), those values are again
interpreted differently.
0x00 - 0x00 : black
0x01 - 0x06 : white
0x07 - 0x08 : gray
the rest: intense white
(If by mistake 0x0106 is used, it will produce a white on white display)
With an 8-color console, only the first 8 values are considered.
With a 16-color console, that is also not consistent:
With vgacon, it supports 16-color foreground (fg), 8-color
background (bg) at 256 chars. Becomes 8 fg and 8 bg with 512 chars.
With fbcon, it supports 16 fg and 16 bg at 256, 16 fg and 8 bg at
512 chars.
And for drivers that have their own con_build_attr() hook, they will be
interpreted differently again.
> +
> + Background:
> + 0x00 = black, 0x40 = blue,
> + 0x10 = red, 0x50 = magenta,
> + 0x20 = green, 0x60 = cyan,
> + 0x30 = brown, 0x70 = gray,
> +
> + For example, 0x1F would yield white on red.
> +
You may need to specify that the values here are the console default,
ie, the default_blue|grn|red boot options are not filled up.
> config HW_CONSOLE
> bool
> depends on VT && !S390 && !UML
> Index: linux-2.6.23/drivers/char/vt.c
> ===
> --- linux-2.6.23.orig/drivers/char/vt.c
> +++ linux-2.6.23/drivers/char/vt.c
> @@ -73,6 +73,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -2344,6 +2345,23 @@ struct tty_driver *console_driver;
>
> #ifdef CONFIG_VT_CONSOLE
>
> +static unsigned int printk_color __read_mostly = CONFIG_VT_PRINTK_COLOR;
> +#ifdef CONFIG_VT_CKO
> +module_param(printk_color, uint, S_IRUGO | S_IWUSR);
> +
> +static inline void vc_set_color(struct vc_data *vc, unsigned char color)
> +{
> + vc->vc_color = color_table[color & 0xF] |
> +(color_table[(color >> 4) & 0x7] << 4) |
> +(color & 0x80);
You may want to leave out the blink attribute (0x80) from this part.
Otherwise setterm -blink on|off will produce the opposite effect.
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Colored kernel output (run3)
On Sat, 2007-10-06 at 22:09 +0200, Jan Engelhardt wrote:
Colored kernel message output (1/2)
This patch makes it possible to give kernel messages a selectable
color. It can be chosen at compile time, overridden at boot time,
and changed at run time.
References: http://lkml.org/lkml/2007/4/1/162
http://lkml.org/lkml/2007/10/5/199
This is quite a long thread :-)
Signed-off-by: Jan Engelhardt [EMAIL PROTECTED]
---
drivers/char/Kconfig | 42 ++
drivers/char/vt.c| 23 +++
2 files changed, 65 insertions(+)
Index: linux-2.6.23/drivers/char/Kconfig
===
--- linux-2.6.23.orig/drivers/char/Kconfig
+++ linux-2.6.23/drivers/char/Kconfig
@@ -58,6 +58,48 @@ config VT_CONSOLE
If unsure, say Y.
+config VT_CKO
+ bool Colored kernel message output
+ depends on VT_CONSOLE
+ ---help---
+ This option enables kernel messages to be emitted in
+ colors other than the default.
+
+ If unsure, say N.
+
+config VT_PRINTK_COLOR
+ hex Colored kernel message output
+ range 0x00 0xFF
+ depends on VT_CKO
+ default 0x07
+ ---help---
+ This option defines with which color kernel messages will be
+ printed to the console.
+
+ The value you need to enter here is the value is composed
The more correct term for The value is probably The attribute.
+ (OR-ed) of a foreground and a background color.
+
+ Foreground:
+ 0x00 = black, 0x08 = dark gray,
+ 0x01 = red, 0x09 = light red,
+ 0x02 = green, 0x0A = light green,
+ 0x03 = brown, 0x0B = yellow,
+ 0x04 = blue,0x0C = light blue,
+ 0x05 = magenta, 0x0D = light magenta,
+ 0x06 = cyan,0x0E = light cyan,
+ 0x07 = gray,0x0F = white,
+
+ (Foreground colors 0x08 to 0x0F do not work when a VGA
+ console font with 512 glyphs is used.)
You might have to include a warning that those values or attributes are
interpreted differently depending on the driver used, and the above is
mostly true for 16-color console drivers only.
For 2-colors (we still have quite a few of them) only bit 0 is true for
color (0x00 and 0x01). The rest of the bits are interpreted as
attributes:
0x02 - italic
0x04 - underline
0x08 - bold
0x80 - blink
The italic, underline and bold attributes will show up in a 2-color
framebuffer console. The blink attribute is ignored.
With a 4-color fb console (4-level grayscale), those values are again
interpreted differently.
0x00 - 0x00 : black
0x01 - 0x06 : white
0x07 - 0x08 : gray
the rest: intense white
(If by mistake 0x0106 is used, it will produce a white on white display)
With an 8-color console, only the first 8 values are considered.
With a 16-color console, that is also not consistent:
With vgacon, it supports 16-color foreground (fg), 8-color
background (bg) at 256 chars. Becomes 8 fg and 8 bg with 512 chars.
With fbcon, it supports 16 fg and 16 bg at 256, 16 fg and 8 bg at
512 chars.
And for drivers that have their own con_build_attr() hook, they will be
interpreted differently again.
+
+ Background:
+ 0x00 = black, 0x40 = blue,
+ 0x10 = red, 0x50 = magenta,
+ 0x20 = green, 0x60 = cyan,
+ 0x30 = brown, 0x70 = gray,
+
+ For example, 0x1F would yield white on red.
+
You may need to specify that the values here are the console default,
ie, the default_blue|grn|red boot options are not filled up.
config HW_CONSOLE
bool
depends on VT !S390 !UML
Index: linux-2.6.23/drivers/char/vt.c
===
--- linux-2.6.23.orig/drivers/char/vt.c
+++ linux-2.6.23/drivers/char/vt.c
@@ -73,6 +73,7 @@
*/
#include linux/module.h
+#include linux/moduleparam.h
#include linux/types.h
#include linux/sched.h
#include linux/tty.h
@@ -2344,6 +2345,23 @@ struct tty_driver *console_driver;
#ifdef CONFIG_VT_CONSOLE
+static unsigned int printk_color __read_mostly = CONFIG_VT_PRINTK_COLOR;
+#ifdef CONFIG_VT_CKO
+module_param(printk_color, uint, S_IRUGO | S_IWUSR);
+
+static inline void vc_set_color(struct vc_data *vc, unsigned char color)
+{
+ vc-vc_color = color_table[color 0xF] |
+(color_table[(color 4) 0x7] 4) |
+(color 0x80);
You may want to leave out the blink attribute (0x80) from this part.
Otherwise setterm -blink on|off will produce the opposite effect.
Tony
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Colored kernel output (run3)
On Tue, 2007-10-09 at 01:31 +0200, Jan Engelhardt wrote: On Oct 9 2007 07:12, Antonino A. Daplas wrote: References: http://lkml.org/lkml/2007/4/1/162 http://lkml.org/lkml/2007/10/5/199 This is quite a long thread :-) It was a patch series after all. But as Greg puts it, be persistent. +config VT_PRINTK_COLOR + hex Colored kernel message output + range 0x00 0xFF + depends on VT_CKO + default 0x07 + ---help--- + This option defines with which color kernel messages will be + printed to the console. + + The value you need to enter here is the value is composed The more correct term for The value is probably The attribute. The value for this kconfig entry it should read in the minds. + (Foreground colors 0x08 to 0x0F do not work when a VGA + console font with 512 glyphs is used.) You might have to include a warning that those values or attributes are interpreted differently depending on the driver used, and the above is mostly true for 16-color console drivers only. Are there any other drivers besides vgacon and fbcon that use vt.c? All drivers under drivers/video/console. That would be: vgacon dummycon fbcon newport_con sticon promcon mdacon There are perhaps a few more drivers outside this directory, such as sisusbcon or something. snip You may want to leave out the blink attribute (0x80) from this part. Otherwise setterm -blink on|off will produce the opposite effect. But 0x80 might be interpreted in a different fashion for some othercon, yielding for example superbold rather than blinking. That's right. But setting the blink attribute is done with an XOR (^). So 'setterm -blink' on will unset the blink attribute (0x80 ^ 0x80). I'll have to try this, because usually, setterm operates on TTYs rather than VCs. Yes, but if the tty driver type is a virtual console, then vt.c is still affected. Well the blink attribute is ignored by most drivers, if I'm not mistaken. So you generally won't see the effect :-). But with fbcon, the blink attribute is interpreted as change background color from black to light gray. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sleepy linux 2.6.23-rc9
On Tue, 2007-10-09 at 00:05 +0200, Pavel Machek wrote: Hi! I played with powertop a bit, and found a fairly interesting failure mode. If I boot init=/bin/bash vga=1, I get ~2 wakeups a second, nice. When I boot init=/bin/bash vga=791 (vesa framebuffer), most wakeups are caused by cursor painting (I should fix that some day, I guess). But... the cursor blinking does not even work properly! It blinks at normal speed, then (randomly) it blinks slowly, then gets back to normal speed, then inserts longer delay. The effect is so nice that I thought about youtube ;-). Thinkpad x60.. question is, how to debug it? The cursor blinking is done by software via a timer. It's in drivers/video/console/fbcon.c. With the latest -rc kernel you can turn off the blinking with echo 0 /sys/class/graphics/fbcon/cursor_blink Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH 0/6] Patch series to add of_platform binding to xilinxfb
On Mon, 2007-10-08 at 22:43 -0600, Grant Likely wrote: On 10/2/07, Antonino A. Daplas [EMAIL PROTECTED] wrote: On Mon, 2007-10-01 at 09:57 -0600, Grant Likely wrote: Assuming there are no major issues, I'd like to get this patch series queued up for inclusion in 2.6.24. Okay. Tony BTW, what path do framebuffer patches take to get into Linus' tree? Does he pull your tree directly, or do they go through someone else's tree? They all go to -mm tree, unless it's a needed fix, then to Linus's. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH 0/6] Patch series to add of_platform binding to xilinxfb
On Mon, 2007-10-01 at 09:57 -0600, Grant Likely wrote: > (resend due to mailer issues. Apologies to anyone receiving this twice) > > This patch series reworks the Xilinx framebuffer driver and then adds > an of_platform bus binding. The of_platform bus binding is needed to use > the driver in arch/powerpc platforms. > > Antonino, > > Assuming there are no major issues, I'd like to get this patch series > queued up for inclusion in 2.6.24. Okay. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH 0/6] Patch series to add of_platform binding to xilinxfb
On Mon, 2007-10-01 at 09:57 -0600, Grant Likely wrote: (resend due to mailer issues. Apologies to anyone receiving this twice) This patch series reworks the Xilinx framebuffer driver and then adds an of_platform bus binding. The of_platform bus binding is needed to use the driver in arch/powerpc platforms. Antonino, Assuming there are no major issues, I'd like to get this patch series queued up for inclusion in 2.6.24. Okay. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make unicode default
On Sat, 2007-09-29 at 10:36 +0200, Jan Engelhardt wrote: > Make the vt return to the system default when it is reset. > Also make UTF-8 the system default. It's about time we do, so this is fine with me. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] make unicode default
On Sat, 2007-09-29 at 10:36 +0200, Jan Engelhardt wrote: Make the vt return to the system default when it is reset. Also make UTF-8 the system default. It's about time we do, so this is fine with me. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vga text console not working on 2.6.23-rc8
On Fri, 2007-09-28 at 22:03 +0200, Santiago Garcia Mantinan wrote:
> Hi!
>
> I have just compiled a 2.6.23-rc8 using the config from my 2.6.22 as a basis
> and I came out with a not working (almost black) vga text console.
>
> This is what I'm getting on my logs:
>
> Console: colour dummy device 80x25
> console [tty0] enabled
>
> Instead of the old:
>
> Console: colour VGA+ 80x25
>
> The options related to the console on my config are these:
>
> CONFIG_VT=y
> CONFIG_VT_CONSOLE=y
> CONFIG_HW_CONSOLE=y
> CONFIG_SERIAL_8250=y
> CONFIG_SERIAL_8250_CONSOLE=y
> CONFIG_SERIAL_CORE=y
> CONFIG_SERIAL_CORE_CONSOLE=y
> CONFIG_VGA_CONSOLE=y
> CONFIG_VIDEO_SELECT=y
> CONFIG_DUMMY_CONSOLE=y
>
> The machine is a AMD x64 X2 Athlon with a NForce 4 chipset, vga is a ATI
> radeon and I have also set:
>
> CONFIG_DRM=m
> CONFIG_DRM_RADEON=m
>
> I have tried with and without CONFIG_VIDEO_SELECT and
> CONFIG_VIDEO_OUTPUT_CONTROL with the same results. BTW: when X starts the
> display is Ok.
>
> If you want me to do any tests or need more info just tell me.
Also insert this in drivers/video/console/vgacon.c as the first
statement of vgacon_startup()
printk("vgacon: ORIG_VIDEO_ISVGA %x ORIG_VIDEO_MODE %x ORIG_VIDEO_LINES
%x ORIG_VIDEO_COLS %x\n", ORIG_VIDEO_ISVGA, ORIG_VIDEO_MODE,
ORIG_VIDEO_LINES, ORIG_VIDEO_COLS);
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] video gfx: merge kconfig menus
On Mon, 2007-09-24 at 23:25 -0700, Randy Dunlap wrote: > Is there some reason that we don't put all video gfx config in one > place? Is the split just historical, based on subdirectory locations, > or is there a bigger reason for it? Just historical, based on subdirectory locations. Someone did attempt to move the drm subdirectory under the video subdirectory during the 2.5 era but it was rejected. Anyway, I'm fine with this too. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] [VIDEO FRAMEBUFFER] Blackfin BF54x framebuffer device driver for a SHARP LQ043T1DG01 TFT LCD
On Wed, 2007-09-26 at 11:43 +0800, Bryan Wu wrote: > From: Michael Hennerich <[EMAIL PROTECTED]> > Date: Wed, 26 Sep 2007 11:33:01 +0800 > Subject: [PATCH 2/2] [VIDEO FRAMEBUFFER] Blackfin BF54x framebuffer device > driver for a SHARP LQ043T1DG01 TFT LCD > > Signed-off-by: Michael Hennerich <[EMAIL PROTECTED]> > Signed-off-by: Bryan Wu <[EMAIL PROTECTED]> > --- > drivers/video/Kconfig |9 + > drivers/video/Makefile|1 + > drivers/video/bf54x-lq043.c | 786 > + > include/asm-blackfin/mach-bf548/bf54x-lq043.h | 30 + > 4 files changed, 826 insertions(+), 0 deletions(-) > create mode 100644 drivers/video/bf54x-lq043.c > create mode 100644 include/asm-blackfin/mach-bf548/bf54x-lq043.h > > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig > index 5216c11..41fae00 100644 > --- a/drivers/video/Kconfig > +++ b/drivers/video/Kconfig > @@ -535,6 +535,15 @@ config FB_VGA16 > To compile this driver as a module, choose M here: the > module will be called vga16fb. > > +config FB_BF54X_LQ043 > + tristate "SHARP LQ043 TFT LCD (BF548 EZKIT)" > + depends on FB && (BF54x) > + select FB_CFB_FILLRECT > + select FB_CFB_COPYAREA > + select FB_CFB_IMAGEBLIT > + help > + This is the framebuffer device driver for a SHARP LQ043T1DG01 TFT LCD > + > config FB_STI > tristate "HP STI frame buffer device support" > depends on FB && PARISC > diff --git a/drivers/video/Makefile b/drivers/video/Makefile > index 06eec7b..359e560 100644 > --- a/drivers/video/Makefile > +++ b/drivers/video/Makefile > @@ -122,6 +122,7 @@ obj-$(CONFIG_FB_OF) += offb.o > > # the test framebuffer is last > obj-$(CONFIG_FB_VIRTUAL) += vfb.o > +obj-$(CONFIG_FB_BF54X_LQ043) += bf54x-lq043.o It's standard that we suffix all framebuffer drivers with an 'fb'. I'm making it so in my tree. Also, you shouldn't place your driver after vfb, that's why there's a comment that the test framebuffer is last. If someone accidentally enables vfb, he/she will get a blank screen. So I'm moving it under the platform driver section. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] [VIDEO FRAMEBUFFER] Blackfin BF54x framebuffer device driver for a SHARP LQ043T1DG01 TFT LCD
On Wed, 2007-09-26 at 11:43 +0800, Bryan Wu wrote: From: Michael Hennerich [EMAIL PROTECTED] Date: Wed, 26 Sep 2007 11:33:01 +0800 Subject: [PATCH 2/2] [VIDEO FRAMEBUFFER] Blackfin BF54x framebuffer device driver for a SHARP LQ043T1DG01 TFT LCD Signed-off-by: Michael Hennerich [EMAIL PROTECTED] Signed-off-by: Bryan Wu [EMAIL PROTECTED] --- drivers/video/Kconfig |9 + drivers/video/Makefile|1 + drivers/video/bf54x-lq043.c | 786 + include/asm-blackfin/mach-bf548/bf54x-lq043.h | 30 + 4 files changed, 826 insertions(+), 0 deletions(-) create mode 100644 drivers/video/bf54x-lq043.c create mode 100644 include/asm-blackfin/mach-bf548/bf54x-lq043.h diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 5216c11..41fae00 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -535,6 +535,15 @@ config FB_VGA16 To compile this driver as a module, choose M here: the module will be called vga16fb. +config FB_BF54X_LQ043 + tristate SHARP LQ043 TFT LCD (BF548 EZKIT) + depends on FB (BF54x) + select FB_CFB_FILLRECT + select FB_CFB_COPYAREA + select FB_CFB_IMAGEBLIT + help + This is the framebuffer device driver for a SHARP LQ043T1DG01 TFT LCD + config FB_STI tristate HP STI frame buffer device support depends on FB PARISC diff --git a/drivers/video/Makefile b/drivers/video/Makefile index 06eec7b..359e560 100644 --- a/drivers/video/Makefile +++ b/drivers/video/Makefile @@ -122,6 +122,7 @@ obj-$(CONFIG_FB_OF) += offb.o # the test framebuffer is last obj-$(CONFIG_FB_VIRTUAL) += vfb.o +obj-$(CONFIG_FB_BF54X_LQ043) += bf54x-lq043.o It's standard that we suffix all framebuffer drivers with an 'fb'. I'm making it so in my tree. Also, you shouldn't place your driver after vfb, that's why there's a comment that the test framebuffer is last. If someone accidentally enables vfb, he/she will get a blank screen. So I'm moving it under the platform driver section. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] video gfx: merge kconfig menus
On Mon, 2007-09-24 at 23:25 -0700, Randy Dunlap wrote: Is there some reason that we don't put all video gfx config in one place? Is the split just historical, based on subdirectory locations, or is there a bigger reason for it? Just historical, based on subdirectory locations. Someone did attempt to move the drm subdirectory under the video subdirectory during the 2.5 era but it was rejected. Anyway, I'm fine with this too. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: vga text console not working on 2.6.23-rc8
On Fri, 2007-09-28 at 22:03 +0200, Santiago Garcia Mantinan wrote: Hi! I have just compiled a 2.6.23-rc8 using the config from my 2.6.22 as a basis and I came out with a not working (almost black) vga text console. This is what I'm getting on my logs: Console: colour dummy device 80x25 console [tty0] enabled Instead of the old: Console: colour VGA+ 80x25 The options related to the console on my config are these: CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y CONFIG_VGA_CONSOLE=y CONFIG_VIDEO_SELECT=y CONFIG_DUMMY_CONSOLE=y The machine is a AMD x64 X2 Athlon with a NForce 4 chipset, vga is a ATI radeon and I have also set: CONFIG_DRM=m CONFIG_DRM_RADEON=m I have tried with and without CONFIG_VIDEO_SELECT and CONFIG_VIDEO_OUTPUT_CONTROL with the same results. BTW: when X starts the display is Ok. If you want me to do any tests or need more info just tell me. Also insert this in drivers/video/console/vgacon.c as the first statement of vgacon_startup() printk(vgacon: ORIG_VIDEO_ISVGA %x ORIG_VIDEO_MODE %x ORIG_VIDEO_LINES %x ORIG_VIDEO_COLS %x\n, ORIG_VIDEO_ISVGA, ORIG_VIDEO_MODE, ORIG_VIDEO_LINES, ORIG_VIDEO_COLS); Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VGA text console display problem with kernel 2.6.23-rc5/6
On Thu, 2007-09-20 at 02:26 -0400, ben soo wrote: > Antonino A. Daplas wrote: > > On Tue, 2007-09-18 at 03:26 -0400, ben soo wrote: > >> i've 2 servers with old PCI VGA cards, one using X86_64 kernel > >> version 2.6.23-rc5 and one with i386 kernel version 2.6.23-rc6, > >> both wired into the same CRT via a KVM switch. > > > > Is this new? If yes, what's the version of the last working kernel? > > Hi Antonio; i'm very sorry about the delay in answering: been > pretty ill. > That's okay. > i had upgraded all four servers here to 2.6.23-rc6 and found that > only one had this console problem. It runs a very old S3 Virge > PCI vidcard. > > Tonight i upgraded it to 2.6.23-rc7 and the console is fine again, > but, just to be complete i include the requested info: > > > Can you post dmesg and output of stty -a? > > stty -a > > speed 38400 baud; rows 34; columns 80; line = 0; Yes, you have an 80x34 screen (normal VGA is 80x25). I have received several reports about this problem (if the kernel boots with an initial screen which is not 80x25 and the init scripts attempts to set an 8x16 font, the user gets a display that does not fit the screen). Your problem though is probably unrelated. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VGA text console display problem with kernel 2.6.23-rc5/6
On Thu, 2007-09-20 at 02:26 -0400, ben soo wrote: Antonino A. Daplas wrote: On Tue, 2007-09-18 at 03:26 -0400, ben soo wrote: i've 2 servers with old PCI VGA cards, one using X86_64 kernel version 2.6.23-rc5 and one with i386 kernel version 2.6.23-rc6, both wired into the same CRT via a KVM switch. Is this new? If yes, what's the version of the last working kernel? Hi Antonio; i'm very sorry about the delay in answering: been pretty ill. That's okay. i had upgraded all four servers here to 2.6.23-rc6 and found that only one had this console problem. It runs a very old S3 Virge PCI vidcard. Tonight i upgraded it to 2.6.23-rc7 and the console is fine again, but, just to be complete i include the requested info: Can you post dmesg and output of stty -a? stty -a speed 38400 baud; rows 34; columns 80; line = 0; Yes, you have an 80x34 screen (normal VGA is 80x25). I have received several reports about this problem (if the kernel boots with an initial screen which is not 80x25 and the init scripts attempts to set an 8x16 font, the user gets a display that does not fit the screen). Your problem though is probably unrelated. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VGA text console display problem with kernel 2.6.23-rc5/6
On Tue, 2007-09-18 at 03:26 -0400, ben soo wrote: > i've 2 servers with old PCI VGA cards, one using X86_64 kernel > version 2.6.23-rc5 and one with i386 kernel version 2.6.23-rc6, > both wired into the same CRT via a KVM switch. Is this new? If yes, what's the version of the last working kernel? > > No matter what text screen size i set on both these machines (using > resizecons) the shell line where i type in commands is past the > bottom of the screen, invisible. > > Another box connected to the same KVM displays fine, and it runs > 2.6.22-rc7. > > i also have a box running kernel 2.6.23-rc5 where the console > display is fine: it uses a GeForce 8500 PCI-E vidcard driving a LCD > screen. Can you post dmesg and output of stty -a? Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VGA text console display problem with kernel 2.6.23-rc5/6
On Tue, 2007-09-18 at 03:26 -0400, ben soo wrote: i've 2 servers with old PCI VGA cards, one using X86_64 kernel version 2.6.23-rc5 and one with i386 kernel version 2.6.23-rc6, both wired into the same CRT via a KVM switch. Is this new? If yes, what's the version of the last working kernel? No matter what text screen size i set on both these machines (using resizecons) the shell line where i type in commands is past the bottom of the screen, invisible. Another box connected to the same KVM displays fine, and it runs 2.6.22-rc7. i also have a box running kernel 2.6.23-rc5 where the console display is fine: it uses a GeForce 8500 PCI-E vidcard driving a LCD screen. Can you post dmesg and output of stty -a? Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH] fbdev: find mode with highest refresh rate in fb_find_mode()
On Sun, 2007-08-26 at 21:09 +0200, Michal Januszewski wrote:
> On Wed, Jul 18, 2007 at 11:18:15PM +0800, Antonino A. Daplas wrote:
>
> How about modifying it so that it looks for a mode with the highest
> refresh rate if either a non-generic modedb is used or
> info.monspecs.{vfmin,vfmax,hfmin,hfmax,dclkmax} are all non-zero,
> and for a mode with refresh rate closest to 60 Hz otherwise?
I would opt for combining the two, return the highest refresh rate only
if the modedb was built by the driver and with the mode checked against
the display's operating limits.
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH] fbdev: find mode with highest refresh rate in fb_find_mode()
On Sun, 2007-08-26 at 21:09 +0200, Michal Januszewski wrote:
On Wed, Jul 18, 2007 at 11:18:15PM +0800, Antonino A. Daplas wrote:
How about modifying it so that it looks for a mode with the highest
refresh rate if either a non-generic modedb is used or
info.monspecs.{vfmin,vfmax,hfmin,hfmax,dclkmax} are all non-zero,
and for a mode with refresh rate closest to 60 Hz otherwise?
I would opt for combining the two, return the highest refresh rate only
if the modedb was built by the driver and with the mode checked against
the display's operating limits.
Tony
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Bad addresses in MAINTAINERS
On Mon, 2007-08-13 at 12:07 -0700, Joe Perches wrote: > > INTEL FRAMEBUFFER DRIVER (excluding 810 and 815) > P:Sylvain Meyer > M:[EMAIL PROTECTED] > Maybe Dave? > IMS TWINTURBO FRAMEBUFFER DRIVER > P:Paul Mundt > M:[EMAIL PROTECTED] That's not Paul's current email. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Bad addresses in MAINTAINERS
On Mon, 2007-08-13 at 12:07 -0700, Joe Perches wrote: INTEL FRAMEBUFFER DRIVER (excluding 810 and 815) P:Sylvain Meyer M:[EMAIL PROTECTED] Maybe Dave? IMS TWINTURBO FRAMEBUFFER DRIVER P:Paul Mundt M:[EMAIL PROTECTED] That's not Paul's current email. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23-rc2
On Sun, 2007-08-05 at 20:11 +0800, Jeff Chua wrote: > On 8/5/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote: > > Also, please submit your .config and kernel command line. > > # cat /proc/cmdline > > BOOT_IMAGE=(hd0,14)/linux/bzc1 root=/dev/sda2 resume=/dev/sda3 reboot=bios > > Can you try with the boot option acpi_sleep=s3_bios,s3_mode OR if using s2ram, use s2ram -f a3 Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23-rc2
On Sun, 2007-08-05 at 20:11 +0800, Jeff Chua wrote: On 8/5/07, H. Peter Anvin [EMAIL PROTECTED] wrote: Also, please submit your .config and kernel command line. # cat /proc/cmdline BOOT_IMAGE=(hd0,14)/linux/bzc1 root=/dev/sda2 resume=/dev/sda3 reboot=bios Can you try with the boot option acpi_sleep=s3_bios,s3_mode OR if using s2ram, use s2ram -f a3 Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23-rc2
On Sat, 2007-08-04 at 11:06 -0700, H. Peter Anvin wrote: > Linus Torvalds wrote: > > > > On Sat, 4 Aug 2007, Jeff Chua wrote: > >> On 8/4/07, Jeff Chua <[EMAIL PROTECTED]> wrote: > After resume from s2ram or switching to console from X, my console is > messed up on rc1 and rc2. Is there a fix for this? > >>> This is on IBM X60. i915 chipset. No problem on 2.6.22. If this is a > >>> known problem, than I don't need to bisect all over again. > >> I managed to bisect down to this commit. Without this, console screen > >> can resume without video mess. > > > > [ The commit being 4fd06960f120e02e9abc802a09f9511c400042a5: "Use the new > > x86 setup code for i386" ] > > > > Very interesting. > > > > Jeff - do I understand correctly that the "or" means that even *without* a > > suspend-to-ram sequence, and just by going into X and then going back to > > text-mode, the screen is corrupt? > > Also, can you please describe "messed up" in more detail? We had one > report of "screen messed up" already that did get fixed > (CONFIG_FIRMWARE_EDID not working.) I believe this is the case where VBE DDC reading is non-contributory. > > Are you using the VGA console or a framebuffer console? > > Also, please submit your .config and kernel command line. The dmesg output, the X logs and the s2ram options will also be useful. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.23-rc2
On Sat, 2007-08-04 at 11:06 -0700, H. Peter Anvin wrote: Linus Torvalds wrote: On Sat, 4 Aug 2007, Jeff Chua wrote: On 8/4/07, Jeff Chua [EMAIL PROTECTED] wrote: After resume from s2ram or switching to console from X, my console is messed up on rc1 and rc2. Is there a fix for this? This is on IBM X60. i915 chipset. No problem on 2.6.22. If this is a known problem, than I don't need to bisect all over again. I managed to bisect down to this commit. Without this, console screen can resume without video mess. [ The commit being 4fd06960f120e02e9abc802a09f9511c400042a5: Use the new x86 setup code for i386 ] Very interesting. Jeff - do I understand correctly that the or means that even *without* a suspend-to-ram sequence, and just by going into X and then going back to text-mode, the screen is corrupt? Also, can you please describe messed up in more detail? We had one report of screen messed up already that did get fixed (CONFIG_FIRMWARE_EDID not working.) I believe this is the case where VBE DDC reading is non-contributory. Are you using the VGA console or a framebuffer console? Also, please submit your .config and kernel command line. The dmesg output, the X logs and the s2ram options will also be useful. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] retrieve VBE EDID/DDC info independent of used video mode
On Thu, 2007-08-02 at 22:33 -0400, Daniel Drake wrote:
> Antonino A. Daplas wrote:
> > How about this patch?
> >
> > Tony
> > ---
> >
> > Subject: video setup: Fix VBE DDC reading
> >
> > Add memory operand constraint and write-only modifier to the inline
> > assembly to effect the writing of the EDID block to boot_params.edid_info.
>
>
> Thanks, this patch works in that Linux now reports the correct resolution.
>
> However, the TV output is now scrambled...
The previous problem was just a display shift of 6 pixels, correct? If
the display is now scrambled, then this is a new problem.
> I suspect this might be a result of adding CONFIG_FRAMEBUFFER_CONSOLE in
> the most recent tests.
It's useless to unset CONFIG_FRAMEBUFFER_CONSOLE to 'n', he'll just end
up with a 640x400 stretched or windowed display.
Can he...
1. describe what 'scrambled' means?
2. Boot with video=intelfb:accel=0,?
3. post the output of 'fbset -i' and the latest dmesg?
4. change the color depth ('fbset -depth 16')?
5. If possible, run X using 'fbdev' as the driver at 16 bpp
(I don't think 32 bpp works with X-fbdev)?
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] retrieve VBE EDID/DDC info independent of used video mode
H. Peter Anvin wrote: > Antonino A. Daplas wrote: >> On Wed, 2007-08-01 at 09:54 +0800, Antonino A. Daplas wrote: >>> On Tue, 2007-07-31 at 21:17 -0400, Daniel Drake wrote: >>>> Zwane Mwaikambo wrote: >>>>> Sorry if this has been hashed out before, but could you point me >>>>> towards the gentoo bugzilla entry? I'm trying to understand how >>>>> your setup broke. Which version VBE does your system have? >>>> Here's the bug: >>>> http://bugs.gentoo.org/show_bug.cgi?id=181067 >>>> >>> Looking at the dmesg output of the working and failing kernel, it does >>> seem that there's no EDID block available in the failing kernel. >>> >> >> BTW, I looked at the above bug report, it seems his last dmesg does not >> have fbcon enabled. Make sure that CONFIG_FRAMEBUFFER_CONSOLE=y before >> doing more tests (the problem of lack of the EDID block in the failing >> kernel still applies). >> > > Okay, I'm royally puzzled why that would be. I've gone over the code > quite a few times, and I do not see any way (other than VESA < 2.0) that > could cause that. > > I look forward to getting the debug output; depending on what it is we > might have to get some debugging output from the setup code. > > We can printf in the new setup code, although obviously that requires > leaving the screen in text mode. However, EDID information should still > be available. > How about this patch? Tony --- Subject: video setup: Fix VBE DDC reading Add memory operand constraint and write-only modifier to the inline assembly to effect the writing of the EDID block to boot_params.edid_info. Signed-off-by: Antonino Daplas <[EMAIL PROTECTED]> --- arch/i386/boot/video-vesa.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/i386/boot/video-vesa.c b/arch/i386/boot/video-vesa.c index e6aa9eb..f1bc71e 100644 --- a/arch/i386/boot/video-vesa.c +++ b/arch/i386/boot/video-vesa.c @@ -268,7 +268,7 @@ #ifdef CONFIG_FIRMWARE_EDID dx = 0; /* EDID block number */ di =(size_t) _params.edid_info; /* (ES:)Pointer to block */ asm(INT10 - : "+a" (ax), "+b" (bx), "+d" (dx) + : "+a" (ax), "+b" (bx), "+d" (dx), "=m" (boot_params.edid_info) : "c" (cx), "D" (di) : "esi"); #endif /* CONFIG_FIRMWARE_EDID */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] retrieve VBE EDID/DDC info independent of used video mode
H. Peter Anvin wrote: Antonino A. Daplas wrote: On Wed, 2007-08-01 at 09:54 +0800, Antonino A. Daplas wrote: On Tue, 2007-07-31 at 21:17 -0400, Daniel Drake wrote: Zwane Mwaikambo wrote: Sorry if this has been hashed out before, but could you point me towards the gentoo bugzilla entry? I'm trying to understand how your setup broke. Which version VBE does your system have? Here's the bug: http://bugs.gentoo.org/show_bug.cgi?id=181067 Looking at the dmesg output of the working and failing kernel, it does seem that there's no EDID block available in the failing kernel. BTW, I looked at the above bug report, it seems his last dmesg does not have fbcon enabled. Make sure that CONFIG_FRAMEBUFFER_CONSOLE=y before doing more tests (the problem of lack of the EDID block in the failing kernel still applies). Okay, I'm royally puzzled why that would be. I've gone over the code quite a few times, and I do not see any way (other than VESA 2.0) that could cause that. I look forward to getting the debug output; depending on what it is we might have to get some debugging output from the setup code. We can printf in the new setup code, although obviously that requires leaving the screen in text mode. However, EDID information should still be available. How about this patch? Tony --- Subject: video setup: Fix VBE DDC reading Add memory operand constraint and write-only modifier to the inline assembly to effect the writing of the EDID block to boot_params.edid_info. Signed-off-by: Antonino Daplas [EMAIL PROTECTED] --- arch/i386/boot/video-vesa.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/i386/boot/video-vesa.c b/arch/i386/boot/video-vesa.c index e6aa9eb..f1bc71e 100644 --- a/arch/i386/boot/video-vesa.c +++ b/arch/i386/boot/video-vesa.c @@ -268,7 +268,7 @@ #ifdef CONFIG_FIRMWARE_EDID dx = 0; /* EDID block number */ di =(size_t) boot_params.edid_info; /* (ES:)Pointer to block */ asm(INT10 - : +a (ax), +b (bx), +d (dx) + : +a (ax), +b (bx), +d (dx), =m (boot_params.edid_info) : c (cx), D (di) : esi); #endif /* CONFIG_FIRMWARE_EDID */ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] retrieve VBE EDID/DDC info independent of used video mode
On Thu, 2007-08-02 at 22:33 -0400, Daniel Drake wrote:
Antonino A. Daplas wrote:
How about this patch?
Tony
---
Subject: video setup: Fix VBE DDC reading
Add memory operand constraint and write-only modifier to the inline
assembly to effect the writing of the EDID block to boot_params.edid_info.
Thanks, this patch works in that Linux now reports the correct resolution.
However, the TV output is now scrambled...
The previous problem was just a display shift of 6 pixels, correct? If
the display is now scrambled, then this is a new problem.
I suspect this might be a result of adding CONFIG_FRAMEBUFFER_CONSOLE in
the most recent tests.
It's useless to unset CONFIG_FRAMEBUFFER_CONSOLE to 'n', he'll just end
up with a 640x400 stretched or windowed display.
Can he...
1. describe what 'scrambled' means?
2. Boot with video=intelfb:accel=0,old options?
3. post the output of 'fbset -i' and the latest dmesg?
4. change the color depth ('fbset -depth 16')?
5. If possible, run X using 'fbdev' as the driver at 16 bpp
(I don't think 32 bpp works with X-fbdev)?
Tony
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] retrieve VBE EDID/DDC info independent of used video mode
On Wed, 2007-08-01 at 09:54 +0800, Antonino A. Daplas wrote: > On Tue, 2007-07-31 at 21:17 -0400, Daniel Drake wrote: > > Zwane Mwaikambo wrote: > > > Sorry if this has been hashed out before, but could you point me towards > > > the gentoo bugzilla entry? I'm trying to understand how your setup broke. > > > Which version VBE does your system have? > > > > Here's the bug: > > http://bugs.gentoo.org/show_bug.cgi?id=181067 > > > > Looking at the dmesg output of the working and failing kernel, it does > seem that there's no EDID block available in the failing kernel. > BTW, I looked at the above bug report, it seems his last dmesg does not have fbcon enabled. Make sure that CONFIG_FRAMEBUFFER_CONSOLE=y before doing more tests (the problem of lack of the EDID block in the failing kernel still applies). Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] retrieve VBE EDID/DDC info independent of used video mode
On Wed, 2007-08-01 at 09:54 +0800, Antonino A. Daplas wrote: On Tue, 2007-07-31 at 21:17 -0400, Daniel Drake wrote: Zwane Mwaikambo wrote: Sorry if this has been hashed out before, but could you point me towards the gentoo bugzilla entry? I'm trying to understand how your setup broke. Which version VBE does your system have? Here's the bug: http://bugs.gentoo.org/show_bug.cgi?id=181067 Looking at the dmesg output of the working and failing kernel, it does seem that there's no EDID block available in the failing kernel. BTW, I looked at the above bug report, it seems his last dmesg does not have fbcon enabled. Make sure that CONFIG_FRAMEBUFFER_CONSOLE=y before doing more tests (the problem of lack of the EDID block in the failing kernel still applies). Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] x86_64 EFI support -v3: EFI framebuffer driver
On Tue, 2007-07-31 at 11:13 +0800, Huang, Ying wrote: > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > + I don't see any problems with this driver, just a few minor nits. Do you really need all the #include's? I presume this driver only supports bpp 16 and above? Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] retrieve VBE EDID/DDC info independent of used video mode
On Tue, 2007-07-31 at 21:17 -0400, Daniel Drake wrote: > Zwane Mwaikambo wrote: > > Sorry if this has been hashed out before, but could you point me towards > > the gentoo bugzilla entry? I'm trying to understand how your setup broke. > > Which version VBE does your system have? > > Here's the bug: > http://bugs.gentoo.org/show_bug.cgi?id=181067 > Looking at the dmesg output of the working and failing kernel, it does seem that there's no EDID block available in the failing kernel. > How can we identify the VBE version? If vesafb works, then it is at least VBE 2.0. To confirm, you can use X + the 'vesa' driver and check /var/log/X*.log. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] retrieve VBE EDID/DDC info independent of used video mode
On Tue, 2007-07-31 at 19:58 -0400, Daniel Drake wrote: > Hi, > > H. Peter Anvin wrote: > >> So, 2.6.22-rc6-mm1 should work fine with CONFIG_FIRMWARE_EDID=y, or are > >> further patches needed? > >> > > > > It should, yes. > > It didn't work, and the bug still exists in 2.6.23-rc1: the resolution > is wrong by 6 pixels. The user does have CONFIG_FIRMWARE_EDID enabled. > > So far the only known working setups since 2.6.20.11 are: > 1. Zwane's patch reverted > 2. Jan's patch applied (to 2.6.22 or lower, I guess it no longer works > for 2.6.23) > > Here is dmesg output from 2.6.23: > http://bugs.gentoo.org/attachment.cgi?id=126203=view > The dmesg ouput did show that intelfb was not able to acquire the EDID from the BIOS, even if CONFIG_FIRMWARE_EDID=y I presume. I don't think it's the VBE version, the chipset is an Intel 830 which should at least be a VBE 2.0. Is it the same for the working kernel? Do you have a link to the dmesg ouput of a working kernel, if possible with #define DEBUG in drivers/video/fbmon.c. The output of read-edid or /var/log/X?.log will also be helpful. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] retrieve VBE EDID/DDC info independent of used video mode
On Tue, 2007-07-31 at 19:58 -0400, Daniel Drake wrote: Hi, H. Peter Anvin wrote: So, 2.6.22-rc6-mm1 should work fine with CONFIG_FIRMWARE_EDID=y, or are further patches needed? It should, yes. It didn't work, and the bug still exists in 2.6.23-rc1: the resolution is wrong by 6 pixels. The user does have CONFIG_FIRMWARE_EDID enabled. So far the only known working setups since 2.6.20.11 are: 1. Zwane's patch reverted 2. Jan's patch applied (to 2.6.22 or lower, I guess it no longer works for 2.6.23) Here is dmesg output from 2.6.23: http://bugs.gentoo.org/attachment.cgi?id=126203action=view The dmesg ouput did show that intelfb was not able to acquire the EDID from the BIOS, even if CONFIG_FIRMWARE_EDID=y I presume. I don't think it's the VBE version, the chipset is an Intel 830 which should at least be a VBE 2.0. Is it the same for the working kernel? Do you have a link to the dmesg ouput of a working kernel, if possible with #define DEBUG in drivers/video/fbmon.c. The output of read-edid or /var/log/X?.log will also be helpful. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] retrieve VBE EDID/DDC info independent of used video mode
On Tue, 2007-07-31 at 21:17 -0400, Daniel Drake wrote: Zwane Mwaikambo wrote: Sorry if this has been hashed out before, but could you point me towards the gentoo bugzilla entry? I'm trying to understand how your setup broke. Which version VBE does your system have? Here's the bug: http://bugs.gentoo.org/show_bug.cgi?id=181067 Looking at the dmesg output of the working and failing kernel, it does seem that there's no EDID block available in the failing kernel. How can we identify the VBE version? If vesafb works, then it is at least VBE 2.0. To confirm, you can use X + the 'vesa' driver and check /var/log/X*.log. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] x86_64 EFI support -v3: EFI framebuffer driver
On Tue, 2007-07-31 at 11:13 +0800, Huang, Ying wrote: + +#include linux/delay.h +#include linux/errno.h +#include linux/fb.h +#include linux/kernel.h +#include linux/init.h +#include linux/ioport.h +#include linux/mm.h +#include linux/module.h +#include linux/platform_device.h +#include linux/screen_info.h +#include linux/slab.h +#include linux/string.h +#include linux/dmi.h +#include linux/efi.h +#include linux/io.h + +#include video/vga.h + I don't see any problems with this driver, just a few minor nits. Do you really need all the #include's? I presume this driver only supports bpp 16 and above? Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Framebuffer: Consolidated cleanup of pvr2fb.c for Sega Dreamcast
On Tue, 2007-07-31 at 04:48 +0900, Paul Mundt wrote: > On Sun, Jul 29, 2007 at 01:39:51AM +0100, Adrian McMenamin wrote: > This looks fine to me in any event. I can either wrap this up in my tree > or Tony can include it with his next set of updates if he has any other > concerns. Thanks, Adrian. > > Acked-by: Paul Mundt <[EMAIL PROTECTED]> I'll do the merge and push to mainline. This patch is really composed of three changes (one is already in mainline, the second is a resource allocation clean-up, and the third is Adrian's change). Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Framebuffer: Consolidated cleanup of pvr2fb.c for Sega Dreamcast
On Tue, 2007-07-31 at 04:48 +0900, Paul Mundt wrote: On Sun, Jul 29, 2007 at 01:39:51AM +0100, Adrian McMenamin wrote: This looks fine to me in any event. I can either wrap this up in my tree or Tony can include it with his next set of updates if he has any other concerns. Thanks, Adrian. Acked-by: Paul Mundt [EMAIL PROTECTED] I'll do the merge and push to mainline. This patch is really composed of three changes (one is already in mainline, the second is a resource allocation clean-up, and the third is Adrian's change). Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with framebuffer in 2.6.22-git17
On Sat, 2007-07-28 at 10:14 +0800, Antonino A. Daplas wrote: > On Sat, 2007-07-28 at 02:06 +0100, Adrian McMenamin wrote: > > On 28/07/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote: > > > > > > tmp = transp << var->transp.offset | red << var->red.offset | > green << var->green.offset | blue << var->green.offset; > The above should be: tmp = regno << var->transp.offset | regno << var->red.offset | regno << var->green.offset | regno << var->green.offset; Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with framebuffer in 2.6.22-git17
On Sat, 2007-07-28 at 02:06 +0100, Adrian McMenamin wrote: > On 28/07/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote: > > > > But certainly better at 16bpp > > Can mess about with it later to see if I can get the colours right I suppose. > You can start with pvr2fb_setcolreg() and pvr2fb_set_pal_entry(). A few things I've noticed: 1. In pvr2fb_setcolreg(), pvr2fb_set_pal_entry() is called for bpp 16 and 32. This means that the palette is modifiable, so FB_VISUAL_TRUECOLOR is probably not the correct visual for this driver, FB_VISUAL_DIRECTCOLOR is more appropriate. So, you either remove the call to set_pal_entry() in setcolreg() or change the visual to FB_VISUAL_DIRECTCOLOR. Of course, with directcolor, the pseudo_palette is now written with tmp as: tmp = transp << var->transp.offset | red << var->red.offset | green << var->green.offset | blue << var->green.offset; 2. Perhaps, the 3rd parameter passed to set_pal_entry() is not correct? Maybe you can try doing it like this for all bpp's, assuming ARGB? pvr2fb_set_pal_entry(par, regno, transp << 24 | red << 16 | green << 8 | blue); And if you want to maintain FB_VISUAL_TRUECOLOR format, initialize the palette once on init: for (i = 0; i < 256; i++) pvr2fb_set_pal_entry(par, i, i << 24 | i << 16 | i << 8 | i); to create a linear color map consistent with truecolor, then remove all other calls to pvr2fb_set_pal_entry(). Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with framebuffer in 2.6.22-git17
On Sat, 2007-07-28 at 01:32 +0100, Adrian McMenamin wrote: > On 28/07/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote: > > On Fri, 2007-07-27 at 23:25 +0100, Adrian McMenamin wrote: > > > On 27/07/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote: > > > > On Fri, 2007-07-27 at 21:18 +0100, Adrian McMenamin wrote: > > > > > On 27/07/07, Adrian McMenamin <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > With the patch reverted and 24bpp, it oopses before freezing (with > > > > > > two > > > > > > odd looking boot logos on the screen): > > > > > > > > > > > Tested this further and it fails on: > > > > > > > > > > rev = fb_readl(par->mmio_base + 0x04); > > > > > > > > Doubtful if this line is the point of failure, this line is executed > > > > only once, on initialization. > > > > > > > > > par->mmio_base is corrupted in some way during the call to > > > register_framebuffer - still investigating how/why. > > > > Possible, par->mmio_base is the last field in struct pvr2fb_par, > > after that is the pseudo_palette. The oops did not manifest when the > > pseudo_palette was written as u16, but oops'ed when written as u32. > > Memory alignment problems? > > > > Try the patch I posted before, might help. > > > Apologies, missed the patch before. > > With the patch applied the Dreamcast no longer crashes or locks with > either 16, 24 or 32 bpp, so that's good. > > With 24bpp everything is doubled up (eg two boot logos on screen) and > about twice (?) the size it should be - though with a black screen. > > With 32 bpp everything is about 4 (?) times the size it should be and > all on a yellow background. > > With 16bpp then everything is on a blue background as before, but is > also the correct size (as before). Is this with commit a66ad56eb2c9644717da4d7f05f971d6786145e3 reverted? Reapply this commit again, it might (fingers crossed) correct the color problem. As to your display doubling/quadrupling with bpp 24/32, I don't have any answers (no hardware) though it seems to be a framebuffer pitch/display width mismatch. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with framebuffer in 2.6.22-git17
On Fri, 2007-07-27 at 23:25 +0100, Adrian McMenamin wrote: > On 27/07/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote: > > On Fri, 2007-07-27 at 21:18 +0100, Adrian McMenamin wrote: > > > On 27/07/07, Adrian McMenamin <[EMAIL PROTECTED]> wrote: > > > > > > > With the patch reverted and 24bpp, it oopses before freezing (with two > > > > odd looking boot logos on the screen): > > > > > > > Tested this further and it fails on: > > > > > > rev = fb_readl(par->mmio_base + 0x04); > > > > Doubtful if this line is the point of failure, this line is executed > > only once, on initialization. > > > par->mmio_base is corrupted in some way during the call to > register_framebuffer - still investigating how/why. Possible, par->mmio_base is the last field in struct pvr2fb_par, after that is the pseudo_palette. The oops did not manifest when the pseudo_palette was written as u16, but oops'ed when written as u32. Memory alignment problems? Try the patch I posted before, might help. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with framebuffer in 2.6.22-git17
On Fri, 2007-07-27 at 20:47 +0100, Adrian McMenamin wrote:
> On 26/07/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
>
> >
> > I'm also confused. Can you change the color depth to 32 bpp ('fbset
> > -depth 32')? I'm thinking of a possible pseudo_palette overrun.
> >
>
> The code behaves in exactly the same way with the bit depth set to 32
> and without the patch reversion (ie forces a reboot).
>
> With the parch reverted there is a flicker of output on the screen
> before a reboot is forced (it will boot with 16bpp though the colour
> is a bit iffy)
>
> With the patch reverted and 24bpp, it oopses before freezing (with two
> odd looking boot logos on the screen):
Can you try the attached patch? It's just a clean-up patch: uses
framebuffer_alloc/release instead of kmalloc.
Tony
diff --git a/drivers/video/pvr2fb.c b/drivers/video/pvr2fb.c
index f930026..a72921b 100644
--- a/drivers/video/pvr2fb.c
+++ b/drivers/video/pvr2fb.c
@@ -143,6 +143,7 @@ static struct pvr2fb_par {
unsigned char is_lowres; /* Is horizontal pixel-doubling enabled? */
unsigned long mmio_base; /* MMIO base */
+ u32 palette[16];
} *currentpar;
static struct fb_info *fb_info;
@@ -790,7 +791,7 @@ static int __devinit pvr2fb_common_init(
fb_info->fbops = _ops;
fb_info->fix = pvr2_fix;
fb_info->par = currentpar;
- fb_info->pseudo_palette = (void *)(fb_info->par + 1);
+ fb_info->pseudo_palette = currentpar->palette;
fb_info->flags = FBINFO_DEFAULT | FBINFO_HWACCEL_YPAN;
if (video_output == VO_VGA)
@@ -1082,14 +1083,15 @@ #ifndef MODULE
#endif
size = sizeof(struct fb_info) + sizeof(struct pvr2fb_par) + 16 * sizeof(u32);
- fb_info = kzalloc(size, GFP_KERNEL);
+ fb_info = framebuffer_alloc(sizeof(struct pvr2fb_par), NULL);
+
if (!fb_info) {
printk(KERN_ERR "Failed to allocate memory for fb_info\n");
return -ENOMEM;
}
- currentpar = (struct pvr2fb_par *)(fb_info + 1);
+ currentpar = fb_info->par;
for (i = 0; i < ARRAY_SIZE(board_driver); i++) {
struct pvr2_board *pvr_board = board_driver + i;
@@ -1102,7 +1104,7 @@ #endif
if (ret != 0) {
printk(KERN_ERR "pvr2fb: Failed init of %s device\n",
pvr_board->name);
- kfree(fb_info);
+ framebuffer_release(fb_info);
break;
}
}
@@ -1126,7 +1128,7 @@ #ifdef CONFIG_SH_STORE_QUEUES
#endif
unregister_framebuffer(fb_info);
- kfree(fb_info);
+ framebuffer_release(fb_info);
}
module_init(pvr2fb_init);
Re: Problems with framebuffer in 2.6.22-git17
On Fri, 2007-07-27 at 21:18 +0100, Adrian McMenamin wrote: > On 27/07/07, Adrian McMenamin <[EMAIL PROTECTED]> wrote: > > > With the patch reverted and 24bpp, it oopses before freezing (with two > > odd looking boot logos on the screen): > > > Tested this further and it fails on: > > rev = fb_readl(par->mmio_base + 0x04); Doubtful if this line is the point of failure, this line is executed only once, on initialization. > > Will try to see what's up - but if anyone knows what is likely to be > wrong here please shout out! I'm still thinking there's something wrong on how the resources are allocated causing a pseudo_palette overrun. I'll post a clean-up patch later. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with framebuffer in 2.6.22-git17
On Fri, 2007-07-27 at 21:18 +0100, Adrian McMenamin wrote: On 27/07/07, Adrian McMenamin [EMAIL PROTECTED] wrote: With the patch reverted and 24bpp, it oopses before freezing (with two odd looking boot logos on the screen): Tested this further and it fails on: rev = fb_readl(par-mmio_base + 0x04); Doubtful if this line is the point of failure, this line is executed only once, on initialization. Will try to see what's up - but if anyone knows what is likely to be wrong here please shout out! I'm still thinking there's something wrong on how the resources are allocated causing a pseudo_palette overrun. I'll post a clean-up patch later. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with framebuffer in 2.6.22-git17
On Fri, 2007-07-27 at 20:47 +0100, Adrian McMenamin wrote:
On 26/07/07, Antonino A. Daplas [EMAIL PROTECTED] wrote:
I'm also confused. Can you change the color depth to 32 bpp ('fbset
-depth 32')? I'm thinking of a possible pseudo_palette overrun.
The code behaves in exactly the same way with the bit depth set to 32
and without the patch reversion (ie forces a reboot).
With the parch reverted there is a flicker of output on the screen
before a reboot is forced (it will boot with 16bpp though the colour
is a bit iffy)
With the patch reverted and 24bpp, it oopses before freezing (with two
odd looking boot logos on the screen):
Can you try the attached patch? It's just a clean-up patch: uses
framebuffer_alloc/release instead of kmalloc.
Tony
diff --git a/drivers/video/pvr2fb.c b/drivers/video/pvr2fb.c
index f930026..a72921b 100644
--- a/drivers/video/pvr2fb.c
+++ b/drivers/video/pvr2fb.c
@@ -143,6 +143,7 @@ static struct pvr2fb_par {
unsigned char is_lowres; /* Is horizontal pixel-doubling enabled? */
unsigned long mmio_base; /* MMIO base */
+ u32 palette[16];
} *currentpar;
static struct fb_info *fb_info;
@@ -790,7 +791,7 @@ static int __devinit pvr2fb_common_init(
fb_info-fbops = pvr2fb_ops;
fb_info-fix = pvr2_fix;
fb_info-par = currentpar;
- fb_info-pseudo_palette = (void *)(fb_info-par + 1);
+ fb_info-pseudo_palette = currentpar-palette;
fb_info-flags = FBINFO_DEFAULT | FBINFO_HWACCEL_YPAN;
if (video_output == VO_VGA)
@@ -1082,14 +1083,15 @@ #ifndef MODULE
#endif
size = sizeof(struct fb_info) + sizeof(struct pvr2fb_par) + 16 * sizeof(u32);
- fb_info = kzalloc(size, GFP_KERNEL);
+ fb_info = framebuffer_alloc(sizeof(struct pvr2fb_par), NULL);
+
if (!fb_info) {
printk(KERN_ERR Failed to allocate memory for fb_info\n);
return -ENOMEM;
}
- currentpar = (struct pvr2fb_par *)(fb_info + 1);
+ currentpar = fb_info-par;
for (i = 0; i ARRAY_SIZE(board_driver); i++) {
struct pvr2_board *pvr_board = board_driver + i;
@@ -1102,7 +1104,7 @@ #endif
if (ret != 0) {
printk(KERN_ERR pvr2fb: Failed init of %s device\n,
pvr_board-name);
- kfree(fb_info);
+ framebuffer_release(fb_info);
break;
}
}
@@ -1126,7 +1128,7 @@ #ifdef CONFIG_SH_STORE_QUEUES
#endif
unregister_framebuffer(fb_info);
- kfree(fb_info);
+ framebuffer_release(fb_info);
}
module_init(pvr2fb_init);
Re: Problems with framebuffer in 2.6.22-git17
On Fri, 2007-07-27 at 23:25 +0100, Adrian McMenamin wrote: On 27/07/07, Antonino A. Daplas [EMAIL PROTECTED] wrote: On Fri, 2007-07-27 at 21:18 +0100, Adrian McMenamin wrote: On 27/07/07, Adrian McMenamin [EMAIL PROTECTED] wrote: With the patch reverted and 24bpp, it oopses before freezing (with two odd looking boot logos on the screen): Tested this further and it fails on: rev = fb_readl(par-mmio_base + 0x04); Doubtful if this line is the point of failure, this line is executed only once, on initialization. par-mmio_base is corrupted in some way during the call to register_framebuffer - still investigating how/why. Possible, par-mmio_base is the last field in struct pvr2fb_par, after that is the pseudo_palette. The oops did not manifest when the pseudo_palette was written as u16, but oops'ed when written as u32. Memory alignment problems? Try the patch I posted before, might help. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with framebuffer in 2.6.22-git17
On Sat, 2007-07-28 at 01:32 +0100, Adrian McMenamin wrote: On 28/07/07, Antonino A. Daplas [EMAIL PROTECTED] wrote: On Fri, 2007-07-27 at 23:25 +0100, Adrian McMenamin wrote: On 27/07/07, Antonino A. Daplas [EMAIL PROTECTED] wrote: On Fri, 2007-07-27 at 21:18 +0100, Adrian McMenamin wrote: On 27/07/07, Adrian McMenamin [EMAIL PROTECTED] wrote: With the patch reverted and 24bpp, it oopses before freezing (with two odd looking boot logos on the screen): Tested this further and it fails on: rev = fb_readl(par-mmio_base + 0x04); Doubtful if this line is the point of failure, this line is executed only once, on initialization. par-mmio_base is corrupted in some way during the call to register_framebuffer - still investigating how/why. Possible, par-mmio_base is the last field in struct pvr2fb_par, after that is the pseudo_palette. The oops did not manifest when the pseudo_palette was written as u16, but oops'ed when written as u32. Memory alignment problems? Try the patch I posted before, might help. Apologies, missed the patch before. With the patch applied the Dreamcast no longer crashes or locks with either 16, 24 or 32 bpp, so that's good. With 24bpp everything is doubled up (eg two boot logos on screen) and about twice (?) the size it should be - though with a black screen. With 32 bpp everything is about 4 (?) times the size it should be and all on a yellow background. With 16bpp then everything is on a blue background as before, but is also the correct size (as before). Is this with commit a66ad56eb2c9644717da4d7f05f971d6786145e3 reverted? Reapply this commit again, it might (fingers crossed) correct the color problem. As to your display doubling/quadrupling with bpp 24/32, I don't have any answers (no hardware) though it seems to be a framebuffer pitch/display width mismatch. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with framebuffer in 2.6.22-git17
On Sat, 2007-07-28 at 02:06 +0100, Adrian McMenamin wrote: On 28/07/07, Antonino A. Daplas [EMAIL PROTECTED] wrote: But certainly better at 16bpp Can mess about with it later to see if I can get the colours right I suppose. You can start with pvr2fb_setcolreg() and pvr2fb_set_pal_entry(). A few things I've noticed: 1. In pvr2fb_setcolreg(), pvr2fb_set_pal_entry() is called for bpp 16 and 32. This means that the palette is modifiable, so FB_VISUAL_TRUECOLOR is probably not the correct visual for this driver, FB_VISUAL_DIRECTCOLOR is more appropriate. So, you either remove the call to set_pal_entry() in setcolreg() or change the visual to FB_VISUAL_DIRECTCOLOR. Of course, with directcolor, the pseudo_palette is now written with tmp as: tmp = transp var-transp.offset | red var-red.offset | green var-green.offset | blue var-green.offset; 2. Perhaps, the 3rd parameter passed to set_pal_entry() is not correct? Maybe you can try doing it like this for all bpp's, assuming ARGB? pvr2fb_set_pal_entry(par, regno, transp 24 | red 16 | green 8 | blue); And if you want to maintain FB_VISUAL_TRUECOLOR format, initialize the palette once on init: for (i = 0; i 256; i++) pvr2fb_set_pal_entry(par, i, i 24 | i 16 | i 8 | i); to create a linear color map consistent with truecolor, then remove all other calls to pvr2fb_set_pal_entry(). Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with framebuffer in 2.6.22-git17
On Sat, 2007-07-28 at 10:14 +0800, Antonino A. Daplas wrote: On Sat, 2007-07-28 at 02:06 +0100, Adrian McMenamin wrote: On 28/07/07, Antonino A. Daplas [EMAIL PROTECTED] wrote: tmp = transp var-transp.offset | red var-red.offset | green var-green.offset | blue var-green.offset; The above should be: tmp = regno var-transp.offset | regno var-red.offset | regno var-green.offset | regno var-green.offset; Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with framebuffer in 2.6.22-git17
On Tue, 2007-07-24 at 22:45 +0100, Adrian McMenamin wrote:
> On 23/07/07, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> > On Sun, 2007-07-22 at 19:41 +0100, Adrian McMenamin wrote:
> > > I ma having problems with the pvr2 fb on the Dreamcast in 2.6.22-git17
> > > - when the code is executed it appears to lock the Dreamcast up.
> > >
> > > The problem seems to be:
> > >
> > > fb_notifier_call_chain(FB_EVENT_FB_REGISTERED, );
> > >
> > > In drivers/video/fbmem.c
> > >
> > > This hasn't been an issue before, so are there any recent changes that
> > > might have caused this?
> >
> > What's the last kernel that worked for you? Can you also post your
> > config?
> >
> > >
> > > (fb_notifier_call_chain calls a succession of stubs ending in
> > > __blocking_notifier_call_chain in kernel/sys.c)
> > >
> >
> > Try reverting commit a66ad56eb2c9644717da4d7f05f971d6786145e3.
> >
> > Tony
> >
>
> Tony,
>
> I have checked this a few times now, including against Paul's git as
> well as Linus's and the Dreamcast won't boot without its reversion.
> Don't know why, but it needs to be reverted until a better fix is
> available.
I'm also confused. Can you change the color depth to 32 bpp ('fbset
-depth 32')? I'm thinking of a possible pseudo_palette overrun.
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with framebuffer in 2.6.22-git17
On Tue, 2007-07-24 at 22:45 +0100, Adrian McMenamin wrote:
On 23/07/07, Antonino A. Daplas [EMAIL PROTECTED] wrote:
On Sun, 2007-07-22 at 19:41 +0100, Adrian McMenamin wrote:
I ma having problems with the pvr2 fb on the Dreamcast in 2.6.22-git17
- when the code is executed it appears to lock the Dreamcast up.
The problem seems to be:
fb_notifier_call_chain(FB_EVENT_FB_REGISTERED, event);
In drivers/video/fbmem.c
This hasn't been an issue before, so are there any recent changes that
might have caused this?
What's the last kernel that worked for you? Can you also post your
config?
(fb_notifier_call_chain calls a succession of stubs ending in
__blocking_notifier_call_chain in kernel/sys.c)
Try reverting commit a66ad56eb2c9644717da4d7f05f971d6786145e3.
Tony
Tony,
I have checked this a few times now, including against Paul's git as
well as Linus's and the Dreamcast won't boot without its reversion.
Don't know why, but it needs to be reverted until a better fix is
available.
I'm also confused. Can you change the color depth to 32 bpp ('fbset
-depth 32')? I'm thinking of a possible pseudo_palette overrun.
Tony
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix fbcon - 'map_override' defined but not used warning
On Mon, 2007-07-23 at 14:07 +0200, Gabriel C wrote: > Antonino A. Daplas wrote: > > On Sun, 2007-07-22 at 18:23 +0200, Gabriel C wrote: > >> Hi, > >> > >> I got this warning on current git: > >> > >> ... > >> > >> drivers/video/console/fbcon.c:130: warning: 'map_override' defined but not > >> used > >> > >> ... > >> > >> Signed-off-by: Gabriel Craciunescu <[EMAIL PROTECTED]> > >> > >> --- > >> > >> diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c > >> index decfdc8..60a14de 100644 > >> --- a/drivers/video/console/fbcon.c > >> +++ b/drivers/video/console/fbcon.c > >> @@ -127,7 +127,9 @@ static int last_fb_vc = MAX_NR_CONSOLES - 1; > >> static int fbcon_is_default = 1; > >> static int fbcon_has_exited; > >> static int primary_device = -1; > >> +#ifndef MODULE > > > > Disrecard my other comment. This should be > > > > #ifdef CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY > > You really sure ? Yes, I realize that. I already have a patch in my tree that will fix this properly. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix fbcon - 'map_override' defined but not used warning
On Sun, 2007-07-22 at 18:23 +0200, Gabriel C wrote: > Hi, > > I got this warning on current git: > > ... > > drivers/video/console/fbcon.c:130: warning: 'map_override' defined but not > used > > ... > > Signed-off-by: Gabriel Craciunescu <[EMAIL PROTECTED]> > > --- > > diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c > index decfdc8..60a14de 100644 > --- a/drivers/video/console/fbcon.c > +++ b/drivers/video/console/fbcon.c > @@ -127,7 +127,9 @@ static int last_fb_vc = MAX_NR_CONSOLES - 1; > static int fbcon_is_default = 1; > static int fbcon_has_exited; > static int primary_device = -1; > +#ifndef MODULE Disrecard my other comment. This should be #ifdef CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY > static int map_override; > +#endif > > /* font data */ > static char fontname[40]; Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix fbcon - 'map_override' defined but not used warning
On Sun, 2007-07-22 at 18:23 +0200, Gabriel C wrote: Hi, I got this warning on current git: ... drivers/video/console/fbcon.c:130: warning: 'map_override' defined but not used ... Signed-off-by: Gabriel Craciunescu [EMAIL PROTECTED] --- diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c index decfdc8..60a14de 100644 --- a/drivers/video/console/fbcon.c +++ b/drivers/video/console/fbcon.c @@ -127,7 +127,9 @@ static int last_fb_vc = MAX_NR_CONSOLES - 1; static int fbcon_is_default = 1; static int fbcon_has_exited; static int primary_device = -1; +#ifndef MODULE Disrecard my other comment. This should be #ifdef CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY static int map_override; +#endif /* font data */ static char fontname[40]; Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix fbcon - 'map_override' defined but not used warning
On Mon, 2007-07-23 at 14:07 +0200, Gabriel C wrote: Antonino A. Daplas wrote: On Sun, 2007-07-22 at 18:23 +0200, Gabriel C wrote: Hi, I got this warning on current git: ... drivers/video/console/fbcon.c:130: warning: 'map_override' defined but not used ... Signed-off-by: Gabriel Craciunescu [EMAIL PROTECTED] --- diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c index decfdc8..60a14de 100644 --- a/drivers/video/console/fbcon.c +++ b/drivers/video/console/fbcon.c @@ -127,7 +127,9 @@ static int last_fb_vc = MAX_NR_CONSOLES - 1; static int fbcon_is_default = 1; static int fbcon_has_exited; static int primary_device = -1; +#ifndef MODULE Disrecard my other comment. This should be #ifdef CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY You really sure ? Yes, I realize that. I already have a patch in my tree that will fix this properly. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with framebuffer in 2.6.22-git17
On Sun, 2007-07-22 at 19:41 +0100, Adrian McMenamin wrote: > I ma having problems with the pvr2 fb on the Dreamcast in 2.6.22-git17 > - when the code is executed it appears to lock the Dreamcast up. > > The problem seems to be: > > fb_notifier_call_chain(FB_EVENT_FB_REGISTERED, ); > > In drivers/video/fbmem.c > > This hasn't been an issue before, so are there any recent changes that > might have caused this? What's the last kernel that worked for you? Can you also post your config? > > (fb_notifier_call_chain calls a succession of stubs ending in > __blocking_notifier_call_chain in kernel/sys.c) > Try reverting commit a66ad56eb2c9644717da4d7f05f971d6786145e3. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/7] console: fix section mismatch warning in vgacon.c
On Sun, 2007-07-22 at 12:20 +0200, Geert Uytterhoeven wrote: > On Sat, 21 Jul 2007, Antonino A. Daplas wrote: > > On Fri, 2007-07-20 at 23:27 +0200, Sam Ravnborg wrote: > > > Fix following section mismatch warning: > > > WARNING: vmlinux.o(.text+0x121e62): Section mismatch: reference to > > > .init.text:__alloc_bootmem (between 'vgacon_startup' and > > > 'vgacon_scrolldelta') > > > > > > Browsing the code it seems that vgacon_scrollback_startup() is only > > > called during the init phase so the reference to the .init.text > > > section is OK. > > > Teach modpost not to warn using ___init_refok. > > > > > > Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]> > > Acked-by: Antonino Daplas <[EMAIL PROTECTED]> > > I assume the check for `vga_init_done' in vgacon_startup() is sufficient to > prevent vgacon_scrollback_startup() from being called later due to > (un)bind_con_driver()? > Yes. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix fbcon - 'map_override' defined but not used warning
On Sun, 2007-07-22 at 18:23 +0200, Gabriel C wrote: > Hi, > > I got this warning on current git: > > ... > > drivers/video/console/fbcon.c:130: warning: 'map_override' defined but not > used > > ... > > Signed-off-by: Gabriel Craciunescu <[EMAIL PROTECTED]> Acked-by: Antonino Daplas <[EMAIL PROTECTED]> Thanks. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/7] console: fix section mismatch warning in vgacon.c
On Sun, 2007-07-22 at 12:20 +0200, Geert Uytterhoeven wrote: On Sat, 21 Jul 2007, Antonino A. Daplas wrote: On Fri, 2007-07-20 at 23:27 +0200, Sam Ravnborg wrote: Fix following section mismatch warning: WARNING: vmlinux.o(.text+0x121e62): Section mismatch: reference to .init.text:__alloc_bootmem (between 'vgacon_startup' and 'vgacon_scrolldelta') Browsing the code it seems that vgacon_scrollback_startup() is only called during the init phase so the reference to the .init.text section is OK. Teach modpost not to warn using ___init_refok. Signed-off-by: Sam Ravnborg [EMAIL PROTECTED] Acked-by: Antonino Daplas [EMAIL PROTECTED] I assume the check for `vga_init_done' in vgacon_startup() is sufficient to prevent vgacon_scrollback_startup() from being called later due to (un)bind_con_driver()? Yes. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix fbcon - 'map_override' defined but not used warning
On Sun, 2007-07-22 at 18:23 +0200, Gabriel C wrote: Hi, I got this warning on current git: ... drivers/video/console/fbcon.c:130: warning: 'map_override' defined but not used ... Signed-off-by: Gabriel Craciunescu [EMAIL PROTECTED] Acked-by: Antonino Daplas [EMAIL PROTECTED] Thanks. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Problems with framebuffer in 2.6.22-git17
On Sun, 2007-07-22 at 19:41 +0100, Adrian McMenamin wrote: I ma having problems with the pvr2 fb on the Dreamcast in 2.6.22-git17 - when the code is executed it appears to lock the Dreamcast up. The problem seems to be: fb_notifier_call_chain(FB_EVENT_FB_REGISTERED, event); In drivers/video/fbmem.c This hasn't been an issue before, so are there any recent changes that might have caused this? What's the last kernel that worked for you? Can you also post your config? (fb_notifier_call_chain calls a succession of stubs ending in __blocking_notifier_call_chain in kernel/sys.c) Try reverting commit a66ad56eb2c9644717da4d7f05f971d6786145e3. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/7] console: fix section mismatch warning in vgacon.c
On Fri, 2007-07-20 at 23:27 +0200, Sam Ravnborg wrote: > Fix following section mismatch warning: > WARNING: vmlinux.o(.text+0x121e62): Section mismatch: reference to > .init.text:__alloc_bootmem (between 'vgacon_startup' and 'vgacon_scrolldelta') > > Browsing the code it seems that vgacon_scrollback_startup() is only > called during the init phase so the reference to the .init.text > section is OK. > Teach modpost not to warn using ___init_refok. > > Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]> Acked-by: Antonino Daplas <[EMAIL PROTECTED]> Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/7] console: fix section mismatch warning in vgacon.c
On Fri, 2007-07-20 at 23:27 +0200, Sam Ravnborg wrote: Fix following section mismatch warning: WARNING: vmlinux.o(.text+0x121e62): Section mismatch: reference to .init.text:__alloc_bootmem (between 'vgacon_startup' and 'vgacon_scrolldelta') Browsing the code it seems that vgacon_scrollback_startup() is only called during the init phase so the reference to the .init.text section is OK. Teach modpost not to warn using ___init_refok. Signed-off-by: Sam Ravnborg [EMAIL PROTECTED] Acked-by: Antonino Daplas [EMAIL PROTECTED] Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VESAFB CUSTOM RESOLUTION
On Wed, 2007-07-18 at 10:38 -0700, H. Peter Anvin wrote: > Antonino A. Daplas wrote: > > > >> What about the VBE 3.0 arbitrary vertical refresh rate thing? > > > > This is not implemented by the video-vesa.c because it will require > > complex calculations of mode timings (such as with GTF) to be done > > before starting the kernel. However, uvesafb probably does. > > > > There is no real reason video-vesa.c couldn't do those calculations, but > it would have to get the information from the command line proper and > not just from the 16-bit vga= mode number. That is a minor > complication, but not significant (the new setup code has a proper > command line parser.) > > The desirability of it is another matter, especially since it wouldn't > let any switching happen at runtime. Yes, it's a lot of extra code that will be used only once, I would rather not have it in the setup code. It's more appropriate for uvesafb to implement that functionality. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VESAFB CUSTOM RESOLUTION
On Wed, 2007-07-18 at 19:59 +0300, Matan Ziv-Av wrote: > On Wed, 18 Jul 2007, Antonino A. Daplas wrote: > > > So, one cannot just set any mode, unless that mode is already defined in > > the BIOS mode table. In VBE 3.0, you might be able to choose an > > arbitrary vertical refresh rate, but that's the best mode tuning you can > > do with the video BIOS. > > Theoretically, not correct. VBE 3.0 allows arbitrary mode setting - not > only vertical refresh, but all mode parameters (the ones appearing in X > modelines). This is supported by both svgalib and uvesafb. I don't know > on how many VBE3 cards this feature really works, but it does work for > some cards. The CRTCInfoBlock structure passed for Function 0x4f02 does not include xres and yres so the horizontal and vertical active lengths cannot be modified arbitrarily, an appropriate mode ID must still be chosen. I cannot set 880x244, for example, if it's not in the table. It's the horizontal timings, the vertical timings and the pixelclock that can be adjusted. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH] fbdev: find mode with highest refresh rate in fb_find_mode()
On Wed, 2007-07-18 at 16:38 +0200, Ondrej Zajicek wrote: > On Wed, Jul 18, 2007 at 10:41:02AM +0200, Michal Januszewski wrote: > > Currently if the refresh rate is not specified fb_find_mode() returns > > the first known video mode with the requested resoluion, which provides > > no guarantees wrt the refresh rate. Change this so that the mode with > > the highest refresh rate is returned instead. > > What refresh rate it sets when used on card or monitor without DDC? Yes, I noted this also while reviewing patches. fb_find_mode() is used predominantly with the 'generic' modedb which contains modes that are not specific to the card or monitor. And fb_try_mode() is not a guarantee that the returned refresh rate will be safe (we have a lot of drivers that do not check the timings against the display capabilities). It would be best that fb_find_mode() return the safest refresh rate (60Hz) instead of the highest. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VESAFB CUSTOM RESOLUTION
On Wed, 2007-07-18 at 17:52 +0300, Al Boldi wrote: > Antonino A. Daplas wrote: > > On Wed, 2007-07-18 at 16:45 +0300, Al Boldi wrote: > > > Antonino A. Daplas wrote: > > > > On Wed, 2007-07-18 at 13:42 +0300, Al Boldi wrote: > > > > > Geert Uytterhoeven wrote: > > > > > > On Wed, 18 Jul 2007, Sasa Ostrouska wrote: > > > > > > What about the VBE 3.0 arbitrary vertical refresh rate thing? This is not implemented by the video-vesa.c because it will require complex calculations of mode timings (such as with GTF) to be done before starting the kernel. However, uvesafb probably does. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VESAFB CUSTOM RESOLUTION
On Wed, 2007-07-18 at 16:45 +0300, Al Boldi wrote: > Antonino A. Daplas wrote: > > On Wed, 2007-07-18 at 13:42 +0300, Al Boldi wrote: > > > Geert Uytterhoeven wrote: > > > > On Wed, 18 Jul 2007, Sasa Ostrouska wrote: > > > > > > Is there any technical reason why vesafb shouldn't support non-BIOS > > > modes? > > > > vesafb can only use modes included by the vendor in the card's BIOS. The > > mode table contains standard modes defined by VESA, and perhaps > > vendor-defined custom modes. However, the mode ID of custom modes varies > > from card to card, so you have to 'probe' the BIOS first for the list of > > modes and their associated ID. X + the 'vesa' driver does that probe, > > and so does the lrmi tool vbetest. > > > > So, one cannot just set any mode, unless that mode is already defined in > > the BIOS mode table. In VBE 3.0, you might be able to choose an > > arbitrary vertical refresh rate, but that's the best mode tuning you can > > do with the video BIOS. > > Thanks for a great explanation! > > Looks like this chip supports VBE 3.0, but it only locks into 60Hz refresh. > Here is an excerpt; full log attached. > > What you need to look at the X log is this particular part (this is the output of my card, and for the sake of brevity, I removed the descriptive sections): Mode: 100 (640x400) Mode: 101 (640x480) Mode: 102 (800x600) Mode: 103 (800x600) Mode: 104 (1024x768) Mode: 105 (1024x768) Mode: 106 (1280x1024) Mode: 107 (1280x1024) *Mode: 10e (320x200) Mode: 10f (320x200) *Mode: 111 (640x480) Mode: 112 (640x480) *Mode: 114 (800x600) Mode: 115 (800x600) *Mode: 117 (1024x768) Mode: 118 (1024x768) Mode: 11a (1280x1024) Mode: 11b (1280x1024) Mode: 130 (320x200) Mode: 131 (320x400) *Mode: 132 (320x400) Mode: 133 (320x400) Mode: 134 (320x240) *Mode: 135 (320x240) Mode: 136 (320x240) *Mode: 13d (640x400) Mode: 13e (640x400) Mode: 145 (1600x1200) Mode: 146 (1600x1200) Mode: 147 (1400x1050) Mode: 148 (1400x1050) Mode: 152 (2048x1536) The list of modes include standard VESA modes and custom modes such as 2048x1536. So, if I want to use this mode for vesafb, I will add vga=0x352 (0x152 + 0x200) to my boot line. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VESAFB CUSTOM RESOLUTION
On Wed, 2007-07-18 at 13:42 +0300, Al Boldi wrote: > Geert Uytterhoeven wrote: > > On Wed, 18 Jul 2007, Sasa Ostrouska wrote: > Is there any technical reason why vesafb shouldn't support non-BIOS modes? > vesafb can only use modes included by the vendor in the card's BIOS. The mode table contains standard modes defined by VESA, and perhaps vendor-defined custom modes. However, the mode ID of custom modes varies from card to card, so you have to 'probe' the BIOS first for the list of modes and their associated ID. X + the 'vesa' driver does that probe, and so does the lrmi tool vbetest. So, one cannot just set any mode, unless that mode is already defined in the BIOS mode table. In VBE 3.0, you might be able to choose an arbitrary vertical refresh rate, but that's the best mode tuning you can do with the video BIOS. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VESAFB CUSTOM RESOLUTION
On Wed, 2007-07-18 at 13:42 +0300, Al Boldi wrote: Geert Uytterhoeven wrote: On Wed, 18 Jul 2007, Sasa Ostrouska wrote: Is there any technical reason why vesafb shouldn't support non-BIOS modes? vesafb can only use modes included by the vendor in the card's BIOS. The mode table contains standard modes defined by VESA, and perhaps vendor-defined custom modes. However, the mode ID of custom modes varies from card to card, so you have to 'probe' the BIOS first for the list of modes and their associated ID. X + the 'vesa' driver does that probe, and so does the lrmi tool vbetest. So, one cannot just set any mode, unless that mode is already defined in the BIOS mode table. In VBE 3.0, you might be able to choose an arbitrary vertical refresh rate, but that's the best mode tuning you can do with the video BIOS. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VESAFB CUSTOM RESOLUTION
On Wed, 2007-07-18 at 16:45 +0300, Al Boldi wrote: Antonino A. Daplas wrote: On Wed, 2007-07-18 at 13:42 +0300, Al Boldi wrote: Geert Uytterhoeven wrote: On Wed, 18 Jul 2007, Sasa Ostrouska wrote: Is there any technical reason why vesafb shouldn't support non-BIOS modes? vesafb can only use modes included by the vendor in the card's BIOS. The mode table contains standard modes defined by VESA, and perhaps vendor-defined custom modes. However, the mode ID of custom modes varies from card to card, so you have to 'probe' the BIOS first for the list of modes and their associated ID. X + the 'vesa' driver does that probe, and so does the lrmi tool vbetest. So, one cannot just set any mode, unless that mode is already defined in the BIOS mode table. In VBE 3.0, you might be able to choose an arbitrary vertical refresh rate, but that's the best mode tuning you can do with the video BIOS. Thanks for a great explanation! Looks like this chip supports VBE 3.0, but it only locks into 60Hz refresh. Here is an excerpt; full log attached. What you need to look at the X log is this particular part (this is the output of my card, and for the sake of brevity, I removed the descriptive sections): Mode: 100 (640x400) Mode: 101 (640x480) Mode: 102 (800x600) Mode: 103 (800x600) Mode: 104 (1024x768) Mode: 105 (1024x768) Mode: 106 (1280x1024) Mode: 107 (1280x1024) *Mode: 10e (320x200) Mode: 10f (320x200) *Mode: 111 (640x480) Mode: 112 (640x480) *Mode: 114 (800x600) Mode: 115 (800x600) *Mode: 117 (1024x768) Mode: 118 (1024x768) Mode: 11a (1280x1024) Mode: 11b (1280x1024) Mode: 130 (320x200) Mode: 131 (320x400) *Mode: 132 (320x400) Mode: 133 (320x400) Mode: 134 (320x240) *Mode: 135 (320x240) Mode: 136 (320x240) *Mode: 13d (640x400) Mode: 13e (640x400) Mode: 145 (1600x1200) Mode: 146 (1600x1200) Mode: 147 (1400x1050) Mode: 148 (1400x1050) Mode: 152 (2048x1536) The list of modes include standard VESA modes and custom modes such as 2048x1536. So, if I want to use this mode for vesafb, I will add vga=0x352 (0x152 + 0x200) to my boot line. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VESAFB CUSTOM RESOLUTION
On Wed, 2007-07-18 at 17:52 +0300, Al Boldi wrote: Antonino A. Daplas wrote: On Wed, 2007-07-18 at 16:45 +0300, Al Boldi wrote: Antonino A. Daplas wrote: On Wed, 2007-07-18 at 13:42 +0300, Al Boldi wrote: Geert Uytterhoeven wrote: On Wed, 18 Jul 2007, Sasa Ostrouska wrote: What about the VBE 3.0 arbitrary vertical refresh rate thing? This is not implemented by the video-vesa.c because it will require complex calculations of mode timings (such as with GTF) to be done before starting the kernel. However, uvesafb probably does. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Linux-fbdev-devel] [PATCH] fbdev: find mode with highest refresh rate in fb_find_mode()
On Wed, 2007-07-18 at 16:38 +0200, Ondrej Zajicek wrote: On Wed, Jul 18, 2007 at 10:41:02AM +0200, Michal Januszewski wrote: Currently if the refresh rate is not specified fb_find_mode() returns the first known video mode with the requested resoluion, which provides no guarantees wrt the refresh rate. Change this so that the mode with the highest refresh rate is returned instead. What refresh rate it sets when used on card or monitor without DDC? Yes, I noted this also while reviewing patches. fb_find_mode() is used predominantly with the 'generic' modedb which contains modes that are not specific to the card or monitor. And fb_try_mode() is not a guarantee that the returned refresh rate will be safe (we have a lot of drivers that do not check the timings against the display capabilities). It would be best that fb_find_mode() return the safest refresh rate (60Hz) instead of the highest. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VESAFB CUSTOM RESOLUTION
On Wed, 2007-07-18 at 19:59 +0300, Matan Ziv-Av wrote: On Wed, 18 Jul 2007, Antonino A. Daplas wrote: So, one cannot just set any mode, unless that mode is already defined in the BIOS mode table. In VBE 3.0, you might be able to choose an arbitrary vertical refresh rate, but that's the best mode tuning you can do with the video BIOS. Theoretically, not correct. VBE 3.0 allows arbitrary mode setting - not only vertical refresh, but all mode parameters (the ones appearing in X modelines). This is supported by both svgalib and uvesafb. I don't know on how many VBE3 cards this feature really works, but it does work for some cards. The CRTCInfoBlock structure passed for Function 0x4f02 does not include xres and yres so the horizontal and vertical active lengths cannot be modified arbitrarily, an appropriate mode ID must still be chosen. I cannot set 880x244, for example, if it's not in the table. It's the horizontal timings, the vertical timings and the pixelclock that can be adjusted. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VESAFB CUSTOM RESOLUTION
On Wed, 2007-07-18 at 10:38 -0700, H. Peter Anvin wrote: Antonino A. Daplas wrote: What about the VBE 3.0 arbitrary vertical refresh rate thing? This is not implemented by the video-vesa.c because it will require complex calculations of mode timings (such as with GTF) to be done before starting the kernel. However, uvesafb probably does. There is no real reason video-vesa.c couldn't do those calculations, but it would have to get the information from the command line proper and not just from the 16-bit vga= mode number. That is a minor complication, but not significant (the new setup code has a proper command line parser.) The desirability of it is another matter, especially since it wouldn't let any switching happen at runtime. Yes, it's a lot of extra code that will be used only once, I would rather not have it in the setup code. It's more appropriate for uvesafb to implement that functionality. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VESAFB CUSTOM RESOLUTION
On Tue, 2007-07-17 at 16:13 +0200, Sasa Ostrouska wrote: > Hi , > > I want to ask one question about a custom resolution in the console. > I have a Sony Vaio Laptop VGN-SZ2VP/X, the screen resolution is > 1280x800, now I'm using the vga=773 which is an 1024x768 but this is > ugly as I get a border of about 2-3cm on one the sides of the screen. > So is there a way that I set the 1280x800 resolution at boot time ? 1280x800 is not a VESA standard, so you have to find out the vendor mode ID for it. You can use vbetest to list all modes supported by your card. Or if you don't have vbetest, use X plus the 'vesa' driver and look at /var/log/X*.log. Choose the mode ID number you want, add 0x200 and use that. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VESAFB CUSTOM RESOLUTION
On Tue, 2007-07-17 at 16:13 +0200, Sasa Ostrouska wrote: Hi , I want to ask one question about a custom resolution in the console. I have a Sony Vaio Laptop VGN-SZ2VP/X, the screen resolution is 1280x800, now I'm using the vga=773 which is an 1024x768 but this is ugly as I get a border of about 2-3cm on one the sides of the screen. So is there a way that I set the 1280x800 resolution at boot time ? 1280x800 is not a VESA standard, so you have to find out the vendor mode ID for it. You can use vbetest to list all modes supported by your card. Or if you don't have vbetest, use X plus the 'vesa' driver and look at /var/log/X*.log. Choose the mode ID number you want, add 0x200 and use that. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Geode GX framebuffer driver: Arcom vs. AMD
On Sat, 2007-07-14 at 17:05 -0400, Andrew Paprocki wrote:
> Tony,
>
> Do you have the patch working already? I'd love to try this out in the
> meantime on the LX system I am developing with at the moment. I'm
> assuming you worked this into the existing Arcom framework (gxfb) and
> pulled the necessary pieces from the AMD code?
The patch is from Jordan, and from what I can see it's independent from
gxfb. I'm attaching that patch.
Tony
diff --git a/drivers/video/geode/Kconfig b/drivers/video/geode/Kconfig
index a814b6c..c45181e 100644
--- a/drivers/video/geode/Kconfig
+++ b/drivers/video/geode/Kconfig
@@ -8,6 +8,21 @@ config FB_GEODE
Say 'Y' here to allow you to select framebuffer drivers for
the AMD Geode family of processors.
+config FB_GEODE_LX
+ tristate "AMD Geode LX framebuffer support (EXPERIMENTAL)"
+ depends on FB && FB_GEODE
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ ---help---
+ Framebuffer driver for the display controller integrated into the
+ AMD Geode LX processors.
+
+ To compile this driver as a module, choose M here: the module will
+ be called lxfb.
+
+ If unsure, say N.
+
config FB_GEODE_GX
tristate "AMD Geode GX framebuffer support (EXPERIMENTAL)"
depends on FB && FB_GEODE && EXPERIMENTAL
diff --git a/drivers/video/geode/Makefile b/drivers/video/geode/Makefile
index f896565..957304b 100644
--- a/drivers/video/geode/Makefile
+++ b/drivers/video/geode/Makefile
@@ -2,6 +2,8 @@ # Makefile for the Geode family framebuf
obj-$(CONFIG_FB_GEODE_GX1) += gx1fb.o
obj-$(CONFIG_FB_GEODE_GX) += gxfb.o
+obj-$(CONFIG_FB_GEODE_LX) += lxfb.o
gx1fb-objs := gx1fb_core.o display_gx1.o video_cs5530.o
gxfb-objs := gxfb_core.o display_gx.o video_gx.o
+lxfb-objs := lxfb_core.o lxfb_ops.o
diff --git a/drivers/video/geode/lxfb.h b/drivers/video/geode/lxfb.h
new file mode 100644
index 000..6c227f9
--- /dev/null
+++ b/drivers/video/geode/lxfb.h
@@ -0,0 +1,199 @@
+#ifndef _LXFB_H_
+#define _LXFB_H_
+
+#include
+
+#define OUTPUT_CRT 0x01
+#define OUTPUT_PANEL 0x02
+
+struct lxfb_par {
+ int output;
+ int panel_width;
+ int panel_height;
+
+ void __iomem *gp_regs;
+ void __iomem *dc_regs;
+ void __iomem *df_regs;
+};
+
+static inline unsigned int lx_get_pitch(unsigned int xres, int bpp)
+{
+ return (((xres * (bpp >> 3)) + 7) & ~7);
+}
+
+void lx_set_mode(struct fb_info *);
+void lx_get_gamma(struct fb_info *, unsigned int *, int);
+void lx_set_gamma(struct fb_info *, unsigned int *, int);
+unsigned int lx_framebuffer_size(void);
+int lx_blank_display(struct fb_info *, int);
+void lx_set_palette_reg(struct fb_info *, unsigned int, unsigned int,
+ unsigned int, unsigned int);
+
+/* MSRS */
+
+#define MSR_LX_GLD_CONFIG0x48002001
+#define MSR_LX_GLCP_DOTPLL 0x4c15
+#define MSR_LX_DF_PADSEL 0x4811
+#define MSR_LX_DC_SPARE 0x8011
+#define MSR_LX_DF_GLCONFIG 0x48002001
+
+#define MSR_LX_GLIU0_P2D_RO0 0x1029
+
+#define GLCP_DOTPLL_RESET(1 << 0)
+#define GLCP_DOTPLL_BYPASS (1 << 15)
+#define GLCP_DOTPLL_HALFPIX (1 << 24)
+#define GLCP_DOTPLL_LOCK (1 << 25)
+
+#define DF_CONFIG_OUTPUT_MASK 0x38
+#define DF_OUTPUT_PANEL 0x08
+#define DF_OUTPUT_CRT 0x00
+#define DF_SIMULTANEOUS_CRT_AND_FP (1 << 15)
+
+#define DF_DEFAULT_TFT_PAD_SEL_LOW 0xDFFF
+#define DF_DEFAULT_TFT_PAD_SEL_HIGH 0x003F
+
+#define DC_SPARE_DISABLE_CFIFO_HGO 0x0800
+#define DC_SPARE_VFIFO_ARB_SELECT 0x0400
+#define DC_SPARE_WM_LPEN_OVRD 0x0200
+#define DC_SPARE_LOAD_WM_LPEN_MASK 0x0100
+#define DC_SPARE_DISABLE_INIT_VID_PRI 0x0080
+#define DC_SPARE_DISABLE_VFIFO_WM 0x0040
+#define DC_SPARE_DISABLE_CWD_CHECK 0x0020
+#define DC_SPARE_PIX8_PAN_FIX 0x0010
+#define DC_SPARE_FIRST_REQ_MASK0x0002
+
+/* Registers */
+
+#define DC_UNLOCK 0x00
+#define DC_UNLOCK_CODE 0x4758
+
+#define DC_GENERAL_CFG0x04
+#define DC_GCFG_DFLE (1 << 0)
+#define DC_GCFG_VIDE (1 << 3)
+#define DC_GCFG_VGAE (1 << 7)
+#define DC_GCFG_CMPE (1 << 5)
+#define DC_GCFG_DECE (1 << 6)
+#define DC_GCFG_FDTY (1 << 17)
+
+#define DC_DISPLAY_CFG0x08
+#define DC_DCFG_TGEN (1 << 0)
+#define DC_DCFG_GDEN (1 << 3)
+#define DC_DCFG_VDEN (1 << 4)
+#define DC_DCFG_TRUP (1 << 6)
+#define DC_DCFG_DCEN (1 << 24)
+#define DC_DCFG_PALB (1 << 25)
+#define DC_DCFG_VISL (1 << 27)
+
+#define DC_DCFG_16BPP 0x0
+
+#define DC_DCFG_DISP_MODE_MASK 0x0300
+#define DC_DCFG_DISP_MODE_8BPP 0x
+#define DC_DCFG_DISP_MODE_16BPP 0x0100
+#define DC_DCFG_DISP_MODE_24BPP 0x0200
+#define DC_DCFG_DISP_MODE_32BPP 0x0300
+
+
+#define DC_ARB_CFG0x0C
+
+#define DC_FB_START 0x10
+#define DC_CB_START 0x14
+#define DC_CURSOR_START 0x18
+
+#define DC_DV_TOP 0x2C
+#define DC_DV_TOP_ENABLE (1 << 0)
+
Re: Geode GX framebuffer driver: Arcom vs. AMD
On Sat, 2007-07-14 at 15:01 -0400, Andrew Paprocki wrote: > Is there any reason why the GPL framebuffer driver for the GX/GX1/LX > directly from AMD is not integrated into the kernel and only a custom > driver for only the GX/GX1 written by Arcom exists? > (drivers/video/geode/*) > > If you have an LX, the Arcom driver won't work and it is difficult to > use AMD's patch for 2.6.11 with a more recent kernel because the > drivers/video/geode directory has filename conflicts with files in the > patch. > > If there are no issues preventing its inclusion, would updated patches > be accepted to switch to AMD's framebuffer driver? The AMD patches > would need to be combined to support all three platforms in the driver > dir, all sitting on top of the Cimarron HAL installed in lib/cimarron. > There's a patch for the AMD Geode LX which I'm going to send for the -mm tree soon. Its module name is lxfb. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Geode GX framebuffer driver: Arcom vs. AMD
On Sat, 2007-07-14 at 15:01 -0400, Andrew Paprocki wrote: Is there any reason why the GPL framebuffer driver for the GX/GX1/LX directly from AMD is not integrated into the kernel and only a custom driver for only the GX/GX1 written by Arcom exists? (drivers/video/geode/*) If you have an LX, the Arcom driver won't work and it is difficult to use AMD's patch for 2.6.11 with a more recent kernel because the drivers/video/geode directory has filename conflicts with files in the patch. If there are no issues preventing its inclusion, would updated patches be accepted to switch to AMD's framebuffer driver? The AMD patches would need to be combined to support all three platforms in the driver dir, all sitting on top of the Cimarron HAL installed in lib/cimarron. There's a patch for the AMD Geode LX which I'm going to send for the -mm tree soon. Its module name is lxfb. Tony - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Geode GX framebuffer driver: Arcom vs. AMD
On Sat, 2007-07-14 at 17:05 -0400, Andrew Paprocki wrote:
Tony,
Do you have the patch working already? I'd love to try this out in the
meantime on the LX system I am developing with at the moment. I'm
assuming you worked this into the existing Arcom framework (gxfb) and
pulled the necessary pieces from the AMD code?
The patch is from Jordan, and from what I can see it's independent from
gxfb. I'm attaching that patch.
Tony
diff --git a/drivers/video/geode/Kconfig b/drivers/video/geode/Kconfig
index a814b6c..c45181e 100644
--- a/drivers/video/geode/Kconfig
+++ b/drivers/video/geode/Kconfig
@@ -8,6 +8,21 @@ config FB_GEODE
Say 'Y' here to allow you to select framebuffer drivers for
the AMD Geode family of processors.
+config FB_GEODE_LX
+ tristate AMD Geode LX framebuffer support (EXPERIMENTAL)
+ depends on FB FB_GEODE
+ select FB_CFB_FILLRECT
+ select FB_CFB_COPYAREA
+ select FB_CFB_IMAGEBLIT
+ ---help---
+ Framebuffer driver for the display controller integrated into the
+ AMD Geode LX processors.
+
+ To compile this driver as a module, choose M here: the module will
+ be called lxfb.
+
+ If unsure, say N.
+
config FB_GEODE_GX
tristate AMD Geode GX framebuffer support (EXPERIMENTAL)
depends on FB FB_GEODE EXPERIMENTAL
diff --git a/drivers/video/geode/Makefile b/drivers/video/geode/Makefile
index f896565..957304b 100644
--- a/drivers/video/geode/Makefile
+++ b/drivers/video/geode/Makefile
@@ -2,6 +2,8 @@ # Makefile for the Geode family framebuf
obj-$(CONFIG_FB_GEODE_GX1) += gx1fb.o
obj-$(CONFIG_FB_GEODE_GX) += gxfb.o
+obj-$(CONFIG_FB_GEODE_LX) += lxfb.o
gx1fb-objs := gx1fb_core.o display_gx1.o video_cs5530.o
gxfb-objs := gxfb_core.o display_gx.o video_gx.o
+lxfb-objs := lxfb_core.o lxfb_ops.o
diff --git a/drivers/video/geode/lxfb.h b/drivers/video/geode/lxfb.h
new file mode 100644
index 000..6c227f9
--- /dev/null
+++ b/drivers/video/geode/lxfb.h
@@ -0,0 +1,199 @@
+#ifndef _LXFB_H_
+#define _LXFB_H_
+
+#include linux/fb.h
+
+#define OUTPUT_CRT 0x01
+#define OUTPUT_PANEL 0x02
+
+struct lxfb_par {
+ int output;
+ int panel_width;
+ int panel_height;
+
+ void __iomem *gp_regs;
+ void __iomem *dc_regs;
+ void __iomem *df_regs;
+};
+
+static inline unsigned int lx_get_pitch(unsigned int xres, int bpp)
+{
+ return (((xres * (bpp 3)) + 7) ~7);
+}
+
+void lx_set_mode(struct fb_info *);
+void lx_get_gamma(struct fb_info *, unsigned int *, int);
+void lx_set_gamma(struct fb_info *, unsigned int *, int);
+unsigned int lx_framebuffer_size(void);
+int lx_blank_display(struct fb_info *, int);
+void lx_set_palette_reg(struct fb_info *, unsigned int, unsigned int,
+ unsigned int, unsigned int);
+
+/* MSRS */
+
+#define MSR_LX_GLD_CONFIG0x48002001
+#define MSR_LX_GLCP_DOTPLL 0x4c15
+#define MSR_LX_DF_PADSEL 0x4811
+#define MSR_LX_DC_SPARE 0x8011
+#define MSR_LX_DF_GLCONFIG 0x48002001
+
+#define MSR_LX_GLIU0_P2D_RO0 0x1029
+
+#define GLCP_DOTPLL_RESET(1 0)
+#define GLCP_DOTPLL_BYPASS (1 15)
+#define GLCP_DOTPLL_HALFPIX (1 24)
+#define GLCP_DOTPLL_LOCK (1 25)
+
+#define DF_CONFIG_OUTPUT_MASK 0x38
+#define DF_OUTPUT_PANEL 0x08
+#define DF_OUTPUT_CRT 0x00
+#define DF_SIMULTANEOUS_CRT_AND_FP (1 15)
+
+#define DF_DEFAULT_TFT_PAD_SEL_LOW 0xDFFF
+#define DF_DEFAULT_TFT_PAD_SEL_HIGH 0x003F
+
+#define DC_SPARE_DISABLE_CFIFO_HGO 0x0800
+#define DC_SPARE_VFIFO_ARB_SELECT 0x0400
+#define DC_SPARE_WM_LPEN_OVRD 0x0200
+#define DC_SPARE_LOAD_WM_LPEN_MASK 0x0100
+#define DC_SPARE_DISABLE_INIT_VID_PRI 0x0080
+#define DC_SPARE_DISABLE_VFIFO_WM 0x0040
+#define DC_SPARE_DISABLE_CWD_CHECK 0x0020
+#define DC_SPARE_PIX8_PAN_FIX 0x0010
+#define DC_SPARE_FIRST_REQ_MASK0x0002
+
+/* Registers */
+
+#define DC_UNLOCK 0x00
+#define DC_UNLOCK_CODE 0x4758
+
+#define DC_GENERAL_CFG0x04
+#define DC_GCFG_DFLE (1 0)
+#define DC_GCFG_VIDE (1 3)
+#define DC_GCFG_VGAE (1 7)
+#define DC_GCFG_CMPE (1 5)
+#define DC_GCFG_DECE (1 6)
+#define DC_GCFG_FDTY (1 17)
+
+#define DC_DISPLAY_CFG0x08
+#define DC_DCFG_TGEN (1 0)
+#define DC_DCFG_GDEN (1 3)
+#define DC_DCFG_VDEN (1 4)
+#define DC_DCFG_TRUP (1 6)
+#define DC_DCFG_DCEN (1 24)
+#define DC_DCFG_PALB (1 25)
+#define DC_DCFG_VISL (1 27)
+
+#define DC_DCFG_16BPP 0x0
+
+#define DC_DCFG_DISP_MODE_MASK 0x0300
+#define DC_DCFG_DISP_MODE_8BPP 0x
+#define DC_DCFG_DISP_MODE_16BPP 0x0100
+#define DC_DCFG_DISP_MODE_24BPP 0x0200
+#define DC_DCFG_DISP_MODE_32BPP 0x0300
+
+
+#define DC_ARB_CFG0x0C
+
+#define DC_FB_START 0x10
+#define DC_CB_START 0x14
+#define DC_CURSOR_START 0x18
+
+#define DC_DV_TOP 0x2C
+#define DC_DV_TOP_ENABLE (1 0)
+
+#define DC_LINE_SIZE 0x30
+#define
Re: [patch 2/4] fbdev: Add fb_append_extra_logo()
On Fri, 2007-07-13 at 08:58 +0200, Geert Uytterhoeven wrote:
> On Fri, 13 Jul 2007, Antonino A. Daplas wrote:
> > On Tue, 2007-07-10 at 14:27 +0200, Geert Uytterhoeven wrote:
> > > --- a/include/linux/linux_logo.h
> > > +++ b/include/linux/linux_logo.h
> > > @@ -33,5 +33,13 @@ struct linux_logo {
> > > };
> > >
> > > extern const struct linux_logo *fb_find_logo(int depth);
> > > +#if defined(CONFIG_LOGO) && defined(CONFIG_FB)
> >
> > The CONFIG_LOGO is also probably redundant, but that's arguable.
>
> You can have CONFIG_LOGO without CONFIG_FB (depends on FB ||
> SGI_NEWPORT_CONSOLE).
>
Okay.
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/4] fbdev: Add fb_append_extra_logo()
On Fri, 2007-07-13 at 08:56 +0200, Geert Uytterhoeven wrote:
> On Fri, 13 Jul 2007, Antonino A. Daplas wrote:
> > On Tue, 2007-07-10 at 14:27 +0200, Geert Uytterhoeven wrote:
> > > --- a/drivers/video/fbmem.c
> > > +++ b/drivers/video/fbmem.c
> > > @@ -318,6 +318,13 @@ static struct logo_data {
> > > const struct linux_logo *logo;
> > > } fb_logo __read_mostly;
> > >
> > > +#define FB_LOGO_EX_NUM_MAX 10
> > > +static struct logo_data_extra {
> > > + const struct linux_logo *logo;
> > > + unsigned int n;
> > > +} fb_logo_ex[FB_LOGO_EX_NUM_MAX];
> > > +static unsigned int fb_logo_ex_num;
> > > +
> > > static void fb_rotate_logo_ud(const u8 *in, u8 *out, u32 width, u32
> > > height)
> > > {
> > > u32 size = width * height, i;
> > > @@ -411,10 +418,22 @@ static void fb_do_show_logo(struct fb_in
> > > }
> > > }
> > >
> > > +#ifdef CONFIG_FB
> >
> > The #ifdef is redundant.
>
> IIRC, it's needed for the CONFIG_FB=m case.
What would happen if CONFIG_FB=m? (We already have a patch that prevents
logo drawing if the driver or fbcon is modular)
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/4] fbdev: Add fb_append_extra_logo()
On Fri, 2007-07-13 at 08:58 +0200, Geert Uytterhoeven wrote:
On Fri, 13 Jul 2007, Antonino A. Daplas wrote:
On Tue, 2007-07-10 at 14:27 +0200, Geert Uytterhoeven wrote:
--- a/include/linux/linux_logo.h
+++ b/include/linux/linux_logo.h
@@ -33,5 +33,13 @@ struct linux_logo {
};
extern const struct linux_logo *fb_find_logo(int depth);
+#if defined(CONFIG_LOGO) defined(CONFIG_FB)
The CONFIG_LOGO is also probably redundant, but that's arguable.
You can have CONFIG_LOGO without CONFIG_FB (depends on FB ||
SGI_NEWPORT_CONSOLE).
Okay.
Tony
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/4] fbdev: Add fb_append_extra_logo()
On Fri, 2007-07-13 at 08:56 +0200, Geert Uytterhoeven wrote:
On Fri, 13 Jul 2007, Antonino A. Daplas wrote:
On Tue, 2007-07-10 at 14:27 +0200, Geert Uytterhoeven wrote:
--- a/drivers/video/fbmem.c
+++ b/drivers/video/fbmem.c
@@ -318,6 +318,13 @@ static struct logo_data {
const struct linux_logo *logo;
} fb_logo __read_mostly;
+#define FB_LOGO_EX_NUM_MAX 10
+static struct logo_data_extra {
+ const struct linux_logo *logo;
+ unsigned int n;
+} fb_logo_ex[FB_LOGO_EX_NUM_MAX];
+static unsigned int fb_logo_ex_num;
+
static void fb_rotate_logo_ud(const u8 *in, u8 *out, u32 width, u32
height)
{
u32 size = width * height, i;
@@ -411,10 +418,22 @@ static void fb_do_show_logo(struct fb_in
}
}
+#ifdef CONFIG_FB
The #ifdef is redundant.
IIRC, it's needed for the CONFIG_FB=m case.
What would happen if CONFIG_FB=m? (We already have a patch that prevents
logo drawing if the driver or fbcon is modular)
Tony
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
