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

Re: [Linux-fbdev-devel] Best font drawing algorthim.

[Romain D. <do...@ir...>]

James Simmons wrote:

>   I'm looking for the best font drawing alogrithm for the framebuffer
> layer. I'm been banging my head on a really fast implementation that
> can work at any pixel depth. Anyone got pointers?

My understanding of ruby was that a 1bit fb_image would be sent to
the driver 'xxxfb_imageblit' function to be expanded in hardware.
Are you talking about filling the fb_image (one per character or
one per line or...), or about a generic 'xxxfb_imageblit' for driver
not supplying their own ?

Or eventually of adding another API similar to the current one
(2.2 / 2.4) that would ask a driver to draw a specific character
at a specific localtion by whatever means the driver see fit ?

I believe that the last would be both easier for you (simple
reuse of current working code) and the most efficient for
driver writers, as they could use the best/fastest way for
the hardware to draw glyphs ; it's not necessarily expanding
a 1-bit image (even if it's the way I'm doing it ATM :-)

Just my 0.02 euros.

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

Re: [Linux-fbdev-devel] dummy console

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

On Tue, 10 Apr 2001, James Simmons wrote:
>    The solution I thought of to deal with this we not have dummy_con at
> the very beginning. Instead have fbcon spawn its own VTs instead of
> calling take_over_console. What we if don't have vgacon or mdacon at the
> beginning. I thought about not have the console enabled (CON_ENABLE) so
> nothing is printed yet by printk. If we do have mdacon and vgacon
> then we can enable the console. People could argue that data will be

Note that fbcon can work as some kind of dummycon as well, if you supply a
dummy display_switch.

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] Best font drawing algorthim.

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

Hi!

  I'm looking for the best font drawing alogrithm for the framebuffer
layer. I'm been banging my head on a really fast implementation that
can work at any pixel depth. Anyone got pointers?

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

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

[Linux-fbdev-devel] dummy console

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

Hi!

   I'm looking for some feedback to a problem I have been having. As you
know I have a true multidesktop going. One of the most annoying things I
coming across is the one vt intialization in the beginning. Why is this a
problem? Well I like to use my mda display as my printk console. It is
most helpful when experimenting with vgacon or fbcon. Now I have to go and
hack things up to get mdacon going right away. I can in theory have both
going right away which is what I like to do but still use one for the
console to use printk. Either way I get to see data right away. This is
pretty much I like to do it. So I like to see mda_console_init go away in
some fashion. Maybe get called in console_init(). We just have to be
careful about any kmallocs.
   Now some could argue use dummy_con and have mdacon take over. With
fbcon also we then need two dummy_cons to take over. Also we don't know
how many fbdev devices we could have. We could end up with many
dummy_cons. Well this brings me to the next issue. What calls
take_over_console to get to fbcon! Since it is possible to have vgacon
along side fbcon the question is do we take over vgacon or have fbcon
spawn a new VT to run along side vgacon? Then if we do have vgacon and
dummycon at the beginning which one does fbcon take over? As you can see
it is quite a mess.

   The solution I thought of to deal with this we not have dummy_con at
the very beginning. Instead have fbcon spawn its own VTs instead of
calling take_over_console. What we if don't have vgacon or mdacon at the
beginning. I thought about not have the console enabled (CON_ENABLE) so
nothing is printed yet by printk. If we do have mdacon and vgacon
then we can enable the console. People could argue that data will be
missed farther back in the log buffer. I thought about that and with Mortons
patch I could do that. In his patch with printk the log buffer and what
the console print are different things. This means data could be added to
the log_buffer while the consoles are still printing the previous line.
Now we could star printing right at the beginning of the log_buffer as
soon as the console becomes enabled and then get up to speed.

So what do you think? Anyone have any better ideas?

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

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

[Linux-fbdev-devel] Re:[Linux-fbdev-users] tdfxfb (fwd)

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

>I am using vesafb, since I have never been able to get tdfxfb working, I
>presume this is because I have no idea wtf vga=number to use.

Don't need to use that. vga= is only for vgacon and vesafb. tdfxfb uses
the new modedb interface. Try something like

video=tdfx:1024x768-16@70

Note it is tdfx and not tdfxfb. I made that mistake. As you can see it is
1024 by 768, the screen resolution. The 16 is the bits per pixel. Note
the dash. The 70 is the frequency you want it to run at. Info you need is in
linux/Documentation/fb/modedb.txt. More info is at
http://linux-fbdev.sourceforge.net and http://www.linux-fbdev.org.

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

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

