New: INTELFB: Colors display incorrectly

Bugme-new Andrew Morton 3 participants 10 messages May 12, 2009 – Jun 30, 2009 3 messages not in the archive Framebuffer layer

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]/

Andrew Morton

author

2009-05-12 22:19 UTC #1 lore raw

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).

Quoted 6 lines · On Tue, 12 May 2009 01:40:48 GMT [email protected] wrote:

http://bugzilla.kernel.org/show_bug.cgi?id=13285

           Summary: INTELFB: Colors display incorrectly
           Product: Drivers
           Version: 2.5
    Kernel Version: 2.6.30-rc5

This is a post-2.6.29 regression.

Quoted 12 lines

Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Console/Framebuffers
AssignedTo: [email protected]
ReportedBy: [email protected]
Regression: Yes

Quoted 8 lines

On my system, the colors are displaying incorrectly when using the Intel framebuffer. For example the Tux penguin logo has a blue background, and when I start X11 with the fbdev drivers, the xterm also has a blue background, when it is set up to have a white background.
This does not occur in kernel 2.6.29 -- I can see the Tasmanian devil in a penguin mask (Tuz) just fine and can view images, etc on the framebuffer.

The only change to drivers/video/intelfb/ since 2.6.29 was 347486bb108fa6e0fd2753c1be3519d6be2516ed ("intelfb: support i854") which added a device ID.

Do we think that this regression is due to fbdev changes, or to DRI changes?

Thanks.

------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com
--

Krzysztof Helt

2009-05-16 18:42 UTC #2 lore raw

Quoted 7 lines · On Tue, 12 May 2009 15:19:34 -0700 Andrew Morton <[email protected]>…

(switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface).
On Tue, 12 May 2009 01:40:48 GMT
[email protected] wrote:

Quoted 30 lines

Quoted 6 lines
http://bugzilla.kernel.org/show_bug.cgi?id=13285
           Summary: INTELFB: Colors display incorrectly
           Product: Drivers
           Version: 2.5
    Kernel Version: 2.6.30-rc5
This is a post-2.6.29 regression.
Quoted 20 lines
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Console/Framebuffers
AssignedTo: [email protected]
ReportedBy: [email protected]
Regression: Yes
On my system, the colors are displaying incorrectly when using the Intel framebuffer. For example the Tux penguin logo has a blue background, and when I start X11 with the fbdev drivers, the xterm also has a blue background, when it is set up to have a white background.
This does not occur in kernel 2.6.29 -- I can see the Tasmanian devil in a penguin mask (Tuz) just fine and can view images, etc on the framebuffer.

I have reproduced the bug on Intel 852/855 chipset (Asus A3L laptop).

It took me long because I had problems with a hard drive and had to wipe it with a low-level format tool.

I am trying to identify cause of the bug.

Regards,
Krzysztof

----------------------------------------------------------------------
Fantastyczne nagrody do zgarniecia!
Zagraj >> http://link.interia.pl/f2177

A message that is not in the archive (sent off-list or not yet received): [email protected]

Andrew Morton

author

2009-05-17 06:19 UTC #4 lore raw

Quoted 9 lines · On Sun, 17 May 2009 08:17:43 +0200 Krzysztof Helt <[email protected]>…

From: Krzysztof Helt <[email protected]>
The intelfb driver sets color map depending on currently active pipe. However, if an LVDS display is attached (like in laptop) the active pipe variable is never set. The default value is PIPE_A and can be wrong.
Set up the pipe variable during driver initialization after hardware state was read.
I also found by experiment that if both pipes were enabled, the PIPE_B is used (active).

Quoted 7 lines

The problem is visible in the 8 bpp mode if colors above 15 are used. The first 16 color entries are displayed correctly.
Signed-off-by Krzysztof Helt <[email protected]>
---
This is not a regression. I have reproduced it in the 2.6.28 easily.

hm, Dean's original report had

