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...