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

[Linux-fbdev-devel] [FB PATCH] fix up readq/writeq usage

[Richard H. <rt...@tw...>]

I'm in the process of getting tgafb to compile again on Alpha.
I ran into these little buglets in the process.  Please apply.


r~



You can import this changeset into BK by piping this whole message to:
'| bk receive [path to repository]' or apply the patch as usual.

===================================================================


ChangeSet@1.955, 2002-12-26 15:27:03-08:00, rt...@ar...
  [FB] Fix minor typos wrt readq/writeq support on 64-bit targets.


 drivers/video/cfbcopyarea.c |    2 +-
 include/linux/fb.h          |    2 ++
 2 files changed, 3 insertions, 1 deletion


diff -Nru a/drivers/video/cfbcopyarea.c b/drivers/video/cfbcopyarea.c
--- a/drivers/video/cfbcopyarea.c	Thu Dec 26 15:31:03 2002
+++ b/drivers/video/cfbcopyarea.c	Thu Dec 26 15:31:03 2002
@@ -38,7 +38,7 @@
 #define BYTES_PER_LONG 4
 #else
 #define FB_WRITEL fb_writeq
-#define FB_READL  fb_readq(x)
+#define FB_READL  fb_readq
 #define SHIFT_PER_LONG 6
 #define BYTES_PER_LONG 8
 #endif
diff -Nru a/include/linux/fb.h b/include/linux/fb.h
--- a/include/linux/fb.h	Thu Dec 26 15:31:03 2002
+++ b/include/linux/fb.h	Thu Dec 26 15:31:03 2002
@@ -424,9 +424,11 @@
 #define fb_readb __raw_readb
 #define fb_readw __raw_readw
 #define fb_readl __raw_readl
+#define fb_readq __raw_readq
 #define fb_writeb __raw_writeb
 #define fb_writew __raw_writew
 #define fb_writel __raw_writel
+#define fb_writeq __raw_writeq
 #define fb_memset memset_io
 
 #else

===================================================================


This BitKeeper patch contains the following changesets:
+
## Wrapped with gzip_uu ##


begin 664 bkpatch21401
M'XL(`#>1"SX``[U5R6[;,!`]FU]!()<6A21N6@$'CK.T00(T<)%341B42%MJ
M+-&A:#LI]/&EY,#.UK@)FFH#-!H.W\R;-]J#E[7424^;'.S!+ZHV28]KZ9I5
M(<1,NI4TUCY2RMJ]7)72LY[>\,PS4^X0UP?VZP4W60Z74M=)#[MT8S&W<YGT
M1L>?+\\/1@#T^_`PY]54?I,&]OO`*+WD,U$/N,EGJG*-YE5=2L/=3)7-QK4A
M"!%[^CBDR`\:'"`6-AD6&'.&I4"$10$#95%-U4#.C'3SQ:/5F!!F0U!"&AKZ
ME($CB-W8]R$B'B8>"2#V$Q(FB#HH2A""-L?!HRK`3P0Z"`SAOX5]"#+X_63X
M`YX4-]#FH'1;-E7#E3902RZNO94NC+R&]6(^5]:H*A@P)RT,-%Q/I:E=<`9I
M2$@$+K8%!LXK#P`01V!_1WI%E<T60GJSHEK<>)/4S>_G&3/<H""FI`D0B5,A
M4IF&4C+.GJOHGX)9M@++%;7E0@A%+:B?=5&6JJH'N2QJ6:523]?`EH4V"S[K
ML`E=M#WH+0LAE9=-TDS-;^V>%OD:I(\9CDCLDX;@(`B:<()$2L.,3&3$)'T6
MXZZ@]\!2&J&H:_,7%K6-_U^RV>YRI7Z5ROU0J4I^_(M\[.W3`,<-90C%G50P
M>:@4FK#P):5@Z.!W44HKDI/A>'1\<'0.G7TX2<>=1CK-=#KH./@*';WJ+MO7
M%R_1\0:9'#$,,3CMGGM"3HI*;C%M$'5]\+3!=\^]MRH,"+Z4Y:!:V(%0%=45
MWR$QW$9DM/'CV%\/1!*]CN5WFX<'0FSJ:#&/[P;@NM8UG-@9:9O9J>=<9RWI
M=D0\8OQIVF\@^I2UA=APO.FU\5CSU1W+UB=^Z','=NVT?MG^([-<9E?UHNRS
/B8A)QD+P&R+@>RV`!P``
`
end

[Linux-fbdev-devel] Re: also frustrated with the framebuffer and your matrox-card in 2.5.53? hack/patch available!

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

> It's rather annoying that in a feature-freeze period a change goes in
> that cripples the one framebuffer with the best speed and features -
> the matrox framebuffer. 

Because a driver has over 10,000 lines of code does not mean it is a 
quality driver.

> The author mentioned it could be weeks or months
> before he would be able to get his matrox framebuffer working with the
> new framework, since its simple API doesn't fit the possibilities of the
> matrox framebuffer. Read more about it on the fbdev-users or
> fbdev-developers mailinglist on sourceforge.

Petr is expressing his political view. It has nothing to do with technical 
arguments. In fact I place a bet. I will port the matrox driver and it 
will have the same functionality as the previous driver except for text 
mode support. If I can't do it I will not only revert the changes but I 
will give Petr his wetdream. I will start inetergrating vt.c and 
vt_ioctl.c into each fbdev driver. Each fbdev driver will be its own 
console system. We will not longer need vt.c and vt_ioctl.c as each driver 
will have its own version intergated into the driver. Sound fair?

Re: [Linux-fbdev-devel] Type confusion in fbcon

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

On 23 Dec 2002, David S. Miller wrote:
> On Mon, 2002-12-23 at 01:18, Geert Uytterhoeven wrote:
> > That's because originally there was no fix.line_length field, and the line
> > length was derived from var.xres_virtual and var.bits_per_pixel.
> > 
> > With some hardware, the line length must be a multiple of 32 or 64 bits, and we
> > needed a way to specify that, so fix.line_length was introduced. If it was
> > zero, user code should fallback to the old behavior.
> 
> And with some cards, the line length is constant.  Ie. to get to
> "X, Y + 1" for a given "X, Y" you add a constant to your current
> frame buffer pointer.
> 
> That is what fix.line_length is for right?

Yep.

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] Type confusion in fbcon

[David S. M. <da...@re...>]

On Mon, 2002-12-23 at 01:18, Geert Uytterhoeven wrote:
> That's because originally there was no fix.line_length field, and the line
> length was derived from var.xres_virtual and var.bits_per_pixel.
> 
> With some hardware, the line length must be a multiple of 32 or 64 bits, and we
> needed a way to specify that, so fix.line_length was introduced. If it was
> zero, user code should fallback to the old behavior.

And with some cards, the line length is constant.  Ie. to get to
"X, Y + 1" for a given "X, Y" you add a constant to your current
frame buffer pointer.

That is what fix.line_length is for right?

Re: [Linux-fbdev-devel] [PATCH] fix endian problem in color_imageblit

[Russell K. <rm...@ar...>]

On Mon, Dec 23, 2002 at 10:07:35AM +0100, Geert Uytterhoeven wrote:
> Note that the size of the entries in the pseudo palette used to depend on the
> mode, i.e. u16 for bpp = 16, u32 for bpp = 24 or 32.

They used to.  However, reading the code in 2.5 today, this appears to be
no longer the case - they're all one size (u32).

-- 
Russell King (rm...@ar...)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [Linux-fbdev-devel] Mirrored Display?

[Michael K. <kau...@so...>]

Dear James,

thanks for your reply.

On Friday 20 December 2002 18:49, you wrote:
> > I've modified existing drivers, and after a lot of work i now have a
> > clear picture on my display. Unfortunately, the complete picture is
> > mirrored. The Bootlogo is top/right instead of top/left and the ascii
> > output starts from right to left.
>
> Some hardware supports mirroring. Sounds like you turned it on by mista=
ke.

No, there is nothing i could turn on/off in my hardware.=20
I have checked the hardware and the datasheets again, and i'm now sure. T=
he=20
display i'm using is a LCD monochrom display. And this type of display wr=
ites=20
the picture date from right to left (mirrored). There is nothing i can do=
=20
against it. My videocontroller has no feature to output every line mirror=
ed.
The videocontroller start sending the picture datastream to the display f=
rom
videobuffer address 0. The first pixel from the picture datastream will b=
e=20
displayed on the right/top edge on my LCD and the second pixel left to th=
e=20
first and so on.=20

First i thought that this behaviour of my display is extremly unusal. Aft=
er=20
looking to other display datasheets i now know, that it is unusal but far=
 not=20
sooo unusual i thought the first time. =20

> > Where is the right place to modify this behaviour?
> > I'm also looking for a possibility to rotate the picture.
> > Because my videocontroller can emulate 15 grayscales, i'm useing 4bpp=
=2E
>
> The latest 2.5.X kernels have hardware hooks for rotation. I haven't ad=
ded
> it yet to the software accel functions. I plan to a soon as I get time.
> Thank you.

Antonino has also answered to my question. And he said that there is noth=
ing=20
i can do, because user apps will directly acces the framebuffer via read/=
write=20
or nmap. I can only patch the console and the show _logo to write the dat=
a=20
mirrored to the videobuffer (a lot of work).
So my user apps (like nanoX or directfb/GTK+) must know about the mirrore=
d=20
display and should write the picturedata mirrored in the framebuffer.=20

I'm know a litte bit amazed about a rotation feature in next versions. Do=
es=20
this mean, that the buffer where user apps (or also the console) are writ=
ing=20
there picture data is not directly the videobuffer anymore? Or how does t=
his=20
rotation feature works?

I think it would be a good feature to have 'something' between the frameb=
uffer=20
and the physical videobuffer to be able to manipulate the picture data (l=
ike=20
rotation, mirroring, etc.). But i don't know how this peace of software=20
should detect, changed data in the 'framebuffer' to e.g. mirror in the=20
videobuffer? Writing the whole buffers from time to time whould be a very
bad solution (performance).

At the moment i plan to do the manipulation in the directfb layer on top =
of=20
the framebuffer device. I 'only' need to run some GTK+ applications. I ne=
ed=20
to mirror the picture, and i also want to rotate the picture from landcap=
e to=20
portrait.

Bye
Michael=20

Re: [Linux-fbdev-devel] Type confusion in fbcon

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

On Fri, 20 Dec 2002, Russell King wrote:
> On Fri, Dec 20, 2002 at 06:10:17PM +0000, James Simmons wrote:
> > > I'll get back to bashing the sa1100fb driver to work out why fbcon is
> > > producing a _completely_ blank display, despite characters being written
> > > to it.
> > 
> > Did you figure out what was wrong?
> 
> Firstly, setting fix.line_length to zero (which the old API didn't care
> about) caused one set of problems.

That's because originally there was no fix.line_length field, and the line
length was derived from var.xres_virtual and var.bits_per_pixel.

With some hardware, the line length must be a multiple of 32 or 64 bits, and we
needed a way to specify that, so fix.line_length was introduced. If it was
zero, user code should fallback to the old behavior.

Anyway, I think it's good to make fix.line_length mandatory with the new fbdev
API.

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] [PATCH] fix endian problem in color_imageblit

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

On Sat, 21 Dec 2002, Russell King wrote:
> On Sat, Dec 21, 2002 at 11:45:44AM +0800, Antonino Daplas wrote:
> > The pseudopalette will only matter for truecolor and directcolor as the
> > rest of the visuals bypasses the pseudopalette.  Typecasting to
> > "unsigned long" rather than "u32" is also safer (even for bpp16) since
> > in 64-bit machines, the drawing functions use fb_writeq instead of
> > fb_writel.
> 
> Erm, what does the size of the drawing functions have to do with the
> size of the pseudo palette.  The pseudo palette is only there to encode
> the pixel values for the 16 console colours.

Indeed.

> This means that a 64-bit pseudo palette would only be useful if you have
> a graphics card that supports > 32bpp, otherwise a 32-bit pseudo palette
> is perfectly adequate, even if you are using fb_writeq.

Yep. Cards with bpp > 32 are rumoured to exist, but there is no fbdev support
for them right now.

> (note that fbcon doesn't support > 32bpp, so we will only ever look at
> the first 32 bits, and having it be 64-bit would just be a needless
> waste of space imho.)

And this can be fixed, once we have some fbdev driver that uses bpp > 32.

Note that the size of the entries in the pseudo palette used to depend on the
mode, i.e. u16 for bpp = 16, u32 for bpp = 24 or 32.

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] Re: atyfb in 2.5.51

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

On 13 Dec 2002, Alan Cox wrote:
> On Fri, 2002-12-13 at 08:53, Geert Uytterhoeven wrote:
> > (At first I thought you meant an instruction where the opcode crosses those
> >  two memory types, but we don't put code in video RAM...)
> 
> I did. The frame buffer drivers support mmap(). x86 has no "non-exec"
> bit. So any user able to open /dev/fb can bring down such a box. Similar
> things apply with early athlon and prefetching /dev/fb

Weird... So it really crashes the box, not just throwing an exception?
On PPC you cannot use prefetching on non-cached memory, but if you try it won't
take down the whole box.

Then make sure /dev/fb is accessible by `trusted' users on such machines.

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] new fbdev

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

On Sun, 22 Dec 2002, Geert Uytterhoeven wrote:
>   o drivers/video/console/font.h is needed by arch/m68k/kernel/m68k_defs.c
>     (for struct font_desc)

A bit more explanation: on Mac/m68k, head.S uses the fbdev fonts to print
status informtation.

This patch moves the definition of struct font_desc back to <video/font.h>, so
it can be used outside of drivers/video/console.

--- linux-2.5.52/include/video/font.h	Mon Mar 18 12:17:27 2002
+++ linux-m68k-2.5.52/include/video/font.h	Sun Dec 22 13:58:32 2002
@@ -0,0 +1,24 @@
+/*
+ *  font.h -- `Soft' font definitions
+ *
+ *  Created 1995 by Geert Uytterhoeven
+ *
+ *  This file is subject to the terms and conditions of the GNU General Public
+ *  License.  See the file COPYING in the main directory of this archive
+ *  for more details.
+ */
+
+#ifndef _VIDEO_FONT_H
+#define _VIDEO_FONT_H
+
+#include <linux/types.h>
+
+struct font_desc {
+    int idx;
+    char *name;
+    int width, height;
+    void *data;
+    int pref;
+};
+
+#endif /* _VIDEO_FONT_H */
--- linux-2.5.52/drivers/video/console/font.h	Tue Dec 10 13:41:40 2002
+++ linux-m68k-2.5.52/drivers/video/console/font.h	Sun Dec 22 13:58:32 2002
@@ -8,18 +8,10 @@
  *  for more details.
  */
 
-#ifndef _VIDEO_FONT_H
-#define _VIDEO_FONT_H
+#ifndef _VIDEO_CONSOLE_FONT_H
+#define _VIDEO_CONSOLE_FONT_H
 
-#include <linux/types.h>
-
-struct font_desc {
-    int idx;
-    char *name;
-    int width, height;
-    void *data;
-    int pref;
-};
+#include <video/font.h>		/* struct font_desc */
 
 #define VGA8x8_IDX	0
 #define VGA8x16_IDX	1
@@ -50,4 +42,4 @@
 /* Max. length for the name of a predefined font */
 #define MAX_FONT_NAME	32
 
-#endif /* _VIDEO_FONT_H */
+#endif /* _VIDEO_CONSOLE_FONT_H */

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] Re: xxx_check_var

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

On Tue, 10 Dec 2002, James Simmons wrote:
> > > When I look at atyfb_check_var or aty128fb_check_var, I see that they
> > > will alter the contents of *info->par.  Isn't this a bad thing?  My
> >
> > Yes, this wrong, and afaik, it's your original port to 2.5 that did that
> > ;)
> 
> Yeap. The idea of check_var is to validate a mode. Note modedb uses just
> check_var. It is okay to READ the values in your par. You shouldn't alter
> the values in par.

Perhaps it makes sense to make the info parameter of fb_check_var() const to
prevent this from happening?

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] new fbdev

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

Just returned from a long trip, I'm trying to get m68k to work with >
2.5.50 again.

Issues/questions:
  o drivers/video/console/font.h is needed by arch/m68k/kernel/m68k_defs.c
    (for struct font_desc)
  o What is (or will be) CONFIG_PCI_CONSOLE used for?

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] Re: kernel: matrox fb - missing files, doesn't compile

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

On 15 Dec 2002, Antonino Daplas wrote:
> On Sun, 2002-12-15 at 03:44, Petr Vandrovec wrote:
> > What if I'll decide to paint characters through busmastering? Then
> > I need font data in buffers allocated by pci_alloc_consistent...
> > In the past it was not a win to use busmastering, but now, when
> > upper layers might prepare images much larger than 8x16, it may be 
> > worth of rechecking that...
> 
> True, using kmalloc() to cache a good-sized pixmap is probably not the
> best idea in all cases (in my case, it is best when the pixmap is in
> graphics memory). I submitted a proposal before that allows more
> flexibility: it will let the drivers decide on how it wants the buffers
> allocated, the size of the buffer, specific alignment requirements, or
> if it even actually needs one. Other driver-specific needs can probably
> be added if necessary.

Add address/size fields in fb_info to let the driver tell it already allocated
a suitable buffer? If those are NULL, fbcon can fall back to its own buffer
(e.g. static and fixed 8 kiB buffer).

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] Re: kernel: matrox fb - missing files, doesn't compile

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

On 15 Dec 2002, Antonino Daplas wrote:
> On Fri, 2002-12-13 at 15:09, Petr Vandrovec wrote:
> > Current interface just supports only cfb, and only very bad for my needs.
> > And because of matroxfb supports also other modes (such as native text
> > mode, or loading font into accelerator), bye-bye. For now I recommend you 
> > either to not upgrade, or use vesafb. Besides that accel_putcs() does not 
> > call fb_sync when using font width which is not multiple of 8, and that 
> Can you explain why an fb_sync is needed for every character?
> 
> > with fonts greater than 16*16 pixels (I believe that such fonts are still 
> > supported...) it will corrupt memory...
> 
> I agree.  To be more specific, buffer overruns will occur if (xres *
> fontheight/8 > 8192).  The pixmap needs to be dynamically allocated and
> resized somewhere in the fbcon layer (ideally in accel_setup(), but this
> was removed).  For those concerned about this problem, you can try this
> patch as a temporary measure until fbcon is fixed. It should not cause
> to much slowdown:

What about making putcs() check for overflows? I.e. large putcs() will just be
split in multiple image blit calls.

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] problem in displaying logo

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

>  I am using 2.4.18-rmk7 kernel on assabet like board , with 240x320 LCD
> color display panel.
> 
> 
> My problem is i have modified the linux startup logo to 240x320 size
> ,This works fine on 32MB RAM and 16MB flash
>  board, i.e  i can see full screen logo and i boots up fine. This does
> not work on  64MB RAM and 32MB flash board . logo comes up and kernel
> panic..
> 
> I just  tried to reduce the size of logo to 240x280 this works fine.
> 
> Can anybody give some pointers why this is happening..

Wow! I'm amazed changing the size of the logo didn't cause problem at any 
size. The code expect 80x80 size :-/

[Linux-fbdev-devel] problem in displaying logo

[Ramprasad <ram...@nc...>]

Hi ,

 I am using 2.4.18-rmk7 kernel on assabet like board , with 240x320 LCD
color display panel.


My problem is i have modified the linux startup logo to 240x320 size
,This works fine on 32MB RAM and 16MB flash
 board, i.e  i can see full screen logo and i boots up fine. This does
not work on  64MB RAM and 32MB flash board . logo comes up and kernel
panic..

I just  tried to reduce the size of logo to 240x280 this works fine.

Can anybody give some pointers why this is happening..


Thanks in advance,
Ramprasad

Re: [Linux-fbdev-devel] [PATCH] fix endian problem in color_imageblit

[Russell K. <rm...@ar...>]

On Sat, Dec 21, 2002 at 11:45:44AM +0800, Antonino Daplas wrote:
> The pseudopalette will only matter for truecolor and directcolor as the
> rest of the visuals bypasses the pseudopalette.  Typecasting to
> "unsigned long" rather than "u32" is also safer (even for bpp16) since
> in 64-bit machines, the drawing functions use fb_writeq instead of
> fb_writel.

Erm, what does the size of the drawing functions have to do with the
size of the pseudo palette.  The pseudo palette is only there to encode
the pixel values for the 16 console colours.

This means that a 64-bit pseudo palette would only be useful if you have
a graphics card that supports > 32bpp, otherwise a 32-bit pseudo palette
is perfectly adequate, even if you are using fb_writeq.

(note that fbcon doesn't support > 32bpp, so we will only ever look at
the first 32 bits, and having it be 64-bit would just be a needless
waste of space imho.)

-- 
Russell King (rm...@ar...)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

Re: [Linux-fbdev-devel] [PATCH] fix endian problem in color_imageblit

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

On Sat, 2002-12-21 at 03:54, James Simmons wrote:
> 
> > Nice catch :-)  We also need a similar fix for slow_imageblit(), so
> > James can you apply the attached patch also:
> 
> Applied.
> 
> > Also, I noticed that some drivers load the pseudo_palette with entries
> > whose length matches the length of the pixel.  The cfb_* functions
> > always assume that each pseudo_palette entry is an "unsigned long", so
> > bpp16 will segfault, and so will bpp24/32 for 64-bit machines.
> 
> I just noticed that as well. Russell King pointed to it too. I fixed
> the unsigned long problem in color_imageblit. All the pseudo_palette
> in cfb_* are assumed u32. Is this safe for 16bpp or 8 bpp modes? I will

The pseudopalette will only matter for truecolor and directcolor as the
rest of the visuals bypasses the pseudopalette.  Typecasting to
"unsigned long" rather than "u32" is also safer (even for bpp16) since
in 64-bit machines, the drawing functions use fb_writeq instead of
fb_writel.  So, all drivers using the cfb_* functions should change from
"u32" to "unsigned long" _whatever_ the bit depth when loading the
pseudopalette.

Of course, drivers with their own drawing functions can use whatever
they want.

Tony 

PS:  cfb_fillrect is still limited to u32 though which can hopefully be
fixed in the future.

Re: [Linux-fbdev-devel] Type confusion in fbcon

[Russell K. <rm...@ar...>]

On Fri, Dec 20, 2002 at 06:10:17PM +0000, James Simmons wrote:
> > I'll get back to bashing the sa1100fb driver to work out why fbcon is
> > producing a _completely_ blank display, despite characters being written
> > to it.
> 
> Did you figure out what was wrong?

Firstly, setting fix.line_length to zero (which the old API didn't care
about) caused one set of problems.

Secondly, the sa1100fb set_par function doesn't set the var RGB elements -
that's left to the check_var function.  Originally, we effectively did
a fb_set_var which took care of that for us.  Now we explicitly call
our check_var implementation prior to registering the framebuffer
driver with the fbcon core.

-- 
Russell King (rm...@ar...)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html

[Linux-fbdev-devel] Re: [FBDEV]: Framebuffer driver for Intel 810/815 chipsets

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

Applied.

[Linux-fbdev-devel] Re: backlight/frontlight

[Frank B. <fb...@in...>]

Chris Larson wrote:
> * James Simmons (jsi...@in...) wrote:
> 
>>Oh. Could someone list all the approaches people toke to solve this 
>>problem. I like to find a solution that covers as many cases as possible.
> 
> 
> James,
> 
> 	As far as I know, the two that seem worth looking at, at the moment,
> are Russ Dill's implementation, which was posted to the LAK list in this
> thread, and Nicolas' implementation in the -pxa patches.
> There are obviously others out there, but said other implementations are
> individual hacks for certain machine types, and aren't generally useful.

Don't blame Nico for the one in the -pxa patches. That
one is my fault ;)

Mmh, can't find that post. Maybe it's on its way...
Anyway, I googled this:
http://russ.dhs.org:8000/files/tuxpatches/backlight-2.4.16-rmk1-2

Looks nicer than what I've been using. I wouldn't call it
backlight though. Backlight is a device specific term for
illumination, isn't it?

Cheers,
-- 
Frank Becker - Intrinsyc Software, Inc. - http://www.intrinsyc.com/
Need a break? http://criticalmass.sf.net/

Re: [Linux-fbdev-devel] [PATCH] fix endian problem in color_imageblit

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

> Nice catch :-)  We also need a similar fix for slow_imageblit(), so
> James can you apply the attached patch also:

Applied.

> Also, I noticed that some drivers load the pseudo_palette with entries
> whose length matches the length of the pixel.  The cfb_* functions
> always assume that each pseudo_palette entry is an "unsigned long", so
> bpp16 will segfault, and so will bpp24/32 for 64-bit machines.

