You tell me about it. On a laptop I have, I always have to be extremely
cautious not to say for example cat bigger text files. If I do, then the
whole machine is pretty much jammed, until it is done. During that time
even keyboard input (ctrl-c or changing virtual terminals) does not work.
> accelcon where nearly all the drivers use the video cards accel engine to
> draw for the console. This should nearly eliminate the latency problems.
Is it currently possible to make a driver which leaves the accel engine
do its work on the background so you don't have to wait by polling the
hardware until the operation is done? With issues like this, it is still
possible that bigger blits will cause relatively big latencies. Certainly
not in the tens-of-seconds variety but unacceptable for the causes people
keep arguing here about.
> we most likely will run into problems. So the locking system needs to be
> thought out. By next week I will have multihead running for mdacon and
> vgacon so I will find out.
I haven't got a picture how multihead will be worked out? Will you have
some per-head structure? Then it is natural to move most of the current
global variables and locks in this structure.
> Do you think you can come up with some code to try out. As I said by next
> week I will have multihead running so we can give these ideas a try. As
Not so soon, sorry. I don't have time until thursday earliest.
> for moving the console/vt code to userspace. In theory you can do this
> using /dev/fbX and /dev/eventX to create a userland console.
If only you didn't need to printk fatal oopses/panics/etc, the portion of
code which would have to live in kernel would be pretty minimal.
-- D.
- 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/