atafb and X/fbdev

atafb and X/fbdev

[Thorsten Glaser]

Hi,

X/xfbdef gets SIGFPE. X/fbdev doesn’t like *any* atafb mode: it likes
neither interleaved planes nor 1bpp modes, and I don’t think there are
any others. How can we get an X server on ARAnyM running (I’ve got both
current x.org from sid and XFree86 from woody installed)?

Sitting at BAAMM! so quick response appreciated ;)

http://lists.debian.org/debian-68k/2012/05/msg00027.html

bye,
//mirabilos
-- 
13:37⎜«Natureshadow» Deep inside, I hate mirabilos. I mean, he's a good
guy. But he's always right! In every fsckin' situation, he's right. Even
with his deeply perverted taste in software and borked ambition towards
broken OSes - in the end, he's damn right about it :(! […] works in mksh

Re: atafb and X/fbdev

[schmitz]

Thorsten,
> X/xfbdef gets SIGFPE. X/fbdev doesn’t like *any* atafb mode: it likes
> neither interleaved planes nor 1bpp modes, and I don’t think there are
>   
Have you tried the VGA modes (vga256 for instance)? That might boil down 
to interleaved planes in the end though.
> any others. How can we get an X server on ARAnyM running (I’ve got both
> current x.org from sid and XFree86 from woody installed)?
>   
You will have to go back to one of the earlier Debian releases (slink or 
potato) for Atari support in the X server. potato should still have the 
required code.
> Sitting at BAAMM! so quick response appreciated ;)
>   
Geert is your best shot at getting framebuffer device questions answered.

Cheers,

    Michael
   
> http://lists.debian.org/debian-68k/2012/05/msg00027.html
>
> bye,
> //mirabilos
>   

Re: atafb and X/fbdev

[Thorsten Glaser]

schmitz dixit:

> Have you tried the VGA modes (vga256 for instance)? That might boil down to
> interleaved planes in the end though.

Yes, vgs256 was interleaved too. From my limited understanding of
atafb.c all modes are interleaved or monochrome.

> You will have to go back to one of the earlier Debian releases (slink or
> potato) for Atari support in the X server. potato should still have the
> required code.

Hrm, okay. I couldn’t find much in the ’net except a reference to
xfree68 but was unable to find that, either. Too bad, all the history…
you don’t happen to know the _package_ name of the server, and the
needed config? ;-)

bye,
//mirabilos
-- 
  “Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool.”
						-- Edward Burr

Re: atafb and X/fbdev

[Geert Uytterhoeven]

Hi Thorsten,

On Sat, Jul 7, 2012 at 9:54 AM, Thorsten Glaser <tg@mirbsd.de> wrote:
> schmitz dixit:
>> Have you tried the VGA modes (vga256 for instance)? That might boil down to
>> interleaved planes in the end though.
>
> Yes, vgs256 was interleaved too. From my limited understanding of
> atafb.c all modes are interleaved or monochrome.

The 16-bpp Falcon mode should be chunky and work.

The 2, 4, and 8 bpp Atari interleaved bitplane support is botched due to the
removal of the iplan2p[248] code.

The 1 bpp monochrome mode (mfb) is (used to be, cfr. Xsun) fairly standard,
but it may have been broken by regressions introduced in the fbdev X
server code.

It's also broken on Amiga, which uses interleaved bitplanes (ilbm).

I once had a look at it, and at several places the new fbdev X code did stupid
things that wouldn't work on bitplanes. It did work a long time ago, when I
maintained it.

>> You will have to go back to one of the earlier Debian releases (slink or
>> potato) for Atari support in the X server. potato should still have the
>> required code.
>
> Hrm, okay. I couldn’t find much in the ’net except a reference to
> xfree68 but was unable to find that, either. Too bad, all the history…
> you don’t happen to know the _package_ name of the server, and the
> needed config? ;-)

xserver-fbdev? Or is that already the newer broken one?

The "XFree68" binaries I uploaded in the nineties should still be available
on FTP sites, though.

For the future, my plan (if I ever get to it, sigh) is to use tinyX
shadowfb, and
add support for converting rectangles from iplan2p[48] and ilbm (4 and 8 bpp)
to cfb[48]. The actual low-level conversion code is available in the
kernel, for the
console. As I wrote it, there's no license issue in taking that ;-)

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

Re: atafb and X/fbdev

[Thorsten Glaser]

Geert Uytterhoeven dixit:

>The 16-bpp Falcon mode should be chunky and work.

That's video=atafb:falh16 ?

>> Hrm, okay. I couldn’t find much in the ’net except a reference to
>> xfree68 but was unable to find that, either. Too bad, all the history…
>> you don’t happen to know the _package_ name of the server, and the
>> needed config? ;-)
>
>xserver-fbdev? Or is that already the newer broken one?

Hrm. I looked on archive.debian.org but wasn’t too successful;
the “old” stuff is just a package xserver-xfree86 but that one’s
fbdev didn’t like interleaved planes already. (Ok, that was potato.)

>The "XFree68" binaries I uploaded in the nineties should still be available
>on FTP sites, though.

Hrm. I can look through archive.debian.org and snapshot.debian.org;
lookup is easiest by source package names.

>For the future, my plan (if I ever get to it, sigh) is to use tinyX
>shadowfb, and

Hrm sounds interesting, too. (Too bad xfbdev¹ gets SIGFPE, it would
probably have been a reasonable starting point.)

① http://packages.debian.org/sid/xserver-xfbdev

(Looking at p.d.o I probably should try with xserver-xephyr over
ssh X forwarding whether the rest of the system works first.)

>console. As I wrote it, there's no license issue in taking that ;-)

Right ;)

Thanks,
//mirabilos
-- 
13:37⎜«Natureshadow» Deep inside, I hate mirabilos. I mean, he's a good
guy. But he's always right! In every fsckin' situation, he's right. Even
with his deeply perverted taste in software and borked ambition towards
broken OSes - in the end, he's damn right about it :(! […] works in mksh

Re: atafb and X/fbdev

[Thorsten Glaser]

Dixi quot…

>Geert Uytterhoeven dixit:
>
>>The 16-bpp Falcon mode should be chunky and work.
>
>That's video=atafb:falh16 ?

No, that's a 4bpp mode.

From my reading of drivers/video/atafb.c there are
no 16bpp modes?

bye,
//mirabilos
-- 
21:27⎜[Natureshadow] BÄH! Wer hatn das Bier neben den Notebooklüfter
     ⎜    gestellt ...
21:27⎜>Natureshadow< lol                         21:27⎜>Natureshadow< du?
21:27⎜[Natureshadow] vermutlich ...   -- Kev^WNatureshadow allein zu Haus

Re: atafb and X/fbdev

[Michael Schmitz]

Thorsten Glaser wrote:
>>> The 16-bpp Falcon mode should be chunky and work.
>>>       
>> That's video=atafb:falh16 ?
>>     
>
> No, that's a 4bpp mode.
>
> From my reading of drivers/video/atafb.c there are
> no 16bpp modes?
>   
There is a 16 bpp mode - look for 'hicolor' in the source. From my 
understanding,
it has all been wired up right (to be honest, I did only rewrite the 
fbcon interface
for 2.6 onwards, and touched as little of the business end of the driver 
as possible).

The driver detects hicolor mode from bit 8 of f_shift:

        else if (hw->f_shift & 0x100)   /* hicolor */
                var->bits_per_pixel = 16;  

and uses the generic packed pixel cfb interface to draw characters to 
the screen in this case.

Thanks for the hint, Geert - I would have claimed there's only mono and 
interleaved planes otherwise. 
Nothing like a trip down memory lane - I had totally forgotten that I 
wrote Mac fbcon drivers back in the days.

I feel I should give the hicolor mode a test to see whether it does 
actually work after all this time.

Cheers,

  Michael

Re: atafb and X/fbdev

[Michael Schmitz]

Thorsten,

> There is a 16 bpp mode - look for 'hicolor' in the source. From my
> understanding,
> it has all been wired up right (to be honest, I did only rewrite the fbcon
> interface
> for 2.6 onwards, and touched as little of the business end of the driver as
> possible).

The mode is named TrueColor in GEM - I just cannot seem to chose it.
Any hints welcome.

If all else fails I'll hack a truecolor command line option into atafb :-)

Cheers,

  Michael

Re: atafb and X/fbdev

[Michael Schmitz]

[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]

Thorsten,
>> There is a 16 bpp mode - look for 'hicolor' in the source. From my
>> understanding,
>> it has all been wired up right (to be honest, I did only rewrite the fbcon
>> interface
>> for 2.6 onwards, and touched as little of the business end of the driver as
>> possible).
>>     
>
> The mode is named TrueColor in GEM - I just cannot seem to chose it.
> Any hints welcome.
>
>   
Anyone? Do I need special hardware (external pixel clock generation?) to 
use the truecolor mode?
> If all else fails I'll hack a truecolor command line option into atafb :-)
>   
I've played with the framebuffer timing calculations a bit - 16 bpp 
appears to require unreasonably
low hsync frequency in order to keep within the available video 
bandwidth of 32 MHz.

The attached patch should allow you to use the 16bpp mode in ARAnyM. 
video=atafb:truecolor
together with stram_pool=2048k should get you there.

fbset could be used to switch depths on the fly if you don't want to use 
it all the time.

For real existing hardware, I fear 8 bit VGA mode is the best we can do.

Cheers,

    Michael




[-- Attachment #2: atafb-truecolor.diff --]
[-- Type: text/x-patch, Size: 2529 bytes --]

commit cb0ac57a4163fba7a3e73ff613670dc5792fb5b6
Author: schmitz <schmitz@michael.waratah.dyndns.org>
Date:   Sat Jul 14 15:26:25 2012 +1200

    [m68k] Atari: experimental truecolor support for atafb (ARAnyM only!)

diff --git a/drivers/video/atafb.c b/drivers/video/atafb.c
index 64e41f5..71f9279 100644
--- a/drivers/video/atafb.c
+++ b/drivers/video/atafb.c
@@ -409,6 +409,7 @@ static char *vga16_names[] = { "vga16", "default3", NULL };
 static char *vga256_names[] = { "vga256", NULL };
 static char *falh2_names[] = { "falh2", NULL };
 static char *falh16_names[] = { "falh16", NULL };
+static char *truecol_names[] = { "truecolor", NULL };
 
 static char **fb_var_names[] = {
 	autodetect_names,
@@ -424,6 +425,7 @@ static char **fb_var_names[] = {
 	vga256_names,
 	falh2_names,
 	falh16_names,
+	truecol_names,
 	NULL
 };
 
@@ -483,6 +485,10 @@ static struct fb_var_screeninfo atafb_predefined[] = {
 	  896, 608, 896, 0, 0, 0, 4, 0,
 	  {0, 6, 0}, {0, 6, 0}, {0, 6, 0}, {0, 0, 0},
 	  0, 0, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0 },
+	{ /* truecolor */
+	  640, 480, 640, 0, 0, 0, 16, 0,
+	  {0, 5, 0}, {0, 6, 0}, {0, 5, 0}, {0, 0, 0},
+	  0, 0, -1, -1, 0, 0, 0, 0, 0, 0, 0, 0 },
 };
 
 static int num_atafb_predefined = ARRAY_SIZE(atafb_predefined);
@@ -547,6 +553,14 @@ static struct fb_videomode atafb_modedb[] __initdata = {
 		"falh", 60, 896, 608, 32000, 18, 42, 31, 1, 96,3,
 		0, FB_VMODE_NONINTERLACED | FB_VMODE_YWRAP
 	},
+
+	{
+		/* 640x400, 31 kHz, 70 Hz (VGA) */
+		"truecolor", 70, 640, 400, 32000, 18, 42, 31, 11, 96, 3,
+		FB_SYNC_VERT_HIGH_ACT | FB_SYNC_COMP_HIGH_ACT, FB_VMODE_NONINTERLACED | FB_VMODE_YWRAP
+	},
+
+
 };
 
 #define NUM_TOTAL_MODES  ARRAY_SIZE(atafb_modedb)
@@ -1181,8 +1195,13 @@ static int falcon_decode_var(struct fb_var_screeninfo *var,
 	}
 	/* Is video bus bandwidth (32MB/s) too low for this resolution? */
 	/* this is definitely wrong if bus clock != 32MHz */
-	if (pclock->f / plen / 8 * bpp > 32000000L)
-		return -EINVAL;
+	if (bpp == 16) {
+		if (pclock->f / plen / 16 * bpp > 32000000L)
+			return -EINVAL;
+	} else {
+		if (pclock->f / plen / 8 * bpp > 32000000L)
+			return -EINVAL;
+	}
 
 	if (vsync_len < 1)
 		vsync_len = 1;
@@ -3147,7 +3166,7 @@ int __init atafb_init(void)
 	/* Multisync monitor capabilities */
 	/* Atari-TOS defaults if no boot option present */
 	if (fb_info.monspecs.hfmin == 0) {
-		fb_info.monspecs.hfmin = 31000;
+		fb_info.monspecs.hfmin = 16000;
 		fb_info.monspecs.hfmax = 32000;
 		fb_info.monspecs.vfmin = 58;
 		fb_info.monspecs.vfmax = 62;

Re: atafb and X/fbdev

[Geert Uytterhoeven]

On Sat, Jul 14, 2012 at 5:42 AM, Michael Schmitz <schmitzmic@gmail.com> wrote:
>> If all else fails I'll hack a truecolor command line option into atafb :-)
>
> I've played with the framebuffer timing calculations a bit - 16 bpp appears
> to require unreasonably
> low hsync frequency in order to keep within the available video bandwidth of
> 32 MHz.

For 640x480 that's true.

For 320x240, it should work. I definitely used a hicolor mode on ARAnyM when
atafb was revived.

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

Re: atafb and X/fbdev

[Michael Schmitz]

Hi Geert,
>> I've played with the framebuffer timing calculations a bit - 16 bpp appears
>> to require unreasonably
>> low hsync frequency in order to keep within the available video bandwidth of
>> 32 MHz.
> For 640x480 that's true.
>
> For 320x240, it should work. I definitely used a hicolor mode on ARAnyM when
> atafb was revived.
Using what atafb option? Or did you use fbset to switch?

Cheers,

   Michael

Re: atafb and X/fbdev

[Geert Uytterhoeven]

Hi Michael,

On Sun, Jul 15, 2012 at 9:12 AM, Michael Schmitz <schmitzmic@gmail.com> wrote:
>>> I've played with the framebuffer timing calculations a bit - 16 bpp
>>> appears
>>> to require unreasonably
>>> low hsync frequency in order to keep within the available video bandwidth
>>> of
>>> 32 MHz.
>>
>> For 640x480 that's true.
>>
>> For 320x240, it should work. I definitely used a hicolor mode on ARAnyM
>> when
>> atafb was revived.
>
> Using what atafb option? Or did you use fbset to switch?

I used fbset. But it should also be possible using the kernel command line.

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

Re: atafb and X/fbdev

[Michael Schmitz]

Geert,

>>> For 640x480 that's true.
>>>
>>> For 320x240, it should work. I definitely used a hicolor mode on ARAnyM
>>> when
>>> atafb was revived.
>>
>> Using what atafb option? Or did you use fbset to switch?
>
> I used fbset. But it should also be possible using the kernel command line.

Try as I may, I do only get atafb to parse the first option. Neither
the monitorcap nor resolution options were parsed correctly.

I"ll give fbset a shot though.

Cheers,

  Michael

Re: atafb and X/fbdev

[Michael Schmitz]

Thorsten,
>> Have you tried the VGA modes (vga256 for instance)? That might boil down to
>> interleaved planes in the end though.
>>     
>
> Yes, vgs256 was interleaved too. From my limited understanding of
> atafb.c all modes are interleaved or monochrome.
>   

That's the way the Falcon VIDEL is wired up then.

>> You will have to go back to one of the earlier Debian releases (slink or
>> potato) for Atari support in the X server. potato should still have the
>> required code.
>>     
>
> Hrm, okay. I couldn’t find much in the ’net except a reference to
> xfree68 but was unable to find that, either. Too bad, all the history…
>   

Seaching for "xfree86 fbdev server m68k" does refresh my memory a bit -
the server package was called xserver-fbdev and you will find a sample 
config
file at http://people.debian.org/~cts/debian-m68k/slink/XF86Config - 
Christian is
away overseas ATM or else he might be able to give a few hints here.

The entry

    Driver      "FBDev"


in the 'Screen' section is what directs xfree86 to use the generic frame 
buffer server.
> you don’t happen to know the _package_ name of the server, and the
> needed config? ;-)
>
>   

See above - it's xserver-fbdev, IIRC version 3.3.6 was the last to work. 
Also take a look at 
http://people.debian.org/~cts/debian-m68k/slink/debian-m68k-faq
for a few likely X troubleshooting hints.

Blast from the past really - I never had much fun running X on my 
(unaccelerated) Falcon
mainly because the system became really unstable at high resolution or 
color depth.
Waiting for 10 minutes while the X server starts up was a bit annoying, 
too.

Are you trying to get the old X server running in ARAnyM, or 'just' port 
the interleaved bit
planes code to current Xorg? If it's questions on the framebuffer memory 
layout and the VIDEL
that you need answered, Andreas and Petr might be better suited here. 
Regarding building
xfree from source - that's memories well suppressed which do not bear 
recalling.

Cheers,

  Michael

Re: atafb and X/fbdev

[Christian T. Steigies]

On Sun, Jul 08, 2012 at 03:47:40PM +1200, Michael Schmitz wrote:
> 
> Seaching for "xfree86 fbdev server m68k" does refresh my memory a bit -
> the server package was called xserver-fbdev and you will find a
> sample config
> file at http://people.debian.org/~cts/debian-m68k/slink/XF86Config -
> Christian is
> away overseas ATM or else he might be able to give a few hints here.

Not overseas, just Moscow, but I'll be back tomorrow. But I could not give
you any more hints, since it has been years that I used X on an m68k box. It
has not worked on my Amiga since my CV64/3D died, and the Picasso cards I
never got to work properly in X. On the Falcon and Mac I do not remember if
X worked, I used them mostly via the network.

Christian