lkml.org 
[lkml]   [2004]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2005-03-22 14:01    [W:3.254 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site