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

Re: [Linux-fbdev-devel] FB console clears with large white area

[Jim H. <jim...@ac...>]

On 29-Apr-2002 Jani Monoses wrote:
> The way it disappeared for me was by not calling do_set_var in trident
> init.It was called before register_frambuffer.I thought I posted to the
> list last week but it seems I only replied to Jim.
> Antonio Daplas suggested that the card should not be in graphics mode when
> registering the fb.See the list archives subject: tridentfb review some
> months ago)

Jani, thank you. I get what you are saying, now. Sorry it took me so long to
catch on. BTW, I can't find the 'tridentfb review' thread in the archives.

The problem is, essentially, that the outgoing VGA console and the incoming FB
console are the same card. Initialise that card to a graphics mode and *blam*
the card remaps to the graphics mode and fishing around in the text mode
screen memory to find the contents of the outgoing console produces random
garbage.

So Antonio's suggestion that the card should not be in graphics mode when
registering the FB is correct; registering needs to happen before the card is
switched away from VGA mode in any way. Simply removing the call to do_set_var
doesn't work for pm2fb; I think too much initialisation has happened by then.
Sven, pmfb is (I think) similar in this respect; any ideas?

-- 
Jim Hague - jim...@in... (Work), ji...@be... (Play)
Never trust a computer you can't lift or you don't control.

Re: [Linux-fbdev-devel] savagefb

[Alex S. <ale...@co...>]

hi,

thanks for the link, the savagefb driver appears to be working : )

one other question though, what sort of bandwidth are people getting 
writing to their framebuffers. i am running savagefb on a via pro savage 
chipset (PN133T) which has shared memory (a part of main memory is used as 
the framebuffer) and i ran a little test program to test the bandwidth and 
it seems to be quite slow at 32bit colour modes.

the results are as follows:

fb_ptr:401a9000
resolution:640x480x8 virtual resolution:640x480 framebuffer size:307200
frames:500 sec:1.204243 frames/s:415.198594 Mpix/s:127.549008 MB/s:127.549008
fb_ptr:401f4000
resolution:640x480x16 virtual resolution:640x480 framebuffer size:614400
frames:500 sec:2.683917 frames/s:186.294882 Mpix/s:57.229788 MB/s:114.459575
fb_ptr:4028a000
resolution:640x480x32 virtual resolution:640x480 framebuffer size:1228800
frames:500 sec:6.328235 frames/s:79.010972 Mpix/s:24.272171 MB/s:97.088683
fb_ptr:401d3000
resolution:800x600x8 virtual resolution:800x600 framebuffer size:480000
frames:500 sec:1.939521 frames/s:257.795610 Mpix/s:123.741893 MB/s:123.741893
fb_ptr:40248000
resolution:800x600x16 virtual resolution:800x600 framebuffer size:960000
frames:500 sec:4.518773 frames/s:110.649506 Mpix/s:53.111763 MB/s:106.223526
fb_ptr:40332000
resolution:800x600x32 virtual resolution:800x600 framebuffer size:1920000
frames:500 sec:10.488265 frames/s:47.672327 Mpix/s:22.882717 MB/s:91.530868
fb_ptr:4021e000
resolution:1024x768x8 virtual resolution:1024x768 framebuffer size:786432
frames:500 sec:3.384868 frames/s:147.716248 Mpix/s:116.168784 MB/s:116.168784
fb_ptr:402de000
resolution:1024x768x16 virtual resolution:1024x768 framebuffer size:1572864
frames:500 sec:7.626457 frames/s:65.561243 Mpix/s:51.559459 MB/s:103.118919
fb_ptr:4045e000
resolution:1024x768x32 virtual resolution:1024x768 framebuffer size:3145728
frames:500 sec:20.687864 frames/s:24.168759 Mpix/s:19.007086 MB/s:76.028342

the test program malloc's a chunk of memory and mmap's /dev/fb and the 
memory is copied to the framebuffer via memcpy and timed and the results 
are printed out. mtrr is enabled by default by the savagefb driver and the 
system is a PIII 1GHz, 120MB RAM 8MB framebuffer running kernel-2.4.19-pre7 
with the savagefb patch. is the shared memory making this slow ? or is it 
something else that i have missed ?

one other thing i noticed is that when i change timings (from "1024x768-60" 
to"1024x768-72") the results change and "1024x768-72" seems to be always 
faster (30fps) than "1024x768-60". don't know why this is, but i will look 
into it some more.

any help would be appreciated.

cheers,

alex

At 10:58 PM 04/26/2002, Joachim Steiger wrote:
>take a look at the cvs version from directfb (www.directfb.org)
>in the subdirectory patches/ of the module DirectFB you'll find what
>you need.
>
>have fun.
>
>regards
>
>   roh
>
>
>_______________________________________________
>Linux-fbdev-devel mailing list
>Lin...@li...
>https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel

[Linux-fbdev-devel] Re: 2.5.11 framebuffer kernel panic

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

Try this patch and tell me if it works. 

--- /usr/src/linux-2.5.11/drivers/video/aty/atyfb_base.c	Mon Apr 29 10:48:07 2002
+++ atyfb_base.c	Mon Apr 29 15:48:22 2002
@@ -2625,7 +2625,7 @@
 
 #ifdef CONFIG_FB_ATY_CT
     /* Erase HW Cursor */
-    if (info->cursor)
+    if (info->cursor && (fb->currcon >= 0))
 	atyfb_cursor(&fb_display[fb->currcon], CM_ERASE,
 		     info->cursor->pos.x, info->cursor->pos.y);
 #endif /* CONFIG_FB_ATY_CT */

[Linux-fbdev-devel] Re: 2.5.11 framebuffer compilation error

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

> I'll know this kernel is ready for merger with the 2.4 when I can finally 
> compile it :) ... must have tried 6-7 versions by now ...
> 
> Error:
> Note...this is something new that I haven't tried to compile before.
> Error might be caused by an earlier kernel.
> However, 2.5.11 does contain a lot of screen_base changes. 

Thats my fault. I had all the correct changes locally but my experience
with BK is just starting :-/ So this first time was a bit painful. I
asked people to tes my stuff but no one compiled so I toke that as
everything was okay. Please folks. Test the stuff. I even make classic
diff patches for people as well. 

I have fixes against 2.5.11 avaliable for this.

Diff:

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

Also I commited these changes to the BK repository. The URL for this is

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

Re: [Linux-fbdev-devel] FB console clears with large white area

[Jani M. <ja...@iv...>]

The way it disappeared for me was by not calling do_set_var in trident
init.It was called before register_frambuffer.I thought I posted to the
list last week but it seems I only replied to Jim.
Antonio Daplas suggested that the card should not be in graphics mode when
registering the fb.See the list archives subject: tridentfb review some
months ago)


 > I suspect that all/most FB drivers (I think Jani works
round it with
> tridentfb) will show this problem. But to see it you need to be switching from
> a VGA console to a FB console - if I remove the VGA console from my kernel
> everything looks fine - so this problem will only practically be seen on PCs.
> And there are not many reasons to use FB on a PC.

Re: [Linux-fbdev-devel] FB console clears with large white area

[Jim H. <jim...@ac...>]

On 29-Apr-2002 Sven wrote:
>> Except what actually happens is that most of the screen is cleared to white,
>> and console messages appear on the bottom line of the white area. As the
>> console scrolls the white area scrolls up the screen, though that part of it
>> to
>> the right of Tux remains as long as Tux remains.
> 
> I have the same problem with pm3fb.

Good. I have also had reports of this with a couple of other framebuffers, e.g.
Jani Monoses's tridentfb experience. So I don't think it is a problem with the
pm2/3 drivers.

I've not had much time to look further into this, but I think there are
actually two things going wrong. I need to find some more time. Here's what it
looks like to me at the moment.

First, in take_over_console(), save_screen() is called before the old console
is deinit()'ed. This calls vgacon_save_screen() to copy the console contents
at vc_origin into vc_screenbuf. Something is weird for me here; a little dumping
shows that vc_screenbuf always ends up filled with 0xffff.

Then take_over_console() closes the VGA console and calls visual_init() on the
FB console, which in turn calls fbcon_init() and fbcon_setup(). During
fbcon_setup(), the size of the new console is noted as being different from the
old console, and vc_resize() is called. This creates a new vc_screenbuf, and
fills it with data from the old size, taken from vc_origin. I think, though I'm
not sure, that at this point vc_origin is not yet updated for the FB and still
is the VGA origin. This data copied from vc_origin is again always 0xffff for
me.

So now I think I need to understand *why* the data at vc_origin for the VGA
console appears to be completely wrong.

> The difference is most probably that this is not broken for other drivers.
> Maybe the main reason of this, is that both pm2fb and pm3fb were first
> developped on plateforms without vga text console.

I suspect that all/most FB drivers (I think Jani works round it with
tridentfb) will show this problem. But to see it you need to be switching from
a VGA console to a FB console - if I remove the VGA console from my kernel
everything looks fine - so this problem will only practically be seen on PCs.
And there are not many reasons to use FB on a PC. 

> i don't know, but while writing the pm3 X driver, i noticed that may board
> will not save/restore the fonts correctly when doing MMIO (and when not doing
> MMIO it would not work in dual pm3 configuration) so we (Well Alan Hourihane
> actually) did change the code to read/save font memory using a special
> memcopy instead of resorting to the vga interface, which seemed broken in
> this respect. Maybe the pm2 chip shares this problem ?

That's interesting. I will compare your code to pm2fb.

> BTW, what exact pm2 chip are you using ?

My PCI reports TVP4020.

I have no documentation on the chip anyway, so I don't know how it is supposed
to work...

-- 
Jim Hague - jim...@in... (Work), ji...@be... (Play)
Never trust a computer you can't lift.

Re: [Linux-fbdev-devel] FB console clears with large white area at startup

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

On Wed, Apr 24, 2002 at 10:44:18PM +0100, Jim Hague wrote:
> I've been using the Permedia2 driver on x86 for some time. I've always built
> the kernel with the VGA console and the pm2 driver built in.
> 
> So booting begins through the VGA console, and when the pm2 driver is loaded it
> grabs the console, up goes Tux and on we go. As you might expect.
> Except what actually happens is that most of the screen is cleared to white,
> and console messages appear on the bottom line of the white area. As the
> console scrolls the white area scrolls up the screen, though that part of it to
> the right of Tux remains as long as Tux remains.

I have the same problem with pm3fb.

From previous discution here, the culprit seems to be that the part of the
fbdev drvier responsible for getting the VGA text data and writing it to the
fbdev console is broken. 

If you have any fix to this, i would be very interested in it, to try to
duplicate it in pm3fb also.

> The size of the white area is the size of the VGA screen, both considered in
> terms of character positions. So with regular VGA it is 80x25. I tend to use
> 80x50 VGA, hence 'most' of the screen, my fb console size being 144x56.
> 
> For ages I thought this was a problem with the Permedia2 driver, and so have
> been giving myself an introduction to the console code digging around trying to
> find the problem. I haven't got to the bottom of it, but it looks to me like
> the problem is not a Permedia2 driver one, and that users of other drivers
> should see it to.

The difference is most probably that this is not broken for other drivers.
Maybe the main reason of this, is that both pm2fb and pm3fb were first
developped on plateforms without vga text console.

> Is this true? Is this an old chestnut that is well understood and has been done
> to death on the list in the past?

I think it is a known but unfixed problem, see previous posts about pm3fb on
this problem, especially responces to me by Petr with some vga black magic in
it.

> As far as I can tell at the moment, in take_over_console the outgoing console
> is suppose to save its screen contents (if visible) and these will be put onto
> the new console when update_screen() is called. Dumping the saved VGA screen,
> it seems that the saved screen consists entirely of 0x720, which I think
> explains the white. Why the VGA screen contents are like that I have, as yet, no
> idea.

But the traditional way of doing it may be broken on pm2fb.

i don't know, but while writing the pm3 X driver, i noticed that may board
will not save/restore the fonts correctly when doing MMIO (and when not doing
MMIO it would not work in dual pm3 configuration) so we (Well Alan Hourihane
actually) did change the code to read/save font memory using a special memcopy
instead of resorting to the vga interface, which seemed broken in this
respect. Maybe the pm2 chip shares this problem ?

BTW, what exact pm2 chip are you using ?

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] savagefb

[Joachim S. <ro...@hy...>]

take a look at the cvs version from directfb (www.directfb.org)
in the subdirectory patches/ of the module DirectFB you'll find what 
you need.

have fun.

regards

  roh

[Linux-fbdev-devel] framebuffers and spinlocks

[Emmanuel M. <emm...@re...>]

Browsing some documentation and source code,

it appears that kernel module programmers have to be 
aware of the way their own module's spinlocks interact
with other kernel parts ones.

I guess console_lock must be quite important in frame buffer
internals;

is it safe to call register_framebuffer() holding my_lock
given that the same my_lock will certainly be met again in the
refresh routine or other? Can't we reach the deadly embrace
situation here?

Sincerely yours,

-- 
Emmanuel Michon
Chef de projet
REALmagic France SAS
Mobile: 0614372733 GPGkeyID: D2997E42  

[Linux-fbdev-devel] moving consoles around with two EM84xx and one rivafb.o crashes Linux

[Emmanuel M. <emm...@re...>]

Hi,

I'm implementing a framebuffer device driver on top
of Sigma Designs EM84xx OSD engine.

It works nicely usually, and since our kernel module
supports multiple boards we can enable /dev/fb0, /dev/fb1 and so
on.

I have a crash situation I reproduced inside kgdb:

- enable the first EM84xx framebuffer: /dev/fb0. All consoles jump
there (normal)

- enable the second EM84xx framebuffer: /dev/fb1. No consoles jumps
there by itself.

- move all the consoles 0,1,2,3,4,5 from /dev/fb0 to /dev/fb1 using
FBIOPUT_CON2FBMAP ioctl.

- release /dev/fb0 happens gently

- insmod rivafb.o enables /dev/fb0 (it does not use /dev/fb2 as
I would have thought).

