Adi Oanca <adioanca@xxxxxxxxxxxxx> wrote: > >> Yes, this is exactly what I'm proposing a VirtualScreen class. > >>(with it's attached virtual HW Interface (funny combination of > > > words > >>:-P) ) > >>>This way, the ServerWindow code would stay clean. > >> Very! :-) > > Ah, for the first I see a benefit of a VirtualScreen class. > phew! :-) Ah, communication finally works out :-) > >>> Yes, I think this could be a DisplayDriver class. I think this > >>> approach is so simple, we could even have this ready for R1. > >> From what I can tell, Axel really wants this ready for R1! :-) > > Sounds good :-) > > I think it's important that the design will allow most of the > > changes > > we want to do later as well. Wether or not the > > MultiplexDisplayDriver > > will be there or not is less important - although it would > > certainly be > > great to have it :-) > Aren't we doing just that? :-) Yes, indeed :-) > > If we really want to think ahead, we should already sketch out a > > better > > accelerant API that understands multi-head; and this should then be > > the > > basis for HWInterface. AFAICT the changes would be minimal to that > > class anyway. > I'm not too much into drivers... but why do you need to thread a > multi-head card different than 2 separate cards? (because of the > mirroring feature?) If it's a true multi-head card, it would probably not matter that much, indeed. But there might be a lot of issues with this: 1) dependencies from one head to the other with respect to max. resolution, frequency, whatever 2) maybe only one hardware cursor - can we move it around between the heads? 3) special features, like duplicated hardware overlay (window on one screen, full-screen on the other) 4) card memory must be divided between the cards (thus, a single allocator for both would be wanted) 5) maybe only one head can be accelerated - can we switch them on-the- fly? 6) maybe only one head with 3D acceleration? 7) probably more I don't think about - I would guess that these issues could be taken care of much easier when the app_server knows it's the same card, and when there are some functions that communicate between the heads In any way, I guess Rudolf could give us a lot more insight here (and prove me wrong where necessary :)), and maybe he has already in the archives of this list (or the IK team list). I think mirroring itself can "easily" be done by the multiplexing display driver. Bye, Axel.