Re: [Linux-fbdev-devel] directcolor

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

>I have writen a prog, which works perfectly on a g400 card, which uses
>truecolor visual, but it makes a really strange looking picture on an
>ATI XPert@Work card, which uses directcolor.
>so what does the directcolor mean?
>or is there a document about fbdev for programmers?
>I only found a howto for users...

Direct color is when a pixel value is decomposed into three seperate
subfields for colormap indexing. One subfield indexes an array to produce
red intensity values; second subfield indexes a second array to produce
green intensity values etc.

Truecolor represnts multiplane displays with predefinded and read only RGB
values in its hardware colormap. Here pixel values directly encode into
corresponding RGB values.

What does this mean? For truecolor if want white you set all the feilds
RGB to the maximum value. What if that white is not white enough for you.
For truecolor you are out of luck. For direct color you can change the
range of intensities for the RGB feilds. This way we can get a brighter
white.

P.S
  A neat side note. Thier is a staturation limit to colors in color theory.
You can only make white so bright and no matter how much equal amounts of
red, blue, and green you add it doesn't get any brighter.


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

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

Re: [Linux-fbdev-devel] atyfb

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

On Mon, 12 Mar 2001, Marcel Wijlaars wrote:
> I've tried to contact Geert Uytterhoeven for this patch but the old
> mailing list did not accept my subscription and  Geerts email account at
> linux-m68k.org gave a "Returned mail: Cannot send message within 5
> days".
> So I hope he will read this message:

I'm listening :-)

> Could you (if you have some spare time) take a look at my patch for the
> ati
> mobility m1 chipset (Sony Vaio C1VE) . It is a patch on your
> atyfb-new-20010117.diff
> patch (applied on the 2.4.2-ac13 kernel see atyfb-new-20010311.diff.bz2)
> .
> I'm totaly new with this kernel patching  stuff  and I probably did some
> things
> that are normally not done.
> Could you please help me to get this patch right ( it works but the
> implementation
> might not be to nice).

