[PATCH] fb: hide cursor in graphics mode

Xserver Xfbdev (kdrive) uses linux framebuffer in graphics mode. It doesn't
need the text mode cursor, it's a bit annoying to have it there sitting in a
corner. This patch disables the cursor even when in graphics mode.

Signed-off-by: Risto Suominen <redacted>
---
The testing is done on kernel version 2.6.18.

--- a/drivers/video/console/fbcon.c.org	2007-03-03 07:14:54.000000000 +0200
+++ b/drivers/video/console/fbcon.c	2009-01-23 12:42:14.000000000 +0200

@@ -1363,6 +1363,12 @@ static void fbcon_cursor(struct vc_data
 	int y;
  	int c = scr_readw((u16 *) vc->vc_pos);

+	if (mode == CM_ERASE && info->fbops->fb_cursor) {
+		/* Hide H/W-cursor unconditionally */
+		ops->cursor(vc, info, mode, 0, 0, 0);
+		return;
+	}
+
 	if (fbcon_is_inactive(vc, info))
 		return;

On Fri, 23 Jan 2009, Risto Suominen wrote:

Xserver Xfbdev (kdrive) uses linux framebuffer in graphics mode. It doesn't
need the text mode cursor, it's a bit annoying to have it there sitting in a
corner. This patch disables the cursor even when in graphics mode.

Signed-off-by: Risto Suominen <redacted>
---
The testing is done on kernel version 2.6.18.

Which is well... quite old.

Does it also (still) happen with 2.6.28?

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

2009/1/24 Geert Uytterhoeven [off-list ref]:

On Fri, 23 Jan 2009, Risto Suominen wrote:

quoted

Xserver Xfbdev (kdrive) uses linux framebuffer in graphics mode. It doesn't
need the text mode cursor, it's a bit annoying to have it there sitting in a
corner. This patch disables the cursor even when in graphics mode.

Signed-off-by: Risto Suominen <redacted>
---
The testing is done on kernel version 2.6.18.

Which is well... quite old.

Does it also (still) happen with 2.6.28?

Well, I don't really know, but I assume it will: fbcon_is_inactive()
still returns true if vc->vc_mode != KD_TEXT, and thus hinders
fbcon_cursor() from doing anything in graphics mode.

Risto

On Sat, 24 Jan 2009, Risto Suominen wrote:

2009/1/24 Geert Uytterhoeven [off-list ref]:

quoted

On Fri, 23 Jan 2009, Risto Suominen wrote:

quoted

Xserver Xfbdev (kdrive) uses linux framebuffer in graphics mode. It doesn't
need the text mode cursor, it's a bit annoying to have it there sitting in a
corner. This patch disables the cursor even when in graphics mode.

Signed-off-by: Risto Suominen <redacted>
---
The testing is done on kernel version 2.6.18.

Which is well... quite old.

Does it also (still) happen with 2.6.28?

Well, I don't really know, but I assume it will: fbcon_is_inactive()
still returns true if vc->vc_mode != KD_TEXT, and thus hinders
fbcon_cursor() from doing anything in graphics mode.

FYI, I've just seen the other patch you posted before.
I'm also wondering what's really going wrong, as I haven't ever noticed this
problem during the last 10 years.

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

2009/1/24 Geert Uytterhoeven [off-list ref]:

FYI, I've just seen the other patch you posted before.
I'm also wondering what's really going wrong, as I haven't ever noticed this
problem during the last 10 years.

Looks like the problem is connected to using HW-cursor, and not so
many framebuffer drivers do that, I've seen this only on atyfb.

Risto

Xserver Xfbdev (kdrive) uses linux framebuffer in graphics mode. It doesn't
need the text mode cursor, it's a bit annoying to have it there sitting in a
corner. This patch disables the cursor even when in graphics mode.

Signed-off-by: Risto Suominen <redacted>
---
The testing is done on kernel version 2.6.18. This version should be
applyable on 2.6.28.4.

--- a/drivers/video/console/fbcon.c.org 2007-03-03 07:14:54.000000000 +0200
+++ b/drivers/video/console/fbcon.c     2009-01-23 12:42:14.000000000 +0200

@@ -1363,6 +1363,12 @@ static void fbcon_cursor(struct vc_data
        int y;
        int c = scr_readw((u16 *) vc->vc_pos);

+       if (mode == CM_ERASE && info->fbops->fb_cursor) {
+               /* Hide H/W-cursor unconditionally */
+               ops->cursor(vc, info, mode, 0, 0, 0);
+               return;
+       }
+
        if (fbcon_is_inactive(vc, info) || vc->vc_deccm != 1)
                return;

The same as attachment, so the last line won't disappear.

Risto

I can now confirm that the problem exists in 2.6.24, and the same
patch corrects it.

Risto

On Tue, 10 Feb 2009 23:50:08 +0200
Risto Suominen [off-list ref] wrote:

The same as attachment, so the last line won't disappear.

Risto


[fbcon-graphics-nocursor.diff  application/octet-stream (814B)]

help.  My knowledge of fbcon is near zero.

Xserver Xfbdev (kdrive) uses linux framebuffer in graphics mode. It doesn't
need the text mode cursor, it's a bit annoying to have it there sitting in a
corner. This patch disables the cursor even when in graphics mode.

Signed-off-by: Risto Suominen <redacted>
---
The testing is done on kernel version 2.6.18.

That's a truly ancient kernel.  Is the patch needed on current kernels?
Does it work correctly in current kernels?

How does the cursor get re-enabled?

Should we be calling ops->cursor() if fbcon_is_inactive() is true?

2009/2/12 Andrew Morton [off-list ref]:

quoted

---
The testing is done on kernel version 2.6.18.

That's a truly ancient kernel.  Is the patch needed on current kernels?
Does it work correctly in current kernels?

It does not on 2.6.24. The patch works.

How does the cursor get re-enabled?

I have not thought of that.

Should we be calling ops->cursor() if fbcon_is_inactive() is true?

Maybe we shouldn't, but we must. The situation is that we are ordered
to enter graphics mode and the variable saying 'graphics' is already
set in vt_ioctl.c. fbcon_is_inactive() tests it and returns true.

The question is, whether this function is called later during normal
operation, and how often?

Risto

On Thu, 12 Feb 2009 23:12:26 +0200
Risto Suominen [off-list ref] wrote:

2009/2/12 Andrew Morton [off-list ref]:

quoted

quoted

---
The testing is done on kernel version 2.6.18.

That's a truly ancient kernel.  Is the patch needed on current kernels?
Does it work correctly in current kernels?

It does not on 2.6.24. The patch works.

I have tested two cards with the hardware cursor: 
Permedia 2 (pm2fb) and Voodoo-3 (tdfxfb).

Both cards use the hardware cursor and both does
not produce the bug you have described.
I have used the Xorg version 7.2 included in the
Slackware 12 and a current git version of the kernel
(updated two days ago).

I do not have the ATI Mach64 card to test it.
I will test my cards with the kernel 2.6.24.

Either, this bug is related only to the atyfb driver
or it was solved in the current kernel.
I looked into the atyfb driver code and I did not
 see anything suspicious there.

Kind regards,
Krzysztof


----------------------------------------------------------------------
Wyslij kartke walentynkowa
Kliknij >>> http://link.interia.pl/f205f

On Fri, 13 Feb 2009 21:06:35 +0100
Krzysztof Helt [off-list ref] wrote:

On Thu, 12 Feb 2009 23:12:26 +0200
Risto Suominen [off-list ref] wrote:

quoted

2009/2/12 Andrew Morton [off-list ref]:

quoted

quoted

---
The testing is done on kernel version 2.6.18.

That's a truly ancient kernel.  Is the patch needed on current kernels?
Does it work correctly in current kernels?

It does not on 2.6.24. The patch works.

I have tested two cards with the hardware cursor: 
Permedia 2 (pm2fb) and Voodoo-3 (tdfxfb).

Both cards use the hardware cursor and both does
not produce the bug you have described.
I have used the Xorg version 7.2 included in the
Slackware 12 and a current git version of the kernel
(updated two days ago).

I do not have the ATI Mach64 card to test it.
I will test my cards with the kernel 2.6.24.

Either, this bug is related only to the atyfb driver
or it was solved in the current kernel.
I looked into the atyfb driver code and I did not
 see anything suspicious there.

I have done more testing.

The pm2fb and tdfxfb work ok with Xorg 7.2 (xserver 1.3.0)
and kernel 2.6.24 (the same cards as above used).

I have build Xfbdev (kdrive) server for the same version of
Xorg (xserver 1.3.0). The Xfbdev works ok (no cursor left)
with both the pm2fb and tdfxfb.

I start wondering what is your version of Xfbdev and how
did you build it. I have build the Xfbdev with the following 
options:

./configure --enable-kdrive \
--disable-xvmc --disable-glx \
--disable-dri --disable-xinerama \
--enable-static --disable-xnest \
--disable-xvfb --disable-dmx \
--disable-xprint --disable-xsdl \
--disable-xorgcfg --disable-xorg

Either, my Xfbdev version is too new to reproduce the bug
(and then the problem is the Xfbdev regression) or the 
problem shows only with special build option.

Could you provide me with information how to build the
Xfbdev to reproduce the problem?
What is your platform (maybe it is not x86) and kernel
configuration?

Kind regards,
Krzysztof


----------------------------------------------------------------------
Zostan mistrzem parkowania w Bombaju!
Zagraj >> http://link.interia.pl/f204e 

Krzysztof, thank you for your efforts.

I've been using PowerMac platform with built-in ATI mach64 and Xorg
server 1.1.1. Kernel options related to frame buffers include:

CONFIG_FB=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_DEFERRED_IO=y
CONFIG_FB_MACMODES=y
CONFIG_FB_BACKLIGHT=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y

CONFIG_FB_ATY=y
CONFIG_FB_ATY_CT=y
CONFIG_FB_ATY_GENERIC_LCD=y
CONFIG_FB_ATY_GX=y
CONFIG_FB_ATY_BACKLIGHT=y

CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y

Xfbdev options include:

--disable-static \
--enable-xorg \
--enable-xtrap \
--enable-dmx \
--enable-vfb \
--enable-kdrive \
--enable-xephyr \
--disable-xsdl \
--disable-xfake \
--enable-xfbdev \
--disable-kdrive-vesa \
--disable-lbx \
--disable-xprint \
--disable-xorgconfig \
--disable-xorgcfg \
--disable-misc-utils

In my opinion, Xfbdev assumes that the cursor will disappear when
turning on graphics mode with ioctl(LinuxConsoleFd, KDSETMODE,
KD_GRAPHICS). It's obvious that fbcon is not doing anything to switch
the cursor off when it receives this ioctl, fbcon_is_inactive()
prevents it. The problem comes from that something has made it appear,
i.e. text mode frame buffer console. I have text consoles on VTs 1 to
6 and X on 7.

One maybe unusual property of atyfb is that the frame buffer is higher
than the screen. To make Xfbdev work correctly I needed the patch
below.

Risto

If virtual resolution is higher than the screen (as in atyfb), and yoffset
given by the framebuffer driver happens to be non-zero (fbcon changes it on-
the-fly), Xfbdev places its image starting above the displayed part of the
framebuffer. This patch makes sure that the whole picture is visible.

Signed-off-by: Risto Suominen <redacted>
---
The testing is done on version 1.1.1 and linux kernel version 2.6.18.

--- a/hw/kdrive/fbdev/fbdev.c.org       2006-07-05 21:31:39.000000000 +0300
+++ b/hw/kdrive/fbdev/fbdev.c   2009-01-18 15:42:06.000000000 +0200

@@ -215,6 +215,8 @@ fbdevScreenInitialize (KdScreenInfo *scr

     /* Now get the new screeninfo */
     ioctl (priv->fd, FBIOGET_VSCREENINFO, &priv->var);
+    /* We can get anything into yoffset if fbcon is active */
+    priv->var.yoffset = 0;
     depth = priv->var.bits_per_pixel;
     gray = priv->var.grayscale;

On Sun, 22 Feb 2009 11:25:04 +0200
Risto Suominen [off-list ref] wrote:

Krzysztof, thank you for your efforts.

I've been using PowerMac platform with built-in ATI mach64 and Xorg
server 1.1.1. 

I will try to reproduce the problem with Xorg 1.1.1 and your options.
I do not have the PowerMac and the ATI mach64 card.

In my opinion, Xfbdev assumes that the cursor will disappear when
turning on graphics mode with ioctl(LinuxConsoleFd, KDSETMODE,
KD_GRAPHICS). It's obvious that fbcon is not doing anything to switch
the cursor off when it receives this ioctl, fbcon_is_inactive()
prevents it. The problem comes from that something has made it appear,
i.e. text mode frame buffer console. I have text consoles on VTs 1 to
6 and X on 7.

One maybe unusual property of atyfb is that the frame buffer is higher
than the screen. To make Xfbdev work correctly I needed the patch
below.

The patch is not a correct fix. A simple workaround is to set a vyres = yres
and disable panning. I am able to reproduce this problem. A cause is
that Xfbdev prints some messages after it set up graphics mode, so
the screen got scrolled. I do not know what is an expected behaviour
(maybe with KD_GRAPHICS no messages should be printed).

Regards,
Krzysztof


----------------------------------------------------------------------
Zostan mistrzem parkowania w Bombaju!
Zagraj >> http://link.interia.pl/f204e 

From: Krzysztof Helt <redacted>

A hardware cursor is left enabled in
the fb_set_par() which is called when
a new console is created. This is
inconsistent with software cursor's
behaviour.

Also, this makes a hardware cursor
always visible in the Xfbdev
(Xorg kdrive) server.

Signed-off-by: Krzysztof Helt <redacted>
CC: Risto Suominen 
---
Finally, I acquired a Mach64GZ card and was able to 
solve this puzzle.

Risto, please test the patch. 

 drivers/video/aty/mach64_accel.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/video/aty/mach64_accel.c b/drivers/video/aty/mach64_accel.c
index a8f60c3..0cc9724 100644
--- a/drivers/video/aty/mach64_accel.c
+++ b/drivers/video/aty/mach64_accel.c

@@ -39,7 +39,8 @@ void aty_reset_engine(const struct atyfb_par *par)
 {
 	/* reset engine */
 	aty_st_le32(GEN_TEST_CNTL,
-		aty_ld_le32(GEN_TEST_CNTL, par) & ~GUI_ENGINE_ENABLE, par);
+		aty_ld_le32(GEN_TEST_CNTL, par) &
+		~(GUI_ENGINE_ENABLE | HWCURSOR_ENABLE), par);
 	/* enable engine */
 	aty_st_le32(GEN_TEST_CNTL,
 		aty_ld_le32(GEN_TEST_CNTL, par) | GUI_ENGINE_ENABLE, par);

-- 
1.5.2.2


----------------------------------------------------------------------
Szukasz pieniedzy? Wez podwójny limit zad³u¿enia w koncie direct.
>> http://link.interia.pl/f20a3

From: Krzysztof Helt <redacted>

A hardware cursor is left enabled in
the fb_set_par() which is called when
a new console is created. This is
inconsistent with software cursor's
behaviour.

Also, this makes a hardware cursor
always visible in the Xfbdev
(Xorg kdrive) server.

Signed-off-by: Krzysztof Helt <redacted>
CC: Risto Suominen 
---
Finally, I acquired a Mach64GZ card and was able to 
solve this puzzle. It solved the problem Risto described
on my computer.

Risto, please test the patch on your machine. 

 drivers/video/aty/mach64_accel.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/video/aty/mach64_accel.c b/drivers/video/aty/mach64_accel.c
index a8f60c3..0cc9724 100644
--- a/drivers/video/aty/mach64_accel.c
+++ b/drivers/video/aty/mach64_accel.c

@@ -39,7 +39,8 @@ void aty_reset_engine(const struct atyfb_par *par)
 {
 	/* reset engine */
 	aty_st_le32(GEN_TEST_CNTL,
-		aty_ld_le32(GEN_TEST_CNTL, par) & ~GUI_ENGINE_ENABLE, par);
+		aty_ld_le32(GEN_TEST_CNTL, par) &
+		~(GUI_ENGINE_ENABLE | HWCURSOR_ENABLE), par);
 	/* enable engine */
 	aty_st_le32(GEN_TEST_CNTL,
 		aty_ld_le32(GEN_TEST_CNTL, par) | GUI_ENGINE_ENABLE, par);

-- 
1.5.2.2


----------------------------------------------------------------------
Szukasz pieniedzy? Wez podwojny limit zadluzenia w koncie direct.
>> http://link.interia.pl/f20a3


------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com

From: Krzysztof Helt <redacted>

A hardware cursor is left enabled in
the fb_set_par() which is called when
a new console is created. This is
inconsistent with software cursor's
behaviour.

Also, this makes a hardware cursor
always visible in the Xfbdev
(Xorg kdrive) server.

Signed-off-by: Krzysztof Helt <redacted>
Tested-by: Risto Suominen <redacted>
---
Well done, Krzysztof. It solves the problem on my three computers
using the mach64 chip: PowerMac 5500, PowerMac G3 Beige, and a PC with
Mach64 GZ card.

 drivers/video/aty/mach64_accel.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/drivers/video/aty/mach64_accel.c b/drivers/video/aty/mach64_accel.c
index a8f60c3..0cc9724 100644
--- a/drivers/video/aty/mach64_accel.c
+++ b/drivers/video/aty/mach64_accel.c

@@ -39,7 +39,8 @@ void aty_reset_engine(const struct atyfb_par *par)
 {
       /* reset engine */
       aty_st_le32(GEN_TEST_CNTL,
-               aty_ld_le32(GEN_TEST_CNTL, par) & ~GUI_ENGINE_ENABLE, par);
+               aty_ld_le32(GEN_TEST_CNTL, par) &
+               ~(GUI_ENGINE_ENABLE | HWCURSOR_ENABLE), par);
       /* enable engine */
       aty_st_le32(GEN_TEST_CNTL,
               aty_ld_le32(GEN_TEST_CNTL, par) | GUI_ENGINE_ENABLE, par);
--

1.5.2.2