Menu
▾
▴
Re: G550DH + G450DH Framebuffer succes & directfb question.
|
From: Helge H. <hel...@ai...> - 2004-05-19 08:43:48
|
Svetoslav Slavtchev wrote: >>>I managed to find a couple of matrox cards (G550 dual head AGP and a >>> >>> >>G450 >> >> >>>dualhead PCI card), and decided to give it a go with ruby. >>>I did not succeed in setting up a working dualhead X environment yet >>>(although Xinerama works), but with framebuffer i have everything >>> >>> >>workingnow on kernel 2.6.5, even with modular matroxfb & fbcon drivers. >> >> >There are > > >>>still a few issues (I think Helge also mentioned some of them before): >>> >>> * upon loading of the matroxfb drivers, all framebuffers show a >>> >>> >>garbled >> >> >>> screen. >>> >>> >>This is a bug in the mainline kernel as well. The problem is VGA text >>console is not flushing it text buffers before the framebuffer driver >>takes over and then redraw the buffer. Another problem is some framebuffer >>drivers call printk while initializing. When takeover_console is called >>the printk could be called while the hardware is in the in between state >>of vga text mode and graphics mode. The console layer wants to still print >>something to the screen but the hardware is not ready for that. >> >> >> >>> * when loading fbcon, the garbled screen cleans up (mostly), but on >>> >>> >>the >> >> >>> main console I see a big white rectangle. On none of the consoles >>> >>> >>I >> >> >>> can see the login prompt, but it appears after pressing enter key >>> >>> >>:-) >> >>I have seen that before. The white rectangle is the size of the earlier >>console resolution you just toke over. I see this when I go from vgacon to >>neofb with fbcon. The fbdev layer will most likely end up doing a memory >>clear out before taking over as a fix. >> >> >> >>> * when switching virtual console on the main console with F1-F6 >>> >>> >>keys, >> >> >>> the framebuffer setup is somehow messed up and so the main console >>> >>> >>is >> >> >>> also shown on the second head. Rerunning the matroxset commands >>> >>> >>does >> >> >>> not help, but after rerunning my 'reset_matrox' script which also >>> uses fbset to setup the framebuffers, everything works again. >>> >>> >>The matrox is a funny driver. >> >> > >agree :( > > > >>I don't think the matroxset commands where >>meant to be used with the ruby kernel. >> >> > >there is nothing wrong with matroxset with ruby, >and it's the only way to separate the outputs >of the two heads of G4x0DH or G550DH >else both fbdevs are mirrored :( > >does anyone have a better solution ? > > 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 . . .) >( >of course it would be great to get independant fbcon >without matroxset, but i'm not aware of such possibility >) > > > >>>P.S. >>>Did any of you have any success setting up dual independent >>> >>> >>(accelerated) X >> >> >>>servers on the G550? I'm very interested to see your XF86Config! >>> >>> >>Me too. I like to give a demo of that. >> >> > >IMO, this is only possible with the Matrox MMS series cards (G200 or G450) >two/ four heads by choice(pocket) , but they are really too >expensive >it's just that the hardware is missing > > It is possible on a G550, _if_ you stick to 2D-accelearation only. Recipe: Install a ruby kernel, get it going with two independent consoles. Also connect two independent mice. Using framebuffers is one way to achieve this. Install the accelerated X server. Run two such servers, on separate tty's so they will run simultaneously. Use two mostly identical XF86Config's, they should specify separate mice though. At least one of them must use a software mouse cursor, as the G550 only have one of these. No need for any prefbusid/isolatedevice because they run on the same card - and therefore they don't try to disable each other's cards. This works in practice, the two servers didn't corrupt each others state, not even with a smp machine that really lets the two drivers execute simultaneously. This recipe gives two independent accelerated xservers, using separate keyboards & mice. Unfortunately they happen to run on the same screen, and tend to paint over each other all the time. I didn't go further than this, but believe you can use xinerama and simply tell the users to not abuse into each other's screens. Perhaps it is possible to do better than that - if anyone can figure out how to run accelerated X on the second head _only_. (First head only id trivial - it is the standard setup with xinerama off.) Note that this didn't work well with 3D, last time I tried. One server using 3D blocks the other xserver 99% of the time, meaning the other user can't work efficiently if the first user is using a game. Even 2D operations get blocked like this. 3D on both servers were impossible, even though two 3D clients on a single server works fine. Things seems to happen fast on the DRI front, but I don't really expect this to work anytime soon. Virtualizing the 3D accelerator will make this "easy", but the implied slowdown might not be desireable. Zoltán Böszörményi already showed dual 3D using two independent cards though, I believe that is the way to go for dual gaming. Helge Hafting |
