From: James Simmons <hidden> Date: 2002-11-22 17:52:43
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.
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
From: James Simmons <hidden> Date: 2002-11-22 19:04:50
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?
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
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
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
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.
quoted
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.
quoted
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 :-)
quoted
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
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
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
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 -- geert@linux-m68k.org
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
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
From: James Simmons <hidden> Date: 2002-11-25 18:47:06
quoted
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!!!!
-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
From: Johan Bolmsjo <hidden> Date: 2002-11-25 21:43:39
mån 2002-11-25 klockan 19.47 skrev James Simmons:
quoted
quoted
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!!!
quoted
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...
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
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!!!!
-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T
handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
From: James Simmons <hidden> Date: 2002-11-26 00:40:29
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?
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
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 -- geert@linux-m68k.org
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
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
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 -- geert@linux-m68k.org
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
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf