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

Re: [Linux-fbdev-devel] National Geode Framebuffer Drivers

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

> I have posted National's Framebuffer drivers for the Geode processor's
> onboard video at www.eason.com/linux, along with my commentary.  Some of you
> folks may be interested, and I'd love to see this in the kernel once all the
> cruft has been stripped out.

Wow!! I see you got it out the door. I also worked on this device but I
was under NDA. Now that the driver is out I can work on it.

P.S
   They do have everything in their. Oh my!!

RE:[Linux-fbdev-devel] Whats the scoop for the apollo framebuffers?

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

> >I noticed dnfb.c and dn_cfb4.c and dn_cfb8.c. They look the same except
> >for different modes. Anyone have a clue here?
>
> Yes, the only functionnal one was dnfb.c, the others were for testing
> purpose:

So would it be safe to remove dn_cfb4[8].c ?

> Developpers Peter (and me for a less big part) had only the mono frame
> buffer board.
> There is color boards for Apollo DN workstation for which I have docs, but
> I no longuer
> have access to the hardware, color fb or Apollo. Basic color fb management
> is similar to
> the mono one.
> Apollo hardware is ISA based, perhaps someone still have some working one.
> I stoped working on Linux Apollo port because of lack of hardware.

I ported over dnfb.c to the new api. I will post for people to try it.

Re: [Linux-fbdev-devel] Possible bug: nasty interaction between framebuffer and DRI/DRM

[Chris H. <ch...@gm...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

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?

Cheers

=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE898NRF8Iu1zN5WiwRAiU5AJ95WKTct4sFOXe+ruIMvlICGxyhFACggQvB
0RaUngCVTJQdFTS3H3ceb7c=3D
=3D/n6Q
=2D----END PGP SIGNATURE-----

RE:[Linux-fbdev-devel] Whats the scoop for the apollo framebuffers?

[<e....@fo...>]

>I noticed dnfb.c and dn_cfb4.c and dn_cfb8.c. They look the same except
>for different modes. Anyone have a clue here?

Yes, the only functionnal one was dnfb.c, the others were for testing
purpose:
Developpers Peter (and me for a less big part) had only the mono frame
buffer board.
There is color boards for Apollo DN workstation for which I have docs, but
I no longuer
have access to the hardware, color fb or Apollo. Basic color fb management
is similar to
the mono one.
Apollo hardware is ISA based, perhaps someone still have some working one.
I stoped working on Linux Apollo port because of lack of hardware.

Bye.


Emmanuel.
(Sory for my froggy english ;-))

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:
> I seem to have discovered a nasty interaction between framebuffer and DRI/DRM 
> in OpenGL applications. I can reproduce this problem in at least Return to 
> Castle Wolfenstein (version 1.1b) and Tux Racer.
> 
> I am using a 32 MB ATI Rage Pro 128 on Debian woody (XFree86 4.1). If I run 
> Tuxracer or RTCW, and wait for the game to load, everything is alright. 
> However if I switch to a spare virtual terminal, and switch back to X, the 
> fonts become illegible -- they just appear as coloured boxes with no 
> outlines, making things unplayable.
> 
> The problem does not occur when using software based OpenGL rendering which is 
> why I believe DRI/DRM is involved. This problem only occurs when framebuffer 
> is enabled in the kernel, if framebuffer is disabled the problem disappears, 
> so I believe framebuffer is also at fault.

Do you use `option UseFBDev' in your XF86Config?

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

[Keith W. <ke...@tu...>]

Chris Howells wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> I seem to have discovered a nasty interaction between framebuffer and DRI/DRM 
> in OpenGL applications. I can reproduce this problem in at least Return to 
> Castle Wolfenstein (version 1.1b) and Tux Racer.
> 
> I am using a 32 MB ATI Rage Pro 128 on Debian woody (XFree86 4.1). If I run 
> Tuxracer or RTCW, and wait for the game to load, everything is alright. 
> However if I switch to a spare virtual terminal, and switch back to X, the 
> fonts become illegible -- they just appear as coloured boxes with no 
> outlines, making things unplayable.

It sounds like the texture cache is getting wiped out, but the DRI drivers 
aren't realizing that it's happened.  This shouldn't be too hard to fix if 
someone has time.

Keith

[Linux-fbdev-devel] Re: Possible bug: nasty interaction between framebuffer and DRI/DRM

[Chris H. <ch...@gm...>]

Hi,

On Friday 31 May 2002 12:54 pm, Chris Howells wrote:

> I seem to have discovered a nasty interaction between framebuffer and
> DRI/DRM in OpenGL applications. I can reproduce this problem in at least
> Return to Castle Wolfenstein (version 1.1b) and Tux Racer.


Meant to say this before...

I can reproduce this under both kernel 2.4.17 and 2.4.18.

[Linux-fbdev-devel] Possible bug: nasty interaction between framebuffer and DRI/DRM

[Chris H. <ch...@gm...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I seem to have discovered a nasty interaction between framebuffer and DRI/D=
RM=20
in OpenGL applications. I can reproduce this problem in at least Return to=
=20
Castle Wolfenstein (version 1.1b) and Tux Racer.

I am using a 32 MB ATI Rage Pro 128 on Debian woody (XFree86 4.1). If I run=
=20
Tuxracer or RTCW, and wait for the game to load, everything is alright.=20
However if I switch to a spare virtual terminal, and switch back to X, the=
=20
fonts become illegible -- they just appear as coloured boxes with no=20
outlines, making things unplayable.

The problem does not occur when using software based OpenGL rendering which=
 is=20
why I believe DRI/DRM is involved. This problem only occurs when framebuffe=
r=20
is enabled in the kernel, if framebuffer is disabled the problem disappears=
,=20
so I believe framebuffer is also at fault.

Greatful for any help...

Chris Howells
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE892SKF8Iu1zN5WiwRAgMbAJ0V5bWa85Lfsgu4FFtKeIj4c/YX8gCcCrn6
YU1lq0HuQpefLVGsDvFzN4E=3D
=3DqzHZ
=2D----END PGP SIGNATURE-----

[Linux-fbdev-devel] Whats the scoop for the apollo framebuffers?

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

I noticed dnfb.c and dn_cfb4.c and dn_cfb8.c. They look the same except
for different modes. Anyone have a clue here?
 

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

RE: [Linux-fbdev-devel] Making drawing functions available to use rland

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

If you expose the basic blit acceleration functions then there shouldn't be
any reason not to have the device independent fbdev X driver use them.
However, I would stop there. Any function that is not very easily supported
by nearly all fb drivers (Basically anything that isn't a blit) should not
be used in the fbdev driver.

If you want to have a full featured X driver (with Xv etc. ) then you need a
device dependent X driver just as you have now. Instead of the device
dependent driver touching the hardware directly it would just go through a
very thin ioctl (a device dependent one).
This is very similar to how the DRI/DRM work.

There should not be concern for "locking the kernel" If you can't make the
ioctl safe for application use then you shouldn't make it available.
Basically there is no good reason you can't make very thin device dependent
ioctls that can't be abused. The DRM's do this quite well.  During
development is the only time when you have a greater risk of hanging the
kernel... and that is only slightly more catastrophic than wedging the
graphics engine from user-space anyway.

-Matt


-----Original Message-----
From: Antonino Daplas [mailto:ad...@po...]
Sent: Friday, May 31, 2002 8:08 PM
To: fbdev
Subject: [Linux-fbdev-devel] Making drawing functions available to
userland


Hi again,

In my other e-mail, I touched on the possibility of exporting the
drawing functions to userspace.  Actually, I was delving a little on
that.  I added 3 IOCTLS (FBIO_DOACCEL, FBIO_GETCAPABILITIES, and
FBIOSYNC) to the fb API (2.5.19) whose main functions are to describe
the drawing capability of the driver and making them accessible to
userland.  To test that, I added XAA and DGA to XFree86 fbdev and
fbdevhw driver. Here's a part of the XFree86 log:

<<< cut >>>
 (**) FBDEV(0): Enabling Acceleration
(II) Loading sub module "xaa"
(II) LoadModule: "xaa"
(II) Loading /usr/X11R6/lib/modules/libxaa.a
(II) Module xaa: vendor="The XFree86 Project"
	compiled for 4.2.0, module version = 1.0.0
	ABI class: XFree86 Video Driver, version 0.5
(II) FBDEV(0): Using fillrect for SolidFill.
(II) FBDEV(0): Using copyarea for ScreenToScreenCopy.
(II) FBDEV(0): Using imageblit for Mono8x8PatternFill.
(II) FBDEV(0): Using XFree86 Acceleration Architecture (XAA)
	Screen to screen bit blits
	Solid filled rectangles
	8x8 mono pattern filled rectangles
	Solid Horizontal and Vertical Lines
<<< cut >>>

I'm not really going to push for this since I already recognize a few
difficulties.  Firstly, making the drawing functions accessible will
increase the likelihood of crashing the kernel.  Secondly, people might
not remain contented and add more functionality increasing kernel bloat.

Anyways, any thoughts on this?

Tony
---------------------------------------------------------------------

PS: A few benchmarks...

XFBDev - no accel
=================

36000 reps @   0.1407 msec (  7110.0/sec): 100x100 rectangle

18000 reps @   0.3206 msec (  3120.0/sec): 100x100 opaque stippled
rectangle (8x8 stipple)

32000 reps @   0.1713 msec (  5840.0/sec): Copy 100x100 from window to
window

XFBDev - accel
==============

144000 reps @   0.0422 msec ( 23700.0/sec): 100x100 rectangle

18000 reps @   0.3010 msec (  3320.0/sec): 100x100 opaque stippled
rectangle (8x8 stipple)

80000 reps @   0.1026 msec (  9750.0/sec): Copy 100x100 from window to
window

native i810_drv
===============

144000 reps @   0.0428 msec ( 23300.0/sec): 100x100 rectangle

144000 reps @   0.0429 msec ( 23300.0/sec): 100x100 opaque stippled
rectangle (8x8 stipple)

80000 reps @   0.1060 msec (  9430.0/sec): Copy 100x100 from window to
window





_______________________________________________________________

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

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

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

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)

If you are going to allow user apps to drive the blitter you don't want to
force a sync after each call. An application that is doing a lot of blitting
would be wasting lots of time syncing when there is only need for just one
sync at the end. The whole point of ring buffers is to pipeline
instructions, you'd loose this if you always synced.

-Matt



-----Original Message-----
From: Antonino Daplas [mailto:ad...@po...]
Sent: Friday, May 31, 2002 8:07 PM
To: fbdev
Subject: [Linux-fbdev-devel] Adding an fb_sync() operation to fb_ops


Hi,

I have been tesing the 2.5 API for some time now, and I really like the
new changes.  The trend is to consolidate hardware acceleration into 3
functions, fillrect, copyarea and imageblit.  However, there is still
something bugging me. I don't think we can totally avoid mixing direct
graphics memory access with hardware blitting.  For instance, some
drivers probably will have a mixture of accelerated and unaccelerated
drawing functions which may lock up the graphics engine.

In order to avoid that, should we:

a. Just force a hardware sync after each blit?; or

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.

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

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

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.

Tony 


_______________________________________________________________

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] [PATCH] Fbdev updates and fixes.

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

Here are several fixes and a few new ports. The drivers I ported over
to the new api are: 

1) 3DFX Voodoo3+ fbdev driver 

2) NeoMagic fbdev driver

Please review these drivers. 

-----------------
The fixes where for the anakin framebuffer and CLPS711X framebuffer.


/////////////////////////////////////////////////////////////////////
The standard diff is at 

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

and the BK link is 

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

Thank you.

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

[Linux-fbdev-devel] Making drawing functions available to userland

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

Hi again,

In my other e-mail, I touched on the possibility of exporting the
drawing functions to userspace.  Actually, I was delving a little on
that.  I added 3 IOCTLS (FBIO_DOACCEL, FBIO_GETCAPABILITIES, and
FBIOSYNC) to the fb API (2.5.19) whose main functions are to describe
the drawing capability of the driver and making them accessible to
userland.  To test that, I added XAA and DGA to XFree86 fbdev and
fbdevhw driver. Here's a part of the XFree86 log:

<<< cut >>>
 (**) FBDEV(0): Enabling Acceleration
(II) Loading sub module "xaa"
(II) LoadModule: "xaa"
(II) Loading /usr/X11R6/lib/modules/libxaa.a
(II) Module xaa: vendor="The XFree86 Project"
	compiled for 4.2.0, module version = 1.0.0
	ABI class: XFree86 Video Driver, version 0.5
(II) FBDEV(0): Using fillrect for SolidFill.
(II) FBDEV(0): Using copyarea for ScreenToScreenCopy.
(II) FBDEV(0): Using imageblit for Mono8x8PatternFill.
(II) FBDEV(0): Using XFree86 Acceleration Architecture (XAA)
	Screen to screen bit blits
	Solid filled rectangles
	8x8 mono pattern filled rectangles
	Solid Horizontal and Vertical Lines
<<< cut >>>

I'm not really going to push for this since I already recognize a few
difficulties.  Firstly, making the drawing functions accessible will
increase the likelihood of crashing the kernel.  Secondly, people might
not remain contented and add more functionality increasing kernel bloat.

Anyways, any thoughts on this?

Tony
---------------------------------------------------------------------

PS: A few benchmarks...

XFBDev - no accel
=================

36000 reps @   0.1407 msec (  7110.0/sec): 100x100 rectangle

18000 reps @   0.3206 msec (  3120.0/sec): 100x100 opaque stippled
rectangle (8x8 stipple)

32000 reps @   0.1713 msec (  5840.0/sec): Copy 100x100 from window to
window

XFBDev - accel
==============

144000 reps @   0.0422 msec ( 23700.0/sec): 100x100 rectangle

18000 reps @   0.3010 msec (  3320.0/sec): 100x100 opaque stippled
rectangle (8x8 stipple)

80000 reps @   0.1026 msec (  9750.0/sec): Copy 100x100 from window to
window

native i810_drv
===============

144000 reps @   0.0428 msec ( 23300.0/sec): 100x100 rectangle

144000 reps @   0.0429 msec ( 23300.0/sec): 100x100 opaque stippled
rectangle (8x8 stipple)

80000 reps @   0.1060 msec (  9430.0/sec): Copy 100x100 from window to
window

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

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

Hi,

I have been tesing the 2.5 API for some time now, and I really like the
new changes.  The trend is to consolidate hardware acceleration into 3
functions, fillrect, copyarea and imageblit.  However, there is still
something bugging me. I don't think we can totally avoid mixing direct
graphics memory access with hardware blitting.  For instance, some
drivers probably will have a mixture of accelerated and unaccelerated
drawing functions which may lock up the graphics engine.

In order to avoid that, should we:

a. Just force a hardware sync after each blit?; or

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.

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

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

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.

Tony 

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

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

> 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="video=tdfx:1024x768" in LILO.

I'm tracking down the bug you are experiencing. Almost done. 

[Linux-fbdev-devel] National Geode Framebuffer Drivers

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

I have posted National's Framebuffer drivers for the Geode processor's
onboard video at www.eason.com/linux, along with my commentary.  Some of you
folks may be interested, and I'd love to see this in the kernel once all the
cruft has been stripped out.

Alex Pavloff
Software Engineer
Eason Technology  

[Linux-fbdev-devel] Framebuffer policy [ was Re: Linux 2.5.19]

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

> This is about people who think they're god nicking patches from
> the author and maintainer of drivers and bypassing the maintainer
> completely.

Please no fighting. It is clear the problem is the lack of order here.
I understand how Russell feels. Most of the time people send in new fbdev
drivers or good size patches without consulting me or Geert first. I have
to say it has gotten better. So here goes for policy time:

--------------------------------------------------------------------
             Framebuffer driver policy.

1) Basic one or few line fixes for drivers can go straight into the
   kernel. Please don't abuse this.

2) All new drivers must be posted to the fbdev developement list for
   peer review. Me and/or geert have final fword about them going in.
   Please note we do get busy so just harass me about your driver. I
   will not be offended and it pushs me to go do it. I'm the type of
   person if I don't do it right away I will forget.

   lin...@li...

3) Large changes should be posted to both the framebuffer list and the
   kernel mailing list as well to the framebuffer author if they
   are know. Again it is for peer review and wide scale testing. We 
   need to make clear what drivers where effect. And yes if you are the 
   maintainer of a driver you should mail yourself. It makes it easier
   for users to reply to you directly.  

If no one follows these rules then their changes will be ignored. No
exceptions including for myself.

-----------------------------------------------------------------
How does this sound? Again sorry about the confusion.

[Linux-fbdev-devel] sis acceleration

[Andre D. <ao...@un...>]

Hi!

I have built the latest 2.4.18 stable several times. But when I try to 
include as a module the SIS acceleration ( SIS 630/540/730 support only ) 
for the frame buffer I get this error:

depmod: *** Unresolved symbols in 
/lib/modules/2.4.18/kernel/drivers/video/sis/sisfb.o
depmod:         mclk
depmod:         sisfb_set_dispsw_accel
depmod:         eclk
depmod:         sisfb_init_legacy_vga
depmod:         sisfb_calc_clock_param
depmod:         sisfb_calc_clock_freq
make: *** [_modinst_post] Error 1


does anyone know to whom should I send a bug report?

thanks in advance

[Linux-fbdev-devel] Re: Linux 2.5.19

[Martin D. <da...@ev...>]

Russell King wrote:

> If you think this is acceptable, why the hell did I bother sending those
> IDE DMA changes through you?  After all, you don't need to know about
> them because I know better than you, don't I?  *That's* what you're
> advocating here, and I'm sure you're going to object to that.

Well just to make my point clear. I trust you and I thing that you indeed
know better then me on ARM stuff. (At least you can run it on
more then my tinny PSION 5mx... where I still didn't revert to
the original OS, quite cute this little thing under linux :-).
But I wouldn't have minded it at all if you had just sendid
the ARM adjustments directly to Linus!
In the particular case we had it was however good to
have some direct communication in front
just to resolve the API issues. OK?

[Linux-fbdev-devel] Re: Linux 2.5.19

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

On Thu, May 30, 2002 at 12:42:09AM +0200, Martin Dalecki wrote:
> Well ... they have once excuse... if the maintainer is
> himself a bit slow on submitting to Linus. Yes I know that's
> a matter primary of personal style so there is no need
> to discuss about it until down...

You still don't get the point.

1. Patches from cyber2000fb.c have been submitted and the driver in Linus'
   tree up to 2.5.18 is completely up to date and functional, with zero
   known problems.

2. Someone comes along, scans my patch and finds a change.

3. This person takes it upon themselves to solely take that change,
   and, without querying the person who put out the patch set, or
   the maintainer of the driver, decides to send it to Linus without
   testing it in any way since they don't have the hardware to test it.

4. Maintainer, naturally, gets really pissed off.

If you think this is acceptable, why the hell did I bother sending those
IDE DMA changes through you?  After all, you don't need to know about
them because I know better than you, don't I?  *That's* what you're
advocating here, and I'm sure you're going to object to that.

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

[Linux-fbdev-devel] Re: Linux 2.5.19

[Martin D. <da...@ev...>]

Russell King wrote:

> What if I were to take, say, Mochel's experimental tree and send some
> random alpha code to Linus?  Let anarchy rule!

Well ... they have once excuse... if the maintainer is
himself a bit slow on submitting to Linus. Yes I know that's
a matter primary of personal style so there is no need
to discuss about it until down...

About the anarchy - are you sure a Kozaks blood like me
couldn't life up with it ruling? :-).

[Linux-fbdev-devel] Re: Linux 2.5.19

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

On Thu, May 30, 2002 at 12:29:26AM +0200, Martin Dalecki wrote:
> Plese don't take silent aprobation for "don't look" :-).
> I *like* the patches you do... well just my 0.02EUR.

This is about people who think they're god nicking patches from
the author and maintainer of drivers and bypassing the maintainer
completely.

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

[Linux-fbdev-devel] Re: Linux 2.5.19

[Martin D. <da...@ev...>]

James Simmons wrote:

> 
>     I do admit and apologize for not properly saying which drivers have
> been altered. I will make a special note of doing that in the future.
> Especially since very few actually look at my patches.

Plese don't take silent aprobation for "don't look" :-).
I *like* the patches you do... well just my 0.02EUR.

[Linux-fbdev-devel] Re: Linux 2.5.19

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

On Thu, May 30, 2002 at 12:22:25AM +0200, Martin Dalecki wrote:
> Dear Russell why don't you just abuse Linus as a spinlock for this kind
> of synchronization its his job. No need to get angry at this.
> Hey it's developement series time...

The fundamental point I'm making is people shouldn't go around taking
changes randomly from maintainers trees, and believing that they know
far better than the maintainer what they're doing, especially when they
don't have the hardware to even try it out, and go submitting these
changes to Linus without even asking about it first...  after the
maintainer has been very careful and explicitly not submitted
the change because they have very good reasons not to.

What if I were to take, say, Mochel's experimental tree and send some
random alpha code to Linus?  Let anarchy rule!

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

[Linux-fbdev-devel] Re: Linux 2.5.19

[Martin D. <da...@ev...>]

Russell King wrote:

> I'm not talking about general maintainence of the cyber2000fb driver here,
> or general "keep it working" type changes.  I'm talking about a blatent
> "take the version from the rmk patch and submit it to Linus without telling
> the maintainer of the code you're buggering with" attitude here.

Dear Russell why don't you just abuse Linus as a spinlock for this kind
of synchronization its his job. No need to get angry at this.
Hey it's developement series time...