Hardcoded things like VAIO_LCD are not nice. A special
`video=atyfb:vaio1024x480' kernel command line option is probably more
acceptable.

Ideally we would need autoprobing, like we do for PowerBook on PPC.

> I would like to send this(these) patch(es) to "www.stevebarr.com" if
> that's ok with you.

No problem, go ahead!

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: fbcon slowness [was NTP on 2.4.2?]

[Ivan K. <in...@ju...>]

On Mon, Apr 09, 2001 at 12:02:54PM +0200, Maciej W. Rozycki wrote:
>  I think you need an mb here.  To force sychronization with other CPUs.
> Unless you know you are UP or there is no possibility another CPU may
> access the relevant device.

Yes - in most cases you need synchronization at a higher level.
For instance, you don't want other CPUs accessing the device while
you are sending command sequences to it.

Ivan.

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

[Maciej W. R. <ma...@ds...>]

On Sun, 8 Apr 2001, Ivan Kokshaysky wrote:

> Of course. I meant that if you are reading, for example, some status register
> in a loop waiting for "ready bit" set, the memory barrier won't help you
> to notice this event any faster. Actually you'll notice that *later*, as
> "mb" is expensive.

 I think you need an mb here.  To force sychronization with other CPUs.
Unless you know you are UP or there is no possibility another CPU may
access the relevant device.

 Of course mbs hit performance but it's a trade off for coherency. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: ma...@ds..., PGP key available        +

Re: [Linux-fbdev-devel] Query:Regarding Virtual frame buffer

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

On Fri, 6 Apr 2001, Bipin T S wrote:
> >  We are using a Walnut board with a PPC processor. We don't have a
> graphics chip/card in this board and so we planned to use the virtual
> > frame buffer concept for debugging and testing the frame buffer
> system. We build the kernel with the virtual frame buffer enabled in
> Console
> > drivers and we gave video = vfb:enable (Thanks to Simmons)  in the
> command line options.
> 
> 1) We tried giving echo "Hello World" > /dev/fb0. It works fine.

So fbmem.c:fb_write() works, and info->disp->screen_base is the correct virtual
address of the frame buffer.

> 2) We wrote an application that mmaps the /dev/fb0 into user memory.
> This works fine and mmap() returns a valid address
> 
>         fb = open("/dev/fb0", O_RDWR);
>         addr =(unsigned char*)  mmap(NULL, size, PROT_READ|PROT_WRITE,
> MAP_SHARED, fb, 0);
> 
> 3) But when we try to write something into the MAPPED address, we get a
> segmentation fault!!
>             *( addr + 10) = 20;
> 
> We would like to know the reason for the above behaviour. Pointers and
> references will be appreciated

So fbmem.c:fb_mmap() doesn't work. This means either fix.smem_start is not the
correct physical address of the frame buffer, or io_remap_page_range() contains
a bug. The Walnut has a PPC 8xx CPU, IIRC?

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: fbcon slowness [was NTP on 2.4.2?]

[Ivan K. <in...@ju...>]

On Fri, Apr 06, 2001 at 07:13:21PM +0200, Maciej W. Rozycki wrote:
>  You do.  PCI-space registers are volatile and they may change depending
> on what was written (or read) previously.  A memory barrier before a PCI
> read will ensure you get a value that is relevant to previous code
> actions.  Without a barrier you may get pretty anything, depending on
> which of previous writes managed to complete before. 

Of course. I meant that if you are reading, for example, some status register
in a loop waiting for "ready bit" set, the memory barrier won't help you
to notice this event any faster. Actually you'll notice that *later*, as
"mb" is expensive.

Well, here is some info on ev6 IO write buffers - they are a bit different
than ev4/ev5 ones.
Merging rules:
 - byte/word stores aren't allowed to merge into a write buffer;
 - different size stores (32- and 64-bit) aren't allowed to merge;
 - addresses must be in ascending order and non-overlapping,
   but not necessarily consecutive.
The I/O register merge window close (ie write-buffer flushing) occurs after
 - mb and wmb instructions;
 - IO-space load instruction (!);
 - after 1024 cycles if there were no IO-space stores.
Store requests are sent offchip in program order (!).

All this explains, in particular, why XFree86-4.0 worked on ev6 without
memory barriers of any kind, while it crashed badly on ev4/ev5.

Ivan.

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

[Maciej W. R. <ma...@ds...>]

On Fri, 6 Apr 2001, Andrea Arcangeli wrote:

> ev6 works the way you described AFIK (to flush the write buffer you can use

 Thanks for the clarification -- you made me calm down.

> wmb(), note that wmb() semantics doesn't require the cpu to really "flush" but
> just to keep writes oredered across other mb or wmb, but it's basically the
> same from a software point of you and flushing the write buffer synchronously
> obviously provides that semantics).  I didn't followed very closely the

 Of course -- you only want to do mb (and not wmb) if you need to meet
hw's specific timing or you want to perform a read from a volatile
register of a peripheral device. 

> previous part of the thread so I'm not sure what is the issue.

 Someone complained of Alpha not having Intel-style MTRRs to set write
combining for fb memory...

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: ma...@ds..., PGP key available        +

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

[Andrea A. <an...@su...>]

On Fri, Apr 06, 2001 at 07:27:24PM +0200, Maciej W. Rozycki wrote:
> [..] You normally have
> non-cached locations buffered (since you don't always need peripheral
> device accesses to be posted immediately) and can force a writeback with a
> memory barrier. [..]

ev6 works the way you described AFIK (to flush the write buffer you can use
wmb(), note that wmb() semantics doesn't require the cpu to really "flush" but
just to keep writes oredered across other mb or wmb, but it's basically the
same from a software point of you and flushing the write buffer synchronously
obviously provides that semantics).  I didn't followed very closely the
previous part of the thread so I'm not sure what is the issue.

Andrea

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

[Maciej W. R. <ma...@ds...>]

On 6 Apr 2001, Eric W. Biederman wrote:

> I recall on the ev6 all memory accesses to locations with bit 40 set 
> are always to IO space are never cached and are never write buffered.

 If that is the case then EV6 is seriously flawed.  You normally have
non-cached locations buffered (since you don't always need peripheral
device accesses to be posted immediately) and can force a writeback with a
memory barrier.  I don't have my 21264 handbook handy, so I can't check
EV6 details at the moment, especially why it is different.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: ma...@ds..., PGP key available        +

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

[Maciej W. R. <ma...@ds...>]

On Fri, 6 Apr 2001, Ivan Kokshaysky wrote:

> >  Memory barriers are a separate issue.  On the alpha the
> > natural way to implement it would be in the page table fill code.
> > Memory barriers are o.k. but the really don't help the case when what
> > you want to do is read the latest value out of a pci register.  
> 
> You don't need memory barrier for that. "Write memory barriers" are
> used to ensure correct write order, and "memory barriers" are used
> to ensure that all pending reads/writes will complete before next read
> or write.

 You do.  PCI-space registers are volatile and they may change depending
on what was written (or read) previously.  A memory barrier before a PCI
read will ensure you get a value that is relevant to previous code
actions.  Without a barrier you may get pretty anything, depending on
which of previous writes managed to complete before. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: ma...@ds..., PGP key available        +

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

[Maciej W. R. <ma...@ds...>]

On 5 Apr 2001, Eric W. Biederman wrote:

> The point is on the Alpha all ram is always cached, and i/o space is
> completely uncached.  You cannot do write-combing for video card

 You don't want to cache fb memory, do you?  All you want is write
combining and you achieve it with memory barriers.  You write to fb memory
space whatever you need to and write buffers actually deliver data to fb
memory whenever the bus is idle or they get filled up.  When you finally
decide you wrote all data and you want ensure it actually reaches the fb
memory before you perform an operation (say you send a command to fb's
support circuitry) you issue a write memory barrier.  Or a memory barrier,
if you want ensure the data reaches the fb memory ASAP.

 In other words, you have write-combining by default and request
write-through explicitly.

> memory.  Memory barriers are a separate issue.  On the alpha the
> natural way to implement it would be in the page table fill code.

 Please forgive me -- I can't see how this is related to write combining.

> Memory barriers are o.k. but the really don't help the case when what
> you want to do is read the latest value out of a pci register.  

 They do -- you issue an mb and you are sure all pending writes reached
the involved PCI hw. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: ma...@ds..., PGP key available        +

[Linux-fbdev-devel] Re: console.c unblank_screen problem

[Mikael P. <mi...@cs...>]

On Wed, 4 Apr 2001 13:09:11 +0200 (MET DST), Mikael Petterson wrote:

> On Sun, 25 Mar 2001 18:40:03 +0200, Benjamin Herrenschmidt wrote:
> 
> >There is a problem with the power management code for console.c
> >
> >The current code calls do_blank_screen(0); on PM_SUSPEND, and
> >unblank_screen() on PM_RESUME.
> >
> >The problem happens when X is the current display while putting the
> >machine to sleep. The do_blank_screen(0) code will do nothing as
> >the console is not in KD_TEXT mode.
> >However, unblank_screen has no such protection. That means that
> >on wakeup, the cursor timer & console blank timers will be re-enabled
> >while X is frontmost, causing the blinking cursor to be displayed on
> >top of X, and other possible issues.
> >
> >I hacked the following pacth to work around this. It appear to work
> >fine, but since the console code is pretty complex, I'm not sure about
> >possible side effects and I'd like some comments before submiting it
> >to Linus:
>...
> Before the patch: After a few days with a 2.4 kernel and RH7.0
> (XFree86-4.0.1-1 and XFree86-SVGA-3.3.6-33) the latop would
> misbehave at a resume event: when I opened the lid the screen would
> unblank and then after less than a second the entire screen would
> shift (wrap/rotate) left by about 40% of its width.
>...
> With the patch: No problem after 10 days with frequent suspend/resume
> cycles. (2.4.2-ac24 + the patch)

Correction: While the patch eliminated the X screen wrap problem at resume,
it caused a new problem: now when I exit X the console is left in a blanked
state. This seems to happen if at least one suspend/resume cycle has
occurred before X is terminated.

After some experimentation I came up with the patch below (vs. 2.4.3-ac3)
which _so_far_ behaves ok on my laptop. If the resume-while-in-X problems
resurface or not I won't know until after several more days of testing,
but at least the console is unblanked correctly again.

Does _anyone_ understand this code and its interactions with X? I'm lost...

/Mikael

--- linux-2.4.3-ac3/drivers/char/console.c.~1~	Thu Apr  5 15:57:36 2001
+++ linux-2.4.3-ac3/drivers/char/console.c	Thu Apr  5 18:52:43 2001
@@ -2713,23 +2713,23 @@
 		printk("unblank_screen: tty %d not allocated ??\n", fg_console+1);
 		return;
 	}
-	currcons = fg_console;
-	if (vcmode != KD_TEXT) {
-		console_blanked = 0;
-		return;
-	}
 	console_timer.function = blank_screen;
 	if (blankinterval) {
 		mod_timer(&console_timer, jiffies + blankinterval);
 	}
-
+	currcons = fg_console;
 	console_blanked = 0;
 	if (console_blank_hook)
 		console_blank_hook(0);
 	set_palette(currcons);
-	if (sw->con_blank(vc_cons[currcons].d, 0))
+	if (sw->con_blank(vc_cons[currcons].d, 0)) {
+		if (vcmode != KD_TEXT)
+			return;
 		/* Low-level driver cannot restore -> do it ourselves */
 		update_screen(fg_console);
+	}
+	if (vcmode != KD_TEXT)
+		return;
 	set_cursor(fg_console);
 }
 

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

[<ebi...@xm...>]

Ivan Kokshaysky <in...@ju...> writes:

> On Thu, Apr 05, 2001 at 12:20:22PM -0600, Eric W. Biederman wrote:
> > The point is on the Alpha all ram is always cached, and i/o space is
> > completely uncached.  You cannot do write-combing for video card
> > memory.
> 
> Incorrect. Alphas have write buffers - 6x32 bytes on ev5 and
> 4x64 on ev6, IIRC. So alphas do write up to 32 or 64 bytes
> in a single pci transaction.

Sorry I was thinking the current alpha the ev6.  So what I'm saying
doesn't apply to the alpha architecture in general just it's current
specific implementation.   

Yes for the ev6 you have write buffers but can't say just use the
write buffers,  on an arbitrary area of memory. 
 
> >  Memory barriers are a separate issue.  On the alpha the
> > natural way to implement it would be in the page table fill code.
> > Memory barriers are o.k. but the really don't help the case when what
> > you want to do is read the latest value out of a pci register.  
> 
> You don't need memory barrier for that. "Write memory barriers" are
> used to ensure correct write order, and "memory barriers" are used
> to ensure that all pending reads/writes will complete before next read
> or write.

100% Agreed. That is what I was saying.  What the ev6 doesn't have
is the ability to say this: I am using this area of the memory address
space in a particular way: don't cache it but do write combing on it.

Theoretically you could use memory barrier instructions for this but
it would require an I/O bus that supported a cache coherency
protocol.  At which point the problem moves down to your PCI bus
controller.

I recall on the ev6 all memory accesses to locations with bit 40 set 
are always to IO space are never cached and are never write buffered.
Accesses to memory locations with bit 40 clear are always to RAM are
always cached and always write buffered. 

With the high I/O bus speeds unless you are trying to push things to
the absolute limit you are unlikely to see the IO accesses being the
bottleneck in or out to a PCI device.  At which point DMA probably
already compensates, for most devices.

IIRC For PCI card IO regions where you need maximum IO speed through
the memory address space (like frame buffers) the ev6 falls down.

I really like the alpha this is why this gals me so much about the
ev6.  I hope they have it fixed for the ev7 or ev8.  If those chips
ever actually arrive.  But as the ev7 is just supposed to be the ev6
core with an on chip cache I don't have much hope.

Eric

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

[Ivan K. <in...@ju...>]

On Thu, Apr 05, 2001 at 12:20:22PM -0600, Eric W. Biederman wrote:
> The point is on the Alpha all ram is always cached, and i/o space is
> completely uncached.  You cannot do write-combing for video card
> memory.

Incorrect. Alphas have write buffers - 6x32 bytes on ev5 and
4x64 on ev6, IIRC. So alphas do write up to 32 or 64 bytes
in a single pci transaction.

>  Memory barriers are a separate issue.  On the alpha the
> natural way to implement it would be in the page table fill code.
> Memory barriers are o.k. but the really don't help the case when what
> you want to do is read the latest value out of a pci register.  

You don't need memory barrier for that. "Write memory barriers" are
used to ensure correct write order, and "memory barriers" are used
to ensure that all pending reads/writes will complete before next read
or write.

Ivan.

[Linux-fbdev-devel] [DRIVER] New framebuffer driver for Permedia3 (2.2.x & 2.4.y)

[Romain D. <do...@ir...>]

[To:linux-kernel & CC:linux-fbdev-devel]

Hello,

I've written a framebuffer (fbdev) driver for the 3DLabs Permedia3
chipset, targeted at both kernel 2.2.x and 2.4.y, and available at:

<http://www.irisa.fr/prive/dolbeau/pm3fb/pm3fb.html>

As mentioned on the page, the driver hasn't been thoroughly
tested except on my board, as even after two announcements
on the fbdev-devel list there hasn't been any answer beside
a XFree86 driver develloper. Fortunately that's two different
boards on two different architectures of different endianess.

The only _known_ remaining bug relate to depth switching,
going from 8 to 16/32 bpp give a wrong colormap (need to
go to X and back to restore). The only known current fix
is a small patch again driver/video/fbgen.c that probably
break something else, so I haven't included it in the
distributed patch.

If the driver is ever integrated, here's the MAINTAINERS
stuff: (not yet included in the linux kernel patches)

PERMEDIA 3 FRAMEBUFFER DRIVER
P: Romain Dolbeau
M: do...@ir...
L: lin...@li...
W: <http://www.irisa.fr/prive/dolbeau/pm3fb/pm3fb.html>
S: Maintained

Hope someone will find it useful,

-- 
DOLBEAU Romain               | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann        |     je l'ai imaginee d'un bout a l'autre
do...@ir...             |           -- Boris Vian

[Linux-fbdev-devel] Query:Regarding Virtual frame buffer

[Bipin T S <bi...@lg...>]

Hi,

>  We are using a Walnut board with a PPC processor. We don't have a
graphics chip/card in this board and so we planned to use the virtual
> frame buffer concept for debugging and testing the frame buffer
system. We build the kernel with the virtual frame buffer enabled in
Console
> drivers and we gave video = vfb:enable (Thanks to Simmons)  in the
command line options.

1) We tried giving echo "Hello World" > /dev/fb0. It works fine.

2) We wrote an application that mmaps the /dev/fb0 into user memory.
This works fine and mmap() returns a valid address

        fb = open("/dev/fb0", O_RDWR);
        addr =(unsigned char*)  mmap(NULL, size, PROT_READ|PROT_WRITE,
MAP_SHARED, fb, 0);

3) But when we try to write something into the MAPPED address, we get a
segmentation fault!!
            *( addr + 10) = 20;

We would like to know the reason for the above behaviour. Pointers and
references will be appreciated

Thanks and regards
Bipin

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

[<ebi...@xm...>]

"Maciej W. Rozycki" <ma...@ds...> writes:

> On Thu, 5 Apr 2001, Geert Uytterhoeven wrote:
> 
> > > 32bit writes on a bus with a word size of 64 or more bits.  By the way
> > > does anyone know who didn't implement MTRR's or the equivalent on
> > > alpha so we can shoot them?
> > 
> > People never get shot in Open Source projects. Not when they write buggy code,
> 
> > not when they don't implement some features.
> 
>  Was DEC Alpha an Open Source project? ;-)
> 
>  Memory barriers are more RISC-styled and more flexible anyway (e.g. you
> can't run out of them ;-) ), though they require a greater care when
> writing code.  MTRRs are the Intel style of complicating designs.  Still
> they are probably a reasonable solution to preserve DOS compatibility. 

The point is on the Alpha all ram is always cached, and i/o space is
completely uncached.  You cannot do write-combing for video card
memory.  Memory barriers are a separate issue.  On the alpha the
natural way to implement it would be in the page table fill code.
Memory barriers are o.k. but the really don't help the case when what
you want to do is read the latest value out of a pci register.  

Eric

[Linux-fbdev-devel] directcolor

[BERECZ S. <sz...@in...>]

Hi!

I have writen a prog, which works perfectly on a g400 card, which uses
truecolor visual, but it makes a really strange looking picture on an
ATI XPert@Work card, which uses directcolor.
so what does the directcolor mean?
or is there a document about fbdev for programmers?
I only found a howto for users...

Bye,
Szabi

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

[Maciej W. R. <ma...@ds...>]

On Thu, 5 Apr 2001, Geert Uytterhoeven wrote:

> > 32bit writes on a bus with a word size of 64 or more bits.  By the way
> > does anyone know who didn't implement MTRR's or the equivalent on
> > alpha so we can shoot them?
> 
> People never get shot in Open Source projects. Not when they write buggy code,
> not when they don't implement some features.

 Was DEC Alpha an Open Source project? ;-)

 Memory barriers are more RISC-styled and more flexible anyway (e.g. you
can't run out of them ;-) ), though they require a greater care when
writing code.  MTRRs are the Intel style of complicating designs.  Still
they are probably a reasonable solution to preserve DOS compatibility. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: ma...@ds..., PGP key available        +

Re: [Linux-fbdev-devel] Re: fbcon slowness [was NTP on 2.4.2?]

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

On 5 Apr 2001, Eric W. Biederman wrote:
> 32bit writes on a bus with a word size of 64 or more bits.  By the way
> does anyone know who didn't implement MTRR's or the equivalent on
> alpha so we can shoot them?

People never get shot in Open Source projects. Not when they write buggy code,
not when they don't implement some features.

Gr{oetje,eeting}s,

						Geert

P.S. Perhaps ESR tends to disagree? ;-)
--
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