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

Re: [Linux-fbdev-devel] Re: fbdev updates.

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

> On Wed, Jun 05, 2002 at 09:39:48AM -0700, James Simmons wrote:
> > Since no one has complianed for some time I like to push the next set of
> > changes to Linus. Anyone with objections please give a yell.
>
> A small suggestion - could you post diffstat -p1 output with your patch
> announcements please?

Patch at http://www.transvirtual.com/~jsimmons/fbdev.diff.gz

diffstat results:

 drivers/video/Config.in     |   40
 drivers/video/Makefile      |   28
 drivers/video/anakinfb.c    |    4
 drivers/video/aty128fb.c    |    5
 drivers/video/cfbcopyarea.c |    4
 drivers/video/cfbimgblt.c   |   10
 drivers/video/clps711xfb.c  |    3
 drivers/video/cyber2000fb.c |    5
 drivers/video/dn_accel.h    |    9
 drivers/video/dn_cfb4.c     |  492 -----
 drivers/video/dn_cfb8.c     |  540 ------
 drivers/video/dnfb.c        |  535 +-----
 drivers/video/fbcmap.c      |    2
 drivers/video/fbmem.c       |    3
 drivers/video/maxinefb.c    |  290 ---
 drivers/video/neofb.c       | 3639 ++++++++++++++++++++------------------------
 drivers/video/neofb.h       |  291 ---
 drivers/video/pm2fb.c       |  745 ++++++---
 drivers/video/pmag-ba-fb.c  |  343 ----
 drivers/video/pmagb-b-fb.c  |  344 ----
 drivers/video/skeletonfb.c  |    2
 drivers/video/tdfxfb.c      | 2434 ++++++++---------------------
 drivers/video/tx3912fb.c    |  566 ++----
 drivers/video/tx3912fb.h    |  128 -
 drivers/video/vfb.c         |    4
 include/video/neomagic.h    |  264 +++
 include/video/pm2fb.h       |  222 ++
 include/video/tx3912.h      |   62
 28 files changed, 4034 insertions(+), 6980 deletions(-)

[Linux-fbdev-devel] Re: fbdev updates.

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

On Wed, Jun 05, 2002 at 09:39:48AM -0700, James Simmons wrote:
> Since no one has complianed for some time I like to push the next set of
> changes to Linus. Anyone with objections please give a yell.

A small suggestion - could you post diffstat -p1 output with your patch
announcements please?

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

[Linux-fbdev-devel] fbdev updates.

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

Since no one has complianed for some time I like to push the next set of
changes to Linus. Anyone with objections please give a yell.

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'\_   _/`\
 \___)=(___/

[Linux-fbdev-devel] 2.5.20 + latest fbdev patch -- Rivafb appears to hang machine

[Miles L. <mi...@me...>]

What happens is that when the rivafb driver is loaded, the video
mode changes and the whole screen is covered with colored
static which has areas that are primarily one or another color.
It looks like the video mode is wrong.  Note that with the same
rivafb parameter value and running 2.5.20-dj2, I get a usable
VT, but the colors are off.

I am booting with "video=riva:1600x1200-16"

This is an Athlon UP machine.

01:05.0 VGA compatible controller: nVidia Corporation GeForce 256 DDR (rev 10) (prog-if 00 [VGA])
	Subsystem: VISIONTEK: Unknown device 000b
	Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 11
	Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
	Memory at e8000000 (32-bit, prefetchable) [size=128M]
	Expansion ROM at feaf0000 [disabled] [size=64K]
	Capabilities: [60] Power Management version 1
	Capabilities: [44] AGP version 2.0

Gnu C                  3.0.4
Gnu make               3.79.1
binutils               2.11.90.0.8
util-linux             2.11f
mount                  2.11g
modutils               2.4.14
e2fsprogs              1.26
reiserfsprogs          3.x.0j
pcmcia-cs              3.1.22
PPP                    2.4.1
isdn4k-utils           3.1pre1
Linux C Library        2.2.4
Dynamic linker (ldd)   2.2.4
Procps                 2.0.7
Net-tools              1.60
Console-tools          0.3.3
Sh-utils               2.0.11

