Am Freitag, 2. März 2007 16:24 schrieb Tilman Sauerbeck:
Hans-Jürgen Koch [2007-03-02 16:10]:
quoted
Am Freitag 02 März 2007 15:39 schrieb Tilman Sauerbeck:
quoted
Hans-Jürgen Koch [2007-03-02 10:53]:
quoted
I'm the proud owner of two NEC MultiSync 2070WNX monitors (1680x1050)
and a Matrox G550 dual DVI card. I'm now trying to set up a dual head
configuration with this equipment.
[snip]
Is this a known limitation of matroxfb? Or a X server bug?
AFAIK matroxfb doesn't support the G550 dual DVI card. The mga X driver
certainly doesn't support it yet.
Well, at the moment I'm using the VGA outputs. Current status is:
I believe/suspect the hardware doesn't care whether you use the 2VGA
cable or the 2DVI cable. Unfortunately, I only have the dual-dvi cable
so I cannot be sure. Last time I had a close look at dual-dvi was around
christmas and I don't remember all the details ;)
quoted
* Without X (boot, VT) I get clean 1280x1024 on both monitors. The
monitors interpolate that to their native resolution, both show the same
image.
Meanwhile, I managed to get 1680x1050 to work with matroxfb. Here's proof that
both monitors really work:
http://www.hjk-az.de/temp/g550-dualhead-fbcon-small.jpg
The left monitor is the primary head (/dev/fb0) and shows text on a VT. There
I issued a command "fbi -d /dev/fb1 image.jpg" that shows a JPEG image on the
second monitor. Note that there is no X running (The black-on-white text is
due to a small patch I usually apply to vt.c).
quoted
* With a xinerama configuration, X starts without any (EE) errors.
Monitor1 shows a clean 1680x1050 image, Monitor2 a distorted image. I can
move the mouse or windows from one monitor to the other. The reason for
the distortion on monitor2 is most probably that the card is still
configured for 1280x1024 while the X server thinks it's 1680x1050.
Meanwhile I doubt this explanation. Here's what fbset has to say:
$ fbset -fb /dev/fb1 --show
mode "1680x1050-60"
# D: 135.501 MHz, H: 65.396 kHz, V: 59.997 Hz
geometry 1680 1050 1680 1050 32
timings 7380 32 224 32 4 136 4
rgba 8/16,8/8,8/0,8/24
endmode
So, even fbset thinks it's 1680x1050. But where does the distortion come
from???
I'm curious, can you describe the distortion in more detail/take a
photo?
Yes, now I've got one:
http://www.hjk-az.de/temp/g550-xinerama-error-small.jpg
This shows a KDE login screen. Note that KDE scaled the background image with
the Debian logo to cover both screens. The right screen is distorted,
but "working": If I move a window over to the second screen, I see changes
there.
Conclusion:
@matroxfb developers: Thanks a lot, guys! Well done! Most people I asked about
having a dual-head framebuffer console at 1680x1050 thought it would be
impossible.
@mga xorg developers: Well... Can you tell me why the kernel guys can
initialize and use the second head and you can't? If you can give me hints
where in the source I can start to look for the bug, I'm willing to spend
some time there. Is there something I could try in my configuration?
Any hints?
Thanks,
Hans
From: Petr Vandrovec <hidden> Date: 2007-03-05 04:59:41
Hans-Jürgen Koch wrote:
Am Freitag, 2. März 2007 16:24 schrieb Tilman Sauerbeck:
Meanwhile I doubt this explanation. Here's what fbset has to say:
$ fbset -fb /dev/fb1 --show
mode "1680x1050-60"
# D: 135.501 MHz, H: 65.396 kHz, V: 59.997 Hz
geometry 1680 1050 1680 1050 32
timings 7380 32 224 32 4 136 4
rgba 8/16,8/8,8/0,8/24
endmode
So, even fbset thinks it's 1680x1050. But where does the distortion come
from???
Can you try setting vxres for second head from 1680 to 1696, or 1728?
Maybe X look at vxres and not at framebuffer line length (what fbset -i
reports for line length?)
If you are using mga driver for second head in X, then probably X driver
does not know correctly what are hardware restrictions for second CRTC
(I think they've changed between G400 and G450), asks for 1680 but gets
1664, and this causes those diagonal lines you see.
Petr
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Am Freitag, 2. M�rz 2007 16:24 schrieb Tilman Sauerbeck:
Meanwhile I doubt this explanation. Here's what fbset has to say:
$ fbset -fb /dev/fb1 --show
mode "1680x1050-60"
# D: 135.501 MHz, H: 65.396 kHz, V: 59.997 Hz
geometry 1680 1050 1680 1050 32
timings 7380 32 224 32 4 136 4
rgba 8/16,8/8,8/0,8/24
endmode
So, even fbset thinks it's 1680x1050. But where does the distortion come
from???
Can you try setting vxres for second head from 1680 to 1696, or 1728?
Maybe X look at vxres and not at framebuffer line length (what fbset -i
reports for line length?)
These days at least the X server in Debian looks correctly at the frame buffer
line length, else it wouldn't work on PS3 with non-fullscreen modes.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
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
@matroxfb developers: Thanks a lot, guys! Well done! Most people I asked about
having a dual-head framebuffer console at 1680x1050 thought it would be
impossible.
@mga xorg developers: Well... Can you tell me why the kernel guys can
initialize and use the second head and you can't? If you can give me hints
where in the source I can start to look for the bug, I'm willing to spend
some time there. Is there something I could try in my configuration?
matroxfb is much better organized wrt dual-head configurations. It also
has support for some hardware that xf86-video-mga doesn't support yet.
I'm working on that.
I think you might be hitting this bug:
https://bugs.freedesktop.org/show_bug.cgi?id=9854
I just attached a temporary fix that you could try.
Regards,
Tilman
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Am Montag, 5. März 2007 05:59 schrieb Petr Vandrovec:
Hans-Jürgen Koch wrote:
quoted
Am Freitag, 2. März 2007 16:24 schrieb Tilman Sauerbeck:
Meanwhile I doubt this explanation. Here's what fbset has to say:
$ fbset -fb /dev/fb1 --show
mode "1680x1050-60"
# D: 135.501 MHz, H: 65.396 kHz, V: 59.997 Hz
geometry 1680 1050 1680 1050 32
timings 7380 32 224 32 4 136 4
rgba 8/16,8/8,8/0,8/24
endmode
So, even fbset thinks it's 1680x1050. But where does the distortion come
from???
Can you try setting vxres for second head from 1680 to 1696, or 1728?
Maybe X look at vxres and not at framebuffer line length (what fbset -i
reports for line length?)
Thanks a lot, Petr, you're on the right track! With
fbset -fb /dev/fb1 -g 1680 1050 1696 1050 32 -t 7380 224 32 32 4 136 4
the distortion disappears. At the moment I have to do this manually after X
has started. I'll have to experiment a bit with my configurations, but at
least now I have working xinerama.
Thanks again for your help.
Hans
From: Michel Dänzer <hidden> Date: 2007-03-05 08:09:58
On Mon, 2007-03-05 at 07:33 +0100, Geert Uytterhoeven wrote:
On Sun, 4 Mar 2007, Petr Vandrovec wrote:
quoted
Hans-Jrgen Koch wrote:
quoted
Am Freitag, 2. Mrz 2007 16:24 schrieb Tilman Sauerbeck:
Meanwhile I doubt this explanation. Here's what fbset has to say:
$ fbset -fb /dev/fb1 --show
mode "1680x1050-60"
# D: 135.501 MHz, H: 65.396 kHz, V: 59.997 Hz
geometry 1680 1050 1680 1050 32
timings 7380 32 224 32 4 136 4
rgba 8/16,8/8,8/0,8/24
endmode
So, even fbset thinks it's 1680x1050. But where does the distortion come
from???
Can you try setting vxres for second head from 1680 to 1696, or 1728?
Maybe X look at vxres and not at framebuffer line length (what fbset -i
reports for line length?)
These days at least the X server in Debian looks correctly at the frame buffer
line length, else it wouldn't work on PS3 with non-fullscreen modes.
It depends on the driver. The fbdev and radeon drivers should handle it
correctly, not sure about others.
--
Earthling Michel Dänzer | http://tungstengraphics.com
Libre software enthusiast | Debian, X and DRI developer
Am Montag, 5. März 2007 05:59 schrieb Petr Vandrovec:
Can you try setting vxres for second head from 1680 to 1696, or 1728?
Maybe X look at vxres and not at framebuffer line length (what fbset -i
reports for line length?)
Here are more details:
1.) I boot my kernel (vanilla 2.6.20.1) with the following parameters:
video=matroxfb:outputs:120,pixclock:7380,xres:1680,yres:1050,upper:32,
lower:4,left:32,right:224,hslen:136,vslen:4,depth:32
This initializes the primary head correctly. The second head is probably
wrong, because the monitor's on screen message complains about a non-ideal
resolution.
2.) X starts with Xinerama=On, using this modeline for each monitor:
Modeline "1680x1050@60" 154.20 1680 1712 2296 2328 1050 1071 1081 1103
3.) After that, fbset -i reports this:
$ fbset -i -fb /dev/fb0
mode "1680x1050-60"
# D: 135.501 MHz, H: 65.396 kHz, V: 59.997 Hz
geometry 1680 1050 1696 2473 32
timings 7380 32 224 32 4 136 4
accel true
rgba 8/16,8/8,8/0,8/24
endmode
Frame buffer device information:
Name : MATROX
Address : 0xd4000000
Size : 16777216
Type : PACKED PIXELS
Visual : TRUECOLOR
XPanStep : 8
YPanStep : 1
YWrapStep : 0
LineLength : 6784
MMIO Address: 0xd6000000
MMIO Size : 16384
Accelerator : Matrox G400
$ fbset -i -fb /dev/fb1
mode "640x480-60"
# D: 25.176 MHz, H: 31.469 kHz, V: 59.942 Hz
geometry 640 480 640 480 32
timings 39721 48 16 33 10 96 2
rgba 8/16,8/8,8/0,8/24
endmode
Frame buffer device information:
Name : MATROX DH
Address : 0xd5800000
Size : 8388608
Type : PACKED PIXELS
Visual : TRUECOLOR
XPanStep : 8
YPanStep : 1
YWrapStep : 0
LineLength : 2560
MMIO Address: 0xd6000000
MMIO Size : 16384
Accelerator : No
As you can see, the second monitor fell back to VGA resolution, but the logs
tell that X thinks it successfully switched to 1680x1050. The KDE control
center reports the same. The image on the second monitor is distorted.
4.) I then issue the following command:
$ fbset -fb /dev/fb1 -g 1680 1050 1696 1050 32 -t 7380 224 32 32 4 136 4
With that, the image on the second monitor immediately becomes clear, and I
have a fully working xinerama configuration then.
As far as I can see, fbset is the only way to initialize the second head
properly. Neither matroxfb nor mga do it correctly with 1680x1050.
Cheers,
Hans
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
From: Petr Vandrovec <hidden> Date: 2007-03-06 09:26:07
Hans-Jürgen Koch wrote:
Am Montag, 5. März 2007 05:59 schrieb Petr Vandrovec:
quoted
Can you try setting vxres for second head from 1680 to 1696, or 1728?
Maybe X look at vxres and not at framebuffer line length (what fbset -i
reports for line length?)
Here are more details:
1.) I boot my kernel (vanilla 2.6.20.1) with the following parameters:
video=matroxfb:outputs:120,pixclock:7380,xres:1680,yres:1050,upper:32,
lower:4,left:32,right:224,hslen:136,vslen:4,depth:32
This initializes the primary head correctly. The second head is probably
wrong, because the monitor's on screen message complains about a non-ideal
resolution.
Second head always starts in 640x480/32bpp. You have to use fbset to
switch it to different mode, so matroxfb works fine as far as I can tell.
As you can see, the second monitor fell back to VGA resolution, but the logs
tell that X thinks it successfully switched to 1680x1050. The KDE control
center reports the same. The image on the second monitor is distorted.
Because X (mga driver) was programming hardware...
4.) I then issue the following command:
$ fbset -fb /dev/fb1 -g 1680 1050 1696 1050 32 -t 7380 224 32 32 4 136 4
With that, the image on the second monitor immediately becomes clear, and I
have a fully working xinerama configuration then.
Yes, and this corrects X programming mistake.
As far as I can see, fbset is the only way to initialize the second head
properly. Neither matroxfb nor mga do it correctly with 1680x1050.
Well, fbset == matroxfb, so I do not quite understand your complaint.
Petr
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Am Dienstag, 6. März 2007 10:25 schrieb Petr Vandrovec:
Hans-Jürgen Koch wrote:
quoted
Am Montag, 5. März 2007 05:59 schrieb Petr Vandrovec:
quoted
Can you try setting vxres for second head from 1680 to 1696, or 1728?
Maybe X look at vxres and not at framebuffer line length (what fbset -i
reports for line length?)
Here are more details:
1.) I boot my kernel (vanilla 2.6.20.1) with the following parameters:
video=matroxfb:outputs:120,pixclock:7380,xres:1680,yres:1050,upper:32,
lower:4,left:32,right:224,hslen:136,vslen:4,depth:32
This initializes the primary head correctly. The second head is probably
wrong, because the monitor's on screen message complains about a
non-ideal resolution.
Second head always starts in 640x480/32bpp. You have to use fbset to
switch it to different mode, so matroxfb works fine as far as I can tell.
quoted
As you can see, the second monitor fell back to VGA resolution, but the
logs tell that X thinks it successfully switched to 1680x1050. The KDE
control center reports the same. The image on the second monitor is
distorted.
Because X (mga driver) was programming hardware...
quoted
4.) I then issue the following command:
$ fbset -fb /dev/fb1 -g 1680 1050 1696 1050 32 -t 7380 224 32 32 4 136 4
With that, the image on the second monitor immediately becomes clear, and
I have a fully working xinerama configuration then.
Yes, and this corrects X programming mistake.
quoted
As far as I can see, fbset is the only way to initialize the second head
properly. Neither matroxfb nor mga do it correctly with 1680x1050.
Well, fbset == matroxfb, so I do not quite understand your complaint.
If matroxfb deliberately initializes the second head to 640x480/32bpp, then it
is OK. I thought the kernel boot parameters would apply to both heads. But on
second thought, I agree, it has to be that way. Otherwise you'd run into
trouble if you had two different monitors connected as there are no
individual settings for both heads.
Thanks for your explanations!
Hans
This initializes the primary head correctly. The second head is probably
wrong, because the monitor's on screen message complains about a non-ideal
resolution.
Second head always starts in 640x480/32bpp. You have to use fbset to
switch it to different mode, so matroxfb works fine as far as I can tell.
With that, the image on the second monitor immediately becomes clear, and I
have a fully working xinerama configuration then.
Yes, and this corrects X programming mistake.
quoted
As far as I can see, fbset is the only way to initialize the second head
properly. Neither matroxfb nor mga do it correctly with 1680x1050.
Well, fbset == matroxfb, so I do not quite understand your complaint.
If I followed this discussion correctly, there's still an issue with matroxfb,
as it doesn't seem to round up xres_virtual to 1696 automatically.
You have to do that yourself.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
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: Petr Vandrovec <hidden> Date: 2007-03-06 11:35:34
Geert Uytterhoeven wrote:
On Tue, 6 Mar 2007, Petr Vandrovec wrote:
quoted
Hans-J�rgen Koch wrote:
quoted
This initializes the primary head correctly. The second head is probably
wrong, because the monitor's on screen message complains about a non-ideal
resolution.
Second head always starts in 640x480/32bpp. You have to use fbset to
switch it to different mode, so matroxfb works fine as far as I can tell.
With that, the image on the second monitor immediately becomes clear, and I
have a fully working xinerama configuration then.
Yes, and this corrects X programming mistake.
quoted
As far as I can see, fbset is the only way to initialize the second head
properly. Neither matroxfb nor mga do it correctly with 1680x1050.
Well, fbset == matroxfb, so I do not quite understand your complaint.
If I followed this discussion correctly, there's still an issue with matroxfb,
as it doesn't seem to round up xres_virtual to 1696 automatically.
You have to do that yourself.
Well, as far as I can tell 1680 is legal line length for 32bit color
mode. In Hans-Jurgen scenario X program display themselves (otherwise
fbset would not report 640x480 on /dev/fb1 once X start), and apparently
screw up rounding. Having to use 1696 should be necessary only for
16bpp, and for such case matroxfb already contains code to round up
value to multiple of 32...
So unless somebody can reproduce problem with using fbdev driver on both
primary and secondary head I do not believe there is any problem to fix
on matroxfb side.
Petr
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Linux-fbdev-devel mailing list
Linux-fbdev-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel