Re: [Linux-fbdev-devel] [Bugme-new] [Bug 13285] New: INTELFB: Colors display incorrectly
On Wed, 3 Jun 2009 11:27:17 +0200 Michal Suchanek hramr...@centrum.cz 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 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 -- 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] [Bugme-new] [Bug 13285] New: INTELFB: Colors display incorrectly
From: Krzysztof Helt krzysztof...@wp.pl
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 krzysztof...@wp.pl
---
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.
diff -urp linux-ref/drivers/video/intelfb/intelfbdrv.c
linux-2.6.30-rc7/drivers/video/intelfb/intelfbdrv.c
--- linux-ref/drivers/video/intelfb/intelfbdrv.c2009-05-23
23:47:00.0 +0200
+++ linux-2.6.30-rc7/drivers/video/intelfb/intelfbdrv.c 2009-05-29
07:37:27.0 +0200
@@ -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);
diff -urp linux-ref/drivers/video/intelfb/intelfbhw.c
linux-2.6.30-rc7/drivers/video/intelfb/intelfbhw.c
--- linux-ref/drivers/video/intelfb/intelfbhw.c 2009-05-23 23:47:00.0
+0200
+++ linux-2.6.30-rc7/drivers/video/intelfb/intelfbhw.c 2009-05-29
07:42:06.0 +0200
@@ -469,6 +469,32 @@ void intelfbhw_do_blank(int blank, struc
}
+/* Check which pipe is connected to an active display plane. */
+int intelfbhw_active_pipe(const struct intelfb_hwstate *hw)
+{
+ int pipe = -1;
+
+ /* keep old default behaviour - prefer PIPE_A */
+ if (hw-disp_b_ctrl DISPPLANE_PLANE_ENABLE) {
+ pipe = (hw-disp_b_ctrl DISPPLANE_SEL_PIPE_SHIFT);
+ pipe = PIPE_MASK;
+ if (unlikely(pipe == PIPE_A))
+ return PIPE_A;
+ }
+ if (hw-disp_a_ctrl DISPPLANE_PLANE_ENABLE) {
+ pipe = (hw-disp_a_ctrl DISPPLANE_SEL_PIPE_SHIFT);
+ pipe = PIPE_MASK;
+ if (likely(pipe == PIPE_A))
+ return PIPE_A;
+ }
+ /* Impossible that no pipe is selected - return PIPE_A */
+ WARN_ON(pipe == -1);
+ if (unlikely(pipe == -1))
+ pipe = PIPE_A;
+
+ return pipe;
+}
+
void intelfbhw_setcolreg(struct intelfb_info *dinfo, unsigned regno,
unsigned red, unsigned green, unsigned blue,
unsigned transp)
@@ -1019,7 +1045,7 @@ int intelfbhw_mode_to_hw(struct intelfb_
struct intelfb_hwstate *hw,
struct fb_var_screeninfo *var)
{
- int pipe = PIPE_A;
+ int pipe = intelfbhw_active_pipe(hw);
u32 *dpll, *fp0, *fp1;
u32 m1, m2, n, p1, p2, clock_target, clock;
u32 hsync_start, hsync_end, hblank_start, hblank_end, htotal, hactive;
@@ -1033,12 +1059,6 @@ int intelfbhw_mode_to_hw(struct intelfb_
/* Disable VGA */
hw-vgacntrl |= VGA_DISABLE;
- /* Check whether pipe A or pipe B is enabled. */
- if (hw-pipe_a_conf PIPECONF_ENABLE)
- pipe = PIPE_A;
- else if (hw-pipe_b_conf PIPECONF_ENABLE)
- pipe = PIPE_B;
-
/* Set which pipe's registers will be set. */
if (pipe == PIPE_B) {
dpll = hw-dpll_b;
@@ -1262,7 +1282,6 @@ int intelfbhw_mode_to_hw(struct intelfb_
int intelfbhw_program_mode(struct intelfb_info *dinfo,
const struct intelfb_hwstate *hw, int blank)
{
- int pipe = PIPE_A;
u32 tmp;
const u32 *dpll, *fp0, *fp1, *pipe_conf;
const u32 *hs, *ht, *hb, *vs, *vt, *vb, *ss;
@@ -1272,7 +1291,7 @@ int intelfbhw_program_mode(struct intelf
u32 src_size_reg;
u32 count, tmp_val[3];
- /* Assume single pipe, display plane A, analog CRT. */
+ /* Assume single pipe */
#if VERBOSE 0
DBG_MSG(intelfbhw_program_mode\n);
@@ -1283,15 +1302,9 @@ int intelfbhw_program_mode(struct intelf
tmp |= VGA_DISABLE
Re: [Linux-fbdev-devel] [Bugme-new] [Bug 13285] New: INTELFB: Colors display incorrectly
On Tue, 12 May 2009 15:19:34 -0700 Andrew Morton a...@linux-foundation.org wrote: (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 bugzilla-dae...@bugzilla.kernel.org 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. Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Console/Framebuffers AssignedTo: jsimm...@infradead.org ReportedBy: samanddea...@yahoo.com 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 -- 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 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] [Bugme-new] [Bug 13285] New: INTELFB: Colors display incorrectly
From: Krzysztof Helt krzysztof...@wp.pl 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). 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 krzysztof...@wp.pl --- This is not a regression. I have reproduced it in the 2.6.28 easily. Dean, please test the patch. diff --git a/drivers/video/intelfb/intelfbdrv.c b/drivers/video/intelfb/intelfbdrv.c index ace14fe..b47f6dd 100644 --- a/drivers/video/intelfb/intelfbdrv.c +++ b/drivers/video/intelfb/intelfbdrv.c @@ -871,6 +871,12 @@ static int __devinit intelfb_pci_register(struct pci_dev *pdev, 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); -- Dzwonki na komorkê! Sprawdz http://link.interia.pl/f2161 -- 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-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] [Bugme-new] [Bug 13285] New: INTELFB: Colors display incorrectly
On Sat, 16 May 2009 23:19:32 -0700 Andrew Morton a...@linux-foundation.org wrote: On Sun, 17 May 2009 08:17:43 +0200 Krzysztof Helt krzysztof...@poczta.fm wrote: 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. 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. Regards, Krzysztof -- Dzwonki na komorkê! Sprawdz http://link.interia.pl/f2161 -- 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-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] [Bugme-new] [Bug 13285] New: INTELFB: Colors display incorrectly
On Tue, 12 May 2009 15:19:34 -0700 Andrew Morton a...@linux-foundation.org wrote: (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 bugzilla-dae...@bugzilla.kernel.org wrote: 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? There were changes to fbdev common code as well. Dean, could you post more info about your system? A good starting point is an output of the dmesg command. Kind regards, Krzysztof -- Dzwonki na komorkê! Sprawdz http://link.interia.pl/f2161 -- 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-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
