So, below is the little fix. It's self-explanatory. Matrox's fb
can't be compiled without it. Petr, please, apply it.
--- drivers/video/matrox/matroxfb_base.c.orig Mon Feb 4 05:11:15 2002
+++ drivers/video/matrox/matroxfb_base.c Mon Feb 4 05:16:05 2002
@@ -1789,7 +1789,7 @@
strcpy(ACCESS_FBINFO(fbcon.modename), "MATROX VGA");
ACCESS_FBINFO(fbcon.changevar) = NULL;
- ACCESS_FBINFO(fbcon.node) = -1;
+ ACCESS_FBINFO(fbcon.node.value) = -1;
ACCESS_FBINFO(fbcon.fbops) = &matroxfb_ops;
ACCESS_FBINFO(fbcon.disp) = d;
ACCESS_FBINFO(fbcon.switch_con) = &matroxfb_switch;
On Mon, Feb 04, 2002 at 06:01:07AM +0500, Denis Zaitsev wrote:
> So, below is the little fix. It's self-explanatory. Matrox's fb
> can't be compiled without it. Petr, please, apply it.
Thanks. I already tried to push updated matroxfb to both Marcello
and Linus, but only Alan picked it... matroxfb_crtc2.c needs
simillar fix, BTW.
> --- drivers/video/matrox/matroxfb_base.c.orig Mon Feb 4 05:11:15 2002
> +++ drivers/video/matrox/matroxfb_base.c Mon Feb 4 05:16:05 2002
> @@ -1789,7 +1789,7 @@
>
> strcpy(ACCESS_FBINFO(fbcon.modename), "MATROX VGA");
> ACCESS_FBINFO(fbcon.changevar) = NULL;
> - ACCESS_FBINFO(fbcon.node) = -1;
> + ACCESS_FBINFO(fbcon.node.value) = -1;
No, ACCESS_FBINFO(fbcon.node) = B_FREE;
or = NODEV;
> ACCESS_FBINFO(fbcon.fbops) = &matroxfb_ops;
> ACCESS_FBINFO(fbcon.disp) = d;
> ACCESS_FBINFO(fbcon.switch_con) = &matroxfb_switch;
Petr Vandrovec
[email protected]
It was two identical if-else branches in matroxfb_decode_var - one for
var->bits_per_pixel == 4
and the other for
var->bits_per_pixel <= 8
. So, I've removed 4's one. It should be ok, if this branch was ok -
i.e. was intentionally made the same as the 8bpp's. So, Petr, please,
apply this fix, if all ok.
--- drivers/video/matrox/matroxfb_base.c.orig Mon Feb 25 21:38:33 2002
+++ drivers/video/matrox/matroxfb_base.c Tue Feb 26 16:38:33 2002
@@ -494,16 +494,6 @@ static int matroxfb_decode_var(CPMINFO s
var->transp.offset = 0;
var->transp.length = 0;
*visual = MX_VISUAL_PSEUDOCOLOR;
- } else if (var->bits_per_pixel == 4) {
- var->red.offset = 0;
- var->red.length = 8;
- var->green.offset = 0;
- var->green.length = 8;
- var->blue.offset = 0;
- var->blue.length = 8;
- var->transp.offset = 0;
- var->transp.length = 0;
- *visual = MX_VISUAL_PSEUDOCOLOR;
} else if (var->bits_per_pixel <= 8) {
var->red.offset = 0;
var->red.length = 8;
On 27 Feb 02 at 0:26, Denis Zaitsev wrote:
> It was two identical if-else branches in matroxfb_decode_var - one for
> var->bits_per_pixel == 4
> and the other for
> var->bits_per_pixel <= 8
> . So, I've removed 4's one. It should be ok, if this branch was ok -
> i.e. was intentionally made the same as the 8bpp's. So, Petr, please,
> apply this fix, if all ok.
Somebody changed == 8 to <= 8 when I was not looking... But as
bits_per_pixel is already validated, it looks correct. Applied,
will go to Linus next round.
Best regards,
Petr Vandrovec
[email protected]
BTW, a little question: you use the (green.length == 5) test to
distinct bpp15 from bpp16 (matroxfb_base.c:509). Why? Is the "real"
15 not used as the bits_per_pixel's value? Thanks in advance.
On 27 Feb 02 at 3:36, Denis Zaitsev wrote:
> BTW, a little question: you use the (green.length == 5) test to
> distinct bpp15 from bpp16 (matroxfb_base.c:509). Why? Is the "real"
> 15 not used as the bits_per_pixel's value? Thanks in advance.
Yes, it is per spec. bits_per_pixel is bits per pixel, and for both
1:5:5:5 and 5:6:5 this is 16. Matrox hardware does not support 15bpp
pixels (16 pixels in 15 bytes)...
Best regards,
Petr Vandrovec
[email protected]