Messages in this thread | | | Date | Tue, 24 Feb 2004 01:19:46 +0000 (GMT) | From | James Simmons <> | Subject | Re: fbdv/fbcon pending problems |
| |
> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |