From: "Petr Vandrovec" <VANDROVE@vc.cvut.cz>
To: Pozsar Balazs <pozsy@sch.bme.hu>
Cc: linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: FBdev remains in unusable state
Date: Wed, 12 Dec 2001 21:32:53 MET-1 [thread overview]
Message-ID: <BCF1AF35606@vcnet.vc.cvut.cz> (raw)
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.
next reply other threads:[~2001-12-12 20:33 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-12 21:32 Petr Vandrovec [this message]
2001-12-12 20:42 ` FBdev remains in unusable state Pozsar Balazs
-- strict thread matches above, loose matches on Subject: below --
2001-12-13 18:00 Petr Vandrovec
2001-12-13 17:03 ` David Woodhouse
2001-12-12 21:55 Petr Vandrovec
2001-12-13 11:35 ` David Woodhouse
2001-12-13 13:29 ` Pozsar Balazs
2001-12-13 16:11 ` David Woodhouse
2001-12-12 20:13 Petr Vandrovec
2001-12-12 20:14 ` Pozsar Balazs
2001-12-12 18:49 Pozsar Balazs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BCF1AF35606@vcnet.vc.cvut.cz \
--to=vandrove@vc.cvut.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=pozsy@sch.bme.hu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox