> >A console switch has to wait until queued I/O to that console is complete,
>
> Ok, so fix that. (assuming that's not "waiting on the hardware" queued IO)
Strange you are having this problem. I have been using Morton's patch for
months now with the framebuffer layer and have no problems. Well I have
done some modifications which I will post shortly.
> >Also a console switch on a frame buffer with no hardware banking can take
> >a lot of time.
>
> Oh, *grin*, forgot about those evil framebuffer consoles. (never use them
> myself, they really are freakin' slow.) Arguablly, all access to fbdev's
> should be from a process context (it's like having X in the kernel.)
Well the reason the framebuffer suck is because the current api sucks for
them. It draws pixel by pixel. Slow slow slow!!! I have developed a new
api that takes advantage of the accel engine of graphics hardware. It is
much simpler and more flexiable and most important much much faster. Yes
there exist graphics hardware that are pure dummy framebuffers. Here I
have written soft accels (fillrect, draw image, copy area). They are much
faster than the current implemenation. I haven't even assemblty optimized
them or used MMX type things yet. Once that is done it will be very fast.
The point of the console locking change was because their exist graphics
hardware that is IRQ/DMA based only. Using a spinlock turns off printing
to the screen. Oops, big problem. With the new console locking mechanism
we can use the DMA/irq engine of any graphics card. This is much much
faster than using the mmio region like some of the fbdev drivers do. It is
faster than drawing pixel by pixel but it could be much faster.
-
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/
This archive was generated by hypermail 2b29 : Sun Oct 07 2001 - 21:00:23 EST