Menu
▾
▴
linuxconsole-dev
|
From: Petr V. <VAN...@vc...> - 2004-05-19 10:39:04
|
On 19 May 04 at 11:10, Svetoslav Slavtchev wrote:
> > >
> > I'm considering patching it so it'll boot up with separate outputs instead
> > of mirroring by default. This should ideally be a kernel command
> > line option, as the current default is useful for those with only one
> > screen. (But then, why get a G550 if you use one screen only . . .)
>
> Petr refused to help me on this issue,
> do you have idea how to patch it ?
I have no idea what you are talking about...
I sent you which values you should replace in the driver if you want
mapping which is incompatible with BIOS, with Windows drivers, with XFree
and with all singlehead configurations: Just replace output #1 source in the
matroxfb_g450.c::matroxfb_g450_connect with CRTC2 instead of using CRTC1,
and you are done.
- ACCESS_FBINFO(outputs[1]).src = MATROXFB_SRC_CRTC1;
+ ACCESS_FBINFO(outputs[1]).src = MATROXFB_SRC_CRTC2;
But then do not complain that analog output described as PRIMARY in the
matrox documentation displays CRTC2 and not CRTC1 (i.e. it brokes
all analog singlehead configs and thus consider it vetoed for stock
kernel).
Best regards,
Petr Vandrovec
|
|
From: Svetoslav S. <sv...@gm...> - 2004-05-19 11:16:13
Attachments:
DF06-matroxfb_yres_virtual.patch
|
> On 19 May 04 at 11:10, Svetoslav Slavtchev wrote: > > > > > > > I'm considering patching it so it'll boot up with separate outputs > instead > > > of mirroring by default. This should ideally be a kernel command > > > line option, as the current default is useful for those with only one > > > screen. (But then, why get a G550 if you use one screen only . . .) > > > > Petr refused to help me on this issue, > > do you have idea how to patch it ? > > I have no idea what you are talking about... > > I sent you you didn't > which values you should replace in the driver if you want > mapping which is incompatible with BIOS, with Windows drivers, with XFree > and with all singlehead configurations: ok, but i want to use this incompatible config(and do use it) and it would be nicer to not need matroxset in order to get two independant fbcon on G550 > Just replace output #1 source in > the > matroxfb_g450.c::matroxfb_g450_connect with CRTC2 instead of using CRTC1, > and you are done. > > - ACCESS_FBINFO(outputs[1]).src = MATROXFB_SRC_CRTC1; > + ACCESS_FBINFO(outputs[1]).src = MATROXFB_SRC_CRTC2; thanks a lot > But then do not complain that analog output described as PRIMARY in the > matrox documentation displays CRTC2 and not CRTC1 (i.e. it brokes > all analog singlehead configs and thus consider it vetoed for stock > kernel). i'm aware of this, and won't complain :-) sorry if my previous mail sounded ofensive best, svetljo PS. i think the attached fix you send me some time ago is still missing from vanilla 2.6.6-bk care to submit it to Linus ? -- NEU : GMX Internet.FreeDSL Ab sofort DSL-Tarif ohne Grundgebühr: http://www.gmx.net/dsl |
|
From: Petr V. <VAN...@vc...> - 2004-05-19 11:30:42
|
On 19 May 04 at 13:16, Svetoslav Slavtchev wrote:
>
> and it would be nicer to not need matroxset in order
> to get two independant fbcon on G550
It would need sensing card outputs to find which outputs have connected
monitor and which do not, and as there is no doc...
> i think the attached fix you send me some time ago
> is still missing from vanilla 2.6.6-bk
> care to submit it to Linus ?
I can try it. But I sent him missing memset() in matroxfb_maven
(which causes crash, not just ill behavior, and it is obviously
correct) three times and it still did not get through his email
filters. So it is probably time to try to submit my pending patches
again. Last time I sent two one passed (ncpfs) and one was dropped
(matroxfb max/max_t and memset), so maybe that sending patches in
batches increases probability that some will pass...
Petr
|
|
From: Svetoslav S. <sv...@gm...> - 2004-05-19 11:35:58
|
> On 19 May 04 at 13:16, Svetoslav Slavtchev wrote: > > > > and it would be nicer to not need matroxset in order > > to get two independant fbcon on G550 > > It would need sensing card outputs to find which outputs have connected > monitor and which do not, and as there is no doc... :( > > i think the attached fix you send me some time ago > > is still missing from vanilla 2.6.6-bk > > care to submit it to Linus ? > > I can try it. But I sent him missing memset() in matroxfb_maven > (which causes crash, not just ill behavior, and it is obviously > correct) three times and it still did not get through his email > filters. So it is probably time to try to submit my pending patches > again. Last time I sent two one passed (ncpfs) and one was dropped > (matroxfb max/max_t and memset), so maybe that sending patches in > batches increases probability that some will pass... may be you should try sending them to Andrew for -mm and lkml. i've heard Linus has the habit to simply delete his inbox from time to time :-) best, svetljo -- "Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen! Jetzt aktivieren unter http://www.gmx.net/info |
|
From: James S. <jsi...@in...> - 2004-05-19 17:11:55
|
> > I can try it. But I sent him missing memset() in matroxfb_maven > > (which causes crash, not just ill behavior, and it is obviously > > correct) three times and it still did not get through his email > > filters. So it is probably time to try to submit my pending patches > > again. Last time I sent two one passed (ncpfs) and one was dropped > > (matroxfb max/max_t and memset), so maybe that sending patches in > > batches increases probability that some will pass... > > may be you should try sending them to Andrew > for -mm and lkml. > > i've heard Linus has the habit to simply delete > his inbox from time to time :-) Hisis right. The best way to send patches is to Andrew Morton. |
|
From: Svetoslav S. <sv...@gm...> - 2004-05-19 11:41:05
|
> On 19 May 04 at 13:16, Svetoslav Slavtchev wrote: > > > > and it would be nicer to not need matroxset in order > > to get two independant fbcon on G550 > > It would need sensing card outputs to find which outputs have connected > monitor and which do not, and as there is no doc... > isn't it possible to simply assume that both outputs have connected monitors ? or does the driver need to retrive monitor data, in order to setup properly ? best, svetljo -- "Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen! Jetzt aktivieren unter http://www.gmx.net/info |
|
From: Petr V. <VAN...@vc...> - 2004-05-19 12:57:02
|
On 19 May 04 at 13:40, Svetoslav Slavtchev wrote:
> > On 19 May 04 at 13:16, Svetoslav Slavtchev wrote:
> > >
> > > and it would be nicer to not need matroxset in order
> > > to get two independant fbcon on G550
> >
> > It would need sensing card outputs to find which outputs have connected
> > monitor and which do not, and as there is no doc...
> >
>
> isn't it possible to simply assume that both outputs
> have connected monitors ?
> or does the driver need to retrive monitor data,
> in order to setup properly ?
Problem is that "analog" (HD15) output on G550 is actually
secondary output. So you have to do:
nothing on DVI/nothing on HD15: anything -> primary output,
anything -> secondary output,
anything -> DVI output,
nothing on DVI/monitor on HD15: anything -> primary output,
CRTC1 -> secondary output,
anything -> DVI output,
analog monitor on DVI/nothing on HD15: CRTC1 -> primary output,
anything -> secondary output,
anything -> DVI output,
digital monitor on DVI/nothing on HD15:anything -> primary output,
anything -> secondary output,
CRTC1 -> DVI output,
analog monitor on DVI/monitor on HD15: CRTC1 -> primary output
CRTC2 -> secondary output
anything -> DVI output,
digital monitor on DVI/monitor on HD15:anything -> primary output,
CRTC2 -> secondary output,
CRTC1 -> DVI output,
As you can see, you can put CRTC2 to the secondary output only if
monitors are connected to both outputs (or at least if primary output
has monitor connected). If you'll put CRTC2 on secondary output
unconditionally, you do not support (only) analog monitor connected
to analog G550 output...
Moreover, user may want CRTC2 on primary output and CRTC1 on secondary
(if his first monitor is analog one). And you cannot make this
config default too, as it would not work with TV-Out: user would
have primary display on TV then, and it is probably not what user
had in the mind.
So I still think that CRTC1 on all three outputs is configuration
which satisfies most of the users.
Petr Vandrovec
|
|
From: Helge H. <hel...@ai...> - 2004-05-21 10:16:37
|
Petr Vandrovec wrote: >On 19 May 04 at 13:40, Svetoslav Slavtchev wrote: > > >>>On 19 May 04 at 13:16, Svetoslav Slavtchev wrote: >>> >>> >>>>and it would be nicer to not need matroxset in order >>>>to get two independant fbcon on G550 >>>> >>>> >>>It would need sensing card outputs to find which outputs have connected >>>monitor and which do not, and as there is no doc... >>> >>> >>> >>isn't it possible to simply assume that both outputs >>have connected monitors ? >>or does the driver need to retrive monitor data, >>in order to setup properly ? >> >> > >Problem is that "analog" (HD15) output on G550 is actually >secondary output. So you have to do: > >nothing on DVI/nothing on HD15: anything -> primary output, > anything -> secondary output, > anything -> DVI output, >nothing on DVI/monitor on HD15: anything -> primary output, > CRTC1 -> secondary output, > anything -> DVI output, >analog monitor on DVI/nothing on HD15: CRTC1 -> primary output, > anything -> secondary output, > anything -> DVI output, >digital monitor on DVI/nothing on HD15:anything -> primary output, > anything -> secondary output, > CRTC1 -> DVI output, >analog monitor on DVI/monitor on HD15: CRTC1 -> primary output > CRTC2 -> secondary output > anything -> DVI output, >digital monitor on DVI/monitor on HD15:anything -> primary output, > CRTC2 -> secondary output, > CRTC1 -> DVI output, > > >As you can see, you can put CRTC2 to the secondary output only if >monitors are connected to both outputs (or at least if primary output >has monitor connected). If you'll put CRTC2 on secondary output >unconditionally, you do not support (only) analog monitor connected >to analog G550 output... > >Moreover, user may want CRTC2 on primary output and CRTC1 on secondary >(if his first monitor is analog one). And you cannot make this >config default too, as it would not work with TV-Out: user would >have primary display on TV then, and it is probably not what user >had in the mind. > >So I still think that CRTC1 on all three outputs is configuration >which satisfies most of the users. > Petr Vandrovec > > > Thank you for explaining this. I agree that CRTC1 everywhere is a good default. Still, it'd be nice to have an option (specified on the kernel command line or the module.conf file) that allows overriding this. Something like matrox:outputs:xyz x, y, and z can be 1, 2 or 0, in order to connect CRTC1, CRTC2 or nothing. The first position(x) then correspond to the primary output, the second(y) the secondary output, and the third(z) DVI. The default then, when not sepcified, would be matrox:outputs:111 which is your default with CRTC1 everywhere. I have my primary analog monitor on the analog output (this is the one output the BIOS uses) which you call secondary. My other analog monitor is connected to the DVI plug using the DVI->VGA converter supplied with the card. I guess my setup then, would be matrox:outputs:012 to get CRTC1 on the secondary and CRTC2 on the DVI. (or possibly matrox:outputs:210 if the stuff I get from that converter really is the primary out, rather than DVI out converted to analog. I don't know how this converter works.) Are you interested in supporting such an option? I can try to make a patch myself if you aren't interested in developing it yourself. Helge Hafting |
|
From: Petr V. <VAN...@vc...> - 2004-05-21 11:35:40
|
On 21 May 04 at 12:18, Helge Hafting wrote:
> Still, it'd be nice to have an option (specified on the kernel command
> line or the module.conf file) that allows overriding this.
>
> Something like matrox:outputs:xyz
> x, y, and z can be 1, 2 or 0, in order to connect CRTC1, CRTC2 or nothing.
> The first position(x) then correspond to the primary output, the second(y)
> the secondary output, and the third(z) DVI.
>
> The default then, when not sepcified, would be matrox:outputs:111
> which is your default with CRTC1 everywhere.
Yes. It looks reasonable.
> Are you interested in supporting such an option? I can try to make a
> patch myself if you aren't interested in developing it yourself.
I started working on it, but then I made 'bk pull' and found that
fbcon changed a bit and that I have to adapt my infrastructure to get
it back to work (as with stock fbcon I cannot drive my system in a
way I want :-( ).
Petr Vandrovec
|
|
From: Helge H. <hel...@ai...> - 2004-05-23 15:06:39
Attachments:
matroxdiff
|
On Fri, May 21, 2004 at 01:29:24PM +0200, Petr Vandrovec wrote: > On 21 May 04 at 12:18, Helge Hafting wrote: > > > Still, it'd be nice to have an option (specified on the kernel command > > line or the module.conf file) that allows overriding this. > > > > Something like matrox:outputs:xyz > > x, y, and z can be 1, 2 or 0, in order to connect CRTC1, CRTC2 or nothing. > > The first position(x) then correspond to the primary output, the second(y) > > the secondary output, and the third(z) DVI. > > > > The default then, when not sepcified, would be matrox:outputs:111 > > which is your default with CRTC1 everywhere. > > Yes. It looks reasonable. > > > Are you interested in supporting such an option? I can try to make a > > patch myself if you aren't interested in developing it yourself. > > I started working on it, but then I made 'bk pull' and found that > fbcon changed a bit and that I have to adapt my infrastructure to get > it back to work (as with stock fbcon I cannot drive my system in a > way I want :-( ). Here is a patch that works for my G550. It probably needs some polishing, and more work in order to work with other cards than G550 / G450. It is meant for testing by anybody interested. Still, it works on my G550, the kernel parameter video=matrox:outputs:21 connects CRTC2 to the first plug and CRTC1 to the second plug. outputs:11 is the default if the parameter is omitted. The first position is the first plug, the second position is the second plug. I didn't figure out any third output. Specifying 0 connects nothing to that plug. Specifying 1 connects CRTC1, and 2 connects CRTC2. Other values won't work and the default of 1 will be used instead. Helge Hafting |
|
From: Petr V. <van...@vc...> - 2004-05-23 16:00:38
|
On Sun, May 23, 2004 at 05:08:46PM +0200, Helge Hafting wrote:
> On Fri, May 21, 2004 at 01:29:24PM +0200, Petr Vandrovec wrote:
> > On 21 May 04 at 12:18, Helge Hafting wrote:
> >
> > > Still, it'd be nice to have an option (specified on the kernel command
> > > line or the module.conf file) that allows overriding this.
> > >
> > > Something like matrox:outputs:xyz
> > > x, y, and z can be 1, 2 or 0, in order to connect CRTC1, CRTC2 or nothing.
> > > The first position(x) then correspond to the primary output, the second(y)
> > > the secondary output, and the third(z) DVI.
> > >
> > > The default then, when not sepcified, would be matrox:outputs:111
> > > which is your default with CRTC1 everywhere.
> >
> > Yes. It looks reasonable.
> >
> > > Are you interested in supporting such an option? I can try to make a
> > > patch myself if you aren't interested in developing it yourself.
> >
> > I started working on it, but then I made 'bk pull' and found that
> > fbcon changed a bit and that I have to adapt my infrastructure to get
> > it back to work (as with stock fbcon I cannot drive my system in a
> > way I want :-( ).
>
> Here is a patch that works for my G550.
> It probably needs some polishing, and more work in order to
> work with other cards than G550 / G450. It is meant for testing by anybody
> interested.
>
> Still, it works on my G550, the kernel parameter video=matrox:outputs:21
> connects CRTC2 to the first plug and CRTC1 to the second plug.
> outputs:11 is the default if the parameter is omitted.
>
>
> The first position is the first plug, the second position is
> the second plug. I didn't figure out any third output.
>
> Specifying 0 connects nothing to that plug.
> Specifying 1 connects CRTC1, and 2 connects CRTC2. Other values
> won't work and the default of 1 will be used instead.
Ah. I sent my patch to linux-fbdev-devel, not to the linuxconsole-dev... (and to the
ak...@os...). Patch included below.
I'm quite surprised that your change works for 'outputs:21' without changing matroxfb_DAC1064.c
sources...
It should work same way as your patch did, except that it accepts three digits, and it
should work for modular matroxfb too.
Petr
Date: Sun, 23 May 2004 14:03:08 +0200
From: Petr Vandrovec <van...@vc...>
To: ak...@os...
Cc: lin...@li...
Subject: [PATCH] matroxfb: Add support for mapping CRTC<->outputs at boot time
Hi Andrew,
some people expressed interest in having possibility to set CRTC <-> outputs mapping
at boot time, without having to use 'matroxset' later after kernel boots.
This patch adds option 'video=matroxfb:outputs:XYZ', where X sets which CRTC will connect
to primary output, Y sets secondary output and Z sets DVI output.
In addition to that I also added missing memset() into maven, which was broken since
i2c was kobjectified.
I have no idea what you'll do with 'Signed-off-by' line below, but just in case, this
patch was written entirely by me, and I'm not aware about any other IP or patents pending
on it.
Thanks,
Petr Vandrovec
Signed-off-by: Petr Vandrovec <van...@vc...>
diff -urdN linux/drivers/video/matrox/matroxfb_DAC1064.c linux/drivers/video/matrox/matroxfb_DAC1064.c
--- linux/drivers/video/matrox/matroxfb_DAC1064.c 2004-05-22 18:38:19.000000000 +0200
+++ linux/drivers/video/matrox/matroxfb_DAC1064.c 2004-05-23 13:04:23.000000000 +0200
@@ -660,7 +660,7 @@
ACCESS_FBINFO(features.accel.has_cacheflush) = 1;
ACCESS_FBINFO(outputs[0]).output = &m1064;
- ACCESS_FBINFO(outputs[0]).src = MATROXFB_SRC_CRTC1;
+ ACCESS_FBINFO(outputs[0]).src = ACCESS_FBINFO(outputs[0]).default_src;
ACCESS_FBINFO(outputs[0]).data = MINFO;
ACCESS_FBINFO(outputs[0]).mode = MATROXFB_OUTPUT_MODE_MONITOR;
@@ -859,7 +859,7 @@
{
ACCESS_FBINFO(outputs[0]).output = &m1064;
}
- ACCESS_FBINFO(outputs[0]).src = MATROXFB_SRC_CRTC1;
+ ACCESS_FBINFO(outputs[0]).src = ACCESS_FBINFO(outputs[0]).default_src;
ACCESS_FBINFO(outputs[0]).data = MINFO;
ACCESS_FBINFO(outputs[0]).mode = MATROXFB_OUTPUT_MODE_MONITOR;
diff -urdN linux/drivers/video/matrox/matroxfb_Ti3026.c linux/drivers/video/matrox/matroxfb_Ti3026.c
--- linux/drivers/video/matrox/matroxfb_Ti3026.c 2004-05-22 18:38:01.000000000 +0200
+++ linux/drivers/video/matrox/matroxfb_Ti3026.c 2004-05-23 13:03:08.000000000 +0200
@@ -692,7 +692,7 @@
ACCESS_FBINFO(outputs[0]).data = MINFO;
ACCESS_FBINFO(outputs[0]).output = &ti3026_output;
- ACCESS_FBINFO(outputs[0]).src = MATROXFB_SRC_CRTC1;
+ ACCESS_FBINFO(outputs[0]).src = ACCESS_FBINFO(outputs[0]).default_src;
ACCESS_FBINFO(outputs[0]).mode = MATROXFB_OUTPUT_MODE_MONITOR;
if (ACCESS_FBINFO(devflags.noinit))
diff -urdN linux/drivers/video/matrox/matroxfb_base.c linux/drivers/video/matrox/matroxfb_base.c
--- linux/drivers/video/matrox/matroxfb_base.c 2004-05-22 18:38:28.000000000 +0200
+++ linux/drivers/video/matrox/matroxfb_base.c 2004-05-23 13:08:04.000000000 +0200
@@ -1272,6 +1272,7 @@
static int dfp; /* "matrox:dfp */
static int dfp_type = -1; /* "matrox:dfp:xxx */
static int memtype = -1; /* "matrox:memtype:xxx" */
+static char outputs[8]; /* "matrox:outputs:xxx" */
#ifndef MODULE
static char videomode[64]; /* "matrox:mode:xxxxx" or "matrox:xxxxx" */
@@ -1537,6 +1538,39 @@
static int hotplug = 0;
+static void setDefaultOutputs(WPMINFO2) {
+ unsigned int i;
+ const char* ptr;
+
+ ACCESS_FBINFO(outputs[0]).default_src = MATROXFB_SRC_CRTC1;
+ if (ACCESS_FBINFO(devflags.g450dac)) {
+ ACCESS_FBINFO(outputs[1]).default_src = MATROXFB_SRC_CRTC1;
+ ACCESS_FBINFO(outputs[2]).default_src = MATROXFB_SRC_CRTC1;
+ } else if (dfp) {
+ ACCESS_FBINFO(outputs[2]).default_src = MATROXFB_SRC_CRTC1;
+ }
+ ptr = outputs;
+ for (i = 0; i < MATROXFB_MAX_OUTPUTS; i++) {
+ char c = *ptr++;
+
+ if (c == 0) {
+ break;
+ }
+ if (c == '0') {
+ ACCESS_FBINFO(outputs[i]).default_src = MATROXFB_SRC_NONE;
+ } else if (c == '1') {
+ ACCESS_FBINFO(outputs[i]).default_src = MATROXFB_SRC_CRTC1;
+ } else if (c == '2' && ACCESS_FBINFO(devflags.crtc2)) {
+ ACCESS_FBINFO(outputs[i]).default_src = MATROXFB_SRC_CRTC2;
+ } else {
+ printk(KERN_ERR "matroxfb: Unknown outputs setting\n");
+ break;
+ }
+ }
+ /* Nullify this option for subsequent adapters */
+ outputs[0] = 0;
+}
+
static int initMatrox2(WPMINFO struct board* b){
unsigned long ctrlptr_phys = 0;
unsigned long video_base_phys = 0;
@@ -1577,20 +1611,18 @@
ACCESS_FBINFO(devflags.crtc2) = (b->flags & DEVF_CRTC2) != 0;
ACCESS_FBINFO(devflags.maven_capable) = (b->flags & DEVF_MAVEN_CAPABLE) != 0;
ACCESS_FBINFO(devflags.dualhead) = (b->flags & DEVF_DUALHEAD) != 0;
+ ACCESS_FBINFO(devflags.dfp_type) = dfp_type;
+ ACCESS_FBINFO(devflags.g450dac) = (b->flags & DEVF_G450DAC) != 0;
+ ACCESS_FBINFO(devflags.textstep) = ACCESS_FBINFO(devflags.vgastep) * ACCESS_FBINFO(devflags.textmode);
+ ACCESS_FBINFO(devflags.textvram) = 65536 / ACCESS_FBINFO(devflags.textmode);
+ setDefaultOutputs(PMINFO2);
if (b->flags & DEVF_PANELLINK_CAPABLE) {
ACCESS_FBINFO(outputs[2]).data = MINFO;
ACCESS_FBINFO(outputs[2]).output = &panellink_output;
- if (dfp)
- ACCESS_FBINFO(outputs[2]).src = MATROXFB_SRC_CRTC1;
- else
- ACCESS_FBINFO(outputs[2]).src = MATROXFB_SRC_NONE;
+ ACCESS_FBINFO(outputs[2]).src = ACCESS_FBINFO(outputs[2]).default_src;
ACCESS_FBINFO(outputs[2]).mode = MATROXFB_OUTPUT_MODE_MONITOR;
ACCESS_FBINFO(devflags.panellink) = 1;
}
- ACCESS_FBINFO(devflags.dfp_type) = dfp_type;
- ACCESS_FBINFO(devflags.g450dac) = (b->flags & DEVF_G450DAC) != 0;
- ACCESS_FBINFO(devflags.textstep) = ACCESS_FBINFO(devflags.vgastep) * ACCESS_FBINFO(devflags.textmode);
- ACCESS_FBINFO(devflags.textvram) = 65536 / ACCESS_FBINFO(devflags.textmode);
if (ACCESS_FBINFO(capable.cross4MB) < 0)
ACCESS_FBINFO(capable.cross4MB) = b->flags & DEVF_CROSS4MB;
@@ -1813,6 +1845,13 @@
to yres_virtual * xres_virtual < 2^32 */
}
matroxfb_init_fix(PMINFO2);
+ /* Normalize values (namely yres_virtual) */
+ matroxfb_check_var(&vesafb_defined, &ACCESS_FBINFO(fbcon));
+ /* And put it into "current" var. Do NOT program hardware yet, or we'll not take over
+ * vgacon correctly. fbcon_startup will call fb_set_par for us, WITHOUT check_var,
+ * and unfortunately it will do it BEFORE vgacon contents is saved, so it won't work
+ * anyway. But we at least tried... */
+ ACCESS_FBINFO(fbcon.var) = vesafb_defined;
err = -EINVAL;
printk(KERN_INFO "matroxfb: %dx%dx%dbpp (virtual: %dx%d)\n",
@@ -1834,6 +1873,9 @@
* until someone tells me what is proper thing to do */
printk(KERN_INFO "fb%d: initializing hardware\n",
ACCESS_FBINFO(fbcon.node));
+ /* We have to use FB_ACTIVATE_FORCE, as we had to put vesafb_defined to the fbcon.var
+ * already before, so register_framebuffer works correctly. */
+ vesafb_defined.activate |= FB_ACTIVATE_FORCE;
fb_set_var(&ACCESS_FBINFO(fbcon), &vesafb_defined);
}
return 0;
@@ -2012,7 +2054,7 @@
init_waitqueue_head(&ACCESS_FBINFO(crtc1.vsync.wait));
init_waitqueue_head(&ACCESS_FBINFO(crtc2.vsync.wait));
ACCESS_FBINFO(crtc1.panpos) = -1;
-
+
err = initMatrox2(PMINFO b);
if (!err) {
#ifndef CONFIG_FB_MATROX_MULTIHEAD
@@ -2288,6 +2330,8 @@
mem = simple_strtoul(this_opt+4, NULL, 0);
else if (!strncmp(this_opt, "mode:", 5))
strlcpy(videomode, this_opt+5, sizeof(videomode));
+ else if (!strncmp(this_opt, "outputs:", 8))
+ strlcpy(outputs, this_opt+8, sizeof(outputs));
else if (!strncmp(this_opt, "dfp:", 4)) {
dfp_type = simple_strtoul(this_opt+4, NULL, 0);
dfp = 1;
@@ -2463,6 +2507,8 @@
MODULE_PARM_DESC(dfp, "Specifies whether to use digital flat panel interface of G200/G400 (0 or 1) (default=0)");
MODULE_PARM(dfp_type, "i");
MODULE_PARM_DESC(dfp_type, "Specifies DFP interface type (0 to 255) (default=read from hardware)");
+MODULE_PARM(outputs, "c8");
+MODULE_PARM_DESC(outputs, "Specifies which CRTC is mapped to which output (string of up to three letters, consisting of 0 (disabled), 1 (CRTC1), 2 (CRTC2)) (default=111 for Gx50, 101 for G200/G400 with DFP, and 100 for all other devices)");
#ifdef CONFIG_PPC_PMAC
MODULE_PARM(vmode, "i");
MODULE_PARM_DESC(vmode, "Specify the vmode mode number that should be used (640x480 default)");
diff -urdN linux/drivers/video/matrox/matroxfb_base.h linux/drivers/video/matrox/matroxfb_base.h
--- linux/drivers/video/matrox/matroxfb_base.h 2004-05-22 18:38:21.000000000 +0200
+++ linux/drivers/video/matrox/matroxfb_base.h 2004-05-22 19:15:15.000000000 +0200
@@ -479,6 +479,7 @@
struct matrox_altout* output;
void* data;
unsigned int mode;
+ unsigned int default_src;
} outputs[MATROXFB_MAX_OUTPUTS];
#define MATROXFB_MAX_FB_DRIVERS 5
diff -urdN linux/drivers/video/matrox/matroxfb_crtc2.c linux/drivers/video/matrox/matroxfb_crtc2.c
--- linux/drivers/video/matrox/matroxfb_crtc2.c 2004-05-22 18:38:33.000000000 +0200
+++ linux/drivers/video/matrox/matroxfb_crtc2.c 2004-05-23 13:05:47.000000000 +0200
@@ -628,15 +628,6 @@
m2info->mmio.vbase = ACCESS_FBINFO(mmio.vbase);
m2info->mmio.len = ACCESS_FBINFO(mmio.len);
- /*
- * If we have unused output, connect CRTC2 to it...
- */
- if (ACCESS_FBINFO(outputs[1]).output &&
- ACCESS_FBINFO(outputs[1]).src == MATROXFB_SRC_NONE &&
- ACCESS_FBINFO(outputs[2]).src == MATROXFB_SRC_NONE) {
- ACCESS_FBINFO(outputs[1]).src = MATROXFB_SRC_CRTC2;
- }
-
matroxfb_dh_init_fix(m2info);
if (register_framebuffer(&m2info->fbcon)) {
return -ENXIO;
diff -urdN linux/drivers/video/matrox/matroxfb_g450.c linux/drivers/video/matrox/matroxfb_g450.c
--- linux/drivers/video/matrox/matroxfb_g450.c 2004-05-22 18:38:33.000000000 +0200
+++ linux/drivers/video/matrox/matroxfb_g450.c 2004-05-22 20:05:43.000000000 +0200
@@ -591,11 +591,11 @@
if (ACCESS_FBINFO(devflags.g450dac)) {
down_write(&ACCESS_FBINFO(altout.lock));
tvo_fill_defaults(PMINFO2);
- ACCESS_FBINFO(outputs[1]).src = MATROXFB_SRC_CRTC1;
+ ACCESS_FBINFO(outputs[1]).src = ACCESS_FBINFO(outputs[1]).default_src;
ACCESS_FBINFO(outputs[1]).data = MINFO;
ACCESS_FBINFO(outputs[1]).output = &matroxfb_g450_altout;
ACCESS_FBINFO(outputs[1]).mode = MATROXFB_OUTPUT_MODE_MONITOR;
- ACCESS_FBINFO(outputs[2]).src = MATROXFB_SRC_CRTC1;
+ ACCESS_FBINFO(outputs[2]).src = ACCESS_FBINFO(outputs[2]).default_src;
ACCESS_FBINFO(outputs[2]).data = MINFO;
ACCESS_FBINFO(outputs[2]).output = &matroxfb_g450_dvi;
ACCESS_FBINFO(outputs[2]).mode = MATROXFB_OUTPUT_MODE_MONITOR;
diff -urdN linux/drivers/video/matrox/matroxfb_maven.c linux/drivers/video/matrox/matroxfb_maven.c
--- linux/drivers/video/matrox/matroxfb_maven.c 2004-05-22 18:37:59.000000000 +0200
+++ linux/drivers/video/matrox/matroxfb_maven.c 2004-05-22 20:05:04.000000000 +0200
@@ -1188,7 +1188,7 @@
md->client = clnt;
down_write(&ACCESS_FBINFO(altout.lock));
ACCESS_FBINFO(outputs[1]).output = &maven_altout;
- ACCESS_FBINFO(outputs[1]).src = MATROXFB_SRC_NONE;
+ ACCESS_FBINFO(outputs[1]).src = ACCESS_FBINFO(outputs[1]).default_src;
ACCESS_FBINFO(outputs[1]).data = md;
ACCESS_FBINFO(outputs[1]).mode = MATROXFB_OUTPUT_MODE_MONITOR;
up_write(&ACCESS_FBINFO(altout.lock));
@@ -1249,6 +1249,7 @@
err = -ENOMEM;
goto ERROR0;
}
+ memset(new_client, 0, sizeof(*new_client) + sizeof(*data));
data = (struct maven_data*)(new_client + 1);
i2c_set_clientdata(new_client, data);
new_client->addr = address;
|
|
From: Helge H. <hel...@ai...> - 2004-05-19 12:05:44
|
Petr Vandrovec wrote: >On 19 May 04 at 11:10, Svetoslav Slavtchev wrote: > > >>>I'm considering patching it so it'll boot up with separate outputs instead >>>of mirroring by default. This should ideally be a kernel command >>>line option, as the current default is useful for those with only one >>>screen. (But then, why get a G550 if you use one screen only . . .) >>> >>> >>Petr refused to help me on this issue, >>do you have idea how to patch it ? >> >> > >I have no idea what you are talking about... > >I sent you which values you should replace in the driver if you want >mapping which is incompatible with BIOS, with Windows drivers, with XFree >and with all singlehead configurations: Just replace output #1 source in the >matroxfb_g450.c::matroxfb_g450_connect with CRTC2 instead of using CRTC1, >and you are done. > >- ACCESS_FBINFO(outputs[1]).src = MATROXFB_SRC_CRTC1; >+ ACCESS_FBINFO(outputs[1]).src = MATROXFB_SRC_CRTC2; > > >But then do not complain that analog output described as PRIMARY in the >matrox documentation displays CRTC2 and not CRTC1 (i.e. it brokes >all analog singlehead configs and thus consider it vetoed for stock >kernel). > How about a kernel parameter solution? I.e. your current setup is the default, but someone who specifies matrox:twoscreens on the kernel command line (or module parameter) gets the first framebuffer displayed on the first output, _and_ the second framebuffer displayed on the second output. This would not upset compatibility with default configurations, and still allow booting with two independent screens for those who have them. (And two independent terminals, when ruby is in use also.) We don't need to alter the driver for everybody, merely making an option. How about it? Helge Hafting |
|
From: Mark H. <Mar...@xs...> - 2004-05-19 12:27:14
|
Hi,
> How about a kernel parameter solution?
> I.e. your current setup is the default, but someone who specifies
> matrox:twoscreens
> on the kernel command line (or module parameter) gets the first
> framebuffer displayed on the first output, _and_ the second framebuffer
> displayed on the second output.
I like this idea!
I don't need auto-detect of my devices, I already know which devices
are connected :-)
But I would like a more generic solution (since I have 2 matrox cards :-),
e.g. my current setup could be:
matrox:out0=vga,out1=vga,out2=vga,out3=paltv
Or perhaps even a video mode per output could be specified as is now
done with the kernel 'video' parameter.
Would it be hard to implement such a paramater?
This way all my outputs can be set-up correctly right from the kernel
commandline, and I get the right output on the right screen from boot.
Would this also solve the problem where switching videomodes causes the
heads to both show crtc1 output?
Hmm, guess I have some tinkering to do again :-)
> We don't need to alter the driver for everybody, merely making an
> option. How about it?
Couldn't agree more :-)
Mark.
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X