Menu
▾
▴
linux-fbdev-devel
|
From: James S. <jsi...@in...> - 2002-11-22 17:53:51
|
Hi folks!!! Just to let you know where I am for the fbdev developement. I finished off the latest api changes. The cursor api has been cleaned up and it uses fb_image struct. This makes life easier. I ported over the ATI 128 driver to the latest changes. I finished the 3Dfx driver yesterday and got the ATI mach 64 driver done this morning. I will test it tomorrow. Then I will finsih up the NVIDIA driver. After that I'm going to push the code to linus. I started to hack at fbcon.c but realized it is such a mess I am going to rewrite it from scratch. This will be after the push to linus. I plan to use MDA console and create a modular fbcon that I can play with at will. The other annoucement is I have started to look for funding for this developement. At present I haven't found anything. I realized for the fbdev and console changes to be done I need to devote all my time to do this. To do this will require funding so I can pay my most basic bills. Wish me luck. |
|
From: Antonino D. <ad...@po...> - 2002-11-22 18:52:45
|
On Fri, 2002-11-22 at 22:52, James Simmons wrote: > > Hi folks!!! > > Just to let you know where I am for the fbdev developement. I finished > off the latest api changes. The cursor api has been cleaned up and it uses > fb_image struct. This makes life easier. > I ported over the ATI 128 driver to the latest changes. I finished the > 3Dfx driver yesterday and got the ATI mach 64 driver done this morning. > I will test it tomorrow. Then I will finsih up the NVIDIA driver. After > that I'm going to push the code to linus. Any patches in the meantime? I have a few changes I can pass to you: 1. optimized putcs to speed up scrolling by 2-3x. (it's a small patch but it already outperforms fb-2.4 especially at high color depths). Compared with the previous patch I submitted, this change is non-intrusive, so no other changes are required. 2. vga16fb imageblit that supports drawing of the penguin (vga-4-planes only) 3. logo drawing for directcolor visuals. The above should complete softaccel support for most hardware except for the more esoteric ones (mostly authored by Geert). Also cfbcursor is a bit misleading, no? It implies support for packed-pixels only, but I already use it with vga16fb. Tony |
|
From: James S. <jsi...@in...> - 2002-11-22 19:06:00
|
> Any patches in the meantime? I have a few changes I can pass to you: Yes of course!!!! > 1. optimized putcs to speed up scrolling by 2-3x. (it's a small patch > but it already outperforms fb-2.4 especially at high color depths). > Compared with the previous patch I submitted, this change is > non-intrusive, so no other changes are required. > > 2. vga16fb imageblit that supports drawing of the penguin (vga-4-planes > only) > > 3. logo drawing for directcolor visuals. Please send me those patches ASAP!!! I will linclude them right away. > The above should complete softaccel support for most hardware except for > the more esoteric ones (mostly authored by Geert). Geert is busy porting the Amigia driver to the new api. That means all the ilbm, iplan stuff will go away :-) > Also cfbcursor is a bit misleading, no? It implies support for > packed-pixels only, but I already use it with vga16fb. OOps. You are right. What should we call it? |
|
From: Antonino D. <ad...@po...> - 2002-11-22 19:19:53
|
On Sat, 2002-11-23 at 00:04, James Simmons wrote: > > > Any patches in the meantime? I have a few changes I can pass to you: > > Yes of course!!!! > I mean, do you have patches against vanilla linux? I currently don't have bk right now. I browsed the bk repository, and it seems you made a lot of changes. > > 1. optimized putcs to speed up scrolling by 2-3x. (it's a small patch > > but it already outperforms fb-2.4 especially at high color depths). > > Compared with the previous patch I submitted, this change is > > non-intrusive, so no other changes are required. > > > > 2. vga16fb imageblit that supports drawing of the penguin (vga-4-planes > > only) > > > > 3. logo drawing for directcolor visuals. > > Please send me those patches ASAP!!! I will linclude them right away. I can, but against 2.5.48 only + your old fbdev.diff. You might have a hard time merging it to your repository. > > > The above should complete softaccel support for most hardware except for > > the more esoteric ones (mostly authored by Geert). > > Geert is busy porting the Amigia driver to the new api. That means all the > ilbm, iplan stuff will go away :-) > > > Also cfbcursor is a bit misleading, no? It implies support for > > packed-pixels only, but I already use it with vga16fb. > > OOps. You are right. What should we call it? > I don't know, gen_cursor? Tony |
|
From: Antonino D. <ad...@po...> - 2002-11-22 20:04:58
Attachments:
changes.txt
|
On Sat, 2002-11-23 at 00:04, James Simmons wrote: > > > 1. optimized putcs to speed up scrolling by 2-3x. (it's a small patch > > but it already outperforms fb-2.4 especially at high color depths). > > Compared with the previous patch I submitted, this change is > > non-intrusive, so no other changes are required. > > > > 2. vga16fb imageblit that supports drawing of the penguin (vga-4-planes > > only) > > > > 3. logo drawing for directcolor visuals. > > Please send me those patches ASAP!!! I will linclude them right away. > Okay. Instead of patches, I'll just attach a file with the targeted functions which you can choose to cut and paste or modify as you see fit. vga16fb_imageblit in vga16fb.c fbcon_show_logo in fbcon.c fbcon_accel_putcs in fbcon-accel.c |
|
From: Geert U. <ge...@li...> - 2002-11-23 21:09:31
|
On Fri, 22 Nov 2002, James Simmons wrote:
> Geert is busy porting the Amigia driver to the new api. That means all the
> ilbm, iplan stuff will go away :-)
I have first code for amifb, but it doesn't work yet, due to other problems
with 2.5.x on Amiga. I hope to fix these tomorrow...
Besides, we still need someone to take care of the Atari 2-byte interleaved
bitplanes (iplan2p*), since I don't have the hardware, and am not 100% sure how
they work. But reviving 2.5.x on Atari will be even harder...
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
|
|
From: James S. <jsi...@in...> - 2002-11-25 18:48:23
|
> > Geert is busy porting the Amigia driver to the new api. That means all the > > ilbm, iplan stuff will go away :-) > > I have first code for amifb, but it doesn't work yet, due to other problems > with 2.5.x on Amiga. I hope to fix these tomorrow... Yeah!!! > Besides, we still need someone to take care of the Atari 2-byte interleaved > bitplanes (iplan2p*), since I don't have the hardware, and am not 100% sure > how they work. But reviving 2.5.x on Atari will be even harder... Me neither. But there is a way to find out. A trick I used to figure out the hga framebuffer lay out. Build just the fbdev layer without fbcon. Then do a write to /dev/fbX to see what happens. The way I have fbdev now is when you open /dev/fb0 the hardware mode is set. When you close the /dev/fb the hardware goes back to text mode. I did it this way so you could insmod the driver and NOT change the hardware state. Also fb_open is the function register_framebuffer needs just before take_over_console happens. The other benifiet is if X dies that uses /dev/fb to set it modes then the file will be closed automatically and teh hardware state will be set to a sane state. This is for the case of vgacon with fbdev. WHat about from fbco? Well that is easy since fb_open passes a falg to let us knwo if it is from userland for fbcon. P.S It appears fbcon is totally broken in BK. I'm using the above trick to test the code. Tonight I'm going to work on making fbcon completely modular. Yeah!!!! |
|
From: Johan B. <jo...@no...> - 2002-11-25 21:44:11
|
m=E5n 2002-11-25 klockan 19.47 skrev James Simmons: >=20 > > > Geert is busy porting the Amigia driver to the new api. That means al= l the=20 > > > ilbm, iplan stuff will go away :-)=20 > >=20 > > I have first code for amifb, but it doesn't work yet, due to other prob= lems > > with 2.5.x on Amiga. I hope to fix these tomorrow... >=20 > Yeah!!! >=20 > > Besides, we still need someone to take care of the Atari 2-byte interle= aved > > bitplanes (iplan2p*), since I don't have the hardware, and am not 100% = sure=20 > > how they work. But reviving 2.5.x on Atari will be even harder... For what it's worth, the interleaved modes on atari works like this: The bitplanes are interleaved on 16 bit big-endian word basis so if you have two bitplanes, bit 0 of the first 16 pixels would be in the first 16 bit word in the display memory, bit 1 of the first 16 pixels would be in the second word. With bit 0 I mean as masked out by & 0x0001 in C, and bit 1 as masked out by 0x0002. The Atari ST line support three resolutions by default: 320x200 4 bit planes 640x200 2 bit planes 640x400 1 bit plane The Atari Falcon has a programmable clock so many resolutions are possible and it also features a 8 bit planes mode and 16 bit high colour mode. P.S. I don't have any Atari hardware myself anymore. > Me neither. But there is a way to find out. A trick I used to figure=20 > out the hga framebuffer lay out. Build just the fbdev layer without fbcon= .=20 > Then do a write to /dev/fbX to see what happens.=20 > The way I have fbdev now is when you open /dev/fb0 the hardware mode i= s=20 > set. When you close the /dev/fb the hardware goes back to text mode. I di= d=20 > it this way so you could insmod the driver and NOT change the hardware=20 > state. Also fb_open is the function register_framebuffer needs just befor= e=20 > take_over_console happens. The other benifiet is if X dies that uses=20 > /dev/fb to set it modes then the file will be closed automatically and te= h=20 > hardware state will be set to a sane state. This is for the case of vgaco= n=20 > with fbdev. WHat about from fbco? Well that is easy since fb_open passes = a=20 > falg to let us knwo if it is from userland for fbcon. >=20 > P.S > It appears fbcon is totally broken in BK. I'm using the above trick to= =20 > test the code. Tonight I'm going to work on making fbcon completely=20 > modular. Yeah!!!! >=20 >=20 >=20 > ------------------------------------------------------- > This SF.net email is sponsored by: Get the new Palm Tungsten T=20 > handheld. Power & Color in a compact size!=20 > http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en > _______________________________________________ > Linux-fbdev-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel |
|
From: James S. <jsi...@in...> - 2002-11-26 00:41:01
|
> For what it's worth, the interleaved modes on atari works like this: > > The bitplanes are interleaved on 16 bit big-endian word basis so if you > have two bitplanes, bit 0 of the first 16 pixels would be in the first > 16 bit word in the display memory, bit 1 of the first 16 pixels would be > in the second word. With bit 0 I mean as masked out by & 0x0001 in C, > and bit 1 as masked out by 0x0002. > > The Atari ST line support three resolutions by default: > 320x200 4 bit planes > 640x200 2 bit planes > 640x400 1 bit plane Okay I have been think about the other modes and can't figure out how they would work. Could you do a run down to get my hamster running? |
|
From: Geert U. <ge...@li...> - 2002-11-27 23:04:50
|
On 25 Nov 2002, Johan Bolmsjo wrote: > For what it's worth, the interleaved modes on atari works like this: > > The bitplanes are interleaved on 16 bit big-endian word basis so if you > have two bitplanes, bit 0 of the first 16 pixels would be in the first > 16 bit word in the display memory, bit 1 of the first 16 pixels would be > in the second word. With bit 0 I mean as masked out by & 0x0001 in C, > and bit 1 as masked out by 0x0002. Thanks! This is exactly the kind of information I needed! I added simple unoptimized support for Atari interleaved bitplanes to fbtest. When I know I got the basics right, I can start writing optimized drawing routines. Anyone who cares to give it a try? Just check out CVS module `fbtest' from http://sourceforge.net/cvs/?group_id=908, type `make' and run `fbtest' for all available color depths (use fbset first), and tell me whether it works. If no one is left with an Atari with Linux/m68k installed, I can create a ramdisk containing fbset and fbtest, so you just need ataboot and a kernel to test it. Thanks! 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 |
|
From: Geert U. <ge...@li...> - 2002-12-08 11:49:17
|
On Thu, 28 Nov 2002, Geert Uytterhoeven wrote: > On 25 Nov 2002, Johan Bolmsjo wrote: > > For what it's worth, the interleaved modes on atari works like this: > > > > The bitplanes are interleaved on 16 bit big-endian word basis so if you > > have two bitplanes, bit 0 of the first 16 pixels would be in the first > > 16 bit word in the display memory, bit 1 of the first 16 pixels would be > > in the second word. With bit 0 I mean as masked out by & 0x0001 in C, > > and bit 1 as masked out by 0x0002. > > Thanks! This is exactly the kind of information I needed! > > I added simple unoptimized support for Atari interleaved bitplanes to fbtest. > When I know I got the basics right, I can start writing optimized drawing > routines. > > Anyone who cares to give it a try? Just check out CVS module `fbtest' from > http://sourceforge.net/cvs/?group_id=908, type `make' and run `fbtest' for all > available color depths (use fbset first), and tell me whether it works. > > If no one is left with an Atari with Linux/m68k installed, I can create a > ramdisk containing fbset and fbtest, so you just need ataboot and a kernel to > test it. I put the ramdisk at http://home.tvd.be/cr26864/Linux/m68k/ramdisk-fbtest-m68k.gz Just boot it with whatever kernel (incl. atafb, of course) you have, and run `fbtest' for all available color depths. You can change the color depth with `fbset -depth <depth>'. Note that it will be slow, since so far I implemented single pixel drawing only. Thanks for testing! Gr{oetje,eeting}s, Geert P.S. Sorry that it took that long, but my Amiga 4000 needed urgent surgery due to a leaking NiCd battery that started to corrode the mainboard. Fortunately I managed to replace it in time by a new NiMH part. -- 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 |
Thanks for helping keep SourceForge clean.
X