linuxconsole-dev

Re: [linux-fbdev] New atyfb

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

Hi!

  I have placed it into the console CVS. Want to give it a go with the new
API? The ATY driver already has a fillrect function. Its a matter of
writing a copyarea and imageblit function. Also some data reorganization
and cleanup.

Re: [linux-fbdev] New api again

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

> > For 2.5.X I plan to have it such that when you open /dev/fb that fbcon
> > shuts down (replaced by dummycon). This way fbcon and DRI or whatever
> > don't step on each others feet.
>
> I've been thinking about this. Why switch back to dummycon? You can keep on
> using fbcon, but disable rendering to the frame buffer. That way you don't have
> to handle the transfer of the shadow screen from fbcon to dummycon and vice
> versa.

You forget I have fbdev working with vgacon. I need to preserve the state
vgacon is in. Once /dev/fb is closed we can restore the state of vgacon.

Re: vga16fb_rectfill

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

> It should work, as far as my brain sees. But my brain is not VGA hardware...

It seems to ber a problem with the mode setting itself. I'm looking it
fixing it. I applied your work below including the fbmemset and wmb.
Thanks.

Re: [linux-fbdev] New api again

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

On Mon, 22 Jan 2001, James Simmons wrote:
> > My problem, is that you will have to be synchronizing in a way that is common
> > between fbdev/whatever and X. under X i am planning to do 2D access directly
> > to the rasterizer chip, but use the gamma for DRI/3D.
> 
> For 2.5.X I plan to have it such that when you open /dev/fb that fbcon
> shuts down (replaced by dummycon). This way fbcon and DRI or whatever
> don't step on each others feet.

I've been thinking about this. Why switch back to dummycon? You can keep on
using fbcon, but disable rendering to the frame buffer. That way you don't have
to handle the transfer of the shadow screen from fbcon to dummycon and vice
versa.

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

2.4.1 updates

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

Hi folks!!

   Ruby has bene updated to 2.4.1. The other good news is I have a card
which works as a VESA framebuffer. Now I can get some testing and bug
hunting done.

Re: vga16fb_rectfill

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

On 30 Jan 01 at 11:01, James Simmons wrote:

> Petr, for some reason I can't get this to work right. Does it look right
> to you?

It should work, as far as my brain sees. But my brain is not VGA hardware...
What about:
 
