[lkml]   [2001]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Huge console switching lags

> >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
More majordomo info at
Please read the FAQ at

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