[PATCH/RFC] atafb and panning

[PATCH/RFC] atafb and panning

[Geert Uytterhoeven]

Fix panning on ARAnyM (Falcon emulation). Without this, `fbtest test011' fails
(for a 320x200x8 display with virtual 640x400).

As the original code in 2.4.x was the same, I'm wondering:
  o Is this a bug in the ARAnyM emulation?
  o xpanstep is 1, but judging from the visual output on ARAnyM, it looks like
    it should be 16?

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
 drivers/video/atafb.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/video/atafb.c
+++ b/drivers/video/atafb.c
@@ -1697,8 +1697,10 @@ static int falcon_pan_display(struct fb_
 	}
 	par->hw.falcon.line_offset = bpp *
 		(info->var.xres_virtual - info->var.xres) / 16;
+#if 0
 	if (par->hw.falcon.xoffset)
 		par->hw.falcon.line_offset -= bpp;
+#endif;
 	xoffset = var->xoffset - par->hw.falcon.xoffset;
 
 	par->screen_base = screen_base +

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: [PATCH/RFC] atafb and panning

[Petr Stehlík]

Geert Uytterhoeven píše v Ne 16. 11. 2008 v 22:36 +0100:
> Fix panning on ARAnyM (Falcon emulation). Without this, `fbtest test011' fails
> (for a 320x200x8 display with virtual 640x400).
> 
> As the original code in 2.4.x was the same, I'm wondering:
>   o Is this a bug in the ARAnyM emulation?
>   o xpanstep is 1, but judging from the visual output on ARAnyM, it looks like
>     it should be 16?

A bug in ARAnyM emulation is _always_ possible but I do have an idle
Falcon sitting next to my desk so if you send me a disk image to try out
I should be able to find out what's wrong pretty quick.

Petr


--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC] atafb and panning

[Michael Schmitz]

Hi Geert,

> Fix panning on ARAnyM (Falcon emulation). Without this, `fbtest test011' fails
> (for a 320x200x8 display with virtual 640x400).

Fails how, exactly? 
 
> As the original code in 2.4.x was the same, I'm wondering:
>   o Is this a bug in the ARAnyM emulation?
>   o xpanstep is 1, but judging from the visual output on ARAnyM, it looks like
>     it should be 16?
> 
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
>  drivers/video/atafb.c |    2 ++
>  1 file changed, 2 insertions(+)
> 
> --- a/drivers/video/atafb.c
> +++ b/drivers/video/atafb.c
> @@ -1697,8 +1697,10 @@ static int falcon_pan_display(struct fb_
>  	}
>  	par->hw.falcon.line_offset = bpp *
>  		(info->var.xres_virtual - info->var.xres) / 16;
> +#if 0
>  	if (par->hw.falcon.xoffset)
>  		par->hw.falcon.line_offset -= bpp;
> +#endif;

The way I understand this code is:

If var->xoffset has the low order bits set (sub-word pixel offset) 
par->hw.falcon.xoffset takes care of that, and xoffset takes care of the rest. 
Since the partial word offset shifts the beginnig of the scan line into the 
first word, the offset to the next scan line (par->hw.falcon.line_offset) has to 
be shortened. 

I am pretty sure the pan step can be one (see par->hw.falcon.xoffset).

I'll test your patch as soon as I get fbtest to work (missing libgcc_s.so.2).

	Michael

Re: [PATCH/RFC] atafb and panning

[Geert Uytterhoeven]

On Wed, 19 Nov 2008, Michael Schmitz wrote:
> > Fix panning on ARAnyM (Falcon emulation). Without this, `fbtest test011' fails
> > (for a 320x200x8 display with virtual 640x400).
> 
> Fails how, exactly? 

It shows a corrupted display (bad line length) if xoffset & 15 != 0.

> > As the original code in 2.4.x was the same, I'm wondering:
> >   o Is this a bug in the ARAnyM emulation?
> >   o xpanstep is 1, but judging from the visual output on ARAnyM, it looks like
> >     it should be 16?
> > 
> > Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> > ---
> >  drivers/video/atafb.c |    2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > --- a/drivers/video/atafb.c
> > +++ b/drivers/video/atafb.c
> > @@ -1697,8 +1697,10 @@ static int falcon_pan_display(struct fb_
> >  	}
> >  	par->hw.falcon.line_offset = bpp *
> >  		(info->var.xres_virtual - info->var.xres) / 16;
> > +#if 0
> >  	if (par->hw.falcon.xoffset)
> >  		par->hw.falcon.line_offset -= bpp;
> > +#endif;
> 
> The way I understand this code is:
> 
> If var->xoffset has the low order bits set (sub-word pixel offset) 
> par->hw.falcon.xoffset takes care of that, and xoffset takes care of the rest. 
> Since the partial word offset shifts the beginnig of the scan line into the 
> first word, the offset to the next scan line (par->hw.falcon.line_offset) has to 
> be shortened. 

Sounds reasonable. But the shortening part doesn't work on ARAnyM, nor do
small panning increments. So it really smells like an ARAnyM bug.

> I am pretty sure the pan step can be one (see par->hw.falcon.xoffset).
> 
> I'll test your patch as soon as I get fbtest to work (missing libgcc_s.so.2).

The alternative is to compile fbtest yourself (CVS module
FBdev/utlilities/fbtest from project linux-fbdev on sf.net).
I've been thinking of putting a git clone on kernel.org...

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: [PATCH/RFC] atafb and panning

[Petr Stehlik]

Geert Uytterhoeven píše v St 19. 11. 2008 v 09:15 +0100:
> > par->hw.falcon.xoffset takes care of that, and xoffset takes care of the rest. 
> > Since the partial word offset shifts the beginnig of the scan line into the 
> > first word, the offset to the next scan line (par->hw.falcon.line_offset) has to 
> > be shortened. 
> 
> Sounds reasonable. But the shortening part doesn't work on ARAnyM, nor do
> small panning increments. So it really smells like an ARAnyM bug.

I guess this is about horizontal scrolling which was used in old 2D
games only and frankly, we don't have many games running on ARAnyM (it's
not the goal of ARAnyM project, anyway). I hacked the VIDEL emulation
many years ago just to get the TOS booting and even though it's been
improved by others since then it's likely nobody run into this yet.

Just please tell me if the xoffset you mention is the 0xff8264 register
or if I am completely out. And for now write the linux kernel according
to the HW docs and I'll then correct the VIDEL emulation to do the right
thing in fbtests :-)

Thanks :)

Petr

P.S. There is a new release of ARAnyM in sid since last week (that has
the special "--halt" option for Stephen and other installing
Debian/m68k :-) but I am willing to do another release as soon as this
probable/apparent VIDEL deficiency is fixed.


--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC] atafb and panning

[Michael Schmitz]

Hi,

> > > Fix panning on ARAnyM (Falcon emulation). Without this, `fbtest test011' fails
> > > (for a 320x200x8 display with virtual 640x400).
> > 
> > Fails how, exactly? 
> 
> It shows a corrupted display (bad line length) if xoffset & 15 != 0.

OK; this should work but I'll have to verify it in 2.4. 
 
> > If var->xoffset has the low order bits set (sub-word pixel offset) 
> > par->hw.falcon.xoffset takes care of that, and xoffset takes care of the rest. 
> > Since the partial word offset shifts the beginnig of the scan line into the 
> > first word, the offset to the next scan line (par->hw.falcon.line_offset) has to 
> > be shortened. 
> 
> Sounds reasonable. But the shortening part doesn't work on ARAnyM, nor do
> small panning increments. So it really smells like an ARAnyM bug.

Petr said as much if I understand him right. No need to fix ARAnyM though, we 
just need to keep that in mind. 
 
> > I'll test your patch as soon as I get fbtest to work (missing libgcc_s.so.2).
> 
> The alternative is to compile fbtest yourself (CVS module
> FBdev/utlilities/fbtest from project linux-fbdev on sf.net).

Tried that before but could not get it to work a year ago. Will retry.

> I've been thinking of putting a git clone on kernel.org...

Good thinking - git I can use (sort of) :-)

	Michael

Re: [PATCH/RFC] atafb and panning

[Petr Stehlík]

Michael Schmitz píše v So 22. 11. 2008 v 08:16 +0100:
> > > If var->xoffset has the low order bits set (sub-word pixel offset) 
> > > par->hw.falcon.xoffset takes care of that, and xoffset takes care of the rest. 
> > > Since the partial word offset shifts the beginnig of the scan line into the 
> > > first word, the offset to the next scan line (par->hw.falcon.line_offset) has to 
> > > be shortened. 
> > 
> > Sounds reasonable. But the shortening part doesn't work on ARAnyM, nor do
> > small panning increments. So it really smells like an ARAnyM bug.
> 
> Petr said as much if I understand him right. No need to fix ARAnyM though, we 
> just need to keep that in mind. 

ARAnyM's VIDEL emulation has already been fixed by Patrice (yesterday
night, in CVS).

Petr


--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH/RFC] atafb and panning

[Geert Uytterhoeven]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=UTF-8, Size: 1488 bytes --]

On Sat, 22 Nov 2008, Petr Stehlík wrote:
> Michael Schmitz pí¹e v So 22. 11. 2008 v 08:16 +0100:
> > > > If var->xoffset has the low order bits set (sub-word pixel offset) 
> > > > par->hw.falcon.xoffset takes care of that, and xoffset takes care of the rest. 
> > > > Since the partial word offset shifts the beginnig of the scan line into the 
> > > > first word, the offset to the next scan line (par->hw.falcon.line_offset) has to 
> > > > be shortened. 
> > > 
> > > Sounds reasonable. But the shortening part doesn't work on ARAnyM, nor do
> > > small panning increments. So it really smells like an ARAnyM bug.
> > 
> > Petr said as much if I understand him right. No need to fix ARAnyM though, we 
> > just need to keep that in mind. 
> 
> ARAnyM's VIDEL emulation has already been fixed by Patrice (yesterday
> night, in CVS).

I can confirm that (for depths 2, 4, and 8). However, it's not flicker-free.
Dunno if that's an atafb or ARAnyM issue.

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
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

atari_mouse_interrupt_hook (was: Re: [PATCH/RFC] atafb and panning)

[Geert Uytterhoeven]

On Mon, 15 Dec 2008, Michael Schmitz wrote:
> > > That's gotta be from ARAnyM. But I've got another bummer for you: The Atari 
> > > keyboard driver calls atari_mouse_interrupt_hook if it's set, not 
> > > atari_input_mouse_interrupt_hook. Fix below.
> > 
> > Euh, what does this mean?
> > 
> > Who should use atari_mouse_interrupt_hook (no users left)?
> 
> No one should be using atari_mouse_interrupt_hook anymore so it can be killed 
> off. I probably renamed the hook in all but that one place following a 
> recommendation from the list. My bad, as usual.

Looks like you missed one more spot, so I came up with this. OK?

commit 896d2f2715d1fadd4c510c4125b1e4c0f1918f6f
Author: Michael Schmitz <schmitz@biophys.uni-duesseldorf.de>
Date:   Tue Dec 16 21:26:03 2008 +0100

    atari: Use the correct mouse interrupt hook
    
    The Atari keyboard driver calls atari_mouse_interrupt_hook if it's set, not
    atari_input_mouse_interrupt_hook. Fix below.
    
    [geert] Killed off atari_mouse_interrupt_hook completely, after fixing another
    incorrect assignment in atarimouse.c.
    
    Signed-off-by: Michael Schmitz <schmitz@debian.org>
    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>

diff --git a/arch/m68k/atari/atakeyb.c b/arch/m68k/atari/atakeyb.c
index c038b7c..2c16dcb 100644
--- a/arch/m68k/atari/atakeyb.c
+++ b/arch/m68k/atari/atakeyb.c
@@ -37,13 +37,10 @@ extern unsigned int keymap_count;
 
 /* Hook for MIDI serial driver */
 void (*atari_MIDI_interrupt_hook) (void);
-/* Hook for mouse driver */
-void (*atari_mouse_interrupt_hook) (char *);
 /* Hook for keyboard inputdev  driver */
 void (*atari_input_keyboard_interrupt_hook) (unsigned char, char);
 /* Hook for mouse inputdev  driver */
 void (*atari_input_mouse_interrupt_hook) (char *);
-EXPORT_SYMBOL(atari_mouse_interrupt_hook);
 EXPORT_SYMBOL(atari_input_keyboard_interrupt_hook);
 EXPORT_SYMBOL(atari_input_mouse_interrupt_hook);
 
@@ -264,8 +261,8 @@ repeat:
 			kb_state.buf[kb_state.len++] = scancode;
 			if (kb_state.len == 3) {
 				kb_state.state = KEYBOARD;
-				if (atari_mouse_interrupt_hook)
-					atari_mouse_interrupt_hook(kb_state.buf);
+				if (atari_input_mouse_interrupt_hook)
+					atari_input_mouse_interrupt_hook(kb_state.buf);
 			}
 			break;
 
diff --git a/drivers/input/mouse/atarimouse.c b/drivers/input/mouse/atarimouse.c
index adf45b3..a57143c 100644
--- a/drivers/input/mouse/atarimouse.c
+++ b/drivers/input/mouse/atarimouse.c
@@ -108,7 +108,7 @@ static int atamouse_open(struct input_dev *dev)
 static void atamouse_close(struct input_dev *dev)
 {
 	ikbd_mouse_disable();
-	atari_mouse_interrupt_hook = NULL;
+	atari_input_mouse_interrupt_hook = NULL;
 }
 
 static int __init atamouse_init(void)
diff --git a/include/asm-m68k/atarikb.h b/include/asm-m68k/atarikb.h
index 546e7da..68f3622 100644
--- a/include/asm-m68k/atarikb.h
+++ b/include/asm-m68k/atarikb.h
@@ -34,8 +34,6 @@ void ikbd_joystick_disable(void);
 
 /* Hook for MIDI serial driver */
 extern void (*atari_MIDI_interrupt_hook) (void);
-/* Hook for mouse driver */
-extern void (*atari_mouse_interrupt_hook) (char *);
 /* Hook for keyboard inputdev  driver */
 extern void (*atari_input_keyboard_interrupt_hook) (unsigned char, char);
 /* Hook for mouse inputdev  driver */

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: atari_mouse_interrupt_hook (was: Re: [PATCH/RFC] atafb and panning)

[Michael Schmitz]

Hi Geert,

> > > Who should use atari_mouse_interrupt_hook (no users left)?
> > 
> > No one should be using atari_mouse_interrupt_hook anymore so it can be killed 
> > off. I probably renamed the hook in all but that one place following a 
> > recommendation from the list. My bad, as usual.
> 
> Looks like you missed one more spot, so I came up with this. OK?
> 
> commit 896d2f2715d1fadd4c510c4125b1e4c0f1918f6f
> Author: Michael Schmitz <schmitz@biophys.uni-duesseldorf.de>
> Date:   Tue Dec 16 21:26:03 2008 +0100
> 
>     atari: Use the correct mouse interrupt hook
>     
>     The Atari keyboard driver calls atari_mouse_interrupt_hook if it's set, not
>     atari_input_mouse_interrupt_hook. Fix below.
>     
>     [geert] Killed off atari_mouse_interrupt_hook completely, after fixing another
>     incorrect assignment in atarimouse.c.
>     
>     Signed-off-by: Michael Schmitz <schmitz@debian.org>
>     Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>

That should fix it for good. Thanks!

	Michael

Re: [PATCH/RFC] atafb and panning

[Michael Schmitz]

Hi Geert,

> > I'll test your patch as soon as I get fbtest to work (missing libgcc_s.so.2).
> 
> The alternative is to compile fbtest yourself (CVS module
> FBdev/utlilities/fbtest from project linux-fbdev on sf.net).

Logging in to :pserver:anonymous@cvs.sourceforge.net:2401/cvsroot/linux-fbdev
CVS password: 
cvs [login aborted]: connect to cvs.sourceforge.net(216.34.181.96):2401 failed: 
Connection refused

cvsweb access is down as well. 

	Michael

fbtest (was: Re: [PATCH/RFC] atafb and panning)

[Geert Uytterhoeven]

On Sun, 23 Nov 2008, Michael Schmitz wrote:
> > > I'll test your patch as soon as I get fbtest to work (missing libgcc_s.so.2).
> > The alternative is to compile fbtest yourself (CVS module
> > FBdev/utlilities/fbtest from project linux-fbdev on sf.net).
> 
> Logging in to :pserver:anonymous@cvs.sourceforge.net:2401/cvsroot/linux-fbdev
> CVS password: 
> cvs [login aborted]: connect to cvs.sourceforge.net(216.34.181.96):2401 failed: 
> Connection refused
> 
> cvsweb access is down as well. 

I put a git clone at
git://git.kernel.org/pub/scm/linux/kernel/git/geert/fbtest.git

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: fbtest (was: Re: [PATCH/RFC] atafb and panning)

[Michael Schmitz]

Hi Geert,

> > cvs [login aborted]: connect to cvs.sourceforge.net(216.34.181.96):2401 failed: 
> > Connection refused
> > 
> > cvsweb access is down as well. 
> 
> I put a git clone at
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/fbtest.git

Cloned and built. Thank you! 

	Michael