Re: fbdv/fbcon pending problems

[James Simmons]

> I would appreciate if you did so ;) Please let me know what you find.

Okay. 

> I have this problem since the very beginning. The very first
> shift-pageup to display things properly from the back buffer, but to not
> _erase_ properly, until you do a bit of ping pong (down up down up) so
> that your screen end up properly refreshed.

:-( 
 
> I never use modules for fbdevs

Its a handy way to track down bugs :-)

> It does. Radeonfb did one step in this direction, but that's not
> enough. _BUT_ we still need to differenciate between a full mode 
> passed from userland from a mode where we _KNOW_ everything is
> bogus but width/height... In the later case, we really want to
> find a mode that is just large enough for the passed in width/height
> (but not smaller, or just fail if not found) and with the same
> hfreq if possible as the current mode. That's really a different
> request than a full blown mode coming from userland (like a 'tuning'
> tool or whatever...)
> 
> The FB_ACTIVATE_FIND is just that. It justs tells the driver to
> pick up a mode based on width/height only. We know the rest of
> the var is bogus.

Its still possible that the user sends in bogus data using 
FB_ACTIVATE_FIND. 
 
> Yes, but that's less urgent than the other ones. 

I agree.


> We really need to fix
> those basic behaviour problems before multihead. Multihead will come
> later as I will implement dual head support in radeonfb. That leads to
> a while bunch of problems with the userland API that need to be improed
> too, 

That is what sysfs is for :-) 

> and that leads to the problem of properly soft booting additional
> cards. I have various ideas to address those problems, but that's
> definitely less urgent than the list I wrote down.

We will talk about this later.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/