linux-fbdev-devel — linux-fbdev mailing list for project developers

Re: [Linux-fbdev-devel] why not put LOGO_W and LOGO_H in linux_logo.h ?

[James S. <jsi...@in...>]

> > Good question. Is there any reason why this is?
> it's more easy to change the logo if it is in linux_logo.h
>
> i modified fblogo, to make a linux_logo.h with LOGO_W and LOGO_H.

Geert how do you feel about thsi change?

RE: [Linux-fbdev-devel] 2.5 atyfb on Sparc question

[James S. <jsi...@in...>]

> > Oops. Fixed now.
> >
> Whoa, that was neat!  ;o)

Can you try the latest changes in my BK tree.

Re: [Linux-fbdev-devel] fbdev tree pulled into Linus tree

[James S. <jsi...@in...>]

> Hello James,
>   besides that the beast does not compile because of
> the use of p->type instead of info->fix.type in the logo code,
> what's the reason for having next_line, next_plane

I believe that is for ilbm support. I plan to have those go away soon.

> (and maybe other too - can_soft_blank, inverse, yscroll)
> in the display struct, if you moved rest of the values
> into fix.

That stuff will be cleaned up soon. My next set of changes will be big.

> So now I maintain half of state in per-display
> structs, and half in the per-fbdev structure? Nigthmare.
> Can you create some ('tmp' or 'par' or whatever) structure
> and hold them in fb_info too?

This is for the next set of changes. I'm working on them right now.

>   Also because of you moved these type/line_length and
> other into the fix, there is no point in having dispsw
> in the display struct: these functions must not be invoked
> on the fbdev with con != fbcon.currcon now because of
> part of state exists only for foreground console now. So
> move them into per-fb_info structure too, and handle
> con != fbcon.currcon in generic code (if not done already).

Working on it.

>   Then it will be clear what is really per-VT structure
> which should be maintained by upper layer, and what is
> fbdev bussiness. And while you'll move dispsw pointer, change
> it to the embeded structure. It will make life easier to
> atafb and matroxfb at least, as they like to modify fb_ops
> according to the hardware they find, and currently they
> modify structure global to the driver.

As the new cfb* functions mature I can get ride of dispsw and use the
accel pointer directly.

> P.S.: I do not have your new email address here at home,
> and you are neither in MAINTAINERS nor in the CREDITS,
> I hope that the address I randomly choosed from the credits
> in fbdev files will work.

I'm in MAINTAINERS and CREDITS in BK now.

Re: [Linux-fbdev-devel] which's the max resolution of the logo ?

[Stephane W. <ste...@be...>]

ok, i understood the problem with my patch of the logo.

thanks
On Thu, Aug 22, 2002 at 12:00:51PM -0700, James Simmons wrote:
> 
> Eahc logo is 80x80 in size and there is one logo displayed per cpu.
> 
> 
> MS: (n) 1. A debilitating and surprisingly widespread affliction that
> renders the sufferer barely able to perform the simplest task. 2. A disease.
> 
> James Simmons  [jsi...@us...] 	                ____/|
> fbdev/console/gfx developer                             \ o.O|
> http://www.linux-fbdev.org                               =(_)=
> http://linuxgfx.sourceforge.net                            U
> http://linuxconsole.sourceforge.net
> 
> On Sat, 10 Aug 2002, Stephane Wirtel wrote:
> 
> > which is the max resolution of the logo ? because i can't set a picture
> > in 16bits or more.
> >
> > thanks
> >
> > --
> > Stephane Wirtel <ste...@be...>
> > Web : www.linux-mons.be	 "Linux Is Not UniX !!!"
> > Address :
> >     Rue de cartier, 53
> >     6030 Marchienne-au-Pont
> >     Belgium
> > Phone :	+32 474 768 072
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Linux-fbdev-devel mailing list
> > Lin...@li...
> > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
> >
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

-- 
Stephane Wirtel <ste...@be...>
Web : www.linux-mons.be	 "Linux Is Not UniX !!!"

Re: [Linux-fbdev-devel] which's the max resolution of the logo ?

[James S. <jsi...@in...>]

Eahc logo is 80x80 in size and there is one logo displayed per cpu.


MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@us...] 	                ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

On Sat, 10 Aug 2002, Stephane Wirtel wrote:

> which is the max resolution of the logo ? because i can't set a picture
> in 16bits or more.
>
> thanks
>
> --
> Stephane Wirtel <ste...@be...>
> Web : www.linux-mons.be	 "Linux Is Not UniX !!!"
> Address :
>     Rue de cartier, 53
>     6030 Marchienne-au-Pont
>     Belgium
> Phone :	+32 474 768 072
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
>

Re: [Linux-fbdev-devel] why not a specific driver for nvidia geforce ?

[James S. <jsi...@in...>]

That is the Riva driver. Give it a try.


MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@us...] 	                ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

On Sat, 10 Aug 2002, Stephane Wirtel wrote:

> thanks
> --
> Stephane Wirtel <ste...@be...>
> Web : www.linux-mons.be	 "Linux Is Not UniX !!!"
> Address :
>     Rue de cartier, 53
>     6030 Marchienne-au-Pont
>     Belgium
> Phone :	+32 474 768 072
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
>

Re: [Linux-fbdev-devel] why not put LOGO_W and LOGO_H in linux_logo.h ?

[Stephane W. <ste...@be...>]

On Thu, Aug 22, 2002 at 11:44:25AM -0700, James Simmons wrote:
> 
> Good question. Is there any reason why this is?
it's more easy to change the logo if it is in linux_logo.h

i modified fblogo, to make a linux_logo.h with LOGO_W and LOGO_H.

> 
> MS: (n) 1. A debilitating and surprisingly widespread affliction that
> renders the sufferer barely able to perform the simplest task. 2. A disease.
> 
> James Simmons  [jsi...@us...] 	                ____/|
> fbdev/console/gfx developer                             \ o.O|
> http://www.linux-fbdev.org                               =(_)=
> http://linuxgfx.sourceforge.net                            U
> http://linuxconsole.sourceforge.net
> 
> On Sat, 17 Aug 2002, Stephane Wirtel wrote:
> 
> >
> > --
> > Stephane Wirtel <ste...@be...>
> > Web : www.linux-mons.be	 "Linux Is Not UniX !!!"
> >
> >
> > -------------------------------------------------------
> > This sf.net email is sponsored by: OSDN - Tired of that same old
> > cell phone?  Get a new here for FREE!
> > https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> > _______________________________________________
> > Linux-fbdev-devel mailing list
> > Lin...@li...
> > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
> >
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

-- 
Stephane Wirtel <ste...@be...>
Web : www.linux-mons.be	 "Linux Is Not UniX !!!"

Re: [Linux-fbdev-devel] (no subject)

[James S. <jsi...@in...>]

> 	Hi,
>
> In cfb_copyarea(), `tmp' must be unsigned long because it is used to store
> unsigned long values (see patch at the end).

Oops. This might fix the one bug I see sometimes. When I delete some
characters some of the remaining characters get corrputed.

> cfb_copyarea() also doesn't clear the bits to modify in the first and last
> words of a line, e.g. it does
>
> |	last = (FB_READ(src) & start_mask);
> |
> |	if (shift > 0)
> |		FB_WRITE(FB_READ(dst) | (last >> shift_right), dst);
>                          ^^^^^^^^^^^^
> After this read, the bits to modify must be cleared first, before the OR!
>
> I'm working on a version of cfb_copyarea() that fixes this and handles _all_
> possible values of var.bits_per_pixel (the current code assumes
> var.bits_per_pixel is a multiple of 8). Stay tuned!

Yeah!!! Will test.

Re: [Linux-fbdev-devel] why not put LOGO_W and LOGO_H in linux_logo.h ?

[James S. <jsi...@in...>]

Good question. Is there any reason why this is?

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@us...] 	                ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

On Sat, 17 Aug 2002, Stephane Wirtel wrote:

>
> --
> Stephane Wirtel <ste...@be...>
> Web : www.linux-mons.be	 "Linux Is Not UniX !!!"
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
>

Re: [Linux-fbdev-devel] [PATCH] broken cfb* support in the

[James S. <jsi...@in...>]

> Which new API?

The one being worked on for the last 2 years.

> If you are going to remove logo and unaccelerated fbcon-cfb*,
> then remove them completely. If you are not going to remove unaccelerated
> fbcon-cfb*, then there is no reason for breaking them.

The next set of round of changes will will reimplement drawing the penguin
and will support 24 bpp mode. So we will be able to remove fbcon-cfb*
completely the next round.

> I'm not going to remove unaccelerated code from the matroxfb. Never.

Then implement your own soft accel functions.

Re: [Linux-fbdev-devel] [PATCH] broken cfb* support in the 2.5.31-bk

[Geert U. <ge...@li...>]

On Thu, 22 Aug 2002, James Simmons wrote:
> > > > Anyway, you could apply this patch, for a start.  I wish you would be
> > > > a bit more careful about details.
> > >
> > > Done. Well the good news is I have aquired more hardware for different
> > > platforms to test my work on :-)
> >
> > You don't need more hardware to protect yourself against such typos. A
> > cross-compiler (or sometimes even your native gcc) is sufficient ;-)
> 
> That I also lack except for ARM and mips. Do you know where I can get a
> developement kit for for ppc and m68k?

The usual rules for creating cross-{binutils,gcc} apply here.

If you run Debian, check out the toolchain-source package.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [Linux-fbdev-devel] cfbimgblt.c

[James S. <jsi...@in...>]

> Hi,
>
> I want to address some of the limitations of cfbimgblt.c, but
> unfortunately I ended up practically rewriting the whole code.  In
> theory, the code (slow_imageblit):

Done.

> a. supports all possible bit depths

Needs to added.

> b. should be able to handle destination writes that are not aligned by
> an unsigned long

Not added.
> c.  should be able to handle fix->line_length not a multiple of an
> unsigned long

Access is also a unsigned long but currently is not aligned. It will be
fixed.
> d. framebuffer access is always the size of an unsigned long and aligned

Yeah!!!
> e. preliminary code for drawing the logo.

Paul please test the code.

> f. added Paul Mackerra's endianness patch (plus some of my own), but I
> have no big-endian machine, so it's untested, and perhaps incorrect.

> The only tests I've done for slow_imageblit is at 8, 16, 24, and 32 bpp,
> and forcibly misaligning image->dx by 1 pixel. The code is slow, so I
> included fast_imageblit for 8, 16 and 32 bpp which is an implementation
> of fbcon-cfb8/16/32.c.

Will begin testing today.


MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@us...] 	                ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

Re: [Linux-fbdev-devel] [PATCH] broken cfb* support in the 2.5.31-bk

[James S. <jsi...@in...>]

> > > Anyway, you could apply this patch, for a start.  I wish you would be
> > > a bit more careful about details.
> >
> > Done. Well the good news is I have aquired more hardware for different
> > platforms to test my work on :-)
>
> You don't need more hardware to protect yourself against such typos. A
> cross-compiler (or sometimes even your native gcc) is sufficient ;-)

That I also lack except for ARM and mips. Do you know where I can get a
developement kit for for ppc and m68k?

Re: [Linux-fbdev-devel] [PATCH] broken cfb* support in the 2.5.31-bk

[Geert U. <ge...@li...>]

On Thu, 22 Aug 2002, James Simmons wrote:
> > Anyway, you could apply this patch, for a start.  I wish you would be
> > a bit more careful about details.
> 
> Done. Well the good news is I have aquired more hardware for different
> platforms to test my work on :-)

You don't need more hardware to protect yourself against such typos. A
cross-compiler (or sometimes even your native gcc) is sufficient ;-)

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [Linux-fbdev-devel] drawings ops structures

[James S. <jsi...@in...>]

> Then I start to wonder ...
>   - why are dx and dy in struct fb_image of type __u16, while they are of type
>    __u32 in struct fb_copyarea and struct fb_fillrect?
>   - why is the order of the fields different for each structure?
>     Wouldn't it be better to always use the same order for the common fields,
>     e.g.
>
> 	__u32 dx;
> 	__u32 dy;
> 	__u32 width;
> 	__u32 height;

I cleaned it up. We have now:

struct fb_copyarea {
        __u32 sx;       /* screen-relative */
        __u32 sy;
        __u32 dx;
        __u32 dy;
        __u32 width;
        __u32 height;
};

struct fb_fillrect {
        __u32 dx;       /* screen-relative */
        __u32 dy;
        __u32 width;
        __u32 height;
        __u32 color;
        __u32 rop;
};

struct fb_image {
        __u32 dx;       /* Where to place image */
        __u32 dy;
        __u32 width;    /* Size of image */
        __u32 height;
        __u32 fg_color; /* Only used when a mono bitmap */
        __u32 bg_color;
        __u8  depth;    /* Dpeth of the image */
        char  *data;    /* Pointer to image data */
};

[Linux-fbdev-devel] Re: [PATCH] fixes for atyfb

[James S. <jsi...@in...>]

> This patch fixes a number of problems in atyfb.

Applied.

Re: [Linux-fbdev-devel] [PATCH] broken cfb* support in the 2.5.31-bk

[James S. <jsi...@in...>]

> > That was done to push people to port there drivers to the new api.
>
> Well, what _is_ the new API?

From the details in skeletonfb.c.

 *  I have started rewriting this driver as a example of the upcoming new API
 *  The primary goal is to remove the console code from fbdev and place it
 *  into fbcon.c. This reduces the code and makes writing a new fbdev driver
 *  easy since the author doesn't need to worry about console internals. It
 *  also allows the ability to run fbdev without a console/tty system on top
 *  of it.
 *
 *  First the roles of struct fb_info and struct display have changed. Struct
 *  display will go away. The way the the new framebuffer console code will
 *  work is that it will act to translate data about the tty/console in
 *  struct vc_data to data in a device independent way in struct fb_info. Then
 *  various functions in struct fb_ops will be called to store the device
 *  dependent state in the par field in struct fb_info and to change the
 *  hardware to that state. This allows a very clean seperation of the fbdev
 *  layer from the console layer. It also allows one to use fbdev on its own
 *  which is a bounus for embedded devices. The reason this approach works is
 *  for each framebuffer device when used as a tty/console device is allocated
 *  a set of virtual terminals to it. Only one virtual terminal can be active
 *  per framebuffer device. We already have all the data we need in struct
 *  vc_data so why store a bunch of colormaps and other fbdev specific data
 *  per virtual terminal.

 *  As you can see doing this makes the con parameter pretty much useless
 *  for struct fb_ops functions, as it should be. Also having struct
 *  fb_var_screeninfo and other data in fb_info pretty much eliminates the
 *  need for get_fix and get_var. Once all drivers use the fix, var, and cmap
 *  fbcon can be written around these fields. This will also eliminate the
 *  need to regenerate struct fb_var_screeninfo, struct fb_fix_screeninfo
 *  struct fb_cmap every time get_var, get_fix, get_cmap functions are called
 *  as many drivers do now.

See skeletonfb.c for further details.

> Anyway, you could apply this patch, for a start.  I wish you would be
> a bit more careful about details.

Done. Well the good news is I have aquired more hardware for different
platforms to test my work on :-)

MS: (n) 1. A debilitating and surprisingly widespread affliction that
renders the sufferer barely able to perform the simplest task. 2. A disease.

James Simmons  [jsi...@us...] 	                ____/|
fbdev/console/gfx developer                             \ o.O|
http://www.linux-fbdev.org                               =(_)=
http://linuxgfx.sourceforge.net                            U
http://linuxconsole.sourceforge.net

[Linux-fbdev-devel] National Geode drivers

[Alex P. <apa...@ea...>]

Hello folks,

I figure this is a good place to put a message about this so people will be
able find this in the future.  I have sucessfully compiled National
Semiconductor's 1.1.7 Geode kernel framebuffer driver for Linux 2.4.19, and
had the screen come up.  The files are at www.eason.com/linux.    They work,
but they aren't pretty.  (They ARE for multiple OSes/chipsets though).

The drivers are chock-full of features that are commented out and for
different platforms.  This specific configuration works on an Advantech
PCM-5820 board, and I suspect it would work on most of the similar boards
out there.  

Later 1.2.0 drivers are also available on the above mentioned site, but it
appears all they do is add more hooks for National's custom framebuffer
acceleration.

Alex Pavloff
Software Engineer
Eason Technology
 

[Linux-fbdev-devel] cfbimgblt.c

[Antonino D. <ad...@po...>]

Hi, 

I want to address some of the limitations of cfbimgblt.c, but
unfortunately I ended up practically rewriting the whole code.  In
theory, the code (slow_imageblit): 

a. supports all possible bit depths 
b. should be able to handle destination writes that are not aligned by
an unsigned long 
c.  should be able to handle fix->line_length not a multiple of an
unsigned long 
d. framebuffer access is always the size of an unsigned long and aligned
e. preliminary code for drawing the logo. 
f. added Paul Mackerra's endianness patch (plus some of my own), but I
have no big-endian machine, so it's untested, and perhaps incorrect. 

The only tests I've done for slow_imageblit is at 8, 16, 24, and 32 bpp,
and forcibly misaligning image->dx by 1 pixel. The code is slow, so I
included fast_imageblit for 8, 16 and 32 bpp which is an implementation
of fbcon-cfb8/16/32.c. 

Tony 

Re: [Linux-fbdev-devel] TV Out control and Product selection.

[Petr V. <van...@vc...>]

On Mon, Aug 19, 2002 at 03:52:49PM +0100, Francis Reader wrote:
> Is it me, or is it becoming extremley difficult to spec a card that supports
> one of the many fb drivers, AND allow you to control the "tv out"
> capabilities on board.

What you want to control?
 
> Most of the drivers I've come across allow you to control the TV Dacs
> through X, but have put very little effort in providing fb support for the
> same device.
> 
> ATI are refusing to talk due to IP issues with Macrovision, NVidia only
> support this functionality through the XFree driver, the SiS driver
> currently has no standard way of controlling this.

Matrox also refuses to document it... but because of Matrox refuses to
release docs for anything after G400, it is not big surprise. 

matroxfb from 2.5.32, or patches from 
ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/*-tvo*.gz allow you
to use TVOut on G450/G550. TVOut on G400 is supported for years.

Patch from platan has an additional feature which allows you to change
brightness/contrast by using 'v4lctl -c /dev/fb0 bright ...'. matroxfb
supports only composite/svhs output, rgb scart is not supported without
changing sources.

Please note that G450/G550 hardware can do TV output only from /dev/fb1,
so you are limited to 15/16/32bpp, without gamma correction, and with
matroxfb also unaccelerated.
						Petr Vandrovec
						van...@vc...
							

[Linux-fbdev-devel] [PATCH] fix endian problems in cfb_imageblit

[Paul M. <pa...@sa...>]

The cfb_imageblit() function in drivers/video/cfbimgblt.c is broken on
big-endian machines.  Using test_bit on the font data is a really bad
idea.  First, on big-endian machines it doesn't test the bit you
expect, and secondly, many architectures require the pointer argument
to be 4-byte or 8-byte aligned.  Finally, the loop was always doing
the pixels right-to-left within a 32-bit word, which is wrong on
big-endian machines.

Here is a patch that fixes these problems.

Paul.

diff -urN linux-2.5/drivers/video/cfbimgblt.c pmac-2.5/drivers/video/cfbimgblt.c
--- linux-2.5/drivers/video/cfbimgblt.c	Mon Jun 10 03:39:17 2002
+++ pmac-2.5/drivers/video/cfbimgblt.c	Sat Aug 17 21:15:26 2002
@@ -41,11 +41,21 @@
 #define DPRINTK(fmt, args...)
 #endif
 
+#ifdef __BIG_ENDIAN
+#define LEFT_POS(bpp)		(BITS_PER_LONG - bpp)
+#define NEXT_POS(pos, bpp)	((pos) -= (bpp))
+#else
+#define LEFT_POS(bpp)		(0)
+#define NEXT_POS(pos, bpp)	((pos) += (bpp))
+#endif
+
 void cfb_imageblit(struct fb_info *p, struct fb_image *image)
 {
 	int pad, ppw;
 	int x2, y2, n, i, j, k, l = 7;
-	unsigned long tmp = ~0 << (BITS_PER_LONG - p->var.bits_per_pixel);
+	int bpp = p->var.bits_per_pixel;
+	int ppos;
+	unsigned long tmp = (1 << bpp) - 1;
 	unsigned long fgx, bgx, fgcolor, bgcolor, eorx;	
 	unsigned long end_mask;
 	unsigned long *dst = NULL;
@@ -66,11 +76,11 @@
 	image->height = y2 - image->dy;
   
 	dst1 = p->screen_base + image->dy * p->fix.line_length + 
-		((image->dx * p->var.bits_per_pixel) >> 3);
+		((image->dx * bpp) >> 3);
   
-	ppw = BITS_PER_LONG/p->var.bits_per_pixel;
+	ppw = BITS_PER_LONG / bpp;
 
-	src = image->data;	
+	src = image->data;
 
 	if (image->depth == 1) {
 
@@ -83,8 +93,8 @@
 		}	
  
 		for (i = 0; i < ppw-1; i++) {
-			fgx <<= p->var.bits_per_pixel;
-			bgx <<= p->var.bits_per_pixel;
+			fgx <<= bpp;
+			bgx <<= bpp;
 			fgx |= fgcolor;
 			bgx |= bgcolor;
 		}
@@ -98,10 +108,12 @@
 		
 			for (j = image->width/ppw; j > 0; j--) {
 				end_mask = 0;
-		
+				ppos = LEFT_POS(bpp);
+
 				for (k = ppw; k > 0; k--) {
-					if (test_bit(l, (unsigned long *) src))
-						end_mask |= (tmp >> (p->var.bits_per_pixel*(k-1)));
+					if (*src & (1 << l))
+						end_mask |= tmp << ppos;
+					NEXT_POS(ppos, bpp);
 					l--;
 					if (l < 0) { l = 7; src++; }
 				}
@@ -110,10 +122,12 @@
 			}
 		
 			if (n) {
-				end_mask = 0;	
+				end_mask = 0;
+				ppos = LEFT_POS(bpp);
 				for (j = n; j > 0; j--) {
-					if (test_bit(l, (unsigned long *) src))
-						end_mask |= (tmp >> (p->var.bits_per_pixel*(j-1)));
+					if (*src & (1 << l))
+						end_mask |= tmp << ppos;
+					NEXT_POS(ppos, bpp);
 					l--;
 					if (l < 0) { l = 7; src++; }
 				}
@@ -125,7 +139,7 @@
 		}	
 	} else {
 		/* Draw the penguin */
-		n = ((image->width * p->var.bits_per_pixel) >> 3);
+		n = ((image->width * bpp) >> 3);
 		end_mask = 0;
 	}
 }

[Linux-fbdev-devel] drawings ops structures

[Geert U. <ge...@li...>]

If I look at these definitions in <linux/fb.h>:

| struct fb_copyarea {
|         __u32 sx;       /* screen-relative */
|         __u32 sy;
|         __u32 width;
|         __u32 height;
|         __u32 dx;
|         __u32 dy;
| };
| 
| struct fb_fillrect {
|         __u32 dx;       /* screen-relative */
|         __u32 dy;
|         __u32 width;
|         __u32 height;
|         __u32 color;
|         __u32 rop;
| };
| 
| struct fb_image {
|         __u32 width;    /* Size of image */
|         __u32 height;
|         __u16 dx;       /* Where to place image */
|         __u16 dy;
|         __u32 fg_color; /* Only used when a mono bitmap */
|         __u32 bg_color;
|         __u8  depth;    /* Dpeth of the image */
|         char  *data;    /* Pointer to image data */
| };

Then I start to wonder ...
  - why are dx and dy in struct fb_image of type __u16, while they are of type
   __u32 in struct fb_copyarea and struct fb_fillrect?
  - why is the order of the fields different for each structure?
    Wouldn't it be better to always use the same order for the common fields,
    e.g.

	__u32 dx;
	__u32 dy;
	__u32 width;
	__u32 height;

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

[Linux-fbdev-devel] vga bashing et al.

[Gul J. <jon...@ma...>]

Hello!!

If anyone has code to set up a display by writing directly
to the VGA hardware, i would desperately like to see it.
All the information i found on programming the VGA regs
would take me quite a little time to elaborate.
And (this would rather belong on the user mailing list,
i guess) perhaps i overlooked something, but i haven't
found any explanation of how to manipulate vesafb's colour
map in 8bpp modes. ('colormap' section missing in Console
programming howto :()

Jonas

-- 
__________________________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup

[Linux-fbdev-devel] [PATCH] ATI Rage 128 Pro (aty128fb) acceleration fix

[Sergey V. <vs...@al...>]

Hello!

I have found a problem with the aty128fb framebuffer driver. I am using
kernel 2.4.18 (precisely,
ftp://ftp.altlinux.ru/pub/distributions/ALTLinux/Master/2.0/SRPMS.Master/kernel24-2.4.18-alt6master.src.rpm,
uniprocessor config) with the ATI Rage 128 Pro (32M) video card. aty128fb
is loaded as a module in the startup scripts without any module options,
then it is configured by fbset (though the problem is visible even in the
default 640x480 mode).

In this configuration sometimes there is garbage on the screen (parts of
characters, usually in place of spaces). The effect is visible in mutt
(when sorting by threads and there are many long threads) and in aptitude
(pull down the menu and press Left and Right to move between different
submenus).

I looked into aty128fb.c and found two possible problems:

1. The driver does not wrap display_switch.{clear,revc} in all color
depths, therefore some video memory access might be overlapping with the
accelerator.

2. The accelerated bmove function always uses left-to-right and
top-to-bottom direction, without checking the actual direction of move.
When doing overlapped copies, this causes corruption. (The "insert
characters" control code, which causes part of the line to be shifted
right, triggers the problem.)

I have made a patch against the driver sources included in
kernel24-2.4.18-alt6master to fix the problems. (The patch also applies
cleanly to the latest 2.4.x aty128fb as seen at
http://ppc.bkbits.net:8080/linux_2_4/anno/drivers/video/aty128fb.c@1.9?nav=index.html|src/.|src/drivers|src/drivers/video).

On my system, with the Rage128 Pro card, the fixed driver looks stable. 

Note about the patch: the first two hunks fix aty128_rectcopy() (problem
#2), the rest add wrappers for *_clear and *_revc (problem #1).

-- 
Sergey Vlasov

[Linux-fbdev-devel] TV Out control and Product selection.

[Francis R. <fr...@im...>]

Is it me, or is it becoming extremley difficult to spec a card that supports
one of the many fb drivers, AND allow you to control the "tv out"
capabilities on board.

Most of the drivers I've come across allow you to control the TV Dacs
through X, but have put very little effort in providing fb support for the
same device.

ATI are refusing to talk due to IP issues with Macrovision, NVidia only
support this functionality through the XFree driver, the SiS driver
currently has no standard way of controlling this.

Francis Reader


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
Imerge Limited                          Tel :- +44 (0)1954 783600 
Unit 6 Bar Hill Business Park           Fax :- +44 (0)1954 783601 
Saxon Way                               Web :- http://www.imerge.co.uk 
Bar Hill 
Cambridge 
CB3 8SL 
United Kingdom 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~