Hi all,
I am currently using 2.4.17-pre8, and X-4.1.0.
My problem is that if I turn on fb (eg pass vga=0x301 parameter), start an
X session, then switch back to the console using CTRL-ALT-Fx (or
ctrl-alt-bs :), i get 'out of sync' messages on my monitor. I can switch
back to the X session properly using ctrl-alt-fx, but i can never get back
again my console.
The video card is a matrox G450, and I am using the vesa framebuffer.
(I know there's a seperate mga fb driver, but this should work for this
combination)
Is this a bug in the kernel fb code, or in X? Are there any workarounds?
How could I restore textmode?
Please help if you can,
--
Balazs Pozsar
On 12 Dec 01 at 19:49, Pozsar Balazs wrote:
>
> The video card is a matrox G450, and I am using the vesa framebuffer.
> (I know there's a seperate mga fb driver, but this should work for this
> combination)
No. vesafb does not work together with mga driver in X (although
I believe that vesafb works with XFree mga driver, only Matrox driver
is binary bad citizen).
> Is this a bug in the kernel fb code, or in X? Are there any workarounds?
> How could I restore textmode?
Neither. X restore R/W registers to their previous values, while write-only
registers to their values for normal text mode. Yes, there is a
'workaround'. Use (much faster) matroxfb.
Best regards,
Petr Vandrovec
[email protected]
On Wed, 12 Dec 2001, Petr Vandrovec wrote:
> On 12 Dec 01 at 19:49, Pozsar Balazs wrote:
> >
> > The video card is a matrox G450, and I am using the vesa framebuffer.
> > (I know there's a seperate mga fb driver, but this should work for this
> > combination)
>
> No. vesafb does not work together with mga driver in X (although
> I believe that vesafb works with XFree mga driver, only Matrox driver
> is binary bad citizen).
I don't clearly understand you. I am using mga driver which is in the
official xfrr86 release.
> > Is this a bug in the kernel fb code, or in X? Are there any workarounds?
> > How could I restore textmode?
>
> Neither. X restore R/W registers to their previous values, while write-only
> registers to their values for normal text mode. Yes, there is a
> 'workaround'. Use (much faster) matroxfb.
What if setting those W-only registers to their appropiate values on
console-switches?
Why isn't it done by the vesafb driver?
How is the mga fb driver handle handling this situation better?
ps: My problem is that I have to use exactly the same kernel on different
machines, and I need fb. If not all machines have mga, than mga fb is
no-go.
thanks,
--
Pozsar Balazs
On 12 Dec 01 at 21:14, Pozsar Balazs wrote:
> > No. vesafb does not work together with mga driver in X (although
> > I believe that vesafb works with XFree mga driver, only Matrox driver
> > is binary bad citizen).
>
> I don't clearly understand you. I am using mga driver which is in the
> official xfrr86 release.
In that case even xfree mga driver cannot return hardware back to previous
state. It is expected and documented.
> > Neither. X restore R/W registers to their previous values, while write-only
> > registers to their values for normal text mode. Yes, there is a
> > 'workaround'. Use (much faster) matroxfb.
>
> What if setting those W-only registers to their appropiate values on
> console-switches?
It is hardware dependent and undocumented. matroxfb does it...
> Why isn't it done by the vesafb driver?
vesafb is VBE2.0 based. It does not know how to touch hardware, it uses
LILO to do all this dirty work.
> How is the mga fb driver handle handling this situation better?
Because of it actually drives hardware, instead of touching it once before
boot, and then trusting all citizens that it will work. So it can restore
any mode it wants, on any head it wants.
> ps: My problem is that I have to use exactly the same kernel on different
> machines, and I need fb. If not all machines have mga, than mga fb is
> no-go.
I do not understand. If you'll compile both vesafb & matroxfb into kernel,
and you'll boot with
Linux vga=769 video=matrox:vesa:769
on computers with Matrox inside you'll have /dev/fb0 accelerated fb,
and /dev/fb1 VESAFB 'do not use' (maybe vesafb even will not load
as framebuffer will be already acquired by matroxfb, but I never tested
it). On computers without Matrox you'll have /dev/fb0 VESAFB and
/dev/fb1 will not exist at all.
Petr Vandrovec
[email protected]
P.S.: Also try 'Option "UseFBDev"' in /etc/X11/XF86Config-4 driver
section. I think that with this option X11 mga driver will not stomp
on your hardware, and instead it will refuse any videmode != vesafb
one.
On Wed, 12 Dec 2001, Petr Vandrovec wrote:
> On 12 Dec 01 at 21:14, Pozsar Balazs wrote:
> > > No. vesafb does not work together with mga driver in X (although
> > > I believe that vesafb works with XFree mga driver, only Matrox driver
> > > is binary bad citizen).
> >
> > I don't clearly understand you. I am using mga driver which is in the
> > official xfrr86 release.
>
> In that case even xfree mga driver cannot return hardware back to previous
> state. It is expected and documented.
Sorry I didn't know that. Btw, where is it documented?
> > Why isn't it done by the vesafb driver?
>
> vesafb is VBE2.0 based. It does not know how to touch hardware, it uses
> LILO to do all this dirty work.
I think got the point, but I don't really understand how lilo comes here,
because I boot using grub or syslinux.
> Linux vga=769 video=matrox:vesa:769
>
> on computers with Matrox inside you'll have /dev/fb0 accelerated fb,
> and /dev/fb1 VESAFB 'do not use' (maybe vesafb even will not load
> as framebuffer will be already acquired by matroxfb, but I never tested
> it). On computers without Matrox you'll have /dev/fb0 VESAFB and
> /dev/fb1 will not exist at all.
Thanks for this. Are there similar issues with other cards?
Which fb drivers should I compile in?
> P.S.: Also try 'Option "UseFBDev"' in /etc/X11/XF86Config-4 driver
> section. I think that with this option X11 mga driver will not stomp
> on your hardware, and instead it will refuse any videmode != vesafb
> one.
I need 'real' X running, not X using fbdev...
Much thanks for you help,
--
Balazs Pozsar
On 12 Dec 01 at 21:42, Pozsar Balazs wrote:
> On Wed, 12 Dec 2001, Petr Vandrovec wrote:
> > In that case even xfree mga driver cannot return hardware back to previous
> > state. It is expected and documented.
>
> Sorry I didn't know that. Btw, where is it documented?
Documentation/fb/vesafb.txt, X11 paragraph, last sentence:
-------8<-----
The X-Server must restore the video mode correctly, else you end up
with a broken console (and vesafb cannot do anything about this).
-------8<-----
> > > Why isn't it done by the vesafb driver?
> >
> > vesafb is VBE2.0 based. It does not know how to touch hardware, it uses
> > LILO to do all this dirty work.
>
> I think got the point, but I don't really understand how lilo comes here,
> because I boot using grub or syslinux.
Sorry. arch/i386/boot/video.S loader
> > as framebuffer will be already acquired by matroxfb, but I never tested
> > it). On computers without Matrox you'll have /dev/fb0 VESAFB and
> > /dev/fb1 will not exist at all.
>
> Thanks for this. Are there similar issues with other cards?
> Which fb drivers should I compile in?
I have no idea. I know that atyfb does not work on ATIs I have, and
I have no idea how X11 behaves on them. I do not have other hardware
at all.
> > P.S.: Also try 'Option "UseFBDev"' in /etc/X11/XF86Config-4 driver
> > section. I think that with this option X11 mga driver will not stomp
> > on your hardware, and instead it will refuse any videmode != vesafb
> > one.
>
> I need 'real' X running, not X using fbdev...
With driver "mga" and option "usefbdev" you should get 'real' X, they'll
use acceleration. Only difference is that they'll use kernel fbdev
to set videomode (in XF4.0 there is a bug that DGA mode in X11 mga driver
will go directly to hardware even if usefbdev is specified, but with XF4.1
you should be safe).
Best regards,
Petr Vandrovec
[email protected]
[email protected] said:
> Documentation/fb/vesafb.txt, X11 paragraph, last sentence:
> -------8<-----
> The X-Server must restore the video mode correctly, else you end up
> with a broken console (and vesafb cannot do anything about this).
> -------8<-----
This isn't strictly true. We could just call the VESA BIOS to set it up
again for us. The 'vesa' XFree86 driver manages to do this perfectly well
from userspace, even.
--
dwmw2
On Thu, 13 Dec 2001, David Woodhouse wrote:
>
> [email protected] said:
> > Documentation/fb/vesafb.txt, X11 paragraph, last sentence:
> > -------8<-----
> > The X-Server must restore the video mode correctly, else you end up
> > with a broken console (and vesafb cannot do anything about this).
> > -------8<-----
>
> This isn't strictly true. We could just call the VESA BIOS to set it up
> again for us. The 'vesa' XFree86 driver manages to do this perfectly well
> from userspace, even.
Then why not include this set up code into vesafb?
--
Balazs Pozsar
[email protected] said:
> Then why not include this set up code into vesafb?
Because nobody's got round to porting it into the vesafb driver yet. And it
may turn out to be prohibitively ugly if you do.
--
dwmw2
On 13 Dec 01 at 14:29, Pozsar Balazs wrote:
> On Thu, 13 Dec 2001, David Woodhouse wrote:
> >
> > [email protected] said:
> > > Documentation/fb/vesafb.txt, X11 paragraph, last sentence:
> > > -------8<-----
> > > The X-Server must restore the video mode correctly, else you end up
> > > with a broken console (and vesafb cannot do anything about this).
> > > -------8<-----
> >
> > This isn't strictly true. We could just call the VESA BIOS to set it up
> > again for us. The 'vesa' XFree86 driver manages to do this perfectly well
> > from userspace, even.
>
> Then why not include this set up code into vesafb?
As it requires userspace, complete realmode 16bit DOS environment, it
should not live in kernel (due to being 16bit code, and requiring its
own mm). There was some patch which used protected mode VESA services
to set videomode, but as nobody uses these services, BIOSes either do
not provide them at all, or services provided are buggy and unusable.
If VESA BIOS virtualization it is something like (debian) 'read-edid'
package does - then please no. It prints dozens of messages to screen
for about 2 minutes on Matrox hardware, and if you switch consoles
during that, CRTC setting is hopelessly damaged and only starting X
brings picture back to you. And it does not read any EDID, of course...
Petr Vandrovec
[email protected]
[email protected] said:
> As it requires userspace, complete realmode 16bit DOS environment, it
> should not live in kernel (due to being 16bit code, and requiring its
> own mm).
A mechanism for a userspace program to change the video mode, then tell
vesafb about the new mode, might be the best way to do this.
--
dwmw2