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

[Linux-fbdev-devel] Re: fbdev updates

[Larry M. <lm...@bi...>]

On Tue, Jun 18, 2002 at 01:16:26PM -0700, James Simmons wrote:
> If anyone sent me updates in the last 14 days for the fbdev layer please
> send them again. I had a sync problem and then I attempted to fix it all
> my work got blown away for the last week by BK. I guess BK needs ALOT more
> work in this area.

Hmm.  Can you be more specific than "blown away"?  BK is careful to a fault
about not deleting your data.  Unless you did a "rm -rf my_repo" it's hard
to imagine that you lost anything.  How about you contact me offline and we'll
see if you changes are actually still there?
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

[Linux-fbdev-devel] fbdev updates

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

If anyone sent me updates in the last 14 days for the fbdev layer please
send them again. I had a sync problem and then I attempted to fix it all
my work got blown away for the last week by BK. I guess BK needs ALOT more
work in this area.

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

Re: [Linux-fbdev-devel] problem with gen_update_var

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

> In ywrap_up in fbcon.c, it has this code:
>
>     p->var.xoffset = 0;
>     p->var.yoffset = p->yscroll*fontheight(p);
>     p->var.vmode |= FB_VMODE_YWRAP;
>     p->fb_info->updatevar(unit, p->fb_info);
>
> (*p is struct display).  gen_update_var will call pan_display(info->var,
> con, info).

Only if con == currcon.

> But as can be seen, info->var is not updated by ywrap_up.

Your right. I will fix that.

> Unless, the low-level driver's implementation is to get the offsets
> from fb_display[con].var, that's the only time it will work.  But it
> will break userland apps that will call pan_display(var, con, info)
> expecting that the offsets contained in the passed var parameter will be
> updated.

Don't worry about userland apps. They can't pan non foreground consoles.
Only fbcon inside the kernel can.

[Linux-fbdev-devel] Re: tx3912 Re: [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.
>
> Does the code even boot on any machine having tx3912fb?

Yes :-) Also a few other types of MIPS devices use this framebuffer.

Re: [Linux-fbdev-devel] problem with gen_update_var

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

On Tue, 2002-06-18 at 03:27, James Simmons wrote:
> 
> > Hi,
> >
> > gen_update_var will break panning/wrapping since it passes info->var to
> > fb_pan_display.  However, fbcon updates display->var.
> 
> It works. The var info struct fb_info is always the foreground console.
> Notice gen_update_var is only called when it is the foreground console.
> 
> 
In ywrap_up in fbcon.c, it has this code:

    p->var.xoffset = 0;
    p->var.yoffset = p->yscroll*fontheight(p);
    p->var.vmode |= FB_VMODE_YWRAP;
    p->fb_info->updatevar(unit, p->fb_info);

(*p is struct display).  gen_update_var will call pan_display(info->var,
con, info).  But as can be seen, info->var is not updated by ywrap_up.  

Unless, the low-level driver's implementation is to get the offsets 
from fb_display[con].var, that's the only time it will work.  But it
will break userland apps that will call pan_display(var, con, info)
expecting that the offsets contained in the passed var parameter will be
updated.

Tony

Re: [Linux-fbdev-devel] problem with gen_update_var

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

> Hi,
>
> gen_update_var will break panning/wrapping since it passes info->var to
> fb_pan_display.  However, fbcon updates display->var.

It works. The var info struct fb_info is always the foreground console.
Notice gen_update_var is only called when it is the foreground console.

[Linux-fbdev-devel] MagicGraph 256AV framebuffer & kernel 2.5.21: problems

[Carlo E. P. <fl...@fl...>]

I had sent this message to the old list... This must have been the
reason I did not see any echo to it... ;-)

I hope I have better luck now.

----- Forwarded message from "Carlo E. Prelz" <fl...@fl...> -----

From: "Carlo E. Prelz" <fl...@fl...>
Date: Thu, 13 Jun 2002 13:16:07 +0200
To: lin...@vu...
Subject: [linux-fbdev] MagicGraph 256AV framebuffer & kernel 2.5.21: problems

My oldish Sony Vaio, whose video subsystem identifies itself as
follows:

00:0a.0 VGA compatible controller: Neomagic Corporation [MagicMedia 256AV] (rev 20) (prog-if 00 [VGA])
        Subsystem: Sony Corporation: Unknown device 805d
        Flags: medium devsel, IRQ 3
        Memory at fd000000 (32-bit, prefetchable) [size=16M]
        Memory at fe800000 (32-bit, non-prefetchable) [size=4M]
        Memory at fec00000 (32-bit, non-prefetchable) [size=1M]
        Capabilities: [dc] Power Management version 1

and which prints FB-related info at boot in this way:

 PCI: Found IRQ 3 for device 00:0a.0
 neofb: mapped io at c480d000
 Panel is a 1024x768 color TFT display
 neofb: mapped framebuffer at c4a0e000
 neofb v0.3.3: 2560kB VRAM, using 1024x768, 48.361kHz, 60Hz
 Console: switching to colour frame buffer device 128x48
 fb0: MagicGraph 256AV frame buffer device

has a curious behaviour in console mode. It seems that all output is
shifted 1 line downwards: when using a program that handles the screen
(mc, emacs) the topmost line is not used for display, while in normal
console, whenever print has to happen to the bottom line, printout is
not seen and scrolling does not take place. Changing virtual console
(ALT-rightArrow followed by ALT-leftArrow, for example) rebuilds the
right output.

This did not happen with kernel 2.5.19 and neovb v0.3.2. I expect it
must be something trivial, but I do not know where to put my hands... 

Carlo

----- End forwarded message -----

-- 
  *         Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fl...@fl...             che bisogno ci sarebbe
  *               di parlare tanto di amore e di rettitudine? (Chuang-Tzu)

[Linux-fbdev-devel] Help: Where can I find the Linux Framebuffer Driver Writing HOWTO ?

[hzeng <hz...@hf...>]

SGVsbG8sDQogICAgSSB3YW50ICB0byBnZXQgdGhlIExpbnV4IEZyYW1lYnVmZmVyIERyaXZlciBX
cml0aW5nIEhPV1RPLCBidXQgSSBjYW5ub3QgZW50ZXIgIHRoZSBzaXRlIGh0dHA6Ly93d3cubGlu
dXgtZmJkZXYub3JnLy4NCldoZXJlIGNhbiBJIGZpbmQgdGhlIGRvY3VtZW50PyAgT3IgeW91IGFy
ZSBraW5kIHRvIGVtYWlsIG1lIGEgY29weS4gDQpUaGFuayB5b3UgdmVyeSBtdWNoIQ0KSHplbmcN
Cg==

[Linux-fbdev-devel] i810/i815 2.5 framebuffer driver

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

Hi,

Hi, I have ported the i810fb to the 2.5 API.  I've tried to follow the
2.5 API as closely as possible and used only the gen_* functions as much
as possible.

The 2.4 i810 framebuffer driver has been posted in
http://www.sourceforge.net/projects/i810fb for sometime and has been
downloaded quite a number of times.  I've also received a number of mail
from people asking me if I should send the driver to be included to the
mainstream kernel.  I tell them it's not ready yet.  Because the driver
is dependent on agpgart, I have to modify the agpgart code just a bit so
agpgart gets loaded before the framebuffer at boot time.

So, I worked around this "misordered" loading by just having the fb
create and use its own agpgart services until the kernel agpgart becomes
available.  Once the kernel agpgart is available, the driver frees its
own and will start using the kernel's.  

I'm hopefully asking for people who have time to review the code and
perhaps give some thoughts on the agpgart thing.  And for those who have
the hardware, to test it as well.    

Thanks in advance.

Tony

PS:  the diff is against linux-2.5.21

http://i810fb.sourceforge.net/linux-2.5.21-i810fb.diff.gz

The actual source is in:

http://i810fb.sourceforge.net/i810fb.tar.gz

[Linux-fbdev-devel] problem with gen_update_var

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

Hi,

gen_update_var will break panning/wrapping since it passes info->var to
fb_pan_display.  However, fbcon updates display->var.

Tony

 

[Linux-fbdev-devel] Re: Updates to matroxfb: do you want DFP or TVOut on G450/G

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

On  8 Jun 02 at 2:57, Dave Jones wrote:
> On Sat, Jun 08, 2002 at 02:45:39AM +0200, Petr Vandrovec wrote:
>  > (4) You can read PINS through /proc.
>  > (H) Change /proc code to use driverfs instead. Linus refused
>  >     /proc based code already.
> 
> One of the first things I ever wrote for Linux was a PINS decoder.
> It read from /dev/mem to get the PINS structure. Any reason
> why this isn't good enough, and we need the kernel exporting PINS ?

