Re: [PATCH] fbdev driver for S3 Trio/Virge, updated
On Wed, 2007-02-28 at 16:53 +, James Simmons wrote:
> > On Thu, 2007-02-22 at 00:53 +, James Simmons wrote:
> > > > > +/* image data is MSB-first, fb structure is MSB-first too */
> > > > > +static inline u32 expand_color(u32 c)
> > > > > +{
> > > > > + return ((c & 1) | ((c & 2) << 7) | ((c & 4) << 14) | ((c & 8)
> > > > > << 21)) * 0xFF;
> > > > > +}
> > > > > +
> > > > > +/* s3fb_iplan_imageblit silently assumes that almost everything is
> > > > > 8-pixel aligned */
> > > >
> > > > Hmn, same thing with vga16fb... Perhaps we should bring back the
> > > > fontwidth flag of 2.2 and 2.4 kernels.
> > >
> > > Ug no. It is possible to get 12,6 bit width fonts working with vga
> > > interleaved planes. I got it paritally working but never got back to it.
> > > Its in my queue of this to do. Now that I finished the display class I
> > > need to get around to makeing drm/fbdev work together :-)
> > >
> >
> > Of course, not fontwidth exactly, but to allow the driver to specify the
> > alignment of the blit engine, in this case 8 pixels. I do believe X also
> > has similar functionality to compensate for the limitation of the
> > hardware.
>
> Isn't scan_align in pixmap for this? Or do we need more.
No, scan_align is how much to pad each line, and it's up to the engine
to discard the padding. In this case, the hardware does not allow
padding and must be given data in exact multiples. For example, vesafb
can accept 4x4 fonts padded to 8x4, but vga16fb will not be able to draw
4x4 fonts 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] fbdev driver for S3 Trio/Virge, updated
> On Thu, 2007-02-22 at 00:53 +, James Simmons wrote:
> > > > +/* image data is MSB-first, fb structure is MSB-first too */
> > > > +static inline u32 expand_color(u32 c)
> > > > +{
> > > > + return ((c & 1) | ((c & 2) << 7) | ((c & 4) << 14) | ((c & 8)
> > > > << 21)) * 0xFF;
> > > > +}
> > > > +
> > > > +/* s3fb_iplan_imageblit silently assumes that almost everything is
> > > > 8-pixel aligned */
> > >
> > > Hmn, same thing with vga16fb... Perhaps we should bring back the
> > > fontwidth flag of 2.2 and 2.4 kernels.
> >
> > Ug no. It is possible to get 12,6 bit width fonts working with vga
> > interleaved planes. I got it paritally working but never got back to it.
> > Its in my queue of this to do. Now that I finished the display class I
> > need to get around to makeing drm/fbdev work together :-)
> >
>
> Of course, not fontwidth exactly, but to allow the driver to specify the
> alignment of the blit engine, in this case 8 pixels. I do believe X also
> has similar functionality to compensate for the limitation of the
> hardware.
Isn't scan_align in pixmap for this? Or do we need more.
-
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] fbdev driver for S3 Trio/Virge, updated
On Thu, 2007-02-22 at 00:53 +, James Simmons wrote:
+/* image data is MSB-first, fb structure is MSB-first too */
+static inline u32 expand_color(u32 c)
+{
+ return ((c 1) | ((c 2) 7) | ((c 4) 14) | ((c 8)
21)) * 0xFF;
+}
+
+/* s3fb_iplan_imageblit silently assumes that almost everything is
8-pixel aligned */
Hmn, same thing with vga16fb... Perhaps we should bring back the
fontwidth flag of 2.2 and 2.4 kernels.
Ug no. It is possible to get 12,6 bit width fonts working with vga
interleaved planes. I got it paritally working but never got back to it.
Its in my queue of this to do. Now that I finished the display class I
need to get around to makeing drm/fbdev work together :-)
Of course, not fontwidth exactly, but to allow the driver to specify the
alignment of the blit engine, in this case 8 pixels. I do believe X also
has similar functionality to compensate for the limitation of the
hardware.
Isn't scan_align in pixmap for this? Or do we need more.
-
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] fbdev driver for S3 Trio/Virge, updated
On Wed, 2007-02-28 at 16:53 +, James Simmons wrote:
On Thu, 2007-02-22 at 00:53 +, James Simmons wrote:
+/* image data is MSB-first, fb structure is MSB-first too */
+static inline u32 expand_color(u32 c)
+{
+ return ((c 1) | ((c 2) 7) | ((c 4) 14) | ((c 8)
21)) * 0xFF;
+}
+
+/* s3fb_iplan_imageblit silently assumes that almost everything is
8-pixel aligned */
Hmn, same thing with vga16fb... Perhaps we should bring back the
fontwidth flag of 2.2 and 2.4 kernels.
Ug no. It is possible to get 12,6 bit width fonts working with vga
interleaved planes. I got it paritally working but never got back to it.
Its in my queue of this to do. Now that I finished the display class I
need to get around to makeing drm/fbdev work together :-)
Of course, not fontwidth exactly, but to allow the driver to specify the
alignment of the blit engine, in this case 8 pixels. I do believe X also
has similar functionality to compensate for the limitation of the
hardware.
Isn't scan_align in pixmap for this? Or do we need more.
No, scan_align is how much to pad each line, and it's up to the engine
to discard the padding. In this case, the hardware does not allow
padding and must be given data in exact multiples. For example, vesafb
can accept 4x4 fonts padded to 8x4, but vga16fb will not be able to draw
4x4 fonts 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] fbdev driver for S3 Trio/Virge, updated
On Fri, 2007-02-23 at 13:45 +0100, Ondrej Zajicek wrote: > On Thu, Feb 22, 2007 at 08:05:33AM +0800, Antonino A. Daplas wrote: > > On Fri, 2007-02-09 at 20:34 +0100, Ondrej Zajicek wrote: > > > This patch adds driver for S3 Trio / S3 Virge. Driver is tested > > > with most versions of S3 Trio and S3 Virge, on i386. > > > It is tested both as compiled-in and module. It is against > > > linux-2.6.20 . > > > > > > This is version 3. There are some minor modifications from version 2 > > > (mostly coding style cleanups). > > > > Nice, the first driver to use tileblit :-) > > > > Since this driver is already in the -mm tree, can you resubmit a diff > > against that? > > This driver was removed from -mm tree, because it is in 2.6.21-rc1 . > So it is probably unnnecessary to resubmit a diff, isn't it? > Okay, I thought the one in the tree was an older version. Thanks for clarifying. 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] fbdev driver for S3 Trio/Virge, updated
On Fri, 2007-02-23 at 13:45 +0100, Ondrej Zajicek wrote: On Thu, Feb 22, 2007 at 08:05:33AM +0800, Antonino A. Daplas wrote: On Fri, 2007-02-09 at 20:34 +0100, Ondrej Zajicek wrote: This patch adds driver for S3 Trio / S3 Virge. Driver is tested with most versions of S3 Trio and S3 Virge, on i386. It is tested both as compiled-in and module. It is against linux-2.6.20 . This is version 3. There are some minor modifications from version 2 (mostly coding style cleanups). Nice, the first driver to use tileblit :-) Since this driver is already in the -mm tree, can you resubmit a diff against that? This driver was removed from -mm tree, because it is in 2.6.21-rc1 . So it is probably unnnecessary to resubmit a diff, isn't it? Okay, I thought the one in the tree was an older version. Thanks for clarifying. 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] fbdev driver for S3 Trio/Virge, updated
On Thu, Feb 22, 2007 at 08:05:33AM +0800, Antonino A. Daplas wrote:
> On Fri, 2007-02-09 at 20:34 +0100, Ondrej Zajicek wrote:
> > This patch adds driver for S3 Trio / S3 Virge. Driver is tested
> > with most versions of S3 Trio and S3 Virge, on i386.
> > It is tested both as compiled-in and module. It is against
> > linux-2.6.20 .
> >
> > This is version 3. There are some minor modifications from version 2
> > (mostly coding style cleanups).
>
> Nice, the first driver to use tileblit :-)
>
> Since this driver is already in the -mm tree, can you resubmit a diff
> against that?
This driver was removed from -mm tree, because it is in 2.6.21-rc1 .
So it is probably unnnecessary to resubmit a diff, isn't it?
> > +
> > +static int s3fb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
> > + u_int transp, struct fb_info *fb)
> > +{
...
> > + case 16:
> > + if (regno >= 16)
> > + return -EINVAL;
>
> Just return success without doing anything. I presume this is
> truecolor.
OK
> > +static int s3fb_pan_display(struct fb_var_screeninfo *var, struct fb_info
> > *info) {
> > +
> > + unsigned int offset;
> > +
> > + /* Validate the offsets */
> > + if ((var->xoffset + var->xres) > var->xres_virtual)
> > + return -EINVAL;
> > + if ((var->yoffset + var->yres) > var->yres_virtual)
> > + return -EINVAL;
>
> You need not validate the offsets, fb_pan_display() does this for you.
OK
> > +/* Frame buffer operations */
> > +
> > +static struct fb_ops s3fb_ops = {
> > + .owner = THIS_MODULE,
> > + .fb_open= s3fb_open,
> > + .fb_release = s3fb_release,
> > + .fb_check_var = s3fb_check_var,
> > + .fb_set_par = s3fb_set_par,
> > + .fb_setcolreg = s3fb_setcolreg,
> > + .fb_blank = s3fb_blank,
> > + .fb_pan_display = s3fb_pan_display,
> > + .fb_fillrect= s3fb_fillrect,
> > + .fb_copyarea= cfb_copyarea,
>
> No s3fb_copyarea :-). Usually it's the other way around,
> imageblit is unaccelerated.
This driver is unaccelerated (if i don't consider text mode support as
acceleration). s3fb_fillrect and s3fb_imageblit are here because of supported
4bpp modes are not handled by cfb_* functions. cfb_copyarea works for that
modes by coincidence.
--
Ondrej 'SanTiago' Zajicek (email: [EMAIL PROTECTED], jabber: [EMAIL PROTECTED])
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-
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] fbdev driver for S3 Trio/Virge, updated
On Thu, Feb 22, 2007 at 08:05:33AM +0800, Antonino A. Daplas wrote:
On Fri, 2007-02-09 at 20:34 +0100, Ondrej Zajicek wrote:
This patch adds driver for S3 Trio / S3 Virge. Driver is tested
with most versions of S3 Trio and S3 Virge, on i386.
It is tested both as compiled-in and module. It is against
linux-2.6.20 .
This is version 3. There are some minor modifications from version 2
(mostly coding style cleanups).
Nice, the first driver to use tileblit :-)
Since this driver is already in the -mm tree, can you resubmit a diff
against that?
This driver was removed from -mm tree, because it is in 2.6.21-rc1 .
So it is probably unnnecessary to resubmit a diff, isn't it?
+
+static int s3fb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
+ u_int transp, struct fb_info *fb)
+{
...
+ case 16:
+ if (regno = 16)
+ return -EINVAL;
Just return success without doing anything. I presume this is
truecolor.
OK
+static int s3fb_pan_display(struct fb_var_screeninfo *var, struct fb_info
*info) {
+
+ unsigned int offset;
+
+ /* Validate the offsets */
+ if ((var-xoffset + var-xres) var-xres_virtual)
+ return -EINVAL;
+ if ((var-yoffset + var-yres) var-yres_virtual)
+ return -EINVAL;
You need not validate the offsets, fb_pan_display() does this for you.
OK
+/* Frame buffer operations */
+
+static struct fb_ops s3fb_ops = {
+ .owner = THIS_MODULE,
+ .fb_open= s3fb_open,
+ .fb_release = s3fb_release,
+ .fb_check_var = s3fb_check_var,
+ .fb_set_par = s3fb_set_par,
+ .fb_setcolreg = s3fb_setcolreg,
+ .fb_blank = s3fb_blank,
+ .fb_pan_display = s3fb_pan_display,
+ .fb_fillrect= s3fb_fillrect,
+ .fb_copyarea= cfb_copyarea,
No s3fb_copyarea :-). Usually it's the other way around,
imageblit is unaccelerated.
This driver is unaccelerated (if i don't consider text mode support as
acceleration). s3fb_fillrect and s3fb_imageblit are here because of supported
4bpp modes are not handled by cfb_* functions. cfb_copyarea works for that
modes by coincidence.
--
Ondrej 'SanTiago' Zajicek (email: [EMAIL PROTECTED], jabber: [EMAIL PROTECTED])
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
To err is human -- to blame it on a computer is even more so.
-
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] fbdev driver for S3 Trio/Virge, updated
On Thu, 2007-02-22 at 00:53 +, James Simmons wrote:
> > > +/* image data is MSB-first, fb structure is MSB-first too */
> > > +static inline u32 expand_color(u32 c)
> > > +{
> > > + return ((c & 1) | ((c & 2) << 7) | ((c & 4) << 14) | ((c & 8) << 21)) *
> > > 0xFF;
> > > +}
> > > +
> > > +/* s3fb_iplan_imageblit silently assumes that almost everything is
> > > 8-pixel aligned */
> >
> > Hmn, same thing with vga16fb... Perhaps we should bring back the
> > fontwidth flag of 2.2 and 2.4 kernels.
>
> Ug no. It is possible to get 12,6 bit width fonts working with vga
> interleaved planes. I got it paritally working but never got back to it.
> Its in my queue of this to do. Now that I finished the display class I
> need to get around to makeing drm/fbdev work together :-)
>
Of course, not fontwidth exactly, but to allow the driver to specify the
alignment of the blit engine, in this case 8 pixels. I do believe X also
has similar functionality to compensate for the limitation of the
hardware.
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] fbdev driver for S3 Trio/Virge, updated
> > +/* image data is MSB-first, fb structure is MSB-first too */
> > +static inline u32 expand_color(u32 c)
> > +{
> > + return ((c & 1) | ((c & 2) << 7) | ((c & 4) << 14) | ((c & 8) << 21)) *
> > 0xFF;
> > +}
> > +
> > +/* s3fb_iplan_imageblit silently assumes that almost everything is 8-pixel
> > aligned */
>
> Hmn, same thing with vga16fb... Perhaps we should bring back the
> fontwidth flag of 2.2 and 2.4 kernels.
Ug no. It is possible to get 12,6 bit width fonts working with vga
interleaved planes. I got it paritally working but never got back to it.
Its in my queue of this to do. Now that I finished the display class I
need to get around to makeing drm/fbdev work together :-)
-
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] fbdev driver for S3 Trio/Virge, updated
On Fri, 2007-02-09 at 20:34 +0100, Ondrej Zajicek wrote:
> This patch adds driver for S3 Trio / S3 Virge. Driver is tested
> with most versions of S3 Trio and S3 Virge, on i386.
> It is tested both as compiled-in and module. It is against
> linux-2.6.20 .
>
> This is version 3. There are some minor modifications from version 2
> (mostly coding style cleanups).
Nice, the first driver to use tileblit :-)
Since this driver is already in the -mm tree, can you resubmit a diff
against that?
> +
> +static const struct vga_regset s3_h_total_regs[]= {{0x00, 0, 7},
> {0x5D, 0, 0}, VGA_REGSET_END};
> +static const struct vga_regset s3_h_display_regs[] = {{0x01, 0, 7},
> {0x5D, 1, 1}, VGA_REGSET_END};
> +static const struct vga_regset s3_h_blank_start_regs[] = {{0x02, 0, 7},
> {0x5D, 2, 2}, VGA_REGSET_END};
> +static const struct vga_regset s3_h_blank_end_regs[]= {{0x03, 0, 4},
> {0x05, 7, 7}, VGA_REGSET_END};
> +static const struct vga_regset s3_h_sync_start_regs[] = {{0x04, 0, 7},
> {0x5D, 4, 4}, VGA_REGSET_END};
> +static const struct vga_regset s3_h_sync_end_regs[] = {{0x05, 0, 4},
> VGA_REGSET_END};
> +
> +static const struct vga_regset s3_v_total_regs[]= {{0x06, 0, 7},
> {0x07, 0, 0}, {0x07, 5, 5}, {0x5E, 0, 0}, VGA_REGSET_END};
> +static const struct vga_regset s3_v_display_regs[] = {{0x12, 0, 7},
> {0x07, 1, 1}, {0x07, 6, 6}, {0x5E, 1, 1}, VGA_REGSET_END};
> +static const struct vga_regset s3_v_blank_start_regs[] = {{0x15, 0, 7},
> {0x07, 3, 3}, {0x09, 5, 5}, {0x5E, 2, 2}, VGA_REGSET_END};
> +static const struct vga_regset s3_v_blank_end_regs[]= {{0x16, 0, 7},
> VGA_REGSET_END};
> +static const struct vga_regset s3_v_sync_start_regs[] = {{0x10, 0, 7},
> {0x07, 2, 2}, {0x07, 7, 7}, {0x5E, 4, 4}, VGA_REGSET_END};
> +static const struct vga_regset s3_v_sync_end_regs[] = {{0x11, 0, 3},
> VGA_REGSET_END};
> +
> +static const struct vga_regset s3_line_compare_regs[] = {{0x18, 0, 7},
> {0x07, 4, 4}, {0x09, 6, 6}, {0x5E, 6, 6}, VGA_REGSET_END};
> +static const struct vga_regset s3_start_address_regs[] = {{0x0d, 0, 7},
> {0x0c, 0, 7}, {0x31, 4, 5}, {0x51, 0, 1}, VGA_REGSET_END};
> +static const struct vga_regset s3_offset_regs[] = {{0x13, 0, 7},
> {0x51, 4, 5}, VGA_REGSET_END}; /* set 0x43 bit 2 to 0 */
> +
Within reason, try to limit each line to 80 columns.
> +
> +/* image data is MSB-first, fb structure is MSB-first too */
> +static inline u32 expand_color(u32 c)
> +{
> + return ((c & 1) | ((c & 2) << 7) | ((c & 4) << 14) | ((c & 8) << 21)) *
> 0xFF;
> +}
> +
> +/* s3fb_iplan_imageblit silently assumes that almost everything is 8-pixel
> aligned */
Hmn, same thing with vga16fb... Perhaps we should bring back the
fontwidth flag of 2.2 and 2.4 kernels.
> +
> +static int s3fb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
> + u_int transp, struct fb_info *fb)
> +{
> + switch (fb->var.bits_per_pixel) {
> + case 0:
> + case 4:
> + if (regno >= 16)
> + return -EINVAL;
> +
> + if ((fb->var.bits_per_pixel == 4) &&
> + (fb->var.nonstd == 0)) {
> + outb(0xF0, VGA_PEL_MSK);
> + outb(regno*16, VGA_PEL_IW);
> + } else {
> + outb(0x0F, VGA_PEL_MSK);
> + outb(regno, VGA_PEL_IW);
> + }
> + outb(red >> 10, VGA_PEL_D);
> + outb(green >> 10, VGA_PEL_D);
> + outb(blue >> 10, VGA_PEL_D);
> + break;
> + case 8:
> + if (regno >= 256)
> + return -EINVAL;
> +
> + outb(0xFF, VGA_PEL_MSK);
> + outb(regno, VGA_PEL_IW);
> + outb(red >> 10, VGA_PEL_D);
> + outb(green >> 10, VGA_PEL_D);
> + outb(blue >> 10, VGA_PEL_D);
> + break;
> + case 16:
> + if (regno >= 16)
> + return -EINVAL;
Just return success without doing anything. I presume this is
truecolor.
> +
> + if (fb->var.green.length == 5)
> + ((u32*)fb->pseudo_palette)[regno] = ((red & 0xF800) >>
> 1) |
> + ((green & 0xF800) >> 6) | ((blue & 0xF800) >>
> 11);
> + else if (fb->var.green.length == 6)
> + ((u32*)fb->pseudo_palette)[regno] = (red & 0xF800) |
> + ((green & 0xFC00) >> 5) | ((blue & 0xF800) >>
> 11);
> + else return -EINVAL;
Same here.
> + break;
> + case 24:
> + case 32:
> + if (regno >= 16)
> + return -EINVAL;
And here.
> +
> + ((u32*)fb->pseudo_palette)[regno] = ((transp & 0xFF00) << 16) |
> ((red & 0xFF00) << 8) |
> + (green & 0xFF00) | ((blue & 0xFF00) >> 8);
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
Re: [PATCH] fbdev driver for S3 Trio/Virge, updated
On Fri, 2007-02-09 at 20:34 +0100, Ondrej Zajicek wrote:
This patch adds driver for S3 Trio / S3 Virge. Driver is tested
with most versions of S3 Trio and S3 Virge, on i386.
It is tested both as compiled-in and module. It is against
linux-2.6.20 .
This is version 3. There are some minor modifications from version 2
(mostly coding style cleanups).
Nice, the first driver to use tileblit :-)
Since this driver is already in the -mm tree, can you resubmit a diff
against that?
+
+static const struct vga_regset s3_h_total_regs[]= {{0x00, 0, 7},
{0x5D, 0, 0}, VGA_REGSET_END};
+static const struct vga_regset s3_h_display_regs[] = {{0x01, 0, 7},
{0x5D, 1, 1}, VGA_REGSET_END};
+static const struct vga_regset s3_h_blank_start_regs[] = {{0x02, 0, 7},
{0x5D, 2, 2}, VGA_REGSET_END};
+static const struct vga_regset s3_h_blank_end_regs[]= {{0x03, 0, 4},
{0x05, 7, 7}, VGA_REGSET_END};
+static const struct vga_regset s3_h_sync_start_regs[] = {{0x04, 0, 7},
{0x5D, 4, 4}, VGA_REGSET_END};
+static const struct vga_regset s3_h_sync_end_regs[] = {{0x05, 0, 4},
VGA_REGSET_END};
+
+static const struct vga_regset s3_v_total_regs[]= {{0x06, 0, 7},
{0x07, 0, 0}, {0x07, 5, 5}, {0x5E, 0, 0}, VGA_REGSET_END};
+static const struct vga_regset s3_v_display_regs[] = {{0x12, 0, 7},
{0x07, 1, 1}, {0x07, 6, 6}, {0x5E, 1, 1}, VGA_REGSET_END};
+static const struct vga_regset s3_v_blank_start_regs[] = {{0x15, 0, 7},
{0x07, 3, 3}, {0x09, 5, 5}, {0x5E, 2, 2}, VGA_REGSET_END};
+static const struct vga_regset s3_v_blank_end_regs[]= {{0x16, 0, 7},
VGA_REGSET_END};
+static const struct vga_regset s3_v_sync_start_regs[] = {{0x10, 0, 7},
{0x07, 2, 2}, {0x07, 7, 7}, {0x5E, 4, 4}, VGA_REGSET_END};
+static const struct vga_regset s3_v_sync_end_regs[] = {{0x11, 0, 3},
VGA_REGSET_END};
+
+static const struct vga_regset s3_line_compare_regs[] = {{0x18, 0, 7},
{0x07, 4, 4}, {0x09, 6, 6}, {0x5E, 6, 6}, VGA_REGSET_END};
+static const struct vga_regset s3_start_address_regs[] = {{0x0d, 0, 7},
{0x0c, 0, 7}, {0x31, 4, 5}, {0x51, 0, 1}, VGA_REGSET_END};
+static const struct vga_regset s3_offset_regs[] = {{0x13, 0, 7},
{0x51, 4, 5}, VGA_REGSET_END}; /* set 0x43 bit 2 to 0 */
+
Within reason, try to limit each line to 80 columns.
+
+/* image data is MSB-first, fb structure is MSB-first too */
+static inline u32 expand_color(u32 c)
+{
+ return ((c 1) | ((c 2) 7) | ((c 4) 14) | ((c 8) 21)) *
0xFF;
+}
+
+/* s3fb_iplan_imageblit silently assumes that almost everything is 8-pixel
aligned */
Hmn, same thing with vga16fb... Perhaps we should bring back the
fontwidth flag of 2.2 and 2.4 kernels.
+
+static int s3fb_setcolreg(u_int regno, u_int red, u_int green, u_int blue,
+ u_int transp, struct fb_info *fb)
+{
+ switch (fb-var.bits_per_pixel) {
+ case 0:
+ case 4:
+ if (regno = 16)
+ return -EINVAL;
+
+ if ((fb-var.bits_per_pixel == 4)
+ (fb-var.nonstd == 0)) {
+ outb(0xF0, VGA_PEL_MSK);
+ outb(regno*16, VGA_PEL_IW);
+ } else {
+ outb(0x0F, VGA_PEL_MSK);
+ outb(regno, VGA_PEL_IW);
+ }
+ outb(red 10, VGA_PEL_D);
+ outb(green 10, VGA_PEL_D);
+ outb(blue 10, VGA_PEL_D);
+ break;
+ case 8:
+ if (regno = 256)
+ return -EINVAL;
+
+ outb(0xFF, VGA_PEL_MSK);
+ outb(regno, VGA_PEL_IW);
+ outb(red 10, VGA_PEL_D);
+ outb(green 10, VGA_PEL_D);
+ outb(blue 10, VGA_PEL_D);
+ break;
+ case 16:
+ if (regno = 16)
+ return -EINVAL;
Just return success without doing anything. I presume this is
truecolor.
+
+ if (fb-var.green.length == 5)
+ ((u32*)fb-pseudo_palette)[regno] = ((red 0xF800)
1) |
+ ((green 0xF800) 6) | ((blue 0xF800)
11);
+ else if (fb-var.green.length == 6)
+ ((u32*)fb-pseudo_palette)[regno] = (red 0xF800) |
+ ((green 0xFC00) 5) | ((blue 0xF800)
11);
+ else return -EINVAL;
Same here.
+ break;
+ case 24:
+ case 32:
+ if (regno = 16)
+ return -EINVAL;
And here.
+
+ ((u32*)fb-pseudo_palette)[regno] = ((transp 0xFF00) 16) |
((red 0xFF00) 8) |
+ (green 0xFF00) | ((blue 0xFF00) 8);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return 0;
+}
[snip]
+
+/* Pan the display */
+
+static int s3fb_pan_display(struct fb_var_screeninfo *var, struct fb_info
*info) {
+
+ unsigned int offset;
+
+ /*
Re: [PATCH] fbdev driver for S3 Trio/Virge, updated
+/* image data is MSB-first, fb structure is MSB-first too */
+static inline u32 expand_color(u32 c)
+{
+ return ((c 1) | ((c 2) 7) | ((c 4) 14) | ((c 8) 21)) *
0xFF;
+}
+
+/* s3fb_iplan_imageblit silently assumes that almost everything is 8-pixel
aligned */
Hmn, same thing with vga16fb... Perhaps we should bring back the
fontwidth flag of 2.2 and 2.4 kernels.
Ug no. It is possible to get 12,6 bit width fonts working with vga
interleaved planes. I got it paritally working but never got back to it.
Its in my queue of this to do. Now that I finished the display class I
need to get around to makeing drm/fbdev work together :-)
-
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] fbdev driver for S3 Trio/Virge, updated
On Thu, 2007-02-22 at 00:53 +, James Simmons wrote:
+/* image data is MSB-first, fb structure is MSB-first too */
+static inline u32 expand_color(u32 c)
+{
+ return ((c 1) | ((c 2) 7) | ((c 4) 14) | ((c 8) 21)) *
0xFF;
+}
+
+/* s3fb_iplan_imageblit silently assumes that almost everything is
8-pixel aligned */
Hmn, same thing with vga16fb... Perhaps we should bring back the
fontwidth flag of 2.2 and 2.4 kernels.
Ug no. It is possible to get 12,6 bit width fonts working with vga
interleaved planes. I got it paritally working but never got back to it.
Its in my queue of this to do. Now that I finished the display class I
need to get around to makeing drm/fbdev work together :-)
Of course, not fontwidth exactly, but to allow the driver to specify the
alignment of the blit engine, in this case 8 pixels. I do believe X also
has similar functionality to compensate for the limitation of the
hardware.
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] fbdev driver for S3 Trio/Virge, updated
Ondrej Zajicek napsal(a):
This patch adds driver for S3 Trio / S3 Virge. Driver is tested
with most versions of S3 Trio and S3 Virge, on i386.
It is tested both as compiled-in and module. It is against
linux-2.6.20 .
This is version 3. There are some minor modifications from version 2
(mostly coding style cleanups).
Signed-off-by: Ondrej Zajicek <[EMAIL PROTECTED]>
---
[...]
+/* PCI probe */
+
+static int __devinit s3_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
+{
+ struct fb_info *info;
+ struct s3fb_info *par;
+ int rc;
+ u8 regval, cr38, cr39;
+
+ /* Ignore secondary VGA device because there is no VGA arbitration */
+ if (! svga_primary_device(dev)) {
+ dev_info(&(dev->dev), "ignoring secondary device\n");
+ return -ENODEV;
+ }
+
+ /* Allocate and fill driver data structure */
+ info = framebuffer_alloc(sizeof(struct s3fb_info), NULL);
+ if (!info) {
+ dev_err(&(dev->dev), "cannot allocate memory\n");
+ return -ENOMEM;
+ }
+
+ par = info->par;
+ mutex_init(>open_lock);
+
+ info->flags = FBINFO_PARTIAL_PAN_OK | FBINFO_HWACCEL_YPAN;
+ info->fbops = _ops;
+
+ /* Prepare PCI device */
+ rc = pci_enable_device(dev);
+ if (rc < 0) {
+ dev_err(&(dev->dev), "cannot enable PCI device\n");
+ goto err_enable_device;
+ }
+
+ rc = pci_request_regions(dev, "s3fb");
+ if (rc < 0) {
+ dev_err(&(dev->dev), "cannot reserve framebuffer region\n");
+ goto err_request_regions;
+ }
+
+
+ info->fix.smem_start = pci_resource_start(dev, 0);
+ info->fix.smem_len = pci_resource_len(dev, 0);
+
+ /* Map physical IO memory address into kernel space */
+ info->screen_base = pci_iomap(dev, 0, 0);
+ if (! info->screen_base) {
+ rc = -ENOMEM;
+ dev_err(&(dev->dev), "iomap for framebuffer failed\n");
+ goto err_iomap;
+ }
+
+ /* Unlock regs */
+ cr38 = vga_rcrt(NULL, 0x38);
+ cr39 = vga_rcrt(NULL, 0x39);
+ vga_wseq(NULL, 0x08, 0x06);
+ vga_wcrt(NULL, 0x38, 0x48);
+ vga_wcrt(NULL, 0x39, 0xA5);
+
+ /* Find how many physical memory there is on card */
+ /* 0x36 register is accessible even if other registers are locked */
+ regval = vga_rcrt(NULL, 0x36);
+ info->screen_size = s3_memsizes[regval >> 5] << 10;
+ info->fix.smem_len = info->screen_size;
+
+ par->chip = id->driver_data & CHIP_MASK;
+ par->rev = vga_rcrt(NULL, 0x2f);
+ if (par->chip & CHIP_UNDECIDED_FLAG)
+ par->chip = s3_identification(par->chip);
+
+ /* Find MCLK frequency */
+ regval = vga_rseq(NULL, 0x10);
+ par->mclk_freq = ((vga_rseq(NULL, 0x11) + 2) * 14318) / ((regval &
0x1F) + 2);
+ par->mclk_freq = par->mclk_freq >> (regval >> 5);
+
+ /* Restore locks */
+ vga_wcrt(NULL, 0x38, cr38);
+ vga_wcrt(NULL, 0x39, cr39);
+
+ strcpy(info->fix.id, s3_names [par->chip]);
+ info->fix.mmio_start = 0;
+ info->fix.mmio_len = 0;
+ info->fix.type = FB_TYPE_PACKED_PIXELS;
+ info->fix.visual = FB_VISUAL_PSEUDOCOLOR;
+ info->fix.ypanstep = 0;
+ info->fix.accel = FB_ACCEL_NONE;
+ info->pseudo_palette = (void*) (par->pseudo_palette);
+
+ /* Prepare startup mode */
+ rc = fb_find_mode(&(info->var), info, mode, NULL, 0, NULL, 8);
+ if (! ((rc == 1) || (rc == 2))) {
+ rc = -EINVAL;
+ dev_err(&(dev->dev), "mode %s not found\n", mode);
+ goto err_find_mode;
+ }
+
+ rc = fb_alloc_cmap(>cmap, 256, 0);
+ if (rc < 0) {
+ dev_err(&(dev->dev), "cannot allocate colormap\n");
+ goto err_alloc_cmap;
+ }
+
+ rc = register_framebuffer(info);
+ if (rc < 0) {
+ dev_err(&(dev->dev), "cannot register framebugger\n");
Bugger :DD LOL? Buffer?
+ goto err_reg_fb;
+ }
+
+ printk(KERN_INFO "fb%d: %s on %s, %d MB RAM, %d MHz MCLK\n", info->node,
info->fix.id,
+pci_name(dev), info->fix.smem_len >> 20, (par->mclk_freq +
500) / 1000);
+
+ if (par->chip == CHIP_UNKNOWN)
+ printk(KERN_INFO "fb%d: unknown chip, CR2D=%x, CR2E=%x, CRT2F=%x,
CRT30=%x\n",
+ info->node, vga_rcrt(NULL, 0x2d), vga_rcrt(NULL, 0x2e),
+ vga_rcrt(NULL, 0x2f), vga_rcrt(NULL, 0x30));
dev_info x 2, but it's a dite.
+
+ /* Record a reference to the driver data */
+ pci_set_drvdata(dev, info);
+
+#ifdef CONFIG_MTRR
+ if (mtrr) {
+ par->mtrr_reg = -1;
+ par->mtrr_reg = mtrr_add(info->fix.smem_start,
info->fix.smem_len, MTRR_TYPE_WRCOMB, 1);
+ }
+#endif
+
+ return 0;
+
+ /* Error handling */
+err_reg_fb:
+
Re: [PATCH] fbdev driver for S3 Trio/Virge, updated
Ondrej Zajicek napsal(a):
This patch adds driver for S3 Trio / S3 Virge. Driver is tested
with most versions of S3 Trio and S3 Virge, on i386.
It is tested both as compiled-in and module. It is against
linux-2.6.20 .
This is version 3. There are some minor modifications from version 2
(mostly coding style cleanups).
Signed-off-by: Ondrej Zajicek [EMAIL PROTECTED]
---
[...]
+/* PCI probe */
+
+static int __devinit s3_pci_probe(struct pci_dev *dev, const struct
pci_device_id *id)
+{
+ struct fb_info *info;
+ struct s3fb_info *par;
+ int rc;
+ u8 regval, cr38, cr39;
+
+ /* Ignore secondary VGA device because there is no VGA arbitration */
+ if (! svga_primary_device(dev)) {
+ dev_info((dev-dev), ignoring secondary device\n);
+ return -ENODEV;
+ }
+
+ /* Allocate and fill driver data structure */
+ info = framebuffer_alloc(sizeof(struct s3fb_info), NULL);
+ if (!info) {
+ dev_err((dev-dev), cannot allocate memory\n);
+ return -ENOMEM;
+ }
+
+ par = info-par;
+ mutex_init(par-open_lock);
+
+ info-flags = FBINFO_PARTIAL_PAN_OK | FBINFO_HWACCEL_YPAN;
+ info-fbops = s3fb_ops;
+
+ /* Prepare PCI device */
+ rc = pci_enable_device(dev);
+ if (rc 0) {
+ dev_err((dev-dev), cannot enable PCI device\n);
+ goto err_enable_device;
+ }
+
+ rc = pci_request_regions(dev, s3fb);
+ if (rc 0) {
+ dev_err((dev-dev), cannot reserve framebuffer region\n);
+ goto err_request_regions;
+ }
+
+
+ info-fix.smem_start = pci_resource_start(dev, 0);
+ info-fix.smem_len = pci_resource_len(dev, 0);
+
+ /* Map physical IO memory address into kernel space */
+ info-screen_base = pci_iomap(dev, 0, 0);
+ if (! info-screen_base) {
+ rc = -ENOMEM;
+ dev_err((dev-dev), iomap for framebuffer failed\n);
+ goto err_iomap;
+ }
+
+ /* Unlock regs */
+ cr38 = vga_rcrt(NULL, 0x38);
+ cr39 = vga_rcrt(NULL, 0x39);
+ vga_wseq(NULL, 0x08, 0x06);
+ vga_wcrt(NULL, 0x38, 0x48);
+ vga_wcrt(NULL, 0x39, 0xA5);
+
+ /* Find how many physical memory there is on card */
+ /* 0x36 register is accessible even if other registers are locked */
+ regval = vga_rcrt(NULL, 0x36);
+ info-screen_size = s3_memsizes[regval 5] 10;
+ info-fix.smem_len = info-screen_size;
+
+ par-chip = id-driver_data CHIP_MASK;
+ par-rev = vga_rcrt(NULL, 0x2f);
+ if (par-chip CHIP_UNDECIDED_FLAG)
+ par-chip = s3_identification(par-chip);
+
+ /* Find MCLK frequency */
+ regval = vga_rseq(NULL, 0x10);
+ par-mclk_freq = ((vga_rseq(NULL, 0x11) + 2) * 14318) / ((regval
0x1F) + 2);
+ par-mclk_freq = par-mclk_freq (regval 5);
+
+ /* Restore locks */
+ vga_wcrt(NULL, 0x38, cr38);
+ vga_wcrt(NULL, 0x39, cr39);
+
+ strcpy(info-fix.id, s3_names [par-chip]);
+ info-fix.mmio_start = 0;
+ info-fix.mmio_len = 0;
+ info-fix.type = FB_TYPE_PACKED_PIXELS;
+ info-fix.visual = FB_VISUAL_PSEUDOCOLOR;
+ info-fix.ypanstep = 0;
+ info-fix.accel = FB_ACCEL_NONE;
+ info-pseudo_palette = (void*) (par-pseudo_palette);
+
+ /* Prepare startup mode */
+ rc = fb_find_mode((info-var), info, mode, NULL, 0, NULL, 8);
+ if (! ((rc == 1) || (rc == 2))) {
+ rc = -EINVAL;
+ dev_err((dev-dev), mode %s not found\n, mode);
+ goto err_find_mode;
+ }
+
+ rc = fb_alloc_cmap(info-cmap, 256, 0);
+ if (rc 0) {
+ dev_err((dev-dev), cannot allocate colormap\n);
+ goto err_alloc_cmap;
+ }
+
+ rc = register_framebuffer(info);
+ if (rc 0) {
+ dev_err((dev-dev), cannot register framebugger\n);
Bugger :DD LOL? Buffer?
+ goto err_reg_fb;
+ }
+
+ printk(KERN_INFO fb%d: %s on %s, %d MB RAM, %d MHz MCLK\n, info-node,
info-fix.id,
+pci_name(dev), info-fix.smem_len 20, (par-mclk_freq +
500) / 1000);
+
+ if (par-chip == CHIP_UNKNOWN)
+ printk(KERN_INFO fb%d: unknown chip, CR2D=%x, CR2E=%x, CRT2F=%x,
CRT30=%x\n,
+ info-node, vga_rcrt(NULL, 0x2d), vga_rcrt(NULL, 0x2e),
+ vga_rcrt(NULL, 0x2f), vga_rcrt(NULL, 0x30));
dev_info x 2, but it's a dite.
+
+ /* Record a reference to the driver data */
+ pci_set_drvdata(dev, info);
+
+#ifdef CONFIG_MTRR
+ if (mtrr) {
+ par-mtrr_reg = -1;
+ par-mtrr_reg = mtrr_add(info-fix.smem_start,
info-fix.smem_len, MTRR_TYPE_WRCOMB, 1);
+ }
+#endif
+
+ return 0;
+
+ /* Error handling */
+err_reg_fb:
+ fb_dealloc_cmap(info-cmap);
+err_alloc_cmap:
+err_find_mode:
+ pci_iounmap(dev,
