[lkml]   [1998]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: kill -9 <pid of X>
    >>>>> "Albert" == Albert D Cahalan <> writes:

    >>> Huh. OK, so all accels now are to be done with driver-specific
    >>> ioctls?
    >> No in user space

    Albert> So why give userspace a framebuffer device at all? The X
    Albert> server will need to bang the raw hardware anyway. You could
    Albert> have the kernel code just do the /dev/tty* and /dev/vcs*
    Albert> devices, without the useless framebuffer ones. Since X needs
    Albert> privilege to access the accelerator anyway, it might as well
    Albert> just open /dev/mem.

    Because you can do other things than running X-servers on a frame
    buffer device and because it allows you to use the frame buffer device
    to handle things like mode switching.

    Albert> That would be less kernel bloat, even for 680x0 systems with a
    Albert> console! Really, the framebuffer devices don't give us
    Albert> anything useful.

    You are obviously missing the whole point of this, or would you mind
    sending me a patch which will allow me to run the console on a Sparc,
    most m68k boxes & many MIPS, ARM & PPC boxes without setting up the
    video resources in the kernel? /dev/fb gives us a standard way of
    accessing video cards' memory from user space so we don't need to
    reinvent the wheel.

    >> When you want to have accel control in user space, you tell fbdev
    >> and it wont use acceleration for the console until the user space
    >> program finishes with it.

    Albert> That isn't safe. You can't expect to access video memory at
    Albert> all while the X server is running the accelerator. You may
    Albert> crash the card.

    fbdev deals with this, and its only a certain number of cards that are

    Albert> You also need to get into a simple video mode before X starts,
    Albert> so that the X server knows the video mode. You can't do that
    Albert> with VESA.

    Or let the X server use the mode information from /dev/fb and use
    /dev/fb to set the video modes for it.

    Albert> This system just isn't going to cover all PC hardware with
    Albert> full acceleration support in userspace. I'm sure it works just
    Albert> great on your 680x0 machine, but Linux runs on PC hardware
    Albert> too.

    Look at the code and features before commenting please.

    >> We did not do that on purpose, ioctl == context switch and we don't
    >> want that.

    Albert> You don't want it, but I do. Access to the X server is alreay
    Albert> worse than a context switch -- if you are serious, get rid of
    Albert> that.

    Oh, you didn't follow the long thread we had about this on
    linux-kernel some month ago either?

    Albert> The context switches are cheap if you queue a large number of
    Albert> requests. (and cheap if you don't have large numbers) It is a
    Albert> very small price to pay for a reliable system with decent
    Albert> performance.

    No its not - and most of the time you can only queue a very low number
    of requests because you want to sync the blitter before starting new


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:44    [W:0.021 / U:59.088 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site