It does not print decoded structure, it shows it in raw format, 64-128
bytes, just to avoid userspace parsing /dev/mem because of matroxfb 
did it already (and matroxfb needs PINS to properly initialize Gx50 
cards in non-PC hardware). And it may be non-trivial to get PINS from
userspace at all because of BIOSes may be disabled by firmware 
(and f.e. on my PC they are disabled for secondary adapters, so 
simple parsing /dev/mem leads to nowhere because of BIOS is hidden).

Besides that, it lives in complete separate file, so it is easy
to add/remove it.
                                    Best regards,
                                        Petr Vandrovec
                                        van...@vc...
                                        

[Linux-fbdev-devel] Re: Updates to matroxfb: do you want DFP or TVOut on G450/G550?

[Dave J. <da...@su...>]

On Sat, Jun 08, 2002 at 02:45:39AM +0200, Petr Vandrovec wrote:
 > (4) You can read PINS through /proc.
 > (H) Change /proc code to use driverfs instead. Linus refused
 >     /proc based code already.

One of the first things I ever wrote for Linux was a PINS decoder.
It read from /dev/mem to get the PINS structure. Any reason
why this isn't good enough, and we need the kernel exporting PINS ?


        Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs

[Linux-fbdev-devel] Updates to matroxfb: do you want DFP or TVOut on G450/G550?

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

Hello everybody,
  at http://platan.vc.cvut.cz/ftp/pub/linux/matrox-latest
you can find mga-2.5.20-tvout.gz. It is patch against
2.5.20-changeset1.465 (but should apply to 2.5.20
too, and with minor glitches also to 2.4.x - but I do
not plan to put this into official 2.4.x).

   Patch adds:
(0) Fixes CRTC2 bug in 2.5.x kernels. It will reject
    in 2.4.x, and 2.5.x before James's merges.

(1) You can change TV Out parameters on G400
    (luminance, hue, ...). Contributed by Mike Pipper,
    it should be compatible with V4L2.

(2) You can use TV Out capabilities of G450/G550.
    Do not forget that G450/G550 do not have vertical
    downscaler (or at least I did not find one),
    so for PAL use
    fbset -xres X -yres 580 -upper 22 -lower 22 -vslen 1
    where 456 <= X <= 1023 and for NTSC
    fbset -xres X -yres 480 -upper 22 -lower 22 -vslen 1
    where 464 <= X <= 1024. Pixclock does not matter,
    driver computes it to get 50Hz on PAL/59.94Hz on NTSC.
    Also do not forget that only CRTC2 can drive
    TV output on G450/G550. 
    Use matroxset to change secondary output mode
    between PAL/NTSC/monitor.

(3) You can now use DVI output of G550. By default
    you have same picture on all three outputs. Use
    matroxset to change it.

(4) You can read PINS through /proc.

   Known problems:
(a) If you have DFP connected to DVI port when MGA BIOS
    initializes hardware, it somehow forces whole card
    to be driven by TMDS clocks (or something like that...)
    and I did not found how to bring PLLs back to normal. 
    So it is possible that TVOut will not work for you in 
    such case. Simple hit ctrl-alt-del, disconnect DVI,
    and on LILO prompt connect it back. Help wanted...

   To do:
(A) Add changes (TVOut,1) to G450/G550 code. 

(B) Fix code which enforces 525/625 lines on screen in TVOut
    mode. Current behavior is very suboptimal.

(C) Verify that (DVI,3) works on G450. It should, but I have
    no G450-DVI to verify it.

(D) Rewrite DAC handling and PLL handling code. Currently
    it sets some registers unnecessary many times during
    mode switches, including reprogramming PLL even when
    PLL is not needed.

(E) Find what goes wrong if DFP is connected to DVI when
    BIOS boots.

(F) Add DDC support for G450/G550 secondary outputs & DVI.

(G) Add powersaving capabilities to secondary output,
    and to DVI (if someone will tell me how DVI powerdown
    happens).

(H) Change /proc code to use driverfs instead. Linus refused
    /proc based code already.

   Maybe:
(i) Get dual-DVI G550 and find whether it works, or not, and
    what needs to be done...

(ii) Port it to fbgen interface.

  Current version prints TONS of debug messages needed to
