[PATCH][FBCON]: Mode Switch in fbcon_blank()

[PATCH][FBCON]: Mode Switch in fbcon_blank()

[Antonino A. Daplas]

Hi Ben,

As we've discussed in another thread, below is a diff that will do a
set_par() as late as possible when there is KD_TEXT<->KD_GRAPHICS
switch.  The set_par() will be forced in fbcon_resize() instead.

Not sure if this has repercussions with the other drivers, but this patch
fixed the X nv driver hanging when switching to the console. (I believe
the crash is actually caused by an early set_par() -- while in
fbcon_blank. Removing the set_par in fbcon_blank fixed the hang but
caused cursor sprite and display corruption).

What do you think?

Tony

Signed-off-by: Antonino Daplas <adaplas@pol.net>

diff -Naur linux-2.6.7-mm4-orig/drivers/video/console/fbcon.c linux-2.6.7-mm4/drivers/video/console/fbcon.c
--- linux-2.6.7-mm4-orig/drivers/video/console/fbcon.c	2004-06-30 01:45:21.015306888 +0000
+++ linux-2.6.7-mm4/drivers/video/console/fbcon.c	2004-06-30 01:45:58.306637744 +0000
@@ -1679,7 +1679,8 @@
 	var.yres = height * fh;
 	x_diff = info->var.xres - var.xres;
 	y_diff = info->var.yres - var.yres;
-	if (x_diff < 0 || x_diff > fw || (y_diff < 0 || y_diff > fh)) {
+	if (x_diff < 0 || x_diff > fw || (y_diff < 0 || y_diff > fh) ||
+	    (info->flags & FBINFO_MISC_MODESWITCH)) {
 		char mode[40];
 
 		DPRINTK("attempting resize %ix%i\n", var.xres, var.yres);
@@ -1694,9 +1695,12 @@
 			return -EINVAL;
 		DPRINTK("resize now %ix%i\n", var.xres, var.yres);
 		if (CON_IS_VISIBLE(vc)) {
-			var.activate = FB_ACTIVATE_NOW;
+			var.activate = FB_ACTIVATE_NOW |
+				(info->flags & FBINFO_MISC_MODESWITCH) ? 
+				FB_ACTIVATE_FORCE : 0;
 			fb_set_var(info, &var);
 		}
+		info->flags &= ~FBINFO_MISC_MODESWITCH;
 	}
 	updatescrollmode(p, info, vc);
 	return 0;
@@ -1798,17 +1802,8 @@
 	struct fb_info *info = registered_fb[(int) con2fb_map[vc->vc_num]];
 	struct display *p = &fb_display[vc->vc_num];
 
-	if (mode_switch) {
-		struct fb_info *info = registered_fb[(int) con2fb_map[vc->vc_num]];
-		struct fb_var_screeninfo var = info->var;
-
-		if (blank) {
-			fbcon_cursor(vc, CM_ERASE);
-			return 0;
-		}
-		var.activate = FB_ACTIVATE_NOW | FB_ACTIVATE_FORCE;
-		fb_set_var(info, &var);
-	}
+	if (mode_switch)
+		info->flags |= FBINFO_MISC_MODESWITCH;
 
 	fbcon_cursor(vc, blank ? CM_ERASE : CM_DRAW);
 
diff -Naur linux-2.6.7-mm4-orig/include/linux/fb.h linux-2.6.7-mm4/include/linux/fb.h
--- linux-2.6.7-mm4-orig/include/linux/fb.h	2004-06-30 01:47:22.785794960 +0000
+++ linux-2.6.7-mm4/include/linux/fb.h	2004-06-30 01:46:24.799610200 +0000
@@ -532,6 +532,7 @@
 
 #define FBINFO_MISC_MODECHANGEUSER     0x10000 /* mode change request
 						  from userspace */
+#define FBINFO_MISC_MODESWITCH         0x20000 /* mode switch */
 
 struct fb_info {
 	int node;




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: [PATCH][FBCON]: Mode Switch in fbcon_blank()

[Benjamin Herrenschmidt]

On Tue, 2004-06-29 at 21:47, Antonino A. Daplas wrote:
> Hi Ben,
> 
> As we've discussed in another thread, below is a diff that will do a
> set_par() as late as possible when there is KD_TEXT<->KD_GRAPHICS
> switch.  The set_par() will be forced in fbcon_resize() instead.
> 
> Not sure if this has repercussions with the other drivers, but this patch
> fixed the X nv driver hanging when switching to the console. (I believe
> the crash is actually caused by an early set_par() -- while in
> fbcon_blank. Removing the set_par in fbcon_blank fixed the hang but
> caused cursor sprite and display corruption).
> 
> What do you think?

Well... I don't know. It seem to work, so it's probably an acceptable
workaround, but I'd like to find out what's wrong with doing it in blank
precisely (that is what is the bug in XFree or in the kernel VT), since it's
shared by many X drivers, I don't suppose it's a bug in them.

I'll try to find time to toy with this, but I may not have any until after
OLS though....

Ben.




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Telling libSDL that my fbdev can do acclerated fills

[Richard Smith]

I'm working on a app that runs on the STPC Atlas and uses libSDL with 
the stpcfb from STPC.  Kernel 2.4.x. I'm currently using 2.4.23 but any 
of later kernels will work.

The Atlas video accelerator supports hardware assisted fills.  I've been 
looking over the stpcfb code and some of the other framebuffer drivers 
and its not obvious to me how the fb system exports out what kind of 
graphics hardware assisted abilities it has.  Or even how you would call 
those abilities if you knew they were avaiable.

All I see is stuff for text related console work.

The STPC is a pretty slow device and my app needs all the speed help it 
can get. libSDL is currently doing software fills since it dosen't know 
otherwise.

I see in the libSDL source code that the FillHWRect funciton pointer for 
the fb driver is set to NULL as if its not possible to realize hardware 
assisted graphics functions via fbdev.

Is this the case or what am I missing?







-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Telling libSDL that my fbdev can do acclerated fills

[Antonino A. Daplas]

On Wednesday 30 June 2004 11:56, Richard Smith wrote:
> I'm working on a app that runs on the STPC Atlas and uses libSDL with
> the stpcfb from STPC.  Kernel 2.4.x. I'm currently using 2.4.23 but any
> of later kernels will work.
>
> The Atlas video accelerator supports hardware assisted fills.  I've been
> looking over the stpcfb code and some of the other framebuffer drivers
> and its not obvious to me how the fb system exports out what kind of
> graphics hardware assisted abilities it has.  Or even how you would call
> those abilities if you knew they were avaiable.
>
> All I see is stuff for text related console work.
>
> The STPC is a pretty slow device and my app needs all the speed help it
> can get. libSDL is currently doing software fills since it dosen't know
> otherwise.
>
> I see in the libSDL source code that the FillHWRect funciton pointer for
> the fb driver is set to NULL as if its not possible to realize hardware
> assisted graphics functions via fbdev.
>
> Is this the case or what am I missing?
>

All hardware-assisted drawing functions in fbdev are for use by the console
only.  You might want to try DirectFB (www.directfb.org), I believe they have
ported a lot of libs, including SDL.  However, I doubt they have a gfxdriver for
your hardware though.

Tony




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Telling libSDL that my fbdev can do acclerated fills

[Richard Smith]

Antonino A. Daplas wrote:

> 
> All hardware-assisted drawing functions in fbdev are for use by the console
> only.  You might want to try DirectFB (www.directfb.org), I believe they have
> ported a lot of libs, including SDL.  However, I doubt they have a gfxdriver for
> your hardware though.

I'm looking at that now.  Yes they have a SDL driver.  No they don't 
have anything for my hardware.  I'll have to do a port if I want directfb.

The documentation says that it runs on top of the linux framebuffer 
device.  If it runs on top of fbdev but fbdev only does  assisted stuff 
for the console then how does that work?






-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Telling libSDL that my fbdev can do acclerated fills

[Antonino A. Daplas]

On Wednesday 30 June 2004 12:45, Richard Smith wrote:
>
> The documentation says that it runs on top of the linux framebuffer
> device.  If it runs on top of fbdev but fbdev only does  assisted stuff
> for the console then how does that work?

fbdev exports the register space and framebuffer to userspace, DirectFB
uses those to create hardware specific drawing functions via the 
gfxdrivers.

Tony




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: [PATCH][FBCON]: Mode Switch in fbcon_blank()

[Javier Marcet]

Benjamin Herrenschmidt wrote:

>> As we've discussed in another thread, below is a diff that will do a
>> set_par() as late as possible when there is KD_TEXT<->KD_GRAPHICS
>> switch.  The set_par() will be forced in fbcon_resize() instead.

>> Not sure if this has repercussions with the other drivers, but this patch
>> fixed the X nv driver hanging when switching to the console. (I believe
>> the crash is actually caused by an early set_par() -- while in
>> fbcon_blank. Removing the set_par in fbcon_blank fixed the hang but
>> caused cursor sprite and display corruption).

> Well... I don't know. It seem to work, so it's probably an acceptable
> workaround, but I'd like to find out what's wrong with doing it in blank
> precisely (that is what is the bug in XFree or in the kernel VT), since
> it's shared by many X drivers, I don't suppose it's a bug in them.

This was included in 2.6.7-mm5 -that's how I noticed it- and I had to
revert it.

I use radeonfb and when switching from X to console my two monitors will
go out of sync. The VT is actually there since I can type on it, but I
can't see anything on neither of my two monitors :(


-- 

Homer:  Hey, Burns!  Eat my shorts!

Burns:  Who the Sam Hill was that?

                   One Fish, Two Fish, Blowfish, Blue Fish

Javier Marcet <javier@marcet.info>




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Re: [PATCH][FBCON]: Mode Switch in fbcon_blank()

[Antonino A. Daplas]

On Friday 02 July 2004 18:25, Javier Marcet wrote:
> Benjamin Herrenschmidt wrote:
> >> As we've discussed in another thread, below is a diff that will do a
> >> set_par() as late as possible when there is KD_TEXT<->KD_GRAPHICS
> >> switch.  The set_par() will be forced in fbcon_resize() instead.
> >>
> >> Not sure if this has repercussions with the other drivers, but this
> >> patch fixed the X nv driver hanging when switching to the console. (I
> >> believe the crash is actually caused by an early set_par() -- while in
> >> fbcon_blank. Removing the set_par in fbcon_blank fixed the hang but
> >> caused cursor sprite and display corruption).
> >
> > Well... I don't know. It seem to work, so it's probably an acceptable
> > workaround, but I'd like to find out what's wrong with doing it in blank
> > precisely (that is what is the bug in XFree or in the kernel VT), since
> > it's shared by many X drivers, I don't suppose it's a bug in them.
>
> This was included in 2.6.7-mm5 -that's how I noticed it- and I had to
> revert it.
>
> I use radeonfb and when switching from X to console my two monitors will
> go out of sync. The VT is actually there since I can type on it, but I
> can't see anything on neither of my two monitors :(

Grr, I was a little tentative about this patch, hoping against hope that it
will work for all drivers, but you've proven me wrong.  Anyway, we now have
at least 2 drivers that requires reinitialization at different stages, radeonfb
requires it at fbcon_blank() and rivafb at fbcon_switch().  And I really don't
know how to fix it except to look closely at X (and I dread looking at X's code...)
and the VT code (ditto).

Can you try the patch below?  It works for the rivafb, hopefully it works for yours.

Andrew,

This patch is ugly as sin but I can't find a good solution without hacking X or
the vt system.  I've included a big fat comment describing the ugliness.

Tony

Signed-off-by: Antonino Daplas <adaplas@pol.net>

Ugly workaround.  When switching from KD_GRAPHICS to KD_TEXT, the 
event is captured at fbcon_blank() allowing fbcon to reinitialize the hardware.
However, some hardware requires the reinitialization to be done immediately,
others require it to be done later.  Others may need it to be done immediately
and later, this is the worst case. 

diff -Naur linux-2.6.7-mm5-orig/drivers/video/console/fbcon.c linux-2.6.7-mm5/drivers/video/console/fbcon.c
--- linux-2.6.7-mm5-orig/drivers/video/console/fbcon.c	2004-07-02 15:09:02.132667752 +0000
+++ linux-2.6.7-mm5/drivers/video/console/fbcon.c	2004-07-02 15:12:29.935076984 +0000
@@ -1802,8 +1802,31 @@
 	struct fb_info *info = registered_fb[(int) con2fb_map[vc->vc_num]];
 	struct display *p = &fb_display[vc->vc_num];
 
-	if (mode_switch)
-		info->flags |= FBINFO_MISC_MODESWITCH;
+	if (mode_switch) {
+		struct fb_var_screeninfo var = info->var;
+
+/* 
+ * HACK ALERT: Some hardware will require reinitializion at this stage,
+ *             others will require it to be done as late as possible.
+ *             For now, we differentiate this with the 
+ *             FBINFO_MISC_MODESWITCHLATE bitflag.  Worst case will be
+ *             hardware that requires it here and another one later.
+ *             A definitive solution may require fixing X or the VT
+ *             system.
+ */
+		if (info->flags & FBINFO_MISC_MODESWITCHLATE)
+			info->flags |= FBINFO_MISC_MODESWITCH;
+
+		if (blank) {
+		    fbcon_cursor(vc, CM_ERASE);
+		    return 0;
+		}
+
+		if (!(info->flags & FBINFO_MISC_MODESWITCHLATE)) {
+			var.activate = FB_ACTIVATE_NOW | FB_ACTIVATE_FORCE;
+			fb_set_var(info, &var);
+		}
+	}
 
 	fbcon_cursor(vc, blank ? CM_ERASE : CM_DRAW);
 
diff -Naur linux-2.6.7-mm5-orig/drivers/video/riva/fbdev.c linux-2.6.7-mm5/drivers/video/riva/fbdev.c
--- linux-2.6.7-mm5-orig/drivers/video/riva/fbdev.c	2004-07-02 15:08:39.130164664 +0000
+++ linux-2.6.7-mm5/drivers/video/riva/fbdev.c	2004-07-02 15:12:27.322474160 +0000
@@ -1681,7 +1681,8 @@
 		    | FBINFO_HWACCEL_YPAN
 		    | FBINFO_HWACCEL_COPYAREA
 		    | FBINFO_HWACCEL_FILLRECT
-		    | FBINFO_HWACCEL_IMAGEBLIT;
+		    | FBINFO_HWACCEL_IMAGEBLIT
+	            | FBINFO_MISC_MODESWITCHLATE;
 	info->var = rivafb_default_var;
 	info->fix.visual = (info->var.bits_per_pixel == 8) ?
 				FB_VISUAL_PSEUDOCOLOR : FB_VISUAL_DIRECTCOLOR;
diff -Naur linux-2.6.7-mm5-orig/include/linux/fb.h linux-2.6.7-mm5/include/linux/fb.h
--- linux-2.6.7-mm5-orig/include/linux/fb.h	2004-07-02 15:09:17.062398088 +0000
+++ linux-2.6.7-mm5/include/linux/fb.h	2004-07-02 15:12:31.318866616 +0000
@@ -533,6 +533,7 @@
 #define FBINFO_MISC_MODECHANGEUSER     0x10000 /* mode change request
 						  from userspace */
 #define FBINFO_MISC_MODESWITCH         0x20000 /* mode switch */
+#define FBINFO_MISC_MODESWITCHLATE     0x40000 /* init hardware later */
 
 struct fb_info {
 	int node;
 




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: [PATCH][FBCON]: Mode Switch in fbcon_blank()

[Javier Marcet]

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

* Antonino A. Daplas <adaplas@hotpop.com> [040702 17:36]:

>> > Well... I don't know. It seem to work, so it's probably an acceptable
>> > workaround, but I'd like to find out what's wrong with doing it in blank
>> > precisely (that is what is the bug in XFree or in the kernel VT), since
>> > it's shared by many X drivers, I don't suppose it's a bug in them.

>> This was included in 2.6.7-mm5 -that's how I noticed it- and I had to
>> revert it.

>> I use radeonfb and when switching from X to console my two monitors will
>> go out of sync. The VT is actually there since I can type on it, but I
>> can't see anything on neither of my two monitors :(

>Grr, I was a little tentative about this patch, hoping against hope that it
>will work for all drivers, but you've proven me wrong.  Anyway, we now have
>at least 2 drivers that requires reinitialization at different stages, radeonfb
>requires it at fbcon_blank() and rivafb at fbcon_switch().  And I really don't
>know how to fix it except to look closely at X (and I dread looking at X's code...)
>and the VT code (ditto).

>Can you try the patch below?  It works for the rivafb, hopefully it works for yours.

Hi Antonio,
sorry for not answering sooner, I thought I had done before leaving to
work.
Well, with this patch in addition to your original one, it works right
again with my radeon frame buffer & X :)

For me it's fine. Thanks for your help ;-)

If I can be of any help, trying further patches or whatever, please ask.


-- 
If A equals success, then the formula is _\bA = _\bX + _\bY + _\bZ.  _\bX is work.  _\bY
is play.  _\bZ is keep your mouth shut.
s		-- Albert Einstein

Javier Marcet <javier@marcet.info>

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

[PATCH] radeonfb: mode switch work around

[David Eger]

Here's the fix for radeonfb for use with your patch.

-dte

diff -Nru a/drivers/video/aty/radeon_base.c b/drivers/video/aty/radeon_base.c
--- a/drivers/video/aty/radeon_base.c	2004-06-28 02:28:36 +02:00
+++ b/drivers/video/aty/radeon_base.c	2004-07-04 01:50:23 +02:00
@@ -1793,7 +1793,8 @@
 		    | FBINFO_HWACCEL_COPYAREA
 		    | FBINFO_HWACCEL_FILLRECT
 		    | FBINFO_HWACCEL_XPAN
-		    | FBINFO_HWACCEL_YPAN;
+		    | FBINFO_HWACCEL_YPAN
+		    | FBINFO_MISC_MODESWITCHLATE;
 	info->fbops = &radeonfb_ops;
 	info->screen_base = (char *)rinfo->fb_base;
 


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: [PATCH] radeonfb: mode switch work around

[David Eger]

On Sat, Jul 03, 2004 at 08:05:18PM -0400, David Eger wrote:
> Here's the fix for radeonfb for use with your patch.
> 
> -dte

On second look, strike that.  I have general badness trying to 
switch out of X in recent kernels to radeonfb.  Grr..  I'm not
having luck pinpointing what went wrong just yet.

-dte


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: [PATCH] radeonfb: mode switch work around

[Antonino A. Daplas]

On Sunday 04 July 2004 08:46, David Eger wrote:
> On Sat, Jul 03, 2004 at 08:05:18PM -0400, David Eger wrote:
> > Here's the fix for radeonfb for use with your patch.
> >
> > -dte
>
> On second look, strike that.  I have general badness trying to
> switch out of X in recent kernels to radeonfb.  Grr..  I'm not
> having luck pinpointing what went wrong just yet.
>

Maybe your hardware is one that requires a set_par() in both fbcon_blank()
and fbcon_switch(), the worst case scenario....?  If that's the case, we need
another flag (and another ugyly workaround).

Tony




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: [PATCH] radeonfb: mode switch work around

[David Eger]

On Sun, Jul 04, 2004 at 09:00:41AM +0800, Antonino A. Daplas wrote:
> On Sunday 04 July 2004 08:46, David Eger wrote:
> > 
> > > Here's the fix for radeonfb for use with your patch.
> >
> > On second look, strike that.  I have general badness trying to
> > switch out of X in recent kernels to radeonfb.  Grr..  I'm not
> > having luck pinpointing what went wrong just yet.
> 
> Maybe your hardware is one that requires a set_par() in both fbcon_blank()
> and fbcon_switch(), the worst case scenario....?  If that's the case, we need
> another flag (and another ugyly workaround).

Actually, I'm trying older kernels that I'm sure didn't have this problem
(2.6.6) and I'm thinking instead the bad X->VT switch is due to the X.Org 
code.  I recently switched from XFree...  hrmmm :-(

I hate to uninstall/reinstall X again just to test  (I run gentoo... good god)

-Unhappy David


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: [PATCH] radeonfb: mode switch work around

[Jon Smirl]

I have noticed this too. I don't think it is specific to x.org. My best
guess is that the X server is mucking with the VGA registers on the
radeon card.

Try this experiment...
modprobe radeonfb from a VT, then switch to an xterm and rmmod it.
Try it the other way to, modprobe from xterm and rmmod from VT.
Both of those result in a reboot on my machine.

The problem seems to be with radeonfb snap shotting the register state
when it loads, and then restoring it when it unloads. But the VT/xterm
pair causes the retored registers to be set to the wrong values.

This saved register state is also used in other places. These other
uses may be the source of the problem you see. If I remember right, X
is also saving a snap shot of the initial register values.

--- David Eger <eger@havoc.gtf.org> wrote:
> On Sun, Jul 04, 2004 at 09:00:41AM +0800, Antonino A. Daplas wrote:
> > On Sunday 04 July 2004 08:46, David Eger wrote:
> > > 
> > > > Here's the fix for radeonfb for use with your patch.
> > >
> > > On second look, strike that.  I have general badness trying to
> > > switch out of X in recent kernels to radeonfb.  Grr..  I'm not
> > > having luck pinpointing what went wrong just yet.


=====
Jon Smirl
jonsmirl@yahoo.com


		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: [PATCH] radeonfb: mode switch work around

[Geert Uytterhoeven]

On Sat, 3 Jul 2004, Jon Smirl wrote:
> Try this experiment...
> modprobe radeonfb from a VT, then switch to an xterm and rmmod it.
> Try it the other way to, modprobe from xterm and rmmod from VT.
> Both of those result in a reboot on my machine.

I would say modprobing any fbdev while X is already playing with the same
hardware is unsafe...

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 sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: [PATCH] radeonfb: mode switch work around

[David Eger]

Nevermind the patch I sent.  I tracked down my X->VT issue to 
my xorg.conf file.  It was missing the line

    Option          "UseFBDev"

Tony, your patch (the one with the big HACK ALERT sticker on it) 
 seems to give radeon the mode switch call when it is needed.

-dte


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Re: [PATCH][FBCON]: Mode Switch in fbcon_blank()

[Antonino A. Daplas]

On Friday 02 July 2004 18:25, Javier Marcet wrote:
> Benjamin Herrenschmidt wrote:
> >> As we've discussed in another thread, below is a diff that will do a
> >> set_par() as late as possible when there is KD_TEXT<->KD_GRAPHICS
> >> switch.  The set_par() will be forced in fbcon_resize() instead.
> >>
> >> Not sure if this has repercussions with the other drivers, but this
> >> patch fixed the X nv driver hanging when switching to the console. (I
> >> believe the crash is actually caused by an early set_par() -- while in
> >> fbcon_blank. Removing the set_par in fbcon_blank fixed the hang but
> >> caused cursor sprite and display corruption).
> >
> > Well... I don't know. It seem to work, so it's probably an acceptable
> > workaround, but I'd like to find out what's wrong with doing it in blank
> > precisely (that is what is the bug in XFree or in the kernel VT), since
> > it's shared by many X drivers, I don't suppose it's a bug in them.
>
> This was included in 2.6.7-mm5 -that's how I noticed it- and I had to
> revert it.
>
> I use radeonfb and when switching from X to console my two monitors will
> go out of sync. The VT is actually there since I can type on it, but I
> can't see anything on neither of my two monitors :(

Jurriaan's problem told me that I'm probably over-engineering the mode switch
code. Perhaps the ugly workaround patch is not necessary.  All that is needed
is to bypass fbcon_resize() and just do a simple set_par().

David, Javier, can you try the patch below?  Reverse the one with the big
HACK ALERT comment first.  If it works for you two, the code just became
simpler.

Tony

Signed-off-by: Antonino A. Daplas <adaplas@pol.net>

diff -Naur linux-2.6.7-mm5-orig/drivers/video/console/fbcon.c linux-2.6.7-mm5/drivers/video/console/fbcon.c
--- linux-2.6.7-mm5-orig/drivers/video/console/fbcon.c	2004-07-04 23:34:29.873322872 +0800
+++ linux-2.6.7-mm5/drivers/video/console/fbcon.c	2004-07-04 23:36:18.169859296 +0800
@@ -1679,8 +1679,7 @@
 	var.yres = height * fh;
 	x_diff = info->var.xres - var.xres;
 	y_diff = info->var.yres - var.yres;
-	if (x_diff < 0 || x_diff > fw || (y_diff < 0 || y_diff > fh) ||
-	    (info->flags & FBINFO_MISC_MODESWITCH)) {
+	if (x_diff < 0 || x_diff > fw || (y_diff < 0 || y_diff > fh)) {
 		char mode[40];
 
 		DPRINTK("attempting resize %ix%i\n", var.xres, var.yres);
@@ -1695,12 +1694,9 @@
 			return -EINVAL;
 		DPRINTK("resize now %ix%i\n", var.xres, var.yres);
 		if (CON_IS_VISIBLE(vc)) {
-			var.activate = FB_ACTIVATE_NOW |
-				(info->flags & FBINFO_MISC_MODESWITCH) ?
-				FB_ACTIVATE_FORCE : 0;
+			var.activate = FB_ACTIVATE_NOW;
 			fb_set_var(info, &var);
 		}
-		info->flags &= ~FBINFO_MISC_MODESWITCH;
 	}
 	updatescrollmode(p, info, vc);
 	return 0;
@@ -1752,6 +1748,13 @@
 	}
 
  	fbcon_resize(vc, vc->vc_cols, vc->vc_rows);
+
+	if (info->flags & FBINFO_MISC_MODESWITCH &&
+		info->fbops->fb_set_par) {
+		info->fbops->fb_set_par(info);
+	}
+	info->flags &= ~FBINFO_MISC_MODESWITCH;
+
 	switch (p->scrollmode) {
 	case SCROLL_WRAP:
 		scrollback_phys_max = p->vrows - vc->vc_rows;





-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Re: [PATCH][FBCON]: Mode Switch in fbcon_blank()

[David Eger]

On Sun, Jul 04, 2004 at 11:47:46PM +0800, Antonino A. Daplas wrote:
> On Friday 02 July 2004 18:25, Javier Marcet wrote:
> > I use radeonfb and when switching from X to console my two monitors will
> > go out of sync. The VT is actually there since I can type on it, but I
> > can't see anything on neither of my two monitors :(
> 
> Jurriaan's problem told me that I'm probably over-engineering the mode switch
> code. Perhaps the ugly workaround patch is not necessary.  All that is needed
> is to bypass fbcon_resize() and just do a simple set_par().
> 
> David, Javier, can you try the patch below?  Reverse the one with the big
> HACK ALERT comment first.  If it works for you two, the code just became
> simpler.
> 
> Tony

With this patch, X won't even get to the point of showing an X cursor :-(

-dte


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com

Re: Re: [PATCH][FBCON]: Mode Switch in fbcon_blank()

[Antonino A. Daplas]

On Monday 05 July 2004 03:32, David Eger wrote:
> On Sun, Jul 04, 2004 at 11:47:46PM +0800, Antonino A. Daplas wrote:
> > On Friday 02 July 2004 18:25, Javier Marcet wrote:
> > > I use radeonfb and when switching from X to console my two monitors
> > > will go out of sync. The VT is actually there since I can type on it,
> > > but I can't see anything on neither of my two monitors :(
> >
> > Jurriaan's problem told me that I'm probably over-engineering the mode
> > switch code. Perhaps the ugly workaround patch is not necessary.  All
> > that is needed is to bypass fbcon_resize() and just do a simple
> > set_par().
> >
> > David, Javier, can you try the patch below?  Reverse the one with the big
> > HACK ALERT comment first.  If it works for you two, the code just became
> > simpler.
> >
> > Tony
>
> With this patch, X won't even get to the point of showing an X cursor :-(
>

Ok, so the hack is really needed.  Forget the patch then. 

Thanks

Tony




-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com