This does not occur in kernel 2.6.29 -- I can see the Tasmanian devil in a penguin mask (Tuz) just fine and can view images, etc on the framebuffer.

Quoted 1 line

Dean, please test the patch.

Yes please.

Quoted 6 lines

drivers/video/intelfb/intelfbdrv.c +0 -0

index ace14fe..b47f6dd 100644
@@ -871,6 +871,12 @@ static int __devinit intelfb_pci_register(struct pci_dev *pdev,

drivers/video/intelfb/intelfbdrv.c static int __devinit intelfb_pci_register(struct pci_dev *pdev, · line 881

Quoted 10 lines

drivers/video/intelfb/intelfbdrv.c +6 -0

 	intelfbhw_print_hw_state(dinfo, &dinfo->save_state);
 
+	/* Check whether pipe A or pipe B is enabled. */
+	if (dinfo->save_state.pipe_a_conf & PIPECONF_ENABLE)
+		dinfo->pipe = PIPE_A;
+	if (dinfo->save_state.pipe_b_conf & PIPECONF_ENABLE)
+		dinfo->pipe = PIPE_B;
+
 	if (bailearly == 18)
 		bailout(dinfo);

A message that is not in the archive (sent off-list or not yet received): [email protected]

Michal Suchanek

2009-05-17 15:07 UTC #6 lore raw

2009/5/17 Krzysztof Helt <[email protected]>:

Quoted 14 lines

Quoted 10 lines · On Sat, 16 May 2009 23:19:32 -0700 Andrew Morton <[email protected]>…
Quoted 1 line · On Sun, 17 May 2009 08:17:43 +0200 Krzysztof Helt <[email protected]>…
This is not a regression. I have reproduced it in the 2.6.28 easily.
hm, Dean's original report had
This does not occur in kernel 2.6.29 -- I can see the Tasmanian devil in a penguin mask (Tuz) just fine and can view images, etc on the framebuffer.

Quoted 5 lines

I can confirm that Tuz is also broken on my laptop (kernel v2.6.29). Maybe Dean had set different color depth ("vga=" parameter) for the older kernel?
The dmesg output for the 2.6.29 would clear any doubts.

For me this is broken ever since 2.6.26 on a Mac Mini with all of efifb/intelfb/vesafb but perhaps this is a different issue.

I will try to rebuild 2.6.29 with intelfb and the patch to see if that makes a difference.

Currently efifb does give correct geometry but wrong colours for me, the other framebuffers would also produce picture with wrong geometry with 2.6.26.

Thanks

Michal

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
Linux-fbdev-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

Krzysztof Helt

2009-05-30 11:58 UTC #7 lore raw

From: Krzysztof Helt <[email protected]>

The intelfb driver sets color map depending on currently active pipe. However, if an LVDS display is attached (like in laptop) the active pipe variable is never set. The default value is PIPE_A and can be wrong.
Set up the pipe variable during driver initialization after hardware state was read.

Also, the detection of the active display (and hence the pipe) is wrong. The pipes are assigned to so called planes. Both pipes are always enabled on my laptop but only one plane is enabled (the plane A for the CRT or the plane B for the LVDS). Change active pipe detection code to take into account a status of the plane assigned to each pipe.

The problem is visible in the 8 bpp mode if colors above 15 are used. The first 16 color entries are displayed correctly.

The graphics chip description is here (G45 vol. 3):
http://intellinuxgraphics.org/documentation.html

Signed-off-by Krzysztof Helt <[email protected]>

---
The second version of the fix to this problem. Now, it is much more sophisticated based on the knowledge gained from documentation available at http://intellinuxgraphics.org/.

It does not change a default behaviour (assumed pipe A) for all cases except the case that only the plane assigned to the pipe B is active. It is enough to fix the issue for me.

Please test it.

drivers/video/intelfb/intelfbdrv.c +3 -0

diff -urp linux-ref/drivers/video/intelfb/intelfbdrv.c linux-2.6.30-rc7/drivers/video/intelfb/intelfbdrv.c
@@ -874,6 +874,9 @@ static int __devinit intelfb_pci_registe
 	if (bailearly == 18)
 		bailout(dinfo);
 
+	/* read active pipe */
+	dinfo->pipe = intelfbhw_active_pipe(&dinfo->save_state);
+
 	/* Cursor initialisation */
 	if (dinfo->hwcursor) {
 		intelfbhw_cursor_init(dinfo);

drivers/video/intelfb/intelfbhw.c +30 ~~-17~~

84 lines not on this page · raw message

drivers/video/intelfb/intelfbhw.h +1 -0

diff -urp linux-ref/drivers/video/intelfb/intelfbhw.h linux-2.6.30-rc7/drivers/video/intelfb/intelfbhw.h
@@ -604,5 +604,6 @@ extern void intelfbhw_cursor_reset(struc
 extern int intelfbhw_enable_irq(struct intelfb_info *dinfo);
 extern void intelfbhw_disable_irq(struct intelfb_info *dinfo);
 extern int intelfbhw_wait_for_vsync(struct intelfb_info *dinfo, u32 pipe);
+extern int intelfbhw_active_pipe(const struct intelfb_hwstate *hw);
 
 #endif /* _INTELFBHW_H */

----------------------------------------------------------------------
Kup wlasne mieszkanie za 33 tys. zl.
Sprawdz >>> http://link.interia.pl/f21a3

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com

Andrew Morton

author

2009-06-02 20:18 UTC #8 lore raw

Quoted 16 lines · On Sat, 30 May 2009 13:58:33 +0200 Krzysztof Helt <[email protected]>…

The intelfb driver sets color map depending on currently active pipe. However, if an LVDS display is attached (like in laptop) the active pipe variable is never set. The default value is PIPE_A and can be wrong.
Set up the pipe variable during driver initialization after hardware state was read.
Also, the detection of the active display (and hence the pipe) is wrong. The pipes are assigned to so called planes. Both pipes are always enabled on my laptop but only one plane is enabled (the plane A for the CRT or the plane B for the LVDS). Change active pipe detection code to take into account a status of the plane assigned to each pipe.
The problem is visible in the 8 bpp mode if colors above 15 are used. The first 16 color entries are displayed correctly.
The graphics chip description is here (G45 vol. 3):
http://intellinuxgraphics.org/documentation.html

Quoted 8 lines

Signed-off-by Krzysztof Helt <[email protected]>
---
The second version of the fix to this problem. Now, it is much more sophisticated based on the knowledge gained from documentation available at http://intellinuxgraphics.org/.
It does not change a default behaviour (assumed pipe A) for all cases except the case that only the plane assigned to the pipe B is active. It is enough to fix the issue for me.

I queued this.

Quoted 1 line

Please test it.

But it would great be Dean and/or Michal were to be able to test it, please.

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get

Michal Suchanek

2009-06-03 09:27 UTC #9 lore raw

2009/6/2 Andrew Morton <[email protected]>:

Quoted 25 lines

Quoted 22 lines · On Sat, 30 May 2009 13:58:33 +0200 Krzysztof Helt <[email protected]>…
The intelfb driver sets color map depending on currently active pipe. However, if an LVDS display is attached (like in laptop) the active pipe variable is never set. The default value is PIPE_A and can be wrong.
Set up the pipe variable during driver initialization after hardware state was read.
Also, the detection of the active display (and hence the pipe) is wrong. The pipes are assigned to so called planes. Both pipes are always enabled on my laptop but only one plane is enabled (the plane A for the CRT or the plane B for the LVDS). Change active pipe detection code to take into account a status of the plane assigned to each pipe.
The problem is visible in the 8 bpp mode if colors above 15 are used. The first 16 color entries are displayed correctly.
The graphics chip description is here (G45 vol. 3):
http://intellinuxgraphics.org/documentation.html
Signed-off-by Krzysztof Helt <[email protected]>
---
The second version of the fix to this problem. Now, it is much more sophisticated based on the knowledge gained from documentation available at http://intellinuxgraphics.org/.

Quoted 9 lines

Quoted 2 lines
It does not change a default behaviour (assumed pipe A) for all cases except the case that only the plane assigned to the pipe B is active. It is enough to fix the issue for me.
I queued this.
Quoted 1 line
Please test it.
But it would great be Dean and/or Michal were to be able to test it, please.

Thanks for the patch.

Unfortunately I did not get to testing the patch yet.

According to the description it is supposed to resolve some confusion over what pipe is enabled or not.

X server reports the pipes connected as follows:

(II) intel(0):   Pipe A is on
(II) intel(0):   Display plane A is now enabled and connected to pipe A.
(II) intel(0):   Pipe B is off
(II) intel(0):   Display plane B is now disabled and connected to pipe A.
(II) intel(0):   Output VGA is connected to pipe none
(II) intel(0):   Output TMDS-1 is connected to pipe A
(II) intel(0):   Output TV is connected to pipe none

However, I also get this warning before the outputs are listed:
(WW) intel(0): Couldn't detect panel mode. Disabling panel

Is this a configuration that would likely be affected by the issue fixed here or do I have a different problem?

I am currently not using intelfb because last time I tried it produced even worse results than efifb (which does suffer from the wrong colors as well).

Thanks

Michal

Krzysztof Helt

2009-06-04 20:58 UTC #10 lore raw

Quoted 14 lines · On Wed, 3 Jun 2009 11:27:17 +0200 Michal Suchanek <[email protected]> wrote:

Unfortunately I did not get to testing the patch yet.
According to the description it is supposed to resolve some confusion over what pipe is enabled or not.
X server reports the pipes connected as follows:
(II) intel(0):   Pipe A is on
(II) intel(0):   Display plane A is now enabled and connected to pipe A.
(II) intel(0):   Pipe B is off
(II) intel(0):   Display plane B is now disabled and connected to pipe A.
(II) intel(0):   Output VGA is connected to pipe none
(II) intel(0):   Output TMDS-1 is connected to pipe A
(II) intel(0):   Output TV is connected to pipe none

Quoted 6 lines

However, I also get this warning before the outputs are listed:
(WW) intel(0): Couldn't detect panel mode. Disabling panel
Is this a configuration that would likely be affected by the issue fixed here or do I have a different problem?

Frankly speaking, I don't know. Please describe your problem.

The panel mode I suppose is LVDS (LCD panel directly connected to the chip) which is possible only in laptops and tablets or other computers where the LCD panel is integrated with the main unit (e.g. "desk-lamp" like Apple computers). All other computers which you connect the display by external cable (DVI/HDMI or VGA) does not work in the "panel mode".

Kind regards,
Krzysztof

----------------------------------------------------------------------
Sprawdz wiadomosci z Twojego regionu!
Kliknij >>> http://link.interia.pl/f21ba

Michal Suchanek

2009-06-05 12:14 UTC #11 lore raw

2009/6/4 Krzysztof Helt <[email protected]>:

Quoted 24 lines

Quoted 14 lines · On Wed, 3 Jun 2009 11:27:17 +0200 Michal Suchanek <[email protected]> wrote:
Unfortunately I did not get to testing the patch yet.
According to the description it is supposed to resolve some confusion over what pipe is enabled or not.
X server reports the pipes connected as follows:
(II) intel(0): Pipe A is on
(II) intel(0): Display plane A is now enabled and connected to pipe A. (II) intel(0): Pipe B is off
(II) intel(0): Display plane B is now disabled and connected to pipe A. (II) intel(0): Output VGA is connected to pipe none
(II) intel(0): Output TMDS-1 is connected to pipe A
(II) intel(0): Output TV is connected to pipe none
Quoted 6 lines
However, I also get this warning before the outputs are listed:
(WW) intel(0): Couldn't detect panel mode. Disabling panel
Is this a configuration that would likely be affected by the issue fixed here or do I have a different problem?

Quoted 8 lines

Frankly speaking, I don't know. Please describe your problem.
The panel mode I suppose is LVDS (LCD panel directly connected to the chip) which is possible only in laptops and tablets or other computers where the LCD panel is integrated with the main unit (e.g. "desk-lamp" like Apple computers). All other computers which you connect the display by external cable (DVI/HDMI or VGA) does not work in the "panel mode".

This is a mac mini with single TMDS display only.

Thanks

Michal

Michal Suchanek

2009-06-30 11:35 UTC #12 lore raw

In reply to Andrew Morton

Hello

2009/6/2 Andrew Morton <[email protected]>:

Quoted 25 lines

Quoted 22 lines · On Sat, 30 May 2009 13:58:33 +0200 Krzysztof Helt <[email protected]>…
The intelfb driver sets color map depending on currently active pipe. However, if an LVDS display is attached (like in laptop) the active pipe variable is never set. The default value is PIPE_A and can be wrong.
Set up the pipe variable during driver initialization after hardware state was read.
Also, the detection of the active display (and hence the pipe) is wrong. The pipes are assigned to so called planes. Both pipes are always enabled on my laptop but only one plane is enabled (the plane A for the CRT or the plane B for the LVDS). Change active pipe detection code to take into account a status of the plane assigned to each pipe.
The problem is visible in the 8 bpp mode if colors above 15 are used. The first 16 color entries are displayed correctly.
The graphics chip description is here (G45 vol. 3):
http://intellinuxgraphics.org/documentation.html
Signed-off-by Krzysztof Helt <[email protected]>
---
The second version of the fix to this problem. Now, it is much more sophisticated based on the knowledge gained from documentation available at http://intellinuxgraphics.org/.

Quoted 9 lines

Quoted 2 lines
It does not change a default behaviour (assumed pipe A) for all cases except the case that only the plane assigned to the pipe B is active. It is enough to fix the issue for me.
I queued this.
Quoted 1 line
Please test it.
But it would great be Dean and/or Michal were to be able to test it, please.

Sorry about the late reply.

In the end I could not test the patch on my system. Not only does the patch not apply but intelfb fails to produce any screen output at all. the command line is like this:

video=intelfb:mode=1280x1024 fbcon=rotate:1

Here is a boot with both intelfb and efifb. For some reason the efifb is shown in this case but breaks so I thought I was looking at intelfb because the output was different. Both geometry and colours are broken. Part of the console (top, physical right) is invisible, part (right, physical bottom) is not drawn (shows black initially and garbage after switching to X and back).

Jun 29 12:50:30 uvt316-2 kernel: [    0.366168] efifb: dmi detected
Macmini1,1 - framebuffer at 80000000
(1024x768, stride 8192)
Jun 29 12:50:30 uvt316-2 kernel: [    0.366273] efifb: probing for efifb
Jun 29 12:50:30 uvt316-2 kernel: [    0.366486] efifb: framebuffer at
0x80000000, mapped to 0xf8100000, u
sing 6144k, total 6144k
Jun 29 12:50:30 uvt316-2 kernel: [    0.366496] efifb: mode is
1024x768x32, linelength=8192, pages=1
Jun 29 12:50:30 uvt316-2 kernel: [    0.366501] efifb: scrolling: redraw
Jun 29 12:50:30 uvt316-2 kernel: [    0.366508] efifb: Truecolor:
size=8:8:8:8, shift=24:16:8:0
Jun 29 12:50:30 uvt316-2 kernel: [    0.395938] Console: switching to
colour frame buffer device 96x64
Jun 29 12:50:30 uvt316-2 kernel: [    0.423483] fb0: EFI VGA frame buffer device
Jun 29 12:50:30 uvt316-2 kernel: [    0.427641] Linux agpgart interface v0.103
Jun 29 12:50:30 uvt316-2 kernel: [    0.427886] agpgart-intel
0000:00:00.0: Intel 945GM Chipset
Jun 29 12:50:30 uvt316-2 kernel: [    0.429006] agpgart-intel
0000:00:00.0: detected 16124K stolen memory
Jun 29 12:50:30 uvt316-2 kernel: [    0.432312] agpgart-intel
0000:00:00.0: AGP aperture is 256M @ 0x8000
0000
Jun 29 12:50:30 uvt316-2 kernel: [    0.432750] intelfb: Framebuffer
driver for Intel(R)
830M/845G/852GM/855GM/865G/915G/915GM/945G/945GM/945GME/965G/965GM
chipsets
Jun 29 12:50:30 uvt316-2 kernel: [    0.433387] intelfb: Version 0.9.6
Jun 29 12:50:30 uvt316-2 kernel: [    0.433626] intelfb 0000:00:02.0:
PCI INT A -> GSI 16 (level, low) -> IRQ 16
Jun 29 12:50:30 uvt316-2 kernel: [    0.434067] intelfb: Cannot

reserve FB region.

Intelfb only. No console output.

Jun 29 14:16:18 uvt316-2 kernel: [    0.370014] Linux agpgart interface v0.103
Jun 29 14:16:18 uvt316-2 kernel: [    0.370037] agpgart-intel
0000:00:00.0: Intel 945GM Chipset
Jun 29 14:16:18 uvt316-2 kernel: [    0.370786] agpgart-intel
0000:00:00.0: detected 16124K stolen memory
Jun 29 14:16:18 uvt316-2 kernel: [    0.373808] agpgart-intel
0000:00:00.0: AGP aperture is 256M @ 0x8000
0000
Jun 29 14:16:18 uvt316-2 kernel: [    0.373876] intelfb: Framebuffer
driver for Intel(R)
830M/845G/852GM/855GM/865G/915G/915GM/945G/945GM/945GME/965G/965GM
chipsets
Jun 29 14:16:18 uvt316-2 kernel: [    0.373886] intelfb: Version 0.9.6
Jun 29 14:16:18 uvt316-2 kernel: [    0.373937] intelfb 0000:00:02.0:
PCI INT A -> GSI 16 (level, low) -> IRQ 16
Jun 29 14:16:18 uvt316-2 kernel: [    0.373960] intelfb: 00:02.0:
Intel(R) 945GM, aperture size 256MB, stolen memory 16124kB
Jun 29 14:16:18 uvt316-2 kernel: [    0.377376] intelfb: Non-CRT
device is enabled ( DVO port B ).  Disabling mode switching.
Jun 29 14:16:18 uvt316-2 kernel: [    0.377392] intelfb: Video mode

must be programmed at boot time.

Efifb only with video=efifb fbcon=rotate:1
Produces correct geometry but broken colours.

Jun 29 15:26:59 uvt316-2 kernel: [    0.364224] efifb: dmi detected
Macmini1,1 - framebuffer at 80000000
(1024x768, stride 8192)
Jun 29 15:26:59 uvt316-2 kernel: [    0.364328] efifb: probing for efifb
Jun 29 15:26:59 uvt316-2 kernel: [    0.364609] efifb: framebuffer at
0x80000000, mapped to 0xf8100000, u
sing 8192k, total 8192k
Jun 29 15:26:59 uvt316-2 kernel: [    0.364619] efifb: mode is
1280x1024x16, linelength=8192, pages=1
Jun 29 15:26:59 uvt316-2 kernel: [    0.364624] efifb: scrolling: redraw
Jun 29 15:26:59 uvt316-2 kernel: [    0.364631] efifb: Truecolor:
size=8:8:8:8, shift=24:16:8:0
Jun 29 15:26:59 uvt316-2 kernel: [    0.389698] Console: switching to
colour frame buffer device 128x80
Jun 29 15:26:59 uvt316-2 kernel: [    0.413244] fb0: EFI VGA frame buffer device

------------------------------------------------------------------------------