find what is wrong if it goes wrong - if driver does not work
for you, complain loudly. If patch breaks G400 or older card
support, please tell me too.

  Thanks should go to everyone who forced me to
look at DVI and TVOut capabilities of these beasts.

				Best regards,
					Petr Vandrovec
					van...@vc...

[Linux-fbdev-devel] [PATCH] matroxfb dies when you try to use secondary head in 2.5.x

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

Hi Linus,
   please apply this to 2.5.20. James introduced bad bug which
causes NULL pointer dereference as soon as you'll try to use
secondary head because of screen_base is not initialized
(it is initialized on wrong head).
				Thanks,
					Petr Vandrovec
					van...@vc...


diff -urdN linux/drivers/video/matrox/matroxfb_crtc2.c linux/drivers/video/matrox/matroxfb_crtc2.c
--- linux/drivers/video/matrox/matroxfb_crtc2.c	Mon Jun  3 01:44:45 2002
+++ linux/drivers/video/matrox/matroxfb_crtc2.c	Fri Jun  7 23:03:07 2002
@@ -383,7 +383,7 @@
 		chgvar = 0;
 	p->var = *var;
 	/* cmap */
-	ACCESS_FBINFO(fbcon.screen_base) = vaddr_va(m2info->video.vbase);
+	m2info->fbcon.screen_base = vaddr_va(m2info->video.vbase);
 	p->visual = visual;
 	p->ypanstep = 1;
 	p->ywrapstep = 0;

[Linux-fbdev-devel] vesafb and xres_virtual

[Paul F. <pa...@ga...>]

Hi all,
Perhaps someone can enlighten me. I've been ploughing through the vesafb 
source and various other bits (video.S in boot as well) and I see that 
the vesa driver supports changing the virtual y resolution but not the 
virtual x. I suspect there is a really good reason for this - possibly 
the real mode nature of BIOS calls or perhaps something to do with 
bytes_per_line and the console driver - but I am not sure. Would it be 
possible to allow virtual x resolutions to be set at startup? If not 
then can the authors please fix the rivafb driver for GeForce2 Go chips? 
:) I really need hardware x panning - it's for a demo that will boot and 
run off a floppy.

many thanks - and hoping to be able to contribute,

Paul.

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

[Pavel M. <pa...@uc...>]

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.

Does the code even boot on any machine having tx3912fb?
									Pavel
-- 
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa

[Linux-fbdev-devel] Re: Radeon video in PowerBook G4 800

[andrew m. <ac...@ac...>]

On Thu, Jun 06, 2002 at 12:17:31AM +0200, Benjamin Herrenschmidt wrote:
> >----- Forwarded message from andrew may <ac...@ac...> -----
> >
> >Date: Wed, 5 Jun 2002 15:55:04 -0700
> >From: andrew may <ac...@ac...>
> >To: bh...@ca...
> >Cc: Ani Joshi <aj...@sh...>,
> >  Linux fbdev <lin...@li...>
> >Subject: Radeon video in PowerBook G4 800
> >
> >I am having problems with the radeon fb driver in BenH's 2.4.19-pre10
> >kernel. When it boots I get a strange grayish red blob that covers most
> >of the screen starting from the bottom right side.
> >
> >I tried Xfree 4.20 and saw a similar effect.
> >
> >Here is a dump from the init with DEBUG turned on in the driver.
> >
> >The BenH kernel has some fixes from the 0.1.4 radeon driver and
> >I have not been able to get the 0.1.5 patch from the archieves 
> >to try.
> 
> Hrm, weird. Some users are running it without problem. 
> 
> Ani, any clue ?

Well I did get the 0.1.5 patch and I applied it. It did not seem
to help any. I had to merge things by hand at some parts since
the benh kernel did already have some stuff in there. 

Can I get a copy of the 0.1.5 instead of a patch so we can be sure
we are on the same page.

Ben, do you have any an email of someone that has it working
so we can try to compare some things?

[Linux-fbdev-devel] Re: 3dfx framebuffer driver borked in 2.5.19 kernel

[<id...@fe...>]

On Thu, May 30, 2002 at 11:40:14AM -0700, James Simmons wrote:
>=20
> > With the port to the new fbdev interface in kernel
> > 2.5.19 the system now only displays a few unchanging coloured pixels
> > on the first line of the screen.  The rest of the screen remains black
> > until X11 starts.  I am using append=3D"video=3Dtdfx:1024x768" in LILO.
>=20
> I'm tracking down the bug you are experiencing. Almost done.=20

Does the new interface handle multihead any better? I have a dual tdfx
system..

Am interested in testing patches. Head up?

--=20
Ferret

-- Support your government, give Echelon / Carnivore something to parse --
classfield top-secret government restricted data  information project  CIA
Microsoft terrorist Allah Natasha Gregori destroy destruct attack will own
send Russia bank system compromise  World Trade Center  international rule
presidental elections  policital foreign fnord embassy  takeover democracy
--------------------------------------------------------------------------

[Linux-fbdev-devel] Re: More fbdev to pull

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

> On Thu, Jun 06, 2002 at 06:48:00AM -0700, James Simmons wrote:
> >    Now for the new rounds of updates. Please pull the fbdev BK updates and
> > bug fixes.
> >
> > http://fbdev.bkbits.net:8080/fbdev-2.5
> >
> > Standard diff:
> >
> > http://www.transvirtual.com/~jsimmons/fbdev.diff.gz
>
> diffstat output would be useful.  Can you make it part of your standard
> mailings please?  That way, individual framebuffer maintainers know
> whether they need to bother looking or not.

 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: More fbdev to pull

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

On Thu, Jun 06, 2002 at 06:48:00AM -0700, James Simmons wrote:
>    Now for the new rounds of updates. Please pull the fbdev BK updates and
> bug fixes.
> 
> http://fbdev.bkbits.net:8080/fbdev-2.5
> 
> Standard diff:
> 
> http://www.transvirtual.com/~jsimmons/fbdev.diff.gz

diffstat output would be useful.  Can you make it part of your standard
mailings please?  That way, individual framebuffer maintainers know
whether they need to bother looking or not.

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

[Linux-fbdev-devel] More fbdev to pull

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

Hi!

   Now for the new rounds of updates. Please pull the fbdev BK updates and
bug fixes.

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

Standard diff:

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

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

[Linux-fbdev-devel] Re: Radeon video in PowerBook G4 800

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

You may wish to try http://www.unixbox.com/~ajoshi/radeon_drv.o.gz, unzip
and replace your /usr/X11R6/lib/modules/drivers/radeon_drv.o with it.
That should get X working.  If you cannot get the 0.1.5 patch from the
archives still, let me know and i'll send u a copy.


ani

On Wed, 5 Jun 2002, andrew may wrote:

> I am having problems with the radeon fb driver in BenH's 2.4.19-pre10
> kernel. When it boots I get a strange grayish red blob that covers most
> of the screen starting from the bottom right side.
>
> I tried Xfree 4.20 and saw a similar effect.
>
> Here is a dump from the init with DEBUG turned on in the driver.
>
> The BenH kernel has some fixes from the 0.1.4 radeon driver and
> I have not been able to get the 0.1.5 patch from the archieves
> to try.
>

[Linux-fbdev-devel] Radeon video in PowerBook G4 800

[andrew m. <ac...@ac...>]

I am having problems with the radeon fb driver in BenH's 2.4.19-pre10
kernel. When it boots I get a strange grayish red blob that covers most
of the screen starting from the bottom right side.

I tried Xfree 4.20 and saw a similar effect.

Here is a dump from the init with DEBUG turned on in the driver.

The BenH kernel has some fixes from the 0.1.4 radeon driver and
I have not been able to get the 0.1.5 patch from the archieves 
to try.

Re: [Linux-fbdev-devel] Radeonfb patch and riva

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

Hmm, dunno what happened there, attatched is another diff, should apply
cleanly now.  Its against 2.4.19-pre9.


ani

On Wed, 5 Jun 2002, James Simmons wrote:

>
> Joshi I looked at the riva part of your patch and it doesn't line up with
> wgat is in Linus tree. Do you a link to your latest riva fbdev driver ?
>
>
>    . ---
>    |o_o |
>    |:_/ |   Give Micro$oft the Bird!!!!
>   //   \ \  Use Linux!!!!
>  (|     | )
>  /'\_   _/`\
>  \___)=(___/
>
>
> _______________________________________________________________
>
> 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] Radeonfb patch and riva

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

Joshi I looked at the riva part of your patch and it doesn't line up with
wgat is in Linus tree. Do you a link to your latest riva fbdev driver ?


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