- move all the consoles 0,1,2,3,4,5 from /dev/fb1 to /dev/fb0 again.

The last manipulation freezes the scheduler at some point; however it's still
possible to break in using kgdb and the machine is stuck in:

riva_rectfill

Is rivafb stable or do you have some hint here?

Note: if this can be of any help, at the point of this test,
the ``NVdriver'' nvidia X helper kernel module was not loaded.

-- 
Emmanuel Michon
Chef de projet
REALmagic France SAS
Mobile: 0614372733 GPGkeyID: D2997E42  

Re: [Linux-fbdev-devel] FB console clears with large white area at startup

[Jani M. <ja...@iv...>]

I had this problem with the trident driver and the problem went away if
I did not set_var() before register_framebuffer.This was suggested by
Antonio Daplas on this list .So I think the video mode should not be set
until the fb is registered.

>
> The size of the white area is the size of the VGA screen, both considered in
> terms of character positions. So with regular VGA it is 80x25. I tend to use
> 80x50 VGA, hence 'most' of the screen, my fb console size being 144x56.

[Linux-fbdev-devel] savagefb

[Alex S. <ale...@co...>]

hi,

i am looking for a framebuffer driver for the pro savage chipset as the 
vesa drivers are too slow. does such a driver exist ?

if the driver doesn't exist then i will be writing on and where should i 
start ? look at the xfree source and grab hw details from there ?

any help will be greatly appreciated.

cheers,

alex

[Linux-fbdev-devel] software cursor in 2.4.x

[Ghozlane T. <gh...@sy...>]

Hi all, 

I'm working on a voodoo1 (fb driver sstfb.c ) on 2.4.17  , and 
I 'm experiencing a strange "feature" when using a dual head configuration :

The 1st head is a matrox mystique, the second one is the voodoo 1.
sstfb does not support hardware accelerated cursor (although I may be able
to hack something out of the texture engine) , and thus, it uses the software 
cursor, 
The problem is that when I remove the sstfb module, I have 2 cursors on the 
matrox : the original hardware cursor + the software cursor still alive  ...

I have to admit it's quite funny at first , having the 2 cursors blinking at 
different rates, and having  different shapes, but it gets quickly annoying.
Plus it's obviously a wrong behaviour...

So I'm wondering if I have to add some code to my driver exit function to 
remove the software cursor (if so, how?) , or if this is a bug in the actual 
2.4 console subsystem ...

Thanks in advance, 

Ghoz

Re: [Linux-fbdev-devel] FB console clears with large white area at startup

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

> I've been using the Permedia2 driver on x86 for some time. I've always built
> the kernel with the VGA console and the pm2 driver built in.
> 
> So booting begins through the VGA console, and when the pm2 driver is loaded it
> grabs the console, up goes Tux and on we go. As you might expect.
> Except what actually happens is that most of the screen is cleared to white,
> and console messages appear on the bottom line of the white area. As the
> console scrolls the white area scrolls up the screen, though that part of it to
> the right of Tux remains as long as Tux remains.
> 
> The size of the white area is the size of the VGA screen, both considered in
> terms of character positions. So with regular VGA it is 80x25. I tend to use
> 80x50 VGA, hence 'most' of the screen, my fb console size being 144x56.
> 
> For ages I thought this was a problem with the Permedia2 driver, and so have
> been giving myself an introduction to the console code digging around trying to
> find the problem. I haven't got to the bottom of it, but it looks to me like
> the problem is not a Permedia2 driver one, and that users of other drivers
> should see it to.
> 
> Is this true? Is this an old chestnut that is well understood and has been done
> to death on the list in the past?
> 
> As far as I can tell at the moment, in take_over_console the outgoing console
> is suppose to save its screen contents (if visible) and these will be put onto
> the new console when update_screen() is called. Dumping the saved VGA screen,
> it seems that the saved screen consists entirely of 0x720, which I think
> explains the white. Why the VGA screen contents are like that I have, as yet, no
> idea.

I figured the problem was with the core console code. You found the bug
that I have seen before in other drivers. Dave Jones reported to me for
the 3dfx driver. I never had this problem but he did. Now we know what
causes it. I to have no idea why the VGA screen contents are like that
either. 

[Linux-fbdev-devel] Permedia2 - testers wanted for updated driver

[Jim H. <jim...@ac...>]

I've merged the changes from Illo's last released driver into the current 2.4
driver, fixed a few bugs relating mainly to modes with low horizontal or
vertical sync. I'm using the driver successfully now to drive an old Sun
fixed-frequency monitor (which requires low [hv]sync) in conjunction with the
glint driver from XFree 4.1.0.

I need some kind folk to check I haven't buggered anything up, particularly in
regard to non-x86 (esp. big endian) systems, before giving this wider
circulation.

More details and the updated driver or a patch to 2.4.18 at
http://www.bear-cave.org.uk/linux/pm2fb/. All comments welcome.

-- 
Jim Hague - jim...@in... (Work), ji...@be... (Play)
Never trust a computer you can't lift or you don't control.

[Linux-fbdev-devel] FB console clears with large white area at startup

[Jim H. <jim...@ac...>]

I've been using the Permedia2 driver on x86 for some time. I've always built
the kernel with the VGA console and the pm2 driver built in.

So booting begins through the VGA console, and when the pm2 driver is loaded it
grabs the console, up goes Tux and on we go. As you might expect.
Except what actually happens is that most of the screen is cleared to white,
and console messages appear on the bottom line of the white area. As the
console scrolls the white area scrolls up the screen, though that part of it to
the right of Tux remains as long as Tux remains.

The size of the white area is the size of the VGA screen, both considered in
terms of character positions. So with regular VGA it is 80x25. I tend to use
80x50 VGA, hence 'most' of the screen, my fb console size being 144x56.

For ages I thought this was a problem with the Permedia2 driver, and so have
been giving myself an introduction to the console code digging around trying to
find the problem. I haven't got to the bottom of it, but it looks to me like
the problem is not a Permedia2 driver one, and that users of other drivers
should see it to.

Is this true? Is this an old chestnut that is well understood and has been done
to death on the list in the past?

As far as I can tell at the moment, in take_over_console the outgoing console
is suppose to save its screen contents (if visible) and these will be put onto
the new console when update_screen() is called. Dumping the saved VGA screen,
it seems that the saved screen consists entirely of 0x720, which I think
explains the white. Why the VGA screen contents are like that I have, as yet, no
idea.



-- 
Jim Hague - jim...@in... (Work), ji...@be... (Play)
Never trust a computer you can't lift or you don't control.

[Linux-fbdev-devel] SiS550 framebuffer driver for Nan Ya 320x240 color FSTN

[Eric T. <er...@ms...>]

=0A=
Apr 22 18:45:52 localhost kernel: 20011213:enable_dstn=3D1  =0A=

Apr 22 18:45:52 localhost kernel: SIS 550 is used as primary device(VGA =
Engine 2).=20

=0A=
Apr 22 18:45:52 localhost kernel: sisfb: Framebuffer at 0xd0000000, =
mapped to 0xc3844000, size 16384k =0A=

Apr 22 18:45:52 localhost kernel: sisfb: MMIO at 0xdfee0000, mapped to =
0xc4845000, size 128k=20
=0A=
Apr 22 18:45:52 localhost kernel: sisfb: SiS301LV bridge detected=20
				  (this is old version, new version will say Unknown: VB.NONE,
				  since our new designed board have no video bridge)=09
Apr 22 18:45:52 localhost kernel: sisfb: Mode is 320x480x8 (60Hz), =
linelength=3D320=20
=0A=
Apr 22 18:45:52 localhost kernel: VM Adr=3D0xc3844000=20
=0A=
Apr 22 18:45:52 localhost kernel: VM Size=3D16384K =0A=

Apr 22 18:45:52 localhost kernel: IO Adr=3D0xcc30=20
=0A=
Apr 22 18:45:52 localhost kernel: Chip=3D7 =0A=

Apr 22 18:45:52 localhost kernel: ChipRevision=3D0=20
=0A=
Apr 22 18:45:52 localhost kernel: VBChip=3D2 =0A=

Apr 22 18:45:52 localhost kernel: ExtVB=3D0 =0A=
Apr 22 18:45:52 localhost kernel: LCD=3D2=20
=0A=
Apr 22 18:45:52 localhost kernel: bIntegratedMMEnabled=3D1=20
=0A=
Apr 22 18:45:52 localhost kernel: sisfb: CRT2 type is LCD =0A=

Apr 22 18:45:52 localhost kernel: sisfb: SiS_IF_DEF_LVDS:1
sisfb: SiS_IF_DEF_DSTN:1
isfb: SiS_VBType:0 =0A=

Apr 22 18:45:52 localhost kernel: sisfb: (VBInfo =3D 4621) =0A=

Apr 22 18:45:52 localhost kernel: sisfb: (LCDInfo =3D 0x4 LCDResInfo =3D =
0x7 LCDTypeInfo =3D 0x2) =0A=
Apr 22 18:45:52 localhost kernel: sisfb: SiS_VBInfo:4621 =0A=
Apr 22 18:45:52 localhost kernel: sisfb: LVDS-LCD panel type 2 (Resindex =
6) =0A=
Apr 22 18:45:52 localhost kernel: sisfb: Memory heap starting at 8192K =0A=
Apr 22 18:45:52 localhost kernel: sisfb: Using MMIO queue mode =0A=

