Re: FBdev remains in unusable state

Re: FBdev remains in unusable state

[Petr Vandrovec]

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
                                                        vandrove@vc.cvut.cz
                                                        
                                                        

Re: FBdev remains in unusable state

[Pozsar Balazs]

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

Re: FBdev remains in unusable state

[Petr Vandrovec]

On 13 Dec 01 at 14:29, Pozsar Balazs wrote:
> On Thu, 13 Dec 2001, David Woodhouse wrote:
> >
> > VANDROVE@vc.cvut.cz 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
                                            vandrove@vc.cvut.cz

Re: FBdev remains in unusable state

[David Woodhouse]

VANDROVE@vc.cvut.cz 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

Re: FBdev remains in unusable state

[Petr Vandrovec]

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
                                                    vandrove@vc.cvut.cz
                                                    

Re: FBdev remains in unusable state

[David Woodhouse]

VANDROVE@vc.cvut.cz 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

Re: FBdev remains in unusable state

[Pozsar Balazs]

On Thu, 13 Dec 2001, David Woodhouse wrote:

>
> VANDROVE@vc.cvut.cz 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

Re: FBdev remains in unusable state

[David Woodhouse]

pozsy@sch.bme.hu 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

Re: FBdev remains in unusable state

[Petr Vandrovec]

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
                                                    vandrove@vc.cvut.cz
                                                    
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.

Re: FBdev remains in unusable state

[Pozsar Balazs]

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

FBdev remains in unusable state

[Pozsar Balazs]

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