> static void vga16fb_fillrect(struct fb_info *info, int x1, int y1,
>                              unsigned int width, unsigned int height,
>                              unsigned long color, int rop)
> {
>         int line_ofs = info->fix.line_length - width;
>         char *where;
>         int x;
> 
 -         vga_io_wgfx(VGA_GFX_MODE, 0);
 +         vga_io_wgfx(VGA_GFX_MODE, 2);
>         vga_io_wgfx(VGA_GFX_DATA_ROTATE, 0);
 -         vga_io_wgfx(VGA_GFX_SR_ENABLE, 0xf);
 -         vga_io_wgfx(VGA_GFX_SR_VALUE, color);
>         vga_io_wgfx(VGA_GFX_BIT_MASK, 0xff);
> 
>         where = info->screen_base + x1 + y1 * info->fix.line_length;
> 
>         while (height--) {
>                 for (x = 0; x < width; x++) {
 -                         fb_writeb(0, where);
 +                         fb_writeb(color, where);
>                         where++;
>                 }

Saves two outw, at cost of using 'color' instead of zero in loop...
But both can be optimized to 'memset(where, X, width);' on most of archs.

Anyway, your original code is used by fbcon-vga-planes.c, at least
AFAIS... (different macros, writeb instead of fb_writeb...) On non-ia32 
you may have troubles with read/write ordering, but in this code and 
with current VGA adapters just 'wmb()' before 'while (height--)' should 
be sufficient, if 'vga_io_wgfx' uses outw and not two outb.
                                            Best regards,
                                                Petr Vandrovec
                                                van...@vc...
                                                

vga16fb_rectfill

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

Petr, for some reason I can't get this to work right. Does it look right
to you?

static void vga16fb_fillrect(struct fb_info *info, int x1, int y1,
                             unsigned int width, unsigned int height,
                             unsigned long color, int rop)
{
        int line_ofs = info->fix.line_length - width;
        char *where;
        int x;

        vga_io_wgfx(VGA_GFX_MODE, 0);
        vga_io_wgfx(VGA_GFX_DATA_ROTATE, 0);
        vga_io_wgfx(VGA_GFX_SR_ENABLE, 0xf);
        vga_io_wgfx(VGA_GFX_SR_VALUE, color);
        vga_io_wgfx(VGA_GFX_BIT_MASK, 0xff);

        where = info->screen_base + x1 + y1 * info->fix.line_length;

        while (height--) {
                for (x = 0; x < width; x++) {
                        fb_writeb(0, where);
                        where++;
                }
                where += line_ofs;
        }
        return;
}

Results

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

Hi!

   I have have /dev/fb working by itself (vga16fb) on vgacon :-) Next to
test fbcon.

Re: ruby in vesa fb

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

> Ruby today with vesafb gets as far as a black screen and then stops.
> Initialisation problems probably. It doesnt continue booting.

Okay. You had the same problem I did. I'm going to play with it today.

ruby in vesa fb

[Justin C. <jp...@do...>]

Ruby today with vesafb gets as far as a black screen and then stops.
Initialisation problems probably. It doesnt continue booting.

Justin

Fwd: bug report for matroxfb

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

Hi all,
  I got following bugreport for matroxfb:

On 25 Jan 01 at 16:51, Brieuc Jeunhomme wrote:

> Hi ! I'm not sure you are the right person to report this problem,
> please excuse me if you aren't. I have noticed that the driver does not
> display the proper number of spaces when printing the second tabulation
> of the file I send in attachement with a simple cat command. It is not a
> bug of cat, because I had the same problem with a dummy program which
> 
> And the resolution is 200x75. I hope this may help.

Code inspection found that tab_stop[] array has only 160 elements, instead
of needed 200...

Do you see any reason why not apply this patch? This extends vc_tab_stop[]
array from 5x32 bits to 8x32 bits - 256 columns should be enough, as
some kernel parts use only 8bit for column number, so anything wider than
255 does not work reasonable anyway.

Patch was generated from 2.4.0-ac9, but should work also with other versions
(namely 2.4.1-pre10). And even without this patch we need some fixing,
as Esc...g (set tabstop) can modify palette instead of tabstops for
columns >160 :-(

This patch has one problem - it changes size of vc_data struct, so kernels
before patch and after patch are not binary compatible in console subsystem.
						Thanks,
							Petr Vandrovec
							van...@vc...


diff -urdN linux/drivers/char/console.c linux/drivers/char/console.c
--- linux/drivers/char/console.c	Mon Jan 15 11:13:24 2001
+++ linux/drivers/char/console.c	Thu Jan 25 16:20:59 2001
@@ -1411,7 +1411,10 @@
 	tab_stop[1]	=
 	tab_stop[2]	=
 	tab_stop[3]	=
-	tab_stop[4]	= 0x01010101;
+	tab_stop[4]	=
+	tab_stop[5]	=
+	tab_stop[6]	=
+	tab_stop[7]	= 0x01010101;
 
 	bell_pitch = DEFAULT_BELL_PITCH;
 	bell_duration = DEFAULT_BELL_DURATION;
@@ -1689,7 +1692,10 @@
 					tab_stop[1] =
 					tab_stop[2] =
 					tab_stop[3] =
-					tab_stop[4] = 0;
+					tab_stop[4] =
+					tab_stop[5] =
+					tab_stop[6] =
+					tab_stop[7] = 0;
 			}
 			return;
 		case 'm':
diff -urdN linux/include/linux/console_struct.h linux/include/linux/console_struct.h
--- linux/include/linux/console_struct.h	Mon Oct 16 19:53:18 2000
+++ linux/include/linux/console_struct.h	Thu Jan 25 16:19:59 2001
@@ -68,7 +68,7 @@
 	unsigned char	vc_utf		: 1;	/* Unicode UTF-8 encoding */
 	unsigned char	vc_utf_count;
 		 int	vc_utf_char;
-	unsigned int	vc_tab_stop[5];		/* Tab stops. 160 columns. */
+	unsigned int	vc_tab_stop[8];		/* Tab stops. 256 columns. */
 	unsigned char   vc_palette[16*3];       /* Colour palette for VGA+ */
 	unsigned short * vc_translate;
 	unsigned char 	vc_G0_charset;

Re: working multihead

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

On 24 Jan 01 at 21:21, Brad Midgley wrote:
> > If it does not work with dualhead G400, then he did something wrong:
> 
> i wasn't aware that framebuffer could provide access to both screens on a g400. 
> 
> i guess i was basing that on the fact that the matrox-endorsed dual-monitor support for x is
> provided by a closed-source xf4 module -- fb is not used in that scenario.

Yes. It is really unfortunate that G400 driver in XFree is somewhere in
DGA broken - if you run it with 'UseFBDev' on G450, normal X works, but
DGA access (vmware) still accesses ramdac directly, killing monitor (200kHz
horizontal, 200 Hz vertical) and dies in endless loop (PLL not synced) :-(
Matrox driver works fine with UseFBDev.

> that's great we have fb driving two outputs on one card. i looked into doing that for the ati
> ltpro a while back. back then there was no clear way to set two framebuffers to be mirrored
> (taking advantage of the chip's native ability to mirror). mirroring is the main motivation for
> proper ltpro support.

It is only mode I do not support, as it would require too many changes to
my code, and also API is not clear yet... You always want independent
left/right/hslen/upper/lower/vslen/pixclock (and eventually xzoom/yzoom). 
Sometime you want independent xres/yres/xoffset/yoffset, but sometime you 
want them same for both CRTCs... And sometime you do not have enough pixclock
sources, so sometime secondary pixclock can be only few exact values
(33MHz (PCI), 66MHz (AGP), 150MHz (memory clocks), XXX (first head clocks)).
                                                Best regards,
                                                        Petr Vandrovec
                                                        van...@vc...
                                                        

module structure

[Justin C. <jp...@do...>]

AFter writing the newton serial keyboard driver, I found out that it
supports another keyboard (basically identical with a couple of extra
keycodes), and I wrote a driver for the Palm folding keyboard. Any thoughts
on whether I should produce seperate drivers for each device (except those
that are basically the same), or just produce a serkbd driver that has
config options to support selected or all serial keybaords?

The basic drivers are very similar apart from the keycode table, as serial
keyboards tend to be pretty simple, so one driver seems to make sense, so
I am slightly inclined to this. None of them have LEDs or in fact any
way of writing to them, as they just use the TX lines.

Any thoughts?

Justin

Re: working multihead

[Miguel F. <mi...@ce...>]

   Humm, I'm not pretty sure of what is going on, I haven't read the 
original post(s) of this thread...

   I think Brad is right, the multihead with multiple instances of 
XFree86 in a Matrox G400 should only be possible by using 
framebuffer interface. But as I have never been able to use fb with 
my hardware I haven't thought of this before. I wrote in the article 
that it should NOT work with boards like that.

   BTW, I may have removed something important for framebuffer 
from the init routines. If you want to use it please check for any 
mistakes the patch might have. Any updates on this issue are 
greatly appreciated...

Regards,

Miguel Freitas


On 24 Jan 01, at 19:18, Petr Vandrovec wrote:

> On 24 Jan 01 at 18:14, Brad Midgley wrote:
> > http://cambuca.ldhs.cetuc.puc-rio.br/multiuser/
> > 
> > he asks out loud but i'm pretty sure it wouldn't work with a card like a
> > dual-head matrox since two instances of X couldn't coordinate access to
> > the card. that's why the kernel would need to provide a framebuffer
> > interface to each screen (and demonstrates why we really need solid
> > kernel support for doing this properly)
> 
> If it does not work with dualhead G400, then he did something wrong:
> 
> (...)
> 
> If his driver tries to drive /dev/fb1 with matrox accelerated driver, it
> is for sure wrong - fb1 clearly says that there is no acceleration for
> this head. And each head returns 8MB (well, 7.9 and 8) of non-overlapping
> memory, so I do not see any problem here too.
> 
> Only problem which can arise is that fb1 supports 16/32bpp only, while fb0
> supports text/8/16/24/32. But it is again X/Xinerama problem, not fb
> one...
> 
> Or do I miss something?
>                                     Best regards,
>                                      Petr Vandrovec
>                                      van...@vc...
> 

Re: working multihead

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

> check out the hacks this guy made to x to make it support independent 
> multihead. interesting.

Interesting. Note with xfree86 with ruby once fbdev is working you can
start two instances of the X server. Each with the -vt option (-vt 0 for
first X server, -vt 16 for second X server). Then each X server will grab
a seperate keyboard. He is right tho. Future X servers should be using
/dev/eventX and /dev/fb to startup and not even use the console layer at
all.

Re: working multihead

[Brad M. <br...@tu...>]

Petr

> If it does not work with dualhead G400, then he did something wrong:

i wasn't aware that framebuffer could provide access to both screens on a g400. 

i guess i was basing that on the fact that the matrox-endorsed dual-monitor support for x is
provided by a closed-source xf4 module -- fb is not used in that scenario.

that's great we have fb driving two outputs on one card. i looked into doing that for the ati
ltpro a while back. back then there was no clear way to set two framebuffers to be mirrored
(taking advantage of the chip's native ability to mirror). mirroring is the main motivation for
proper ltpro support.

-- 
Brad
br...@tu...      http://www.turbolinux.com/~brad/

Re: working multihead

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

On 24 Jan 01 at 18:14, Brad Midgley wrote:
> http://cambuca.ldhs.cetuc.puc-rio.br/multiuser/
> 
> he asks out loud but i'm pretty sure it wouldn't work with a card like a dual-head matrox since
> two instances of X couldn't coordinate access to the card. that's why the kernel would need to
> provide a framebuffer interface to each screen (and demonstrates why we really need solid kernel
> support for doing this properly)

If it does not work with dualhead G400, then he did something wrong:

/dev/fb0:
mode "1024x768-60"
    # D: 64.994 MHz, H: 48.359 kHz, V: 59.998 Hz
    geometry 1024 768 1024 8188 8
    timings 15386 160 32 30 4 128 4
    accel true
    rgba 8/0,8/0,8/0,0/0
endmode

Frame buffer device information:
    Name        : MATROX
    Address     : 0xdc000000
    Size        : 8384512
    Type        : PACKED PIXELS
    Visual      : PSEUDOCOLOR
    XPanStep    : 8
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 1024
    MMIO Address: 0xdfefc000
    MMIO Size   : 16384
    Accelerator : Matrox G400


/dev/fb1:
mode "640x480-60"
    # D: 25.176 MHz, H: 31.469 kHz, V: 59.942 Hz
    geometry 640 480 640 480 32
    timings 39721 48 16 33 10 96 2
    rgba 8/16,8/8,8/0,8/24
endmode

Frame buffer device information:
    Name        : MATROX DH
    Address     : 0xdc7ff000
    Size        : 8388608
    Type        : PACKED PIXELS
    Visual      : TRUECOLOR
    XPanStep    : 8
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 2560
    MMIO Address: 0xdfefc000
    MMIO Size   : 16384
    Accelerator : No


If his driver tries to drive /dev/fb1 with matrox accelerated driver,
it is for sure wrong - fb1 clearly says that there is no acceleration
for this head. And each head returns 8MB (well, 7.9 and 8) of non-overlapping
memory, so I do not see any problem here too.

Only problem which can arise is that fb1 supports 16/32bpp only, while
fb0 supports text/8/16/24/32. But it is again X/Xinerama problem, not
fb one...

Or do I miss something?
                                    Best regards,
                                        Petr Vandrovec
                                        van...@vc...
                                        

working multihead

[Brad M. <br...@tu...>]

hi

check out the hacks this guy made to x to make it support independent multihead. interesting.

http://cambuca.ldhs.cetuc.puc-rio.br/multiuser/

he asks out loud but i'm pretty sure it wouldn't work with a card like a dual-head matrox since
two instances of X couldn't coordinate access to the card. that's why the kernel would need to
provide a framebuffer interface to each screen (and demonstrates why we really need solid kernel
support for doing this properly)

-- 
Brad
br...@tu...      http://www.turbolinux.com/~brad/

Which fb driver?

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

Justin which fbdev driver do you need updated? I believe I have the fbdev
layer to the point where it should work. I have been trying various video
cards here but none with VESA fb, even with standard tree :-(  

Re: Odd Question: pc_keyb as a module?

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

> I have a need to use pc_keyb as a module. I am using off the shelf ps/2
> keyboard chipsets as chording keyboard controllers. This uses a modified
> pc_keyb.c that see's multiple key presses and translates them into
> scancodes that are then handled by the rest of the keyboard driver.
> 
> It would make life much better if I were able to have one pc_keyb.o module
> that was the kernel original and another that has the chording code. That
> way I could swap them, and I wouldn't need to rebuild and install an 
> entirely kernel everytime I make a tweak to the chording code.
> 
> I'm not entirely sure home much trouble this would cause. But any help or
> direction would be much appreciated.

Hi!
 
   Actually we have something like that in our developement tree. We have
converted over the PS/2 chipset and their devices to the Input API. The
drivers are completely modular. With a USB keybaord this would be really
handy. If have more questions just ask. Take a look at

http://linuxconsole.sourceforge.net

Re: Linux console documentation

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

> Is there some documentation about your project, that describes where
> it is going and what's the current status of the linux console.
> And also of its arhitecture, APIs etc...

Not really. Anyone whats to step forward? I was hoping to get fbcon
running in the next few days. Once this is done most of the critical work
is done. Then it is just a matter of adding needed functionality and bug
fixes.

Re: [linux-fbdev] New api again

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

> Ok, i understand this. each pipe can also be called unit, isn't it ?

Yes. I also have heard it called a stage.

> > Well that depends. Can data be processed by one Pm4 chip and then passed
> > to the second Pm4 chip to be processed by another stage? A good example
> 
> No, but they can handle part of the same image, or process the exact same
> image doubly.

Don't think image. Think vertice object passed into the accel engine to 
be operated on. Rastering the image is just the last stage of the pipeline
that translates for processed vertice data into pixel image on screen.

> No, rotate is done by the gamma.
[snip]...

Okay. That was just for a example.

> You will need an NDA to get access to the specs though :(((

I plan to get around to this card eventually. 

> But i thought that as long as you are planing a new API, it may as well take
> this kind of cases into acount.

That is why I though about this approach.

> You are wrong, both the gamma and the permedia chips can do DMA (with kernel
> or DRI help), command MMIO (register writing) or direct fifo access (well you
> send pairs of register address and command data down the pipeline, sort of
> busy dma-like behavior without a dma engine).

Okay. Now I have a good understanding of what is going on. Most higher end
cards have a dual pipeline line approach. One for 2D stuff and one for 3D
stuff. The reason it is done this way is because the 3D stuff can take a
long time to process when compared to the 2D stuff. This would make the
X server very non responsive. With a dual pipeline approach you can a 
a independent pipeline that handles 2D so the X server is still snappy
while still processing 3D stuff for different OpenGL clients. 

> My problem, is that you will have to be synchronizing in a way that is common
> between fbdev/whatever and X. under X i am planning to do 2D access directly
> to the rasterizer chip, but use the gamma for DRI/3D.

For 2.5.X I plan to have it such that when you open /dev/fb that fbcon
shuts down (replaced by dummycon). This way fbcon and DRI or whatever
don't step on each others feet.

Linux console documentation

[Damjan <ar...@fr...>]

SXMgdGhlcmUgc29tZSBkb2N1bWVudGF0aW9uIGFib3V0IHlvdXIgcHJvamVjdCwgdGhhdCBk
ZXNjcmliZXMgd2hlcmUNCml0IGlzIGdvaW5nIGFuZCB3aGF0J3MgdGhlIGN1cnJlbnQgc3Rh
dHVzIG9mIHRoZSBsaW51eCBjb25zb2xlLg0KQW5kIGFsc28gb2YgaXRzIGFyaGl0ZWN0dXJl
LCBBUElzIGV0Yy4uLg0KDQoNCi0tIA0KRGFtamFuIEdlb3JnaWV2c2tpCQl8ICAgICAgICAg
ICDQlNCw0LzRmNCw0L0g0JPQtdC+0YDQs9C40LXQstGB0LrQuA0KU2tvcGplLCBNYWNlZG9u
aWEJCXwgICAgICAgICAgINCh0LrQvtC/0ZjQtSwg0JzQsNC60LXQtNC+0L3QuNGY0LANCg==

Re: [linux-fbdev] New api again

[Sven L. <lu...@dp...>]

On Thu, Jan 18, 2001 at 04:31:36PM -0800, James Simmons wrote:
> 
> > what if i wanted to write a fbdev for, for example, the 3Dlabs Oxygen GVX420
> > board ? 
> > 
> > For you information this board contains 3 different chip, A gamma 2 chip,
> > acting as agp bridge and T&L engine, and 2 Permedia4 chips, doing 3D setup and
> > rasterization. They can be configuredto be shared for rasterizing the same
> > framebuffer, splitting the scanline between them, or to support dual head.
> 
> I assume T&L is texture and lighting engine. 

Yes, that and some other stuff, i cannot say more though.

> > Each Pm4 has one pipeline, i think.
> 
> First a pipeline is a collect of pipes. Each pipe takes data and changes
> it a certain way. This occurs until we reach the end of the pipeline when
> we get the final desired rastered image.

Ok, i understand this. each pipe can also be called unit, isn't it ?

> Well that depends. Can data be processed by one Pm4 chip and then passed
> to the second Pm4 chip to be processed by another stage? A good example

No, but they can handle part of the same image, or process the exact same
image doubly.

> would be say a triangle strip was passed to the the first chip to say be
> rotated. Then that data is passed onto the second chip to be tranformed to

No, rotate is done by the gamma.

> give the appearance of a prespective view. In this case their is one

mmm, i can have stereoscopic view from one pm4. I guess you can also have two
identic copies of the image in both pm4, each rendering to one output. not
sure though.

> pipeline with 2 pipes. Now if this doesn't occur and each chip processes
> data independent of each other then their is two pipelines with one pipe

I think what trully happens is that it can be configured as only one pipe, or
as two independent pipes, isn't it ?

> each. This is of course assuming each GPU, the Pm4's, can't handle more
> than one graphics command at a time. Is the T&L shared between both

Not true, they can have more than one framebuffer (upto 4 i think). 

> GPU's. I really have to look at the hardware specs to say exactly. As you
> can see for a mor advance card like the Oxygen things get more a bit more
> complex. 

You will need an NDA to get access to the specs though :(((

But i thought that as long as you are planing a new API, it may as well take
this kind of cases into acount.

I may be writting a fbdev for the appian J2000 (two pm3 and 1 gamma, the pm3
cannot be shared for 1 display though, only in dual head, but the gamma can
provide 3D Accel for both display).

> > The additional problem, is that you can address the rasterizer chip either
> > directly (they have FB and Command register pci aperture, and a separate pci
> > id) or trough the Gamma chip, for example, for when doing 3D, you send command
> > to the gamma, which process them (T&L) and then forward the low level commands
> > to one or both Permedia4 chip. If you want ot use one or both accesses, you
> > would need to synchronize correctly between them.
> 
> Okay I'm taking a shot in the dark since I don't have the specs but I'm 
> assuming the Gamma chip is for DMA, especially since you mentioned that 
> it manages the agp port, and the Command register space is for MMIO

mmm, ...

To share some light on the circunstances, i am doing the Xfree driver for it.

You are wrong, both the gamma and the permedia chips can do DMA (with kernel
or DRI help), command MMIO (register writing) or direct fifo access (well you
send pairs of register address and command data down the pipeline, sort of
busy dma-like behavior without a dma engine).

> programming. Yes you do you have to manage access to both of them. 

I have access to both type of command with both type of chips.

> Internal to the fbdev driver this is pretty simple. When userland wants to
> play around with this stuff then you need a RRM (rendering resource
> manager) to balance access. As 2.4.X stands right now you can't use the 
> DMA with fbcon but I will be working on this problem right now. 

My problem, is that you will have to be synchronizing in a way that is common
between fbdev/whatever and X. under X i am planning to do 2D access directly
to the rasterizer chip, but use the gamma for DRI/3D.

Friendly,

Sven Luther

Re: console spin_lock

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

> This statement of mine was grade-A bollocks.  printk cannot of
> course call down().  It needs to use __down_trylock and buffer
> it up if it fails. (faster, too!)

Okay. I'm going to start working on this tomorrow.