Apr 22 18:45:52 localhost kernel: Console: switching to colour frame =
buffer device 40x30=20
=0A=
Apr 22 18:45:52 localhost kernel: fb0: SIS 550 frame buffer device, =
Version 1.3.13 =0A=

[Linux-fbdev-devel] Re: fbdev BK tree ready for testing.

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

> James> http://fbdev.bkbits.net/fbdev-2.5
> 
> ARGH
> 
> If you want people to test out the patches, posting a bitkeeper only
> URL is totally unreasonable!
> 
> This is exactly what caused the long flame on linux-kernel the other
> day ;-(

:-( 

Here is a standard diff patch against 2.5.9. 

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

Please test it out. Patches welcomed. 

[Linux-fbdev-devel] Re: fbdev BK tree ready for testing.

[Jes S. <je...@wi...>]

>>>>> "James" == James Simmons <jsi...@tr...> writes:

James> Hi!

James>    I just finished sending up the last large change I like to
James> send to Linus for the framebuffer changes. Since I can't test
James> all the possible hardware there I like to ask people to test
James> the BK tree out. Once I have positive reports I like to merge
James> it with Linus BK tree. Thank you.

James> http://fbdev.bkbits.net/fbdev-2.5

ARGH

If you want people to test out the patches, posting a bitkeeper only
URL is totally unreasonable!

This is exactly what caused the long flame on linux-kernel the other
day ;-(

Jes

[Linux-fbdev-devel] fbdev BK tree ready for testing.

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

Hi!

   I just finished sending up the last large change I like to send to
Linus for the framebuffer changes. Since I can't test all the
possible hardware there I like to ask people to test the BK
tree out. Once I have positive reports I like to merge it with Linus BK
tree. Thank you.


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

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

Re: [Linux-fbdev-devel] Permedia 2 cards supported?

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

Romain Dolbeau wrote:
> 
> James Simmons wrote:
> 
> > Hm. Now that a good chunk of the new new fbdev api is in the Dave Jones
> > tree would you like to give it a try for porting again? I'm even working
> > on docs right now, I'm presenting a talk on it soon.
> 
> I'd like to, but the DJ tree disagree with us.

Apparently it's not really the DJ tree, regular 2.5.8 doesn't
build on my box either.

-- 
DOLBEAU Romain           | I witness a time and a place that never dies,
ENS Cachan / Ker Lann    | still frozen in time, this darkness the only 
Thesard IRISA / CAPS     | place that I can hide. I witness, a dream.   
dol...@cl...|  -- Black Sabbath, 'I Witness'

Re: [Linux-fbdev-devel] Permedia 2 cards supported?

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

On Wed, Apr 17, 2002 at 01:01:03PM +0100, Jim Hague wrote:
> On 17-Apr-2002 Michel D=E4nzer wrote:
> > On Wed, 2002-04-17 at 13:07, Jim Hague wrote:
> >>=20
> >> I got delayed for a while making it work with the X Glint server. Ro=
main,
> >> have
> >> you noticed that X Glint using the hardware cursor (the default), wh=
en used
> >> with
> >> UseFBDev=3DTrue *always* asks for high sync, regardless of the mode =
requested?
> >=20
> > IIRC I added that code because the HW cursor didn't work with low syn=
c
> > on the Permedia2 board I worked with.
>=20
> The Permedia2 and Permedia3 frame buffer drivers both now set high sync=
 in all
> cases, and use the RAMDAC to invert the sync if low is required, just l=
ike the
> X Glint driver. This wasn't the case in the past.

This will most probably break the glint X driver on apus boards, not nice.

That said, the permedia3 glint driver don't use "USEFBDev", and i guess y=
ou
should be able to run your pci based permedia2 board without this option =
even
if you have are using pm2fb.

> So I suppose that code has outlived its usefulness.

Unless there are no more apus users, then you might be right, but it woul=
d be
best to still support these boards, i may be wanting to resurect mine one=
 of
those days :)))

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] Permedia 2 cards supported?

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

On Wed, Apr 17, 2002 at 01:15:25PM +0200, Romain Dolbeau wrote:
> Jim Hague wrote:
> 
> > I got delayed for a while making it work with the X Glint server. Romain, have
> > you noticed that X Glint using the hardware cursor (the default), when used with
> > UseFBDev=True *always* asks for high sync, regardless of the mode requested?
> > I've bodged a 'force low sync' option into pm2fb to cope.
> 
> No, I didn't notice ; the sync stuff is an area I never
> thoroughly tested. My Iiyama 702HT can take about
> anything and display it :-) I can't even remember if
> my default X config use 'UseFBDev' or not.

No, it doesn't, the fbdev code in the glint X driver is hardcoded for pm2fb.
(and maybe even apus-pm2fb).

> By your description, it definitely look like a XFree86
> bug - or maybe a permedia3 'feature' that you can't
> use low sync with the HW cursor. Sven, any idea on that ?

No, it has been a long time since i looked at that, and i have no real time
for it right now.

That said, i guess he is speaking about pm2fb + glint X driver, and i don't
know if he uses USEFBDev or not, but like said, the glint X driver is
hardcoded for pm2fb, and was done such, by Michel Daenzer i think, but it was
a long time ago, in order to get it working on powerpc/apus(amiga with powerup
board and Blizzard/CyberVision pm2 graphic board) hardware, so it is possible
that it has some hardcoded stuff needed for the apus specific case.

(but i thnk i have seen a mail from michel lower in the thread, so maybe he
will tell you more)

Friendly,

Sven Luther

Re: [Linux-fbdev-devel] Fbdev Bitkeeper repository

[M. R. B. <mr...@0x...>]

* Larry McVoy <lm...@bi...> on Wed, Apr 17, 2002:

>=20
> I think BK can help you and you are so stuck on one way of doing things
> that you are ignoring that possibility.  That's OK with me so long as
> it is just you, but you're posting in a public forum, to a group of
> people that I'm trying to help, and as long as you do, I'll be here,
> annoying as heck, explaining why you are wrong.  I'm not saying that you
> are wrong about BK drop-ins, you're right about that.  We're fixing it as
> fast as we can, it's in my top 3 work items right now.  In the meantime,
> if you poked around, there are lots of ways to use BK and I'm 99% sure
> you could find one that would result in less work overall for you than
> what you are doing now.  I don't care if *you* find one, I care if=20
> others find one.  We're trying to maximize productive work for the
> largest number of people, and I find your posts counterproductive to
> that goal.

The cool thing is, since the linuxconsole drop-in wasn't going anywhere, I
can move on to more useful pursuits instead of going back and forth with yo=
u.
If you want to spend your time denegrating other SCMs and people that don't
subscribe to your divine development tenets, more power to you.  I've
learned enough from this thread to not waste time arguing with you.  Next
time someone says something about Bitkeeper that I happen to agree or
disagree with, do you suppose I should just e-mail them privately?  Or
should I post here to make sure it gets under your scrutinizing eye?

Apologies to those who read this God awful thread without hitting Control-D
first :P.

M. R.

Re: [Linux-fbdev-devel] Fbdev Bitkeeper repository

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

On Wed, Apr 17, 2002 at 08:52:15AM -0500, M. R. Brown wrote:
> > > For the LinuxSH project, we moved from tracking the full kernel tree (via
> > > CVS) to a drop-in tree structure mainly because of the difficulty in
> > > tracking all upstream kernel changes at once.  It wasn't really related to
> > > what CVS did or did not offer.
> > 
> > Disagree.  CVS sucks at tracking an external source of change while
> > maintaining your own changes at the same time, in the same tree.
> > It really sucks at that, you are forced into a broken branching model
> > with awful merge characteristics.  Try the same thing with BK, it's
> > a lot nicer, most stuff just automerges, and the stuff that doesn't
> > only needs to be merged once.  Your claim that it isn't about CVS
> > doesn't make much sense when CVS forces you to split your subtree
> > out.  Having an _option_ to do that is one thing, being forced to
> > do it is another.
> 
> I'd hate to sound like I'm trolling or being a broken record.  But I don't
> currently have that option with BK.  This is the option I want, to be able
> to not have to worry about pulling all changes or being able to cordon off
> only the bit I want/need to work with.  

Here's how you do it with BK.

    a) pick a baseline that you want.  Like 2.4 or 2.5.  clone it.
    b) put your changes on top of it.
    c) for each tree to which you want to apply your changes, clone it,
       and then pull from your tree.

Just go try that for a month's worth of changes and then tell me if it
isn't easier for you.

The deal is that you are trying to take your style of working, which as
far as I can tell, is based on CVS being broken, and insisting on that
style.  If you really want to work that way, you can, you are just losing
a lot in the process.  But whatever.  If you want to maintain a drop in
tree from a BK tree, then just check out the part of the tree you want
and plop the files into CVS.  Cort exported subsets of the trees as
patches for Linus for 2 years, it works.

> > And if that tree has changes in the files that you are "dropping in"?
> > You just stomped on them.  Or you are left with an even more broken
> > merge model than CVS.  And what about file renames.
> 
> When my drop-in tree file changes upstream, I'll find out in the next
> upstream sync.  Obviously if my drop-in tree is current, that file hasn't
> changed yet.  File renames are broken, but I never pretended they weren't.  I
> guess what you're saying is it comes down to me weighing out feature-rich
> set vs. feature-less set, where BK is the former, and I should expect to have
> to sacrifice my entire development model (drop-in trees, not CVS) for the
> bloated model that BK currently *enforces* (see your above paragraph about
> having the option).

That "bloated model" makes all the hard aspects of your model go away.
So you are trading off your model against your time.  That's the whole
point.  For the cost of some local storage, you get some of your time
back to do useful work.  Read that again.  That's the whole point.
An SCM tool is supposed to *save you time*.  What you are doing is
replacing missing features by you manually fixing up the places where
your tools didn't work.

You'd have a strong point if the model that BK was using wasted your time,
but you haven't made that case.

> > Part of the problem I have is that
> > you are, in a public forum, saying that BK is this and that, based on your
> > perceptions from 2 years ago when you said you used it on the ppc tree.
> 
> Nope, I said that based on what I read at www.bitkeeper.com, BK didn't
> support drop-in trees *today*.  I said that the last time I actively used
> the tool was 2 years ago, but I haven't had a reason to use it since then.
> In a public forum, which you use to promote sales and use of your product, I

OK, one day this might not be true, but so far, we haven't made a dime
off the people in this forum.  The people reading this forum don't spend
money, they write/read code.  The fact that this forum has not been
a money make for us has been true for 4 years.  I'm not sure how many
years it needs to be true before it might occur to you that the reason
I post here about BK is for some other reason than to make money.

BK is my primary way, these days, of trying to help out with the kernel.
I'd like it to help as many people as possible because I like Linux.
All of these posts are focussed on one thing: making people more productive
while doing development on the kernel.  Your posts annoyed me because they
made it sound like BK slows you down.  In the case you are talking about,
I think the opposite is true.  You might think that too if you actually 
tried it.

> When I decide to start and maintain the "linux toaster
> driver", I pull out the source I need from mainline, and setup my drop-in
> tree from that and my new imports.  The BK way to do it is to simply "clone
> the master" and work from that.  Not a drop-in.

So what?  Do a hardlinked clone, it costs you nothing, and do your work
in there.  BK will solve all the merge/rename problems that are inevitable
and you can focus on your work.

> Are you
> saying the only way for me to evaluate a tool (one that I haven't used in
> ages) is to use it?  

Yes.  Just like the only way to know how an application performs on a
platform is to run it.  Documentation, peer reviews, the words out of
my mouth, they are all like benchmark results, they are noise compared
to you actually trying to do what you want to do.

> It was a good read, and easy to follow, but it still does the opposite of
> what I need to do.  I want multiple small project-specific trees, not a
> myriad of full kernel trees.  Everything else gave me a good starting point
> for doing SCM-controlled kernel development using BK.  Thanks for the
> pointer.

So use hardlinked clones.  See the clone -l, and the relink docs.  You'll
burn 87MB for the baseline and then 1240 inodes for the directories in
each hardlinked clone.  If inodes take 4K each, that's 5MB, which isn't
free, but that's the best we can.  We'll cut that in half when we get
rid of the SCCS directories.

If you wanted to complain that BK doesn't restore the hardlinks after a
file is updated in multiple clones, that's a legit complaint.  You can
solve that with a post-incoming trigger which runs relink, but it would
be nicer if there was a way to make BK do that automagically.

> for me it boils down to using the best tool for the job.

Hey, I'm all for that.  If Arch worked better for Linus and the
maintainers, I'd be the first to urge them to switch.  We aren't getting
financial benefit from the kernel use of BK, which is a bummer, but that
is OK, that wasn't the point.  The point was to reduce the workload on
the critical people in the equation and that's what we focussed on.

I'm not at all convinced that you have explored BK enough to know whether
it will help you or not, and I'd appreciate it if you did so rather than
claiming it doesn't work.  All you are saying is that it doesn't work
exactly how you work now.  That may or may not be the same as saying it
can't help you (or others).  You won't know until you go explore.

Both Linus and I were fairly convinced that the BK take-it-all whether
you want it or not model was a showstopper.  Then Garzik figured out
a way around that which works well enough for now.  A lot of useful
work is happening faster because of what he figured out.  My complaint
with you is that you are assuming that you can't make BK work faster
for you without trying it or thinking about it.  Does BK mimic your
working model?  No.  Does that mean it can't help you?  Not clear.
That's the point.

I think BK can help you and you are so stuck on one way of doing things
that you are ignoring that possibility.  That's OK with me so long as
it is just you, but you're posting in a public forum, to a group of
people that I'm trying to help, and as long as you do, I'll be here,
annoying as heck, explaining why you are wrong.  I'm not saying that you
are wrong about BK drop-ins, you're right about that.  We're fixing it as
fast as we can, it's in my top 3 work items right now.  In the meantime,
if you poked around, there are lots of ways to use BK and I'm 99% sure
you could find one that would result in less work overall for you than
what you are doing now.  I don't care if *you* find one, I care if 
others find one.  We're trying to maximize productive work for the
largest number of people, and I find your posts counterproductive to
that goal.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm