FreeLists / haiku-appserver / [haiku-appserver] Re: Refactoring

["Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>]

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.