I just noticed that as well. Russell King pointed to it too. I fixed
the unsigned long problem in color_imageblit. All the pseudo_palette
in cfb_* are assumed u32. Is this safe for 16bpp or 8 bpp modes? I will
have test to see. The u16 problem might explain why some people have
trouble with the VESA framebuffer. To all the people having trouble
booting to certain modes for the VESA fraembuffer can you try this patch.
Tell me if it fixes your problems.

--- /usr/src/linus-2.5/drivers/video/cfbimgblt.c	Mon Dec  9 22:23:32 2002
+++ cfbimgblt.c	Fri Dec 20 12:35:25 2002
@@ -102,11 +102,10 @@
 				   unsigned long start_index, unsigned long pitch_index)
 {
 	/* Draw the penguin */
-	int i, n;
-	unsigned long bitmask = SHIFT_LOW(~0UL, BITS_PER_LONG - p->var.bits_per_pixel);
-	unsigned long *palette = (unsigned long *) p->pseudo_palette;
 	unsigned long *dst, *dst2, color = 0, val, shift;
-	unsigned long null_bits = BITS_PER_LONG - p->var.bits_per_pixel;
+	int i, n, bpp = p->var.bits_per_pixel;
+	unsigned long null_bits = BITS_PER_LONG - bpp;
+	u32 *palette = (u32 *) p->pseudo_palette;
 	u8 *src = image->data;

 	dst2 = (unsigned long *) dst1;
@@ -125,9 +124,10 @@
 		while (n--) {
 			if (p->fix.visual == FB_VISUAL_TRUECOLOR ||
 			    p->fix.visual == FB_VISUAL_DIRECTCOLOR )
-				color = palette[*src] & bitmask;
+				color = palette[*src];
 			else
-				color = *src & bitmask;
+				color = *src;
+			color <<= LEFT_POS(bpp);
 			val |= SHIFT_HIGH(color, shift);
 			if (shift >= null_bits) {
 				FB_WRITEL(val, dst++);
@@ -136,7 +136,7 @@
 				else
 					val = SHIFT_LOW(color, BITS_PER_LONG - shift);
 			}
-			shift += p->var.bits_per_pixel;
+			shift += bpp;
 			shift &= (BITS_PER_LONG - 1);
 			src++;
 		}
@@ -188,6 +188,7 @@
 				color = fgcolor;
 			else
 				color = bgcolor;
+			color <<= LEFT_POS(bpp);
 			val |= SHIFT_HIGH(color, shift);

 			/* Did the bitshift spill bits to the next long? */

Re: [Linux-fbdev-devel] Radeon frame buffer compile error?

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

Its coming. More fixes and patches are coming your way.

Re: [Linux-fbdev-devel] anyone working on radeonfb?

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

> hello
> 
> is anyone actively maintaining the radeon fb driver in the 2.4 series?

Ani Joshi is maintinaing it. 

> I've started reviving and older hacked version (based on mplayer radeonfb)
> of the driver. The version I have has proper panning and accel console
> (almost, 32bit mode is causing some minor head-aches still).

I woudl b einterested in seeing this code. 
 
> I'd like to eventually sync my version with the kernel one (and yes, I
> know that the mplayer version is way off Linus coding style, and yes, it's
> based somewhat on xfree86, but I'm willing to work that out eventually).
> 
> currently I have only some radeon boards left, but no DVI anymore, so I'll
> need someone with DVI displays as well. Also I have no access to PPCs, so
> would need someone to test the newer driver there as well if possible.
> 
> thanks :-)
> 
> ak.
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility 
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
> 

Re: [Linux-fbdev-devel] Mirrored Display?

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

> I've modified existing drivers, and after a lot of work i now have a clear
> picture on my display. Unfortunately, the complete picture is mirrored.
> The Bootlogo is top/right instead of top/left and the ascii output starts from 
> right to left. 

Some hardware supports mirroring. Sounds like you turned it on by mistake.

> Where is the right place to modify this behaviour? 
> I'm also looking for a possibility to rotate the picture.
> Because my videocontroller can emulate 15 grayscales, i'm useing 4bpp.

The latest 2.5.X kernels have hardware hooks for rotation. I haven't added 
it yet to the software accel functions. I plan to a soon as I get time.
Thank you.