Menu
▾
▴
linux-fbdev-devel
|
From: Antonino D. <ad...@po...> - 2003-03-08 05:40:10
|
On Sat, 2003-03-08 at 08:58, Antonino Daplas wrote:
> On Sat, 2003-03-08 at 04:51, Thomas Winischhofer wrote:
> > I don't see why this is simpler, but I do see it wastes a lot of screen
> > space :)
> >
>
> yep, it'a a typo.
>
> Tony
>
> diff -Naur linux-2.5.64-fbdev/drivers/video/console/fbcon.c linux-2.5.64/drivers/video/console/fbcon.c
> --- linux-2.5.64-fbdev/drivers/video/console/fbcon.c 2003-03-07 15:03:06.000000000 +0000
> +++ linux-2.5.64/drivers/video/console/fbcon.c 2003-03-08 00:49:09.000000000 +0000
> @@ -1044,6 +1044,7 @@
> vc->vc_rows = nr_rows;
> }
> p->vrows = info->var.yres_virtual / vc->vc_font.height;
> + p->vrows -= info->var.yres/h - vc->vc_rows;
^^^^^^^^^^^^^^^^
I also meant info->var.yres/vc->vc_font.height :-)
Tony
|
|
From: Thomas W. <th...@wi...> - 2003-03-08 14:11:51
|
Antonino Daplas wrote: >> p->vrows = info->var.yres_virtual / vc->vc_font.height; >>+ p->vrows -= info->var.yres/h - vc->vc_rows; > > ^^^^^^^^^^^^^^^^ > > I also meant info->var.yres/vc->vc_font.height :-) Tony, Both ways it works, granted. But I still don't see the advantage of your solution over mine. Your's wastes an area of the size of a whole screen. Certainly no offence, but can you explain why you think this is better? Thomas -- Thomas Winischhofer Vienna/Austria mailto:th...@wi... *** http://www.winischhofer.net |
|
From: Thomas W. <th...@wi...> - 2003-03-08 14:19:52
|
Continued: What happens with your solution of the virtual area is only 1.5 times the size of the visible area? Did your check this? >> p->vrows = info->var.yres_virtual / vc->vc_font.height; >>+ p->vrows -= info->var.yres/vc->vc_font.height - vc->vc_rows; yres = 768 yres_virtual = 1152 fontheight= 16 rows = 48 vrows = 1152 / 16 = 72 72 - (768 / 16) - 48 = -24 :) Any question? Thomas Antonino Daplas wrote: > On Sat, 2003-03-08 at 08:58, Antonino Daplas wrote: > >>On Sat, 2003-03-08 at 04:51, Thomas Winischhofer wrote: >> >>>I don't see why this is simpler, but I do see it wastes a lot of screen >>>space :) >>> >> >>yep, it'a a typo. >> >>Tony >> >>diff -Naur linux-2.5.64-fbdev/drivers/video/console/fbcon.c linux-2.5.64/drivers/video/console/fbcon.c >>--- linux-2.5.64-fbdev/drivers/video/console/fbcon.c 2003-03-07 15:03:06.000000000 +0000 >>+++ linux-2.5.64/drivers/video/console/fbcon.c 2003-03-08 00:49:09.000000000 +0000 >>@@ -1044,6 +1044,7 @@ >> vc->vc_rows = nr_rows; >> } >> p->vrows = info->var.yres_virtual / vc->vc_font.height; >>+ p->vrows -= info->var.yres/h - vc->vc_rows; > > ^^^^^^^^^^^^^^^^ > > I also meant info->var.yres/vc->vc_font.height :-) > > Tony > > > -- Thomas Winischhofer Vienna/Austria mailto:th...@wi... *** http://www.winischhofer.net |
|
From: Antonino D. <ad...@po...> - 2003-03-08 22:03:46
|
On Sat, 2003-03-08 at 22:20, Thomas Winischhofer wrote:
>
>
> Continued: What happens with your solution of the virtual area is only
> 1.5 times the size of the visible area? Did your check this?
>
> >> p->vrows = info->var.yres_virtual / vc->vc_font.height;
> >>+ p->vrows -= info->var.yres/vc->vc_font.height - vc->vc_rows;
>
> yres = 768
> yres_virtual = 1152
> fontheight= 16
> rows = 48
>
> vrows = 1152 / 16 = 72
> 72 - (768 / 16) - 48 = -24
>
> :) Any question?
>
Why?
Your example - 1024x768, yres_virtual = 1152, font = 8x16
2 cases:
1. full screeen console
vc->vc_rows = 48
p->vrows = 72 - (768/16 - 48)
p->vrows = 72 - 0
p->vrows = 72
2. half-height console:
vc->vc_rows = 24
p->vrows = 1152 - (768/16 - 24)
p->vrows = 72 - 24
p->vrows = 48
Second case, 24 rows are wasted, why? See accel_clear_margins:
ch = vc->vc_font_height
bh = yres - (vc->vc_rows * ch)
bh = 768 - (24 * 16)
bh = 768 - 384
bh = 384
This means that a rectangle of height 384 scanlines (_always_) at the
bottom of the display will be cleared . If you pan to the end of
graphics memory, attempting to clear from yres_virtual + 384 will cause
the chipset to crash. But it won't because we reserved 24 rows (384
pixels) to accomodate this.
For the clincher, this is your code:
if(info->var.yres > (vc->vc_font.height * (vc->vc_rows + 1))) {
p->vrows -= (info->var.yres - (vc->vc_font.height *
vc->vc_rows)) / vc->vc_font.height;
}
Simplifying the second line....
p->vrows -= (info->var.yres/vc->vc_font.height) - (vc->vc_font.height *
vc->vc_rows)/vc->vc_font.height;
p->vrows -= info->var.yres/vc->vc_font.height - vc->vc_rows;
Do you recognize the last line? Yep, it's mine. It's also simpler (1
division and 1 subtraction vs 1 division, 1 multiplication and 1
subtraction).
Code correctness was never the issue. The only thing I'm questioning is
using info->var.yres instead of var.yres, and I have explained this
enough times already.
Granted, the patch I submitted was a quickwrite, never meant to be
applied but serves only to illustrate. This is a more proper patch,
applied against James latest fbdev.diff. It simplifies the equation,
remove the unnecessary 'if' conditional. Apply it, don't apply it, I
don't care.
Tony
diff -Naur linux-2.5.64-fbdev/drivers/video/console/fbcon.c linux-2.5.64/drivers/video/console/fbcon.c
--- linux-2.5.64-fbdev/drivers/video/console/fbcon.c 2003-03-08 21:33:25.000000000 +0000
+++ linux-2.5.64/drivers/video/console/fbcon.c 2003-03-08 21:47:26.000000000 +0000
@@ -1044,9 +1044,7 @@
vc->vc_rows = nr_rows;
}
p->vrows = info->var.yres_virtual / vc->vc_font.height;
- if(info->var.yres > (vc->vc_font.height * (vc->vc_rows + 1))) {
- p->vrows -= (info->var.yres - (vc->vc_font.height * vc->vc_rows)) / vc->vc_font.height;
- }
+ p->vrows -= info->var.yres/vc->vc_font.height - vc->vc_rows;
if ((info->var.yres % vc->vc_font.height) &&
(info->var.yres_virtual % vc->vc_font.height <
info->var.yres % vc->vc_font.height))
@@ -1825,9 +1823,8 @@
var.activate = FB_ACTIVATE_NOW;
fb_set_var(&var, info);
}
- p->vrows = var.yres_virtual/fh;
- if(var.yres > (fh * (height + 1)))
- p->vrows -= (var.yres - (fh * height)) / fh;
+ p->vrows = info->var.yres_virtual/fh;
+ p->vrows -= (info->var.yres + (fh - 1))/fh - height;
return 0;
}
@@ -2099,11 +2096,7 @@
/* reset wrap/pan */
info->var.xoffset = info->var.yoffset = p->yscroll = 0;
p->vrows = info->var.yres_virtual / h;
-
-#if 0 /* INCOMPLETE - let the console gurus handle this */
- if(info->var.yres > (h * (vc->vc_rows + 1))
- p->vrows -= (info->var.yres - (h * vc->vc_rows)) / h;
-#endif
+ p->vrows -= info->var.yres/h - vc->vc_rows;
if ((info->var.yres % h)
&& (info->var.yres_virtual % h < info->var.yres % h))
p->vrows--;
|
|
From: Thomas W. <th...@wi...> - 2003-03-07 17:34:18
|
Antonino Daplas wrote: > Right, fbcon never dealt with margins greater than a character > width/height before :-). I think your patch will do the Right Thing. I hope so :) But please think it through, I have no idea about the possible impacts of this. > As for the one you commented out as INCOMPLETE, my guess is it won't > matter since that particular section of code is called only during > initialization. An fbcon_switch() will be called later on, I think. No idea, but ... you're the expert! >>Why you used info->var.yres_virtual (and not the adapted >>var.yres_virtual) in fbcon_resize() is beyond me, BTW. > > Because info->var will _always_ contain the correct var, so we trust > that above all. Then I must have misunderstood the code. You submit var (and not info->var) to fb_set_var, so it is that var that will be treated by check_var and used for set_par. Since check_var() may (and does) change the yres_virtual according to the desired resolution/depth and so on, I thought it might be more correct to use it instead of info->var... I have in the meantime submitted a new sisfb patch to James; it depends, however, on the changes to fbcon we are discussing now (especially the fbcon_resize thing which is too intolerant in James' current code base). Otherwise, mode switches using stty won't work. Thomas -- Thomas Winischhofer Vienna/Austria mailto:th...@wi... http://www.winischhofer.net/ |
|
From: Antonino D. <ad...@po...> - 2003-03-07 17:42:04
|
On Sat, 2003-03-08 at 01:00, Thomas Winischhofer wrote: > >>Why you used info->var.yres_virtual (and not the adapted > >>var.yres_virtual) in fbcon_resize() is beyond me, BTW. > > > > Because info->var will _always_ contain the correct var, so we trust > > that above all. > > Then I must have misunderstood the code. You submit var (and not > info->var) to fb_set_var, so it is that var that will be treated by > check_var and used for set_par. Since check_var() may (and does) change > the yres_virtual according to the desired resolution/depth and so on, I > thought it might be more correct to use it instead of info->var... > Note that fbcon_resize made a copy of info->var, then modified it according to the requested width and height. Then it goes through a test if it needs an fb_set_var or not. So info->var and the modified var can be different if fb_set_var() wasn't called at all. If it indeed went through fb_set_var(), the var returned from check_var() will be placed automatically to info->var before calling set_par(). So, yes, in this case, info->var and the adjusted var will be the same. Of course, in this particular code it is not important whichever var is used because we're only interested in yres_virtual. But using info->var instead of the adjusted var is safer because it is guaranteed to be always correct. BTW: I'll check the patch against vesafb and let you know. Tony |
|
From: Thomas W. <th...@wi...> - 2003-03-09 04:23:56
|
Antonino, > Your example - 1024x768, yres_virtual = 1152, font = 8x16 > > 2 cases: > > 1. full screeen console > vc->vc_rows = 48 > > p->vrows = 72 - (768/16 - 48) > p->vrows = 72 - 0 > p->vrows = 72 You're right. I made a mistake in my calculation. > Granted, the patch I submitted was a quickwrite, never meant to be > applied but serves only to illustrate. This is a more proper patch, > applied against James latest fbdev.diff. It simplifies the equation, > remove the unnecessary 'if' conditional. Apply it, don't apply it, I > don't care. That's not up to me to decide. For me, the only thing that counts is that the console can deal with text areas that are smaller than the screen resolution. Besides, your last sentence was certainly not neccessary. You among friends here. Thomas -- Thomas Winischhofer Vienna/Austria mailto:th...@wi... *** http://www.winischhofer.net |
|
From: Antonino D. <ad...@po...> - 2003-03-09 06:19:56
|
On Sun, 2003-03-09 at 11:47, Thomas Winischhofer wrote: > > > Granted, the patch I submitted was a quickwrite, never meant to be > > applied but serves only to illustrate. This is a more proper patch, > > applied against James latest fbdev.diff. It simplifies the equation, > > remove the unnecessary 'if' conditional. Apply it, don't apply it, I > > don't care. > > That's not up to me to decide. For me, the only thing that counts is > that the console can deal with text areas that are smaller than the > screen resolution. Besides, your last sentence was certainly not > neccessary. You among friends here. > My apologies if I sounded too harsh, no offense was intended. I just meant that your code and mine achieves the same and (hopefully) correct results And because the code is in a non-performance critical section, I don't care whichever is used (except for the var->yres and info->var.yres issue). If the code affects a critical section (blitting, character painting, etc), of course, that's another story. Tony |
|
From: James S. <jsi...@in...> - 2003-03-11 16:09:27
|
> However, the brokenness is really on the driver side. They are unable > to change the video mode unless they are supplied with the correct > timing parameters where in fact they actually have the best knowledge on > how to calculate them. > > So the question: Do we let fbcon spoonfeed the timings to fbdev, or do > we let the drivers calculate it for themselves? I go for the latter, as > fbcon really should not have any business with hardware. I agree. |
|
From: Thomas W. <th...@wi...> - 2003-03-11 21:04:26
|
James Simmons wrote: >>However, the brokenness is really on the driver side. They are unable >>to change the video mode unless they are supplied with the correct >>timing parameters where in fact they actually have the best knowledge on >>how to calculate them. >> >>So the question: Do we let fbcon spoonfeed the timings to fbdev, or do >>we let the drivers calculate it for themselves? I go for the latter, as >>fbcon really should not have any business with hardware. > > > I agree. Me Too(tm). SiSfb (sorry for mentioning this one over and over, but that's the only one I am working on) does that now, according to the following assumptions: If old_x == new_x && old_y == new_y && old_clock == new_clock -> assume a change in depth, hence recalculate the clock based on the htotal and vtotal values (which are calculated using var's horizontal and vertical timing. else if (old_x != new_x || old_y != new_y) && old_clock == new_clock -> assume a mode change originating from fbcon_resize (where only xres and yres are changed, everything else left unchanged; hence, use the default clock (user selectable) because clock is invalid. else if(timings are valid) -> use these timings, they originate from an application using the framebuffer device properly (directFB, for instance) else -> use default clock Works perfectly. Tested all possible applications (mplayer, sdl stuff, etc), no problems. Thomas -- Thomas Winischhofer Vienna/Austria mailto:th...@wi... *** http://www.winischhofer.net |
|
From: Sven L. <lu...@dp...> - 2003-03-06 11:41:28
|
On Thu, Mar 06, 2003 at 06:51:58PM +0800, Antonino Daplas wrote: > On Thu, 2003-03-06 at 18:48, Antonino Daplas wrote: > > On Thu, 2003-03-06 at 18:31, Sven Luther wrote: > > > On Thu, Mar 06, 2003 at 06:05:37PM +0800, Antonino Daplas wrote: > > > > Yes, there is. Using the "stale" pixelclock, htotal and vtotal, > > > > calculate hsync and vsync. Compare this with your monitor's limit -- if > > > > any fall outside, the entire mode, pixelclock and all is not valid. > > > > > > > > (see fb_get_mode() and fb_validate_mode() in fbmon.c) > > > > > > > > And if you use very narrow vsync and hsync ranges, then the "stale" > > > > pixelclock will always most certainly be invalid. > > > > > > BTW, do we have an easy way of knowing if it is an LCD or analog monitor > > > which is attached to the card (or even a TV) ? I think the radeonfb > > > knows how to do this, not sure though. > > > > > > > There's an EDID parser in fbmon.c. I think it will work only for the > > PPC. This is currently used by rivafb and radeonfb. For the rest, either Mmm, is it because the EDID parser uses the EDID information pased by the OF ? > > we implement DDC or just have something similar to XF86Config's > > HorizSync and VertRefresh. We can load this either as a kernel/module > > option or passed via ioctl/sysfs. Most monitors today have DDC support, so i guess best would be to use it, and fall back to a command line option if DDC is not supported. > > I'm already doing this with the i810fb (as boot/module option), which > > greatly simplified mode switching. > > Oops, totally missed your question :-) But yes, I think the EDID block > contains information about the monitor type, not sure thogh. X finds : Digital Display Input So, i guess this is it. Friendly, Sven Luther |
|
From: Antonino D. <ad...@po...> - 2003-03-06 13:24:06
|
On Thu, 2003-03-06 at 19:40, Sven Luther wrote: > > > > > > There's an EDID parser in fbmon.c. I think it will work only for the > > > PPC. This is currently used by rivafb and radeonfb. For the rest, either > > Mmm, is it because the EDID parser uses the EDID information pased by > the OF ? > Yes. Tony |
|
From: James S. <jsi...@in...> - 2003-03-06 15:27:08
|
> > Oops, totally missed your question :-) But yes, I think the EDID block > > contains information about the monitor type, not sure thogh. > > X finds : > > Digital Display Input > > So, i guess this is it. Yes the EDID block does have info on the monitor type. It even has the vendor name. I wonder if it can detect when you unplug a monitor and plug in a new one? |
|
From: James S. <jsi...@in...> - 2003-03-05 19:17:21
|
> > Well, this assumes that the user always want the best refresh rate, > > which is not desired in all cases. > > > > fb_get_mode() accepts 4 flags. Maximum refresh rate, hscan-driven, > vrefresh-driven and dotclock-driven calculations. It's flexible enough, > but of course not as flexible as specifying your own modeline. Things like pixclock rates can be changes by fbset and fbcon still sees these changes. stty is for the basic changes and fbset for advance changes. On a personal note. Many fbdev drivers in 2.4.X where also broken in that only the boot mode worked. This is where the fbset mode database in userland hack came in (/etc/fb.modes). This is horriable. Even with that userland database I often couldn't change video modes after booting. We should split the monitor programing stuff out from stuff like bpp etc. Now if you think about it we can do things like change the bpp without having to redo the monitor programming. This is the flaw with the old and even the new api. |
|
From: Geert U. <ge...@li...> - 2003-03-05 19:32:22
|
On Wed, 5 Mar 2003, James Simmons wrote:
> On a personal note. Many fbdev drivers in 2.4.X where also broken in that
> only the boot mode worked. This is where the fbset mode database in
> userland hack came in (/etc/fb.modes). This is horriable. Even with that
Do you remember how modes were set before the existence of fbset? I guess not
:-)
A driver could support up to 31 modes (cfr. the old minors). You changed mode
by touch'ing the /dev/fb0my_favorite_mode special device that corresponded to
the mode you wanted.
> userland database I often couldn't change video modes after booting.
Ugh, those are serious driver bugs....
> We should split the monitor programing stuff out from stuff like bpp etc.
> Now if you think about it we can do things like change the bpp without
> having to redo the monitor programming. This is the flaw with the old and
> even the new api.
You could have done that from the beginning. Just look at which fields have
changed and which haven't.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
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
|
|
From: James S. <jsi...@in...> - 2003-03-05 19:35:37
|
> Do you remember how modes were set before the existence of fbset? I guess not > :-) before my time. > A driver could support up to 31 modes (cfr. the old minors). You changed mode > by touch'ing the /dev/fb0my_favorite_mode special device that corresponded to > the mode you wanted. Yuck!!!! > > userland database I often couldn't change video modes after booting. > > Ugh, those are serious driver bugs.... So the arrgument that fbset is the solution to all problems is bogus IMO. > > We should split the monitor programing stuff out from stuff like bpp etc. > > Now if you think about it we can do things like change the bpp without > > having to redo the monitor programming. This is the flaw with the old and > > even the new api. > > You could have done that from the beginning. Just look at which fields have > changed and which haven't. I should of but didn't because I knew driver would take teh path of lest resistance to port there drivers. TO much change would have made the current situtation much much worst. |
|
From: Thomas W. <th...@wi...> - 2003-03-05 22:12:40
|
James Simmons wrote: >>>We should split the monitor programing stuff out from stuff like bpp etc. >>>Now if you think about it we can do things like change the bpp without >>>having to redo the monitor programming. This is the flaw with the old and >>>even the new api. >> >>You could have done that from the beginning. Just look at which fields have >>changed and which haven't. > > > I should of but didn't because I knew driver would take teh path of lest > resistance to port there drivers. TO much change would have made the > current situtation much much worst. One could argue that changing stuff more or less constantly does not make it any easier to keep up with a working driver.... :) Thomas -- Thomas Winischhofer Vienna/Austria mailto:th...@wi... *** http://www.winischhofer.net |
|
From: James S. <jsi...@in...> - 2003-03-05 23:54:18
|
> > I should of but didn't because I knew driver would take teh path of lest > > resistance to port there drivers. TO much change would have made the > > current situtation much much worst. > > One could argue that changing stuff more or less constantly does not > make it any easier to keep up with a working driver.... :) Well that was a policy change later on. At first the approach was small changes at a time. I was even converting each driver by myself. This upset some people. It was discussed the best solution would be to dump all the changes at one time and then let the driver maintainers deal with it. That is why the shift in what was going on. |
|
From: Geert U. <ge...@li...> - 2003-03-06 08:35:37
|
On Wed, 5 Mar 2003, James Simmons wrote:
> > > We should split the monitor programing stuff out from stuff like bpp etc.
> > > Now if you think about it we can do things like change the bpp without
> > > having to redo the monitor programming. This is the flaw with the old and
> > > even the new api.
> >
> > You could have done that from the beginning. Just look at which fields have
> > changed and which haven't.
>
> I should of but didn't because I knew driver would take teh path of lest
> resistance to port there drivers. TO much change would have made the
> current situtation much much worst.
One other reason why this isn't done is because X may interfere with it. If we
don't do a full register update, but change the parts that need a change only,
we will see less flickering (no PLL reprogramming), but we will suffer if X
doesn't restore the registers to the exact same values they were before.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
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
|
|
From: Sven L. <lu...@dp...> - 2003-03-06 09:01:58
|
On Thu, Mar 06, 2003 at 09:33:34AM +0100, Geert Uytterhoeven wrote: > On Wed, 5 Mar 2003, James Simmons wrote: > > > > We should split the monitor programing stuff out from stuff like bpp etc. > > > > Now if you think about it we can do things like change the bpp without > > > > having to redo the monitor programming. This is the flaw with the old and > > > > even the new api. > > > > > > You could have done that from the beginning. Just look at which fields have > > > changed and which haven't. > > > > I should of but didn't because I knew driver would take teh path of lest > > resistance to port there drivers. TO much change would have made the > > current situtation much much worst. > > One other reason why this isn't done is because X may interfere with it. If we > don't do a full register update, but change the parts that need a change only, > we will see less flickering (no PLL reprogramming), but we will suffer if X > doesn't restore the registers to the exact same values they were before. X is supposed to do that, even if it doesn't know anything about fbdevs, maybe especially if it doesn't know anything about fbdevs. If it knows about fbdev and uses it, X should not be touching the modes anyway, right ? So, we are saving/restoring things twice, one time in X, the other in the fbdev. Friendly, Sven Luther |
|
From: Antonino D. <ad...@po...> - 2003-03-06 09:02:41
|
On Thu, 2003-03-06 at 16:33, Geert Uytterhoeven wrote: > On Wed, 5 Mar 2003, James Simmons wrote: > > > > We should split the monitor programing stuff out from stuff like bpp etc. > > > > Now if you think about it we can do things like change the bpp without > > > > having to redo the monitor programming. This is the flaw with the old and > > > > even the new api. > > > > > > You could have done that from the beginning. Just look at which fields have > > > changed and which haven't. > > > > I should of but didn't because I knew driver would take teh path of lest > > resistance to port there drivers. TO much change would have made the > > current situtation much much worst. > > One other reason why this isn't done is because X may interfere with it. If we > don't do a full register update, but change the parts that need a change only, > we will see less flickering (no PLL reprogramming), but we will suffer if X > doesn't restore the registers to the exact same values they were before. > Ideally, that is what should happen. However, fb_set_var does a check if the passed var is different from the default var. If it's the same, fb_set_par is skipped. Switching back from X, this check will be mostly false, so fb_set_par will be skipped, and register refreshing would have failed. So, I think fbcon should also detect if the previous console is not fbcon (ie previous con > last_fbvc || previous con < first_fbvc), and if it isn't, force an fb_set_par. Tony |
|
From: James S. <jsi...@in...> - 2003-03-11 16:30:37
|
> So, I think fbcon should also detect if the previous console is not > fbcon (ie previous con > last_fbvc || previous con < first_fbvc), and if > it isn't, force an fb_set_par. This whole idea of mapping a specific VC to a specific piece of hardware is just plain dumb and overly complex. The new console system will allocate a set of 16 console to each independent VT. |
|
From: Antonino D. <ad...@po...> - 2003-03-11 20:11:02
|
On Wed, 2003-03-12 at 00:29, James Simmons wrote: > > > So, I think fbcon should also detect if the previous console is not > > fbcon (ie previous con > last_fbvc || previous con < first_fbvc), and if > > it isn't, force an fb_set_par. > > This whole idea of mapping a specific VC to a specific piece of hardware > is just plain dumb and overly complex. The new console system will > allocate a set of 16 console to each independent VT. > Well, you have info->currcon, fg_console etc... No mapping is done, fbcon will just keep track of the tty's it's currently switched to (vt.c does it, and so does fbcon_switch), and fbcon will just look if the vc has a valid PID (which means a process installed its own vc) and therefore not trust it to completely preserve the graphics state. Note that X does something like this to protect itself. When switch from console to X, it refreshes its own registers. I think you may need some support for this. Several have already reported that switching from X to a console results in a corrupted display which can be cleared by doing an fbset. The choices are: 1. refresh the registers at every switch - slowest but guarantees hardware state is always preserved 2. do not refresh unless var changed - fasted but can result in corruption/crash if registers were changed behind the back of fbdev 3. selective refresh - do not refresh if switching between "trusted" consoles, refresh if switching from "untrusted" consoles. 4. Find a method to detect if the registers were changed behind the back of fbdev. Tony |
|
From: Thomas W. <th...@wi...> - 2003-03-11 20:56:33
|
Antonino Daplas wrote: > Well, you have info->currcon, fg_console etc... No mapping is done, > fbcon will just keep track of the tty's it's currently switched to (vt.c > does it, and so does fbcon_switch), and fbcon will just look if the vc > has a valid PID (which means a process installed its own vc) and > therefore not trust it to completely preserve the graphics state. > > Note that X does something like this to protect itself. When switch > from console to X, it refreshes its own registers. Which does not neccessarily mean that the framebuffer driver must do the same, resulting in two mode switches. Not really healthy for LCD panels. The current implementation (as with James' latest patch) does not show any problems with this, even when switching back to a console with a different resolution than the one X was started under. Then again, maybe that's just due to a all too well working sis driver combination :) > I think you may need some support for this. Several have already > reported that switching from X to a console results in a corrupted > display which can be cleared by doing an fbset. > > The choices are: > > 1. refresh the registers at every switch - slowest but guarantees > hardware state is always preserved Bad. Takes long time, especially on LCD displays which always need a little delay for backlight and sync stability reasons. > 2. do not refresh unless var changed - fasted but can result in > corruption/crash if registers were changed behind the back of fbdev I think one can rely on tidyness of applications changing the registers. Like X does. > 3. selective refresh - do not refresh if switching between "trusted" > consoles, refresh if switching from "untrusted" consoles. > > 4. Find a method to detect if the registers were changed behind the back > of fbdev. Very time taking on some hardware (such as ... erm... SiS) with more than 100 registers for graphic mode setup. Thomas -- Thomas Winischhofer Vienna/Austria mailto:th...@wi... *** http://www.winischhofer.net |
|
From: Antonino D. <ad...@po...> - 2003-03-11 21:48:42
|
On Wed, 2003-03-12 at 04:56, Thomas Winischhofer wrote: > > > > The choices are: > > > > 1. refresh the registers at every switch - slowest but guarantees > > hardware state is always preserved > > Bad. Takes long time, especially on LCD displays which always need a > little delay for backlight and sync stability reasons. > > > 2. do not refresh unless var changed - fasted but can result in > > corruption/crash if registers were changed behind the back of fbdev > > I think one can rely on tidyness of applications changing the registers. > Like X does. Unfortunately, this is what we are trying to prevent. X assumes that the console is in text mode, so only registers that affect text mode are restored. Frequently, cursor registers and bitmaps, as an example, are not refreshed. There's probably more, ie accel engine, etc. Of course, X is not totally to blame, it's doing its best to restore the console back. It really depends on the X drivers, how complicated they are, how comprehensive are their restore routines, etc. > > 3. selective refresh - do not refresh if switching between "trusted" > > consoles, refresh if switching from "untrusted" consoles. I actually prefer #3, and I already have working code for this. We can also make this driver switchable (ie, drivers that are not affected by X can disable this, and only drivers that are affected such as the riva, aty, radeon, etc can turn this on). Tony |
Thanks for helping keep SourceForge clean.
X