linuxconsole-dev

Re: working multihead

[Petr V. <VAN...@vc...>]

On 24 Jan 01 at 18:14, Brad Midgley wrote:
> http://cambuca.ldhs.cetuc.puc-rio.br/multiuser/
> 
> he asks out loud but i'm pretty sure it wouldn't work with a card like a dual-head matrox since
> two instances of X couldn't coordinate access to the card. that's why the kernel would need to
> provide a framebuffer interface to each screen (and demonstrates why we really need solid kernel
> support for doing this properly)

If it does not work with dualhead G400, then he did something wrong:

/dev/fb0:
mode "1024x768-60"
    # D: 64.994 MHz, H: 48.359 kHz, V: 59.998 Hz
    geometry 1024 768 1024 8188 8
    timings 15386 160 32 30 4 128 4
    accel true
    rgba 8/0,8/0,8/0,0/0
endmode

Frame buffer device information:
    Name        : MATROX
    Address     : 0xdc000000
    Size        : 8384512
    Type        : PACKED PIXELS
    Visual      : PSEUDOCOLOR
    XPanStep    : 8
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 1024
    MMIO Address: 0xdfefc000
    MMIO Size   : 16384
    Accelerator : Matrox G400


/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     : 0xdc7ff000
    Size        : 8388608
    Type        : PACKED PIXELS
    Visual      : TRUECOLOR
    XPanStep    : 8
    YPanStep    : 1
    YWrapStep   : 0
    LineLength  : 2560
    MMIO Address: 0xdfefc000
    MMIO Size   : 16384
    Accelerator : No


If his driver tries to drive /dev/fb1 with matrox accelerated driver,
it is for sure wrong - fb1 clearly says that there is no acceleration
for this head. And each head returns 8MB (well, 7.9 and 8) of non-overlapping
memory, so I do not see any problem here too.

Only problem which can arise is that fb1 supports 16/32bpp only, while
fb0 supports text/8/16/24/32. But it is again X/Xinerama problem, not
fb one...

Or do I miss something?
                                    Best regards,
                                        Petr Vandrovec
                                        van...@vc...
                                        

Re: working multihead

[Brad M. <br...@tu...>]

Petr

> If it does not work with dualhead G400, then he did something wrong:

i wasn't aware that framebuffer could provide access to both screens on a g400. 

i guess i was basing that on the fact that the matrox-endorsed dual-monitor support for x is
provided by a closed-source xf4 module -- fb is not used in that scenario.

that's great we have fb driving two outputs on one card. i looked into doing that for the ati
ltpro a while back. back then there was no clear way to set two framebuffers to be mirrored
(taking advantage of the chip's native ability to mirror). mirroring is the main motivation for
proper ltpro support.

-- 
Brad
br...@tu...      http://www.turbolinux.com/~brad/

Re: working multihead

[Miguel F. <mi...@ce...>]

   Humm, I'm not pretty sure of what is going on, I haven't read the 
original post(s) of this thread...

   I think Brad is right, the multihead with multiple instances of 
XFree86 in a Matrox G400 should only be possible by using 
framebuffer interface. But as I have never been able to use fb with 
my hardware I haven't thought of this before. I wrote in the article 
that it should NOT work with boards like that.

   BTW, I may have removed something important for framebuffer 
from the init routines. If you want to use it please check for any 
mistakes the patch might have. Any updates on this issue are 
greatly appreciated...

Regards,

Miguel Freitas


On 24 Jan 01, at 19:18, Petr Vandrovec wrote:

> On 24 Jan 01 at 18:14, Brad Midgley wrote:
> > http://cambuca.ldhs.cetuc.puc-rio.br/multiuser/
> > 
> > he asks out loud but i'm pretty sure it wouldn't work with a card like a
> > dual-head matrox since two instances of X couldn't coordinate access to
> > the card. that's why the kernel would need to provide a framebuffer
> > interface to each screen (and demonstrates why we really need solid
> > kernel support for doing this properly)
> 
> If it does not work with dualhead G400, then he did something wrong:
> 
> (...)
> 
> If his driver tries to drive /dev/fb1 with matrox accelerated driver, it
> is for sure wrong - fb1 clearly says that there is no acceleration for
> this head. And each head returns 8MB (well, 7.9 and 8) of non-overlapping
> memory, so I do not see any problem here too.
> 
> Only problem which can arise is that fb1 supports 16/32bpp only, while fb0
> supports text/8/16/24/32. But it is again X/Xinerama problem, not fb
> one...
> 
> Or do I miss something?
>                                     Best regards,
>                                      Petr Vandrovec
>                                      van...@vc...
> 

Re: working multihead

[Petr V. <VAN...@vc...>]

On 24 Jan 01 at 21:21, Brad Midgley wrote:
> > If it does not work with dualhead G400, then he did something wrong:
> 
> i wasn't aware that framebuffer could provide access to both screens on a g400. 
> 
> i guess i was basing that on the fact that the matrox-endorsed dual-monitor support for x is
> provided by a closed-source xf4 module -- fb is not used in that scenario.

Yes. It is really unfortunate that G400 driver in XFree is somewhere in
DGA broken - if you run it with 'UseFBDev' on G450, normal X works, but
DGA access (vmware) still accesses ramdac directly, killing monitor (200kHz
horizontal, 200 Hz vertical) and dies in endless loop (PLL not synced) :-(
Matrox driver works fine with UseFBDev.

> that's great we have fb driving two outputs on one card. i looked into doing that for the ati
> ltpro a while back. back then there was no clear way to set two framebuffers to be mirrored
> (taking advantage of the chip's native ability to mirror). mirroring is the main motivation for
> proper ltpro support.

It is only mode I do not support, as it would require too many changes to
my code, and also API is not clear yet... You always want independent
left/right/hslen/upper/lower/vslen/pixclock (and eventually xzoom/yzoom). 
Sometime you want independent xres/yres/xoffset/yoffset, but sometime you 
want them same for both CRTCs... And sometime you do not have enough pixclock
sources, so sometime secondary pixclock can be only few exact values
(33MHz (PCI), 66MHz (AGP), 150MHz (memory clocks), XXX (first head clocks)).
                                                Best regards,
                                                        Petr Vandrovec
                                                        van...@vc...