Re: [Linux-fbdev-devel] Rivafb colors all messed up with 2.5.20-dj2.

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

On Wed, 5 Jun 2002, Miles Lane wrote:
> For a long time, I have had messed up colors when I use rivafb.
> In the past, just the penguin logo has been obviously messed up
> (all purple).  Now, all the colors are off.  By running
> "fbset -a 1600x1200-76" I am able to get the framebuffer colors
> correctly set.  Also, running this command gives me the 
> desired refresh rate.  I suspect I am using an incorrect
> boot parameter value.  Can someone tell me what value to use
> to get 1600x1200 @ 76Hz and 16-bit color?

  [...]

> My append= line includes "video=riva:1600x1200-16"

Modedb doesn't have a 1600x1200 76 Hz mode, but it does have 75 Hz.
Please try `1600x1200@75-16' instead.

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] Rivafb colors all messed up with 2.5.20-dj2.

[Miles L. <mi...@me...>]

For a long time, I have had messed up colors when I use rivafb.
In the past, just the penguin logo has been obviously messed up
(all purple).  Now, all the colors are off.  By running
"fbset -a 1600x1200-76" I am able to get the framebuffer colors
correctly set.  Also, running this command gives me the 
desired refresh rate.  I suspect I am using an incorrect
boot parameter value.  Can someone tell me what value to use
to get 1600x1200 @ 76Hz and 16-bit color?

From the kernel log:

rivafb: RIVA MTRR set to ON
Console: switching to colour frame buffer device 200x75
rivafb: PCI nVidia NV10 framebuffer ver 0.9.3 (GeForce-DDR, 32MB @ 0xE8000000)

"lspci -v" gives:

01:05.0 VGA compatible controller: nVidia Corporation GeForce 256 DDR (rev 10) (prog-if 00 [VGA])
	Subsystem: VISIONTEK: Unknown device 000b
	Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 11
	Memory at fd000000 (32-bit, non-prefetchable) [size=16M]
	Memory at e8000000 (32-bit, prefetchable) [size=128M]
	Expansion ROM at feaf0000 [disabled] [size=64K]
	Capabilities: [60] Power Management version 1
	Capabilities: [44] AGP version 2.0

My append= line includes "video=riva:1600x1200-16"

fbset -a (initial state at boot time with whacked colors):

mode "1600x1200-60"
     # D: 162.022 MHz, H: 75.010 kHz, V: 60.008 Hz
     geometry 1600 1200 1600 1200 16
     timings 6172 304 64 46 1 192 3
     hsync high
     vsync high
     accel true
     rgba 5/11,6/5,5/0,0/0
endmode

After running "fbset -a 1600x1200-76" (command gives desired state)
I have:

mode "1600x1200-76"
     # D: 197.981 MHz, H: 95.183 kHz, V: 76.146 Hz
     geometry 1600 1200 1600 1200 8
     timings 5051 304 40 42 3 136 5
     accel true
     rgba 8/0,8/0,8/0,0/0
endmode

[Linux-fbdev-devel] radeon 7500 flat panel support

[Louis G. <lou...@be...>]

The radeonfb driver in kernel-2.4.18 does not work with the radeon 7500 QW.
I have a digital flat screen connected to the dvi port and X works great. I just
see a blank screen when the system boots up. Is this a known issue? Is their
an more recent driver floating around? I got this card because I needed a
dvi connection, is their another card I should get.


Thanks, --Lou

Re: [Linux-fbdev-devel] radeonfb 0.1.5 testing

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

BTW are the pieces of extra code in the DJ tree valid for the Riva
fbdev driver?


P.S

   I plan to port that driver over to the new api code soon. I have a
Nvidia card here at work.

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'\_   _/`\
 \___)=(___/

On Mon, 3 Jun 2002, Ani Joshi wrote:

>
> Hi all,
>
> Attatched is a patch against 2.4.19-pre9 which fixes a host of problems
> with radeonfb, for those experiencing problems please test and give
> feedback, thanks!
>
>
>
> ani
>

[Linux-fbdev-devel] [PATCH] fbdev updates.

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

Hi!

   This patch includes the latest in the fbdev BK repository. I have
modified several fbdev drivers (maxinefb, tx3912fb, pmag drivers) to the
new api. Please test these changes out before I submit them to linus.
Thank you. It is against the latest BK tree and 2.5.20.

diff:

   http://www.transvirtual.com/~jsimmons/fbdev.diff.gz

BK:

   http://fbdev.bkbits.net:8080/fbdev-2.5

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'\_   _/`\
 \___)=(___/

Re: [Linux-fbdev-devel] radeonfb 0.1.5 testing

[Ani J. <aj...@sh...>]

Oops, well test those too!  The rivafb hunks unbreak Riva128 support.


ani

On Tue, 4 Jun 2002 be...@ke... wrote:

> >Attatched is a patch against 2.4.19-pre9 which fixes a host of problems
> >with radeonfb, for those experiencing problems please test and give
> >feedback, thanks!
>
> You included rivafb diffs as well ;)
>
> Ben.
>
>
>

Re: [Linux-fbdev-devel] radeonfb 0.1.5 testing

[<be...@ke...>]

>Attatched is a patch against 2.4.19-pre9 which fixes a host of problems
>with radeonfb, for those experiencing problems please test and give
>feedback, thanks!

You included rivafb diffs as well ;)

Ben.

[Linux-fbdev-devel] radeonfb 0.1.5 testing

[Ani J. <aj...@sh...>]

Hi all,

Attatched is a patch against 2.4.19-pre9 which fixes a host of problems
with radeonfb, for those experiencing problems please test and give
feedback, thanks!



ani

RE: [Linux-fbdev-devel] Adding an fb_sync() operation to fb_ops

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

On Mon, 2002-06-03 at 23:49, Sottek, Matthew J wrote:
> 
> So here is the obvious problem case.
> 
> Application mmap's the framebuffer.
> Application Draws some pixels into the framebuffer.
> Application issues an ioctl that would lead to a blit, the command is put
>  in a ring buffer but hasn't happened yet.
> The application draws some more pixels (via the mmap) in a region that
>  intersects the previously blitted region.
> The hardware gets around to the blit command and overwrites the pixels you
>   just put in the frambuffer.
> 
> 
And it does not have to happen outside the kernel.  Within the kernel
too.  For instance, a particular accelerator may only support fillrect
and copyarea, but not imageblit (neofb).  It has no choice but to mix in
cfb_imageblit and the sync problem will arise unless the accelerator
forces a sync -- which neofb does by the way.
  
Tony

[Linux-fbdev-devel] Purple text on my framebuffer

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

On my National Geode Framebuffer device (National's drivers at
www.eason.com/linux), I've got a strange problem.  I have a CRT and LCD
plugged in at the same time (on my SBC), and while the CRT looks good, the
LCD (connected via LVDS) is coming up with purple text.  Everything white
(including Xfbdev) ends up purple.

Any thoughts?

Alex Pavloff
Software Engineer
Eason Technology  

RE: [Linux-fbdev-devel] Adding an fb_sync() operation to fb_ops

[Sottek, M. J <mat...@in...>]

>> This depends. For traditional MMIO we need to sync up. For async DMA,
Ring
>> buffers, and FIFOs we don't need to sync up. That is why I have no hooks
>> for syncing. I figure drivers can call the syncing functions if they need
>> it inside their own accel functions.

>Is it the other way around, async DMA, ringbuffers, and FIFOS that will
>need the syncing?

Tony is correct. I think James got it backwards.

When you have DMA, Ring Buffers, Fifo's you don't know that the command
has happened, you only know that it went into one of the aforementioned
structures. (And actually in the case are DMA buffers you don't even know
that the DMA buffer will ever be processes, which leads to the need for
flush()  in order to keep this simple we can just make sure that doesn't
happen)

So here is the obvious problem case.

Application mmap's the framebuffer.
Application Draws some pixels into the framebuffer.
Application issues an ioctl that would lead to a blit, the command is put
 in a ring buffer but hasn't happened yet.
The application draws some more pixels (via the mmap) in a region that
 intersects the previously blitted region.
The hardware gets around to the blit command and overwrites the pixels you
  just put in the frambuffer.


This is quite likely to happen when mixing direct access with asynchronous
commands. It is also possible with synchronous commands but not as likely.
The blitter does take time to process so if you access the framebuffer
during the blit you could get mixed results. (And I hear that this can
actually hang some hardware)

-Matt

Re: [Linux-fbdev-devel] Bug in fbcon.c penguin drawing

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

Fixed. I added to the BK repository and will be sending Linus stuff soon.

   . ---
   |o_o |
   |:_/ |   Give Micro$oft the Bird!!!!
  //   \ \  Use Linux!!!!
 (|     | )
 /'\_   _/`\
 \___)=(___/

On Sat, 1 Jun 2002, Geert Uytterhoeven wrote:

>
> By accident I stumbled on this...
> Since `src' is the penguin logo, we must not use fb_read() to access it.
>
> --- linux-2.4.19-pre9/drivers/video/fbcon.c.orig	Fri Feb 22 16:28:32 2002
> +++ linux-2.4.19-pre9/fbcon.c	Sat Jun  1 15:27:31 2002
> @@ -2417,7 +2417,7 @@
>  		else
>  		    dst = fb + y1*line + x/8;
>  		for( x1 = 0; x1 < LOGO_LINE; ++x1 )
> -		    fb_writeb(fb_readb(src++) ^ inverse, dst++);
> +		    fb_writeb(*src++ ^ inverse, dst++);
>  	    }
>  	    done = 1;
>  	}
> --- linux-2.5.19/drivers/video/fbcon.c.orig	Mon Apr 29 09:50:07 2002
> +++ linux-2.5.19/fbcon.c	Sat Jun  1 15:27:40 2002
> @@ -2401,7 +2401,7 @@
>  		else
>  		    dst = fb + y1*line + x/8;
>  		for( x1 = 0; x1 < LOGO_LINE; ++x1 )
> -		    fb_writeb(fb_readb(src++) ^ inverse, dst++);
> +		    fb_writeb(*src++ ^ inverse, dst++);
>  	    }
>  	    done = 1;
>  	}
>
> 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
>
>
> _______________________________________________________________
>
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
>
> _______________________________________________
> Linux-fbdev-devel mailing list
> Lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
>

[Linux-fbdev-devel] Bug in fbcon.c penguin drawing

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

By accident I stumbled on this...
Since `src' is the penguin logo, we must not use fb_read() to access it.

--- linux-2.4.19-pre9/drivers/video/fbcon.c.orig	Fri Feb 22 16:28:32 2002
+++ linux-2.4.19-pre9/fbcon.c	Sat Jun  1 15:27:31 2002
@@ -2417,7 +2417,7 @@
 		else
 		    dst = fb + y1*line + x/8;
 		for( x1 = 0; x1 < LOGO_LINE; ++x1 )
-		    fb_writeb(fb_readb(src++) ^ inverse, dst++);
+		    fb_writeb(*src++ ^ inverse, dst++);
 	    }
 	    done = 1;
 	}
--- linux-2.5.19/drivers/video/fbcon.c.orig	Mon Apr 29 09:50:07 2002
+++ linux-2.5.19/fbcon.c	Sat Jun  1 15:27:40 2002
@@ -2401,7 +2401,7 @@
 		else
 		    dst = fb + y1*line + x/8;
 		for( x1 = 0; x1 < LOGO_LINE; ++x1 )
-		    fb_writeb(fb_readb(src++) ^ inverse, dst++);
+		    fb_writeb(*src++ ^ inverse, dst++);
 	    }
 	    done = 1;
 	}

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] Adding an fb_sync() operation to fb_ops

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

On Sat, 2002-06-01 at 04:14, Geert Uytterhoeven wrote:
> On Fri, 31 May 2002, James Simmons wrote:
> > > Secondly (not related to the topic), I was wondering if we can change
> > > the color value passed to fillrect and imageblit.  Presently, the
> > > palette index is always passed regardless of the visual. Should the
> > > color value passed be reflective of the framebuffer format instead?
> > > Pass a palette index if pseudocolor, an RGB value for truecolor, etc.
> > >
> > > Doing the latter will simplify the low-level drawing function and at the
> > > same time, it will make the drawing functions more flexible -- ie,
> > > possiblity of exporting to userspace.
> > 
> > We had this discussion sometime ago. We discovered it was just impossible
> > to handle all the possible different color formats in the higher levels.
> > We ended up with way to many #ifdefs. So it was decided to let the drivers
> > handle it instead. Actually if you wanted it to be useable to userland
> > then it makes even more sense to use the color map index instead. Think
> > about all the if() statements you would need in userland.
> 
> Userland can easily set up function pointers, depending on the used format
> (for commonly used formats). Even for the generic case it can be done without
> too much loss of efficiency using look-up tables, cfr. fbtest.
> 

I think that's a nice idea.  We can add another fb_op (I know, another
one), something like:

static u32 XXXfb_getcolor(u32 index, struct fb_info *info)
{
	u32 color = 0;

	switch (info->var.bits_per_pixel) {
	case 8:
	     color = index;
	     break;
	case 16:
	case 24:
	case 32:
	     color = ((u32 *)(info->pseudo_palette[index]))
	     break;
	}
	
	return color;
}


Then in fbcon-accel.c, we can have something like:

	region.fg_color = info->fb_getcolor(attr_fgcol(p, c));
	region.bg_color = info->fb_getcolor(attr_bgcol(p, c));

This will simplify fbcon-accel and the drawing functions. 

Tony

Re: [Linux-fbdev-devel] Adding an fb_sync() operation to fb_ops

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

On Sat, 2002-06-01 at 03:56, James Simmons wrote:
> 
> > I don't think we can totally avoid mixing direct
> > graphics memory access with hardware blitting.
> 
> In userland true. In the kernel we can work around it.
> 
> > In order to avoid that, should we:
> >
> > a. Just force a hardware sync after each blit?; or
> 
> > (a) is probably simpler (matrox is already doing that) but might
> > decrease performance a bit (not significant since fbcon is dealing with
> > text)
> 
> This depends. For traditional MMIO we need to sync up. For async DMA, Ring
> buffers, and FIFOs we don't need to sync up. That is why I have no hooks
> for syncing. I figure drivers can call the syncing functions if they need
> it inside their own accel functions.

Is it the other way around, async DMA, ringbuffers, and FIFOS that will
need the syncing? Personally, whether we sync after each blit or sync
only when needed does not matter. Since fb is dealing mostly with
discontiguous regions (character cells), except for the occasional clear
screen, perfomance degradation is not significant. So, is it agreed that
for drivers that need sync's, they will just have to do it after each
blit?  It's just that it defeats the purpose of those FIFO's and
buffers.  

> 
> > b. Add a new operation, fb_sync() which will be called whenever the
> > framebuffer memory will be accessed? fb_sync() should guarantee that the
> > graphics pipeline has been flushed and that there are no pending
> > hardware operations.
> 
> > (b) a bit more complicated, but should not be difficult to add since all
> > drivers probably has some form of 'wait_for_idle' which can be wrapped.
> > Then we can probably just add something like:
> >
> > if (info->fbops->fb_sync())
> > 	info->fbops->fb_sync(info);
> >
> > at the top of fb_write and fb_read.
> 
>   Orginally I had that. Then I realized this doesn't fit all hardware
> models. You are right tho. The one time where we do need a sync is for
Still, a driver can always assign a NULL to fb_sync if it is not
needed.  


> > Secondly (not related to the topic), I was wondering if we can change
> > the color value passed to fillrect and imageblit.  Presently, the
> > palette index is always passed regardless of the visual. Should the
> > color value passed be reflective of the framebuffer format instead?
> > Pass a palette index if pseudocolor, an RGB value for truecolor, etc.
> >
> > Doing the latter will simplify the low-level drawing function and at the
> > same time, it will make the drawing functions more flexible -- ie,
> > possiblity of exporting to userspace.
> 
> We had this discussion sometime ago. We discovered it was just impossible
> to handle all the possible different color formats in the higher levels.
> We ended up with way to many #ifdefs. So it was decided to let the drivers
> handle it instead. Actually if you wanted it to be useable to userland
> then it makes even more sense to use the color map index instead. Think
> about all the if() statements you would need in userland.
> 
I agree that fbcon-accel will be swamped by  if-else/case-switch
statements, and passing palette indices may be the best solution
overall. The price, though, is that those drawing functions may only be
usable within the kernel. 

If these drawing functions are to be exported to userland, then the
current implementation will necessitate a workaround.  Within the kernel
we are dealing with 16 colors, and color palettes (in pseudocolor) have
a practical limit of 256. In userland we are dealing with thousands to
millions of colors.  So how will I convert a particular 16-bit RGB
colorvalue into a palette index?

a.  Reset the colormap so that a particular colorvalue can be indexed
from the map and keep track which colorvalue is in the map or not.  

b.  Tell the accelerator that it is not actually a palette index, but
treat it as directcolor;

c.  Or allocate a colormap that will encompass the entire color range
(insane).

I can't really think of any other way, so correct me if I'm wrong. In
the end though, it's much simpler to just pass the appropriate color
value.

Secondly, if I'm going to use, for instance, imageblit to tile and
expand an 8x8 mono bitmap, then for each tile, the accelerator has to
lookup the color which is too inefficient.  On the other hand, if the
color is looked up in the upper layer, then it's done only once.  Of
course, this is not done in the console, so it's a bad example. 


Tony

[Linux-fbdev-devel] radeon 7500 dvi

[Louis G. <lou...@be...>]

The radeonfb from kernel-2.4.18 does not work with the radeon 7500 QW. I have
a digital flat screen connected to the dvi port and X works great. I just
see a blank screen when the system boots up. Is this a known issue? Is their
an more recent driver floating around? I got this card because I needed a
dvi connection, is their another card I should get.


Thanks, --Lou

Re: [Linux-fbdev-devel] Comments on fbgen.c and fbcon-accel.c

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

> The above is fine if everything is done in the console.  However,
> problems may arise if an app that touches the graphics hardware (ie X)
> is launched.  From the point of view of fbcon, the hardware state hasn't
> changed (compare of newvar with oldvar is false) when display is
> switched back to console.  And if that app did not fully restore the
> hardware state,  we will be left with a corrupted display.

I'm aware of this flaw. I plan to fix this when the rewrite of the console
system starts. The console system should handle restore ths video mode.

Re: [Linux-fbdev-devel] Adding an fb_sync() operation to fb_ops

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

On Fri, 31 May 2002, James Simmons wrote:
> > Secondly (not related to the topic), I was wondering if we can change
> > the color value passed to fillrect and imageblit.  Presently, the
> > palette index is always passed regardless of the visual. Should the
> > color value passed be reflective of the framebuffer format instead?
> > Pass a palette index if pseudocolor, an RGB value for truecolor, etc.
> >
> > Doing the latter will simplify the low-level drawing function and at the
> > same time, it will make the drawing functions more flexible -- ie,
> > possiblity of exporting to userspace.
> 
> We had this discussion sometime ago. We discovered it was just impossible
> to handle all the possible different color formats in the higher levels.
> We ended up with way to many #ifdefs. So it was decided to let the drivers
> handle it instead. Actually if you wanted it to be useable to userland
> then it makes even more sense to use the color map index instead. Think
> about all the if() statements you would need in userland.

Userland can easily set up function pointers, depending on the used format
(for commonly used formats). Even for the generic case it can be done without
too much loss of efficiency using look-up tables, cfr. fbtest.

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] Possible bug: nasty interaction between framebuffer and DRI/DRM

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

On Fri, 31 May 2002, Chris Howells wrote:
> On Friday 31 May 2002 1:08 pm, Geert Uytterhoeven wrote:
> 
> > Do you use `option UseFBDev' in your XF86Config?
> 
> No I'm not. Should I be?

Yes. Without that option, the X server will change the graphics chip's
registers behind the back of aty128fb.

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] Adding an fb_sync() operation to fb_ops

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

> I agree, I have some API's that I've been using for embedded applications
> and it always seems that if you allow mmap() you must have a sync()
> function. (A flush is nice too but not required)

Hm. There is also the issue of the cache and memory going out of sync. The
question is do we need device specific hooks?

Re: [Linux-fbdev-devel] Adding an fb_sync() operation to fb_ops

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

> I don't think we can totally avoid mixing direct
> graphics memory access with hardware blitting.

In userland true. In the kernel we can work around it.

> In order to avoid that, should we:
>
> a. Just force a hardware sync after each blit?; or

> (a) is probably simpler (matrox is already doing that) but might
> decrease performance a bit (not significant since fbcon is dealing with
> text)

This depends. For traditional MMIO we need to sync up. For async DMA, Ring
buffers, and FIFOs we don't need to sync up. That is why I have no hooks
for syncing. I figure drivers can call the syncing functions if they need
it inside their own accel functions.

> b. Add a new operation, fb_sync() which will be called whenever the
> framebuffer memory will be accessed? fb_sync() should guarantee that the
> graphics pipeline has been flushed and that there are no pending
> hardware operations.

> (b) a bit more complicated, but should not be difficult to add since all
> drivers probably has some form of 'wait_for_idle' which can be wrapped.
> Then we can probably just add something like:
>
> if (info->fbops->fb_sync())
> 	info->fbops->fb_sync(info);
>
> at the top of fb_write and fb_read.

  Orginally I had that. Then I realized this doesn't fit all hardware
models. You are right tho. The one time where we do need a sync is for
fb_write and fb_read. How do we solve this? I was planning anyways to
inplement read and write hooks. The reason being is some devices don't
have proper linear framebuffers. Some have banked buffers and some like
the epson 1385 is linear but filling in a solid color at 16bpp gives
strips due to the hardware only working with word or byte align access
only. So we need hooks in this case. So these hooks could also handle the
case of havingv to sync up as well.

> Secondly (not related to the topic), I was wondering if we can change
> the color value passed to fillrect and imageblit.  Presently, the
> palette index is always passed regardless of the visual. Should the
> color value passed be reflective of the framebuffer format instead?
> Pass a palette index if pseudocolor, an RGB value for truecolor, etc.
>
> Doing the latter will simplify the low-level drawing function and at the
> same time, it will make the drawing functions more flexible -- ie,
> possiblity of exporting to userspace.

We had this discussion sometime ago. We discovered it was just impossible
to handle all the possible different color formats in the higher levels.
We ended up with way to many #ifdefs. So it was decided to let the drivers
handle it instead. Actually if you wanted it to be useable to userland
then it makes even more sense to use the color map index instead. Think
about all the if() statements you would need in userland.