Re: [patch] radeonfb: FB_WAITFORVSYNC implementation

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Sat, 2005-03-12 at 17:29 -0800, Jon Smirl wrote:
> --- Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> > 
> > > When we get merged my thought was to let fbdev catch the vsync IRQ
> > and
> > > then chain into DRM. In that model fbdev becomes the mini-driver.
> > > Right now I don't think there is any other solution than merging
> > > fbdev/DRM that doesn't result in some kind of dead on VT switch
> > > scenario.
> > 
> > A VT switch should stop all asynchronous activity (interrupt, DRM,
> > etc...). X already stops the DRM on switch-out, this could be
> > enforced
> > by the kernel.
> 
> The stopping interrupts on VT switch doesn't really work in a multiuser
> system. That's what burnt me with radeonfb and X. My radeonfb was
> essentially running a different user. X caught a VT switch from the
> first user and stomped on the second.
> 
> fbdev doesn't know about VT switch and shouldn't. It's fbcon that knows
> about it.

Currently, we still need a few hacks to make things work, including that
sort of thing. In fact, the problem at this point is that once the VT
subsystem has lost ownership of the console (because X switch it to
KD_GRAPHICS), we should assume that all video cards, including the ones
not used by fbcon or whatever, have lost ownership.

That sucks, but we don't have a choice until we have proper arbitration.

> Why don't we just make X/DRM/fbdev all play nice with each other, then
> nothing has to be stopped on VT switch.

We do and are working toward that goal, remember ? 

Ben.




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click