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

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

[Chris L. <ke...@ha...>]

* 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.

--
Chris Larson
kergoth at handhelds dot org
OpenZaurus Project Maintainer - http://openzaurus.org/

Re: [Linux-fbdev-devel] fbmem.c - fb_mmap

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

> fb_mmap contains an ifdef for every architecture on
> Linux.  Is it possible to implement this using
> something like ioremap_nocache() and avoid the ifdefs?

Unfortunely no. We are dealing with special memory that has special needs 
whcih vary from platform to platform.

Re: [Linux-fbdev-devel] My Matrox G200 died with 2.5.51

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

> I compiled the new 2.5.51 kernel and enabled the new framebuffer with 
> the VESA generic driver.
> My system is a Slackware 8.0. My graphic card was a Matrox G200 and the 
> resolution of fb console was 1024 X 768, 16M of colors (0x318).
> When I rebooted with my new kernel, i noted that fb didn't work well 
> (when i switched from a tty to another, some parts of the first tty were 
> "pasted" to the second).
> When I rebooted, my Matrox G200 died definetly.  I've made something 
> wrong or it's an fb's bug?
> If it is a bug, I hope to have been helpful.
> see you,

Your card died :-( Sounds like your hardware bit the dust. The VESA code 
isn't able to kill any cards as it depends on the BIOS to do the right 
thing.

Re: [Linux-fbdev-devel] 3DFX framebuffer driver v0.2.2

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

> > The current kernel still contains version 0.1.3 which is rather old. Much
> > work has been done until version 0.2.2, mainly support for:
> > 
> > * non-8 dot wide fonts
> > * multihead
> > * full 8/16/24/32 bit color (fixes the ugly bootup penguin)
> > * MIPS
> > * module options
> > 
> > I think it's worth to give it a chance and to continue development on the
> > base of that code. So I "ported" it to kernel 2.4.2x. Get this new patch
> > here:
> > 
> > http://tu-ilmenau.de/~johe-ii/3dfx-0.2.2-2.4.21-pre1.diff.gz
> > 
> > I just merged the improvements that happened to v0.1.3 while it was in the
> > kernel and did some source formating.

Thanks. I'm looking over the patch now and will intergrate it into 2.5.X.

Re: [Linux-fbdev-devel] [PATCH][TRIVIAL] drivers/video/tdfxfb.c compile failure (Linux 2.5.52)

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

Thank you. I have other changes as well coming for this driver.


> 
> drivers/video/tdfxfb.c does not compile, because banshee_wait_idle()
> is used before declaration. A simple fix follows:
> 
> --- linux-2.5.52/drivers/video/tdfxfb.c.old	2002-12-19 18:55:03.000000000 +0100
> +++ linux-2.5.52/drivers/video/tdfxfb.c	2002-12-19 18:56:25.000000000 +0100
> @@ -166,6 +166,7 @@
>  static void tdfxfb_copyarea(struct fb_info *info, struct fb_copyarea *area);  
>  static void tdfxfb_imageblit(struct fb_info *info, struct fb_image *image); 
>  static int tdfxfb_cursor(struct fb_info *info, struct fb_cursor *cursor);
> +static inline void banshee_wait_idle(struct fb_info *info);
>  
>  static struct fb_ops tdfxfb_ops = {
>  	.owner		= THIS_MODULE,
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by: Geek Gift Procrastinating?
> Get the perfect geek gift now!  Before the Holidays pass you by.
> T H I N K G E E K . C O M      http://www.thinkgeek.com/sf/
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
> 

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

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

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.

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

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

> > What's required actually, is someone who's willing to pick that 
> > implementation (or another one, whatever is best) and lead maintainership 
> > for that code by gathering other's contribution.  Then, when the 
> > generic interface 
> > is suitable for most devices out there then it can be submited for 
> > inclusion with the -rmk patch, and/or James Simons' frame buffer rework in 
> > 2.5.
> 
> It'd definitely be best to involve James Simmons in this - he's the
> maintainer for fbcon, and, since the drivers are in framebuffer display
> land, it seems only sensible.

Hi!

     I would like to see this as well. At present the core api is 
finished. Of course it is possible to add other stuff as long as it 
doesn't require us changing a bunch of drivers that wouldn't support it.

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

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

> I'm in the midst of porting sa1100fb over to the new fb API, and I stumbled
> across an apparant confusion over the type of fb_info->pseudo_palette.
> 
> Some code appears to think its an unsigned long, others think its u32.
> This doesn't make much difference when sizeof(unsigned long) == sizeof(u32)
> but this isn't always the case (eg, 64-bit architectures).

It show be u32 instead of unsinged long in color_imageblit. Thanks. Fixed.
 
> 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?

[Linux-fbdev-devel] Type confusion in fbcon

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

I'm in the midst of porting sa1100fb over to the new fb API, and I stumbled
across an apparant confusion over the type of fb_info->pseudo_palette.

Some code appears to think its an unsigned long, others think its u32.
This doesn't make much difference when sizeof(unsigned long) == sizeof(u32)
but this isn't always the case (eg, 64-bit architectures).

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.

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

[Linux-fbdev-devel] [PATCH][TRIVIAL] drivers/video/tdfxfb.c compile failure (Linux 2.5.52)

[Gergely N. <alg...@bo...>]

Hi!

drivers/video/tdfxfb.c does not compile, because banshee_wait_idle()
is used before declaration. A simple fix follows:

--- linux-2.5.52/drivers/video/tdfxfb.c.old	2002-12-19 18:55:03.000000000 +0100
+++ linux-2.5.52/drivers/video/tdfxfb.c	2002-12-19 18:56:25.000000000 +0100
@@ -166,6 +166,7 @@
 static void tdfxfb_copyarea(struct fb_info *info, struct fb_copyarea *area);  
 static void tdfxfb_imageblit(struct fb_info *info, struct fb_image *image); 
 static int tdfxfb_cursor(struct fb_info *info, struct fb_cursor *cursor);
+static inline void banshee_wait_idle(struct fb_info *info);
 
 static struct fb_ops tdfxfb_ops = {
 	.owner		= THIS_MODULE,

Re: [Linux-fbdev-devel] 3DFX framebuffer driver v0.2.2

[<id...@ma...>]

On Mon, Dec 16, 2002 at 06:45:00PM +0000, joa...@st... wrote:
> On http://www.medex.hu/~danthe/tdfx/ I found a newer version of the tdfxfb
> driver. It was a patch against linux 2.4.4 . I don't know why it never went
> into the kernel. Maybe Linus was too busy at that time?
> 
> The current kernel still contains version 0.1.3 which is rather old. Much
> work has been done until version 0.2.2, mainly support for:
> 
> * non-8 dot wide fonts
> * multihead
> * full 8/16/24/32 bit color (fixes the ugly bootup penguin)
> * MIPS
> * module options
> 
> I think it's worth to give it a chance and to continue development on the
> base of that code. So I "ported" it to kernel 2.4.2x. Get this new patch
> here:
> 
> http://tu-ilmenau.de/~johe-ii/3dfx-0.2.2-2.4.21-pre1.diff.gz
> 
> I just merged the improvements that happened to v0.1.3 while it was in the
> kernel and did some source formating.
> 
> Be encouraged to test it, do further improvements and please take it into
> the kernel!

I try this out on 2.4.20 with other patching.
My machine is an Asus super 7 (K6 500) with PCI & AGP voodoo banshees.
BIOS requires boot VGA to be PCI.

Both heads are init by driver, BIOS head is head 0. Head 1 is
misdetected to be only 4096KB video memory, should be 16384KB as is head
0. After remapping a virtual console to fb/1, I have no video signal on
either head now until I fbset each to depth 16.

Tested system with mplayer output to tdfxfb driver. Video only on fb/0,
but with mplayer on console on fb/1 both heads are responsive.

Unfortunately I tried mplayer with DirectFB, it crashes unable to init,
and (it's enabled with xfs patch) I get into gdb. And my keventd kernel
thread is zombie. sysrq kessages appear on (current) fb console, but
consoles otherwise unresponsive.

I try mplayer with tdfxfb again. No complaints but also no image on fb/0

[Linux-fbdev-devel] dell i8100 touchstick, 2.5 input -- further info

[James H. C. Jr. <cl...@jh...>]

I've been researching the touchstick breakage in 2.5 on the i8100.

The board appears to use a SMC lpc47n252 superIO chip for keyboard and
ps/2 support.  Details on the chip are at:

http://www.smsc.com/main/datasheets/47n252.pdf
http://www.smsc.com/main/datasheets/47n252add.pdf

It has four ps/2 ports, matrix kb support and an i8051 compatible
µcore.  The i8051 code, then, is responsible for muxing the four ps/2
ports to the host's 0x60/0x64 ioports.

Dell's bios upgrade tool flashes the 47n252.  

I added some printk()s to i8042.c and confirmed that (unless something
else is accessing the kbc during the mux activation test) the synaptics,
et al mux protocol is not supported.  

Something the 2.5 input system is doing is resetting the kbc to a
state where it no longer muxes its ps2 ports.

Obviously, a dump of the i8051 or bios code would provide all the answers.

Does anyone have any ideas on where to go from here?

Having to use the touchpad is bloody irritating. :(

-JimC

[Linux-fbdev-devel] LCD going off

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

Hi All,

  I  am using 2.4.18-rmk4 patch on an assbet like board . I am using
sharp  mono LCD touch panel.

   My problem is , i have an USB master support on my board and  when i
plug an USB diskon key , after some time (Say 50 sec - 70 sec ) the
screen going blank...  and never comes back.

can any body give some pointers.

Thanks in advance,
Ramprasad

[Linux-fbdev-devel] fbmem.c - fb_mmap

[Jon S. <jon...@ya...>]

fb_mmap contains an ifdef for every architecture on
Linux.  Is it possible to implement this using
something like ioremap_nocache() and avoid the ifdefs?

=====
Jon Smirl
jon...@ya...

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

[Linux-fbdev-devel] 3DFX framebuffer driver v0.2.2

[<joa...@st...>]

On http://www.medex.hu/~danthe/tdfx/ I found a newer version of the tdfxfb
driver. It was a patch against linux 2.4.4 . I don't know why it never went
into the kernel. Maybe Linus was too busy at that time?

The current kernel still contains version 0.1.3 which is rather old. Much
work has been done until version 0.2.2, mainly support for:

* non-8 dot wide fonts
* multihead
* full 8/16/24/32 bit color (fixes the ugly bootup penguin)
* MIPS
* module options

I think it's worth to give it a chance and to continue development on the
base of that code. So I "ported" it to kernel 2.4.2x. Get this new patch
here:

http://tu-ilmenau.de/~johe-ii/3dfx-0.2.2-2.4.21-pre1.diff.gz

I just merged the improvements that happened to v0.1.3 while it was in the
kernel and did some source formating.

Be encouraged to test it, do further improvements and please take it into
the kernel!

Thank you
	Joachim

[Linux-fbdev-devel] My Matrox G200 died with 2.5.51

[nomero <no...@us...>]

Hi all.
I compiled the new 2.5.51 kernel and enabled the new framebuffer with 
the VESA generic driver.
My system is a Slackware 8.0. My graphic card was a Matrox G200 and the 
resolution of fb console was 1024 X 768, 16M of colors (0x318).
When I rebooted with my new kernel, i noted that fb didn't work well 
(when i switched from a tty to another, some parts of the first tty were 
"pasted" to the second).
When I rebooted, my Matrox G200 died definetly.  I've made something 
wrong or it's an fb's bug?
If it is a bug, I hope to have been helpful.
see you,

    Moreno

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

[Michel <mi...@da...>]

On Son, 2002-12-15 at 21:57, Antonino Daplas wrote:
>=20
> User apps will always assume that the first pixel written to the
> framebuffer will appear as the first pixel of the first scanline of your
> display.  Meaning, for apps that will always use mmap, you have to
> rewrite them so they raster "right->left" instead of "left->right".
>=20
> If you think about it, a hardware solution seems to be more feasible.

This may be true in general, but at least for X it wouldn't be hard to
add an option for mirroring via a shadow framebuffer.


--=20
Earthling Michel D=E4nzer (MrCooper)/ Debian GNU/Linux (powerpc) developer
XFree86 and DRI project member   /  CS student, Free Software enthusiast

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

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

On Sun, 2002-12-15 at 22:03, Michael Kaufmann wrote:
> On Saturday 14 December 2002 23:29, you wrote:
> > On Fri, 2002-12-13 at 23:33, Michael Kaufmann wrote:
> > > Hello,
> > >
> > > i would like to use a mono LCD with a framebuffer driver.
> > >
> > > 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.
> > >
> > > 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.
> > >
> > > It would be very nice, if someone can guide me in the right direction.
> >
> > Are you using fbcon-cfb4.c to draw the characters?  Is the whole display
> > mirrored, including individual characters?  If you run an fb-based app
> > (like fbtest for instance), is the display also mirrored?
> 
> Yes,  i'm using fbon-cfb4.c. The console is on my display, i see the boot logo 
> and the kernel messages in the display mirrored. I never used fbtest. By the 
> way, where can i find fbtest? But i already startet nanox/microwindows on top 
Check one of the links in www.linux-fbdev.org.

> of the fb, and the picture is also mirrored.  
> 
Ouch, your user apps are also mirrored :-(

> > If it's the whole display, maybe your hardware supports mirroring (some
> > hardware with video overlay need this to support YUV formats that are
> > either vertically or horizontally mirrored).  Maybe it has something
> > like that.  Otherwise, it will be difficult to correct this without
> > rewriting practically everything.
> 
> No, i don't think so. It is a simple video controller. Nevertheless, i have 
> just looked in the datasheet, and do not found such a feature. 
> 
> I don't think that this is a bug or something like this in the framebuffer. 
> Because everthing works like i exect it, but i have to mirror the picture.
No, I never said this was a bug.  Mirroring is a hardware feature
occasionally useful such as for mirrored mpegs.  

> I have also measured with a scope all signals to the display, and the 
> generated output looks like i expect it. The datastream starts with the first 
> pixel (in the picture top/left) and continues with the second pixel (on the 
> right of the first pixel) and so on.
> But my display is mapping this datastream from the right to the left.
This is the problem.  You are writing each byte in the correct location
in the framebuffer, but somehow it gets shown in the "mirrored" location
of your display.

> Please take a look on the attached picture, i think it explains the behaviour.
> I can reproduce it without Linux with a simple monitor programm
> 
> At the moment i have two explanations:
> 1) I have a display witch must be accessed unusual, and the LINUX FB doesn't
>     support this kind of access (not yet).
> 2) There is a hardware problem with the signals to the display (changed 
>    signals like frame-pulse, and line-pulse, or something like this.
> 
> I don't think that it is a hardware problem, but i will check the connection 
> again. Is there really no way in the framebuffer to mirror and/or rotate the 
> picture data?
> When i have to fix it in software, what kind of code do i have to rewrite? 

Fixing the console is feasible enough though it entails a lot of work.
You have to rewrite all the functions in fbcon-cfb4.c so you go
"right->left" instead of "left->right".  Do the same thing to
fbcon_show_logo() in fbcon.c, and fb_read/fb_write in fbmem.c.

Fixing user apps, that's the tough part. The framebuffer API is not
something like XAA which has specific hooks for filling, copying,
expanding, etc an area of pixels to the framebuffer.  All the
framebuffer API provides are two ways to access the graphics memory
(similar to a watered-down version of X's DGA):

1. The standard file read/file write which will be intercepted by
fb_read and fb_write; and

2. mmap 

Of the 2, mmap is usually chosen by user apps because it's simple and
fast.  The disadvantage is that your driver has no control on what will
get displayed, and there is no feasible solution to this, except to
disable mmap by setting fb_fix_screeninfo.smem_len to zero. Hopefully,
if mmap is not possible, they will fall back to using file read and file
write.

User apps will always assume that the first pixel written to the
framebuffer will appear as the first pixel of the first scanline of your
display.  Meaning, for apps that will always use mmap, you have to
rewrite them so they raster "right->left" instead of "left->right".

If you think about it, a hardware solution seems to be more feasible.

Tony

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

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

On Saturday 14 December 2002 23:29, you wrote:
> On Fri, 2002-12-13 at 23:33, Michael Kaufmann wrote:
> > Hello,
> >
> > i would like to use a mono LCD with a framebuffer driver.
> >
> > 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.
> >
> > 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
> >
> > It would be very nice, if someone can guide me in the right direction=
=2E
>
> Are you using fbcon-cfb4.c to draw the characters?  Is the whole displa=
y
> mirrored, including individual characters?  If you run an fb-based app
> (like fbtest for instance), is the display also mirrored?

Yes,  i'm using fbon-cfb4.c. The console is on my display, i see the boot=
 logo=20
and the kernel messages in the display mirrored. I never used fbtest. By =
the=20
way, where can i find fbtest? But i already startet nanox/microwindows on=
 top=20
of the fb, and the picture is also mirrored. =20

> If it's the whole display, maybe your hardware supports mirroring (some
> hardware with video overlay need this to support YUV formats that are
> either vertically or horizontally mirrored).  Maybe it has something
> like that.  Otherwise, it will be difficult to correct this without
> rewriting practically everything.

No, i don't think so. It is a simple video controller. Nevertheless, i ha=
ve=20
just looked in the datasheet, and do not found such a feature.=20

I don't think that this is a bug or something like this in the framebuffe=
r.=20
Because everthing works like i exect it, but i have to mirror the picture=
=2E
I have also measured with a scope all signals to the display, and the=20
generated output looks like i expect it. The datastream starts with the f=
irst=20
pixel (in the picture top/left) and continues with the second pixel (on t=
he=20
right of the first pixel) and so on.
But my display is mapping this datastream from the right to the left.
Please take a look on the attached picture, i think it explains the behav=
iour.
I can reproduce it without Linux with a simple monitor programm

At the moment i have two explanations:
1) I have a display witch must be accessed unusual, and the LINUX FB does=
n't
    support this kind of access (not yet).
2) There is a hardware problem with the signals to the display (changed=20
   signals like frame-pulse, and line-pulse, or something like this.

I don't think that it is a hardware problem, but i will check the connect=
ion=20
again. Is there really no way in the framebuffer to mirror and/or rotate =
the=20
picture data?
When i have to fix it in software, what kind of code do i have to rewrite=
?=20

And, thank's for your reply!
=20
Bye
Michael

Re: [Linux-fbdev-devel] Re: kernel: matrox fb - missing files, doesn't compile

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

On Sun, 2002-12-15 at 03:44, Petr Vandrovec wrote:
> On Sun, Dec 15, 2002 at 05:30:43AM +0500, 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?
> 
> It is not needed after every character. But I thought that it will be called
> before we return to userspace... And I want to rely on fb_sync
> because of hardware setup to change fg_color and bg_color is very costly.
> 
I see. 

> In my tests I'm not able to get accelerated code running faster than
> at 50% of old speed with 12x22 font, and I'm hoping that eliminating these
> two PCI writes could speed it a bit... It will not get on par, but better than
> nothing.
>  
> > > 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:
> 
> But we may try to allocate buffers of order 2 or even 3 with kmalloc, and
> if I remember fork() problems with allocating stack with order=1 correctly,
> it is not best idea under the sun. But using physically non-continuous
> area is probably even worse idea.
You mean the multiple buffering?  Sorry, I did not mean classic
multi-buffering, just a single buffer with size at least 2x that
required.  Then the buffer will just be "walked" by adjusting the buffer
offset.  Once the offset reaches the end of the buffer, we just call
fb_sync() then reset the offset to 0.

> 
> > For anyone concerned, this is a heads up:  The data in the pixmap must
> > be read completely by the hardware before exiting, otherwise font
> > corruption will occur.  If you think this will be a problem, the
> > function can be easily modified to do multiple buffering instead.
> 
> 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.

However, the change is a bit more invasive and complex and thus probably
did not hold very well with the maintainers.  So I submitted a patch
that is simpler but less flexible.  In my case, I have to do an extra
copy of the pixmap contents to graphics memory or directly to the
graphics pipeline depending on the size/alignment and proceed from
there.  It's not the best solution, but definitely better than doing one
imageblit/character.

I really don't have a say on any of this... I just submit patches, you
have to ask James or Geert about these.

Tony

Re: [Linux-fbdev-devel] Mirrored and shiftet fonts and logos

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

On Saturday 14 December 2002 18:53, Andr=E9 Stierenberg wrote:

> i=B4m using the framebuffer driver pxafb for my board using the pxa pro=
cessor
> (Accelent IDP). I have a 4 bit monocrom display. when I run the framebu=
ffer
> I have some problems. The text in the console it in some way shifted. T=
he
> two parts of the font are switched. The first 4 pixels are at dest+2 an=
d
> the last 4 pixels at dest+0. And both parts are mirrored. Now I have do=
ne
> the following in fbcon_cfb4.c in function fbcon_cfb4_putcs:
>
>   for (rows =3D fontheight(p), dest =3D dest0; rows-- ; dest +=3D bytes=
) {
>       fb_writew((nibbletab_cfb4[rv(*cdat) >> 4] & eorx) ^ bgx, dest+2);
>       fb_writew((nibbletab_cfb4[rv(*cdat++) & 0xf] & eorx) ^ bgx, dest+=
0);
>   }
>
>
> The function rv will reverse the bit order (bit 1 is bit 8, bit 2 is bi=
t
> 7.. etc.).
> And i have swaped the destination offset.
> Now the characters are printed correctly. And in the linux logo, the
> pinguin, something is also wrong. It seems the some pixels are mirrored=
 too
> whereas other pixels are correct.
>
> What could this be and in what way can i fix the problem?

i had exactly the same problem, but i fixed it on the hardware side.
I changed the databus between the video controller and the LCD.
My display has a 4bit width databus, so i exchanged D0 with D3 and D1 wit=
h D2.
Now i have a clear picture (logo, font, ...).

Bye
Michael

Re: [Linux-fbdev-devel] Re: atyfb in 2.5.51

[Stefan R. <st...@su...>]

* James Simmons <jsi...@in...> [021211 16:16]:
> 
> > I've always stated that the whole fbdev model was flawed, it makes
> > basic assumptions about how a video card's memory and registers are
> > accessed (ie. the programming model) and many popular cards absolutely
> > do not fit into that model.
> 
> I agree that the design of the /dev/fbX interface is not the best.
> Unfortunely we are stuck with it. Changing it would break userland apps.

One thing I was wondering: Is there a proper way to make sure that 
acceses to the framebuffer end up only on one specific virtual console?
I have an application that runs on one virtual console, but when
switching I do not want the screen to be trashed by writing just into
the framebuffer memory. My solution was to check whether the current
console is the console the application started on, but this looks a
bit bloated to me and I had some weird effects when switching to X and
back - like one frame still got painted into graphics memory while X was
already shown.
  
  Any ideas?
  Stefan

-- 
Laissez Faire Economics is the theory that if each acts like a vulture,
all will end as doves.

Re: [Linux-fbdev-devel] Re: kernel: matrox fb - missing files, doesn't compile

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

On Sun, Dec 15, 2002 at 05:30:43AM +0500, 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?

It is not needed after every character. But I thought that it will be called
before we return to userspace... And I want to rely on fb_sync
because of hardware setup to change fg_color and bg_color is very costly.

In my tests I'm not able to get accelerated code running faster than
at 50% of old speed with 12x22 font, and I'm hoping that eliminating these
two PCI writes could speed it a bit... It will not get on par, but better than
nothing.
 
> > 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:

But we may try to allocate buffers of order 2 or even 3 with kmalloc, and
if I remember fork() problems with allocating stack with order=1 correctly,
it is not best idea under the sun. But using physically non-continuous
area is probably even worse idea.

> For anyone concerned, this is a heads up:  The data in the pixmap must
> be read completely by the hardware before exiting, otherwise font
> corruption will occur.  If you think this will be a problem, the
> function can be easily modified to do multiple buffering instead.

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...
					Best regards,
						Petr Vandrovec
						van...@vc...

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

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

On Thu, 2002-12-12 at 08:41, Paul Mackerras wrote:
> This patch fixes the endian problems in color_imageblit().  With this
> patch, I get the penguin drawn properly on boot.
> 
> The main change is that on big-endian systems, when we load a pixel
> from the source, we now shift it to the left-hand (most significant)
> end of the word.  With this change the rest of the logic is correct on
> big-endian systems.  This may not be the most efficient way to do
> things but it is a simple change that works and avoids disturbing the
> rest of the code.
> 
Nice catch :-)  We also need a similar fix for slow_imageblit(), so
James can you apply the attached patch also:

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.

Tony

diff -Naur linux-2.5.51/drivers/video/cfbimgblt.c linux/drivers/video/cfbimgblt.c
--- linux-2.5.51/drivers/video/cfbimgblt.c	2002-12-15 00:54:04.000000000 +0000
+++ linux/drivers/video/cfbimgblt.c	2002-12-15 00:54:21.000000000 +0000
@@ -189,6 +189,7 @@
 				color = fgcolor;
 			else 
 				color = bgcolor;
+			color <<= LEFT_POS(bpp);
 			val |= SHIFT_HIGH(color, shift);
 			
 			/* Did the bitshift spill bits to the next long? */

Tony

[Linux-fbdev-devel] Re: [BK fbdev] Yet again more fbdev updates.

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

> > 1) Its the same place on the screen or a different place every time?
>
> I think it's at the last line of the screen every time.

I think I might now what the problem is. scrup is using memcpy even when
the memory areas src, dest overlap. The key is to use memmove which
handles overlapping memory gracefully. Tell me if the following patch
works for you.

--- vt.c.orig	Sat Dec 14 13:32:42 2002
+++ vt.c	Sat Dec 14 13:34:46 2002
@@ -262,7 +262,7 @@
 		return;
 	d = (unsigned short *) (origin+video_size_row*t);
 	s = (unsigned short *) (origin+video_size_row*(t+nr));
-	scr_memcpyw(d, s, (b-t-nr) * video_size_row);
+	scr_memmovew(d, s, (b-t-nr) * video_size_row);
 	scr_memsetw(d + (b-t-nr) * video_num_columns, video_erase_char, video_size_row*nr);
 }