Re: TiBook Dual Display
> > Sure, as a first approximation I'd perhaps recommend to go without
> > acceleration anyway. I'm not sure how much more synchronization than plain
> > 'wait until accel idle' would be required (which happens anyway IIRC).
>
> You don't necessarily have to wait for the engine to be idle. You do have to
> realize the current context isn't the one of the head you want to do an
> operation on. If you want to do that transparently inside the framebuffer
> device, you have to map the MMIO area twice and fault on access to the
> inactive one, saving and restoring registers which could make a difference,
> potentially all of them. I doubt that would be very efficient.
Sounds like an interesting concept though (I forgot about mapping MMIO
twice but you're right on that; that's the cleaner way).
Does Linus allow hacks like having special page fault handling code for
that purpose? Or would you rather have a signal handler in user space
handle that?
What are the relevant registers for the accel BTW? Just a few might not be
too much overhead.
> > I'd consider it a Big Problem as soon as XFree86 can switch color depth
> > on the fly :-)
>
> Expect that to happen sooner rather than later. I don't know if the Resize
> and Rotate extension will be in 4.2.0 but it's certainly possible.
Fine, I've been waiting for that for a long time :-)
> > > > X gurus please correct me if the current X release already supports
> > > > Xinereama on rage128 out of the box
>
> Actually, that's the wrong question BTW. Xinerama is a driver independent
> extension. My answer is to a question along the lines of 'does the r128
> driver support single-chip dualhead', which I'm sure you really meant to ask.
> :)
Right - having Xinerama on two different cards should be OK already. I
meant to say Xinerama on two framebuffers that map to the same card (this
would imply UseFBDev probably?).
> > We'll hear about that from him, I'm sure.
>
> He's not subscribed to this list though AFAIK.
But he usually announces major milestones. Maybe on linuxppc-dev :-)
Michael
Reply to: