lkml.org 
[lkml]   [2000]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [linux-fbdev] fbdev 2.4.0 cleanups
    From
    Date
    James A Simmons <jsimmons@acsu.buffalo.edu> writes:

    > Here is the main reasons why I have it so only one app can open /dev/fb at
    > a time. Its called SMP. Consider two apps running at the same time both
    > with /dev/fb opened. Problem:

    SMP is no different from UP as far as graphics hardware is concerned.
    The PCI/AGP bus will serialize accesses and the card will not notice
    any difference between SMP and two processes task switching in UP.

    > 1)
    > Both apps mmap the MMIO region. Both program the accel engine at the
    > same. Hey the card locks up.
    >
    > 2)
    > DRI and fbdev MMIO region. DRI is using accel engine. Some app running
    > from a xterm mmaps MMIO region then uses accel engine. The card locks up.
    >
    > 3)
    > Someone runs fbset while the X server is using accel engine via /dev/fb
    > or DRI. Card locks up. You should only change the mode when the accel
    > engine is idle.

    Then don't do it.

    > Now do people agree with me that /dev/fb should only be opened once.

    No.
    Having several fbdev apps sleeping on several incative VTs while
    you are running another on the current VT must be possible, otherwise
    you are removing important functionality.

    It's most probably too late to redesign fbdev for safe user access
    for 2.4, but in any case only allowing one open() is not the right
    way for 2.4 or any future kernel version. If you want some safety
    for 2.4, then only allow root processes to map the MMIO region.

    //Marcus
    --
    Signature under construction, please come back later.

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

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