Re: [Linux-fbdev-devel] fbdev upstream

[Benjamin H. <be...@ke...>]

> That's my ultimate goal.  There's a couple of things I'm working on to 
> make that more robust.   The DDC2/EDID works great, as long as my KVM is 
> selecting that machine while it boots.   There's also three seperate 
> lists of video modes.  Two in the kernel which are the regular and vesa 
> lists and the modedb that fbset uses.  What I want to eventually do is 
> consolidate all that information along with custom timing modes and 
> corrections to the DDC2 info based on monitor model and move that all to 
> userspace.   Then a script called on startup/shutdown/manually can take 
> that database along with the current EDID and archive it into a 
> intiramfs file fragment (you can concatenate a bunch together and the 
> kernel will unpack them all).  When the kernel boots it can access this 
> information and pull in what it needs for the current card & monitor 
> combo.  Then it can delete the file from the initramfs to free memory or 
> we can use my patch that makes initramfs swappable.

Moving that to userland is a 2.7 goal. For 2.6, we should probably
stay around what I'm doing in radeonfb. Also, we want the machine to
have some sort of working console at boot. The VGA console exist
only on some platforms like x86, for example, PPC needs a working mode
at boot time.

Also, some drivers may have different monitor probing mecanism that
DDC2/EDID. For example, old PowerMac drivers can probe the monitor
type using an old Apple sepcific mecanism that leads to a modelist
(macmodes) which is different. We currently don't deal with that
very well though.
 
> Yes.  I'm putting this into fbcon.  I agree that having the common stuff 
> concentrated in one spot is better that having it scattered amongst all 
> the drivers.  Much cleaner and less maintenance problems.

The important point here is that fbdev must remain independant of fbcon,
you can have fbdev without fbcon, all of the console cruft is not
fbdev business.

> >I don't know about that one. It would be interesting to redo some
> >comparison between XFree CVS "nv" driver and rivafb.
> >
> 
> I though I read on the list somewhere that someone already fixed the 
> nvidia hw cursor problem.  I'll have to do a search for it.
> 
> >Something else I noticed: After playing with resize & console switches
> >for a while, I had the kernel oops somewhere with this code path:
> >
> >sys_write -> vfs_write -> pipe_write -> __wake_up -> __wake_up_common
> >then jumping to random place.
> >  
> >
> 
> I noticed some strangeness like that as well depending how it took to do 
> the video mode switch.  The radeonfb driver does a yield call or 
> something (can't remember at the top of my head) and if a timer kicks in 
> it complains about "schedule while atomic".  The resize loop problem 
> also triggered various oops.  A lot of stuff went away with that call to 
> do_blank_screen(1) I put in as it shuts down the cursor timer and puts a 
> few other things on hold.  I think a mechanism that would replace that 
> do_blank_screen(1) functionality between the vt code, fbcon and fbdev 
> layers that can be initiated from any of the three is needed.  That way 
> if any one of the three layers needs to do something it can tell the 
> other two to suspend operations until it's finished.

We need a way to properly suspend cursor & blanking interrupts and synchronize
them (I'd personally move blanking down to task time with schedule work and
just take the console semaphore)

Ben.