Re: Patch to framebuffer

[Antonino A. Daplas]

Nathan Cline wrote:
> Hello, this is my first time posting to this list so please forgive me
> if I'm violating protocol in some way. :)  I've written a patch to the
> framebuffer code to modify its behavior a bit. I am running on a
> dual-headed system and I noticed when I was working in one console on
> one monitor, the console on the other monitor was "frozen", not
> updating itself. After some digging through the code I realized this
> is because the two framebuffer drivers share the same framebuffer code
> which stores a single pointer to the "current" virtual console. If a
> VC is not current it is considered invisible and is not updated. 

Yes, there is only 1 active console at one time.  And many multi-head
users has been asking (and confused) about this for some time now.

> So I
> patched the code to store a pointer for each framebuffer to the
> "foreground" VC on each one.

Well, you really don't need to store currcon_ptr in fbcon_ops.  Using
vc_cons[ops->currcon].d should be enough to get the current vc attached
to the framebuffer.  It will also make your patch smaller, and hopefully
easier to spot regressions.

> It seems to work well but I'd like to get
> others' input as this is my first time writing any kernel code, and to
> be honest there is so much code it's difficult to get a clear picture
> in my head of how the whole system works.

Yes, the console code is very confusing.  I have been looking at it for
a long time and I still don't know every code pathway it's going to take.

Anyway, with single-head systems, I can't really see your patch causing
regressions, so that's good.  With multi-head, I don't know.

Anyway, maybe Andrew can give this a whirl in the -mm tree?  Just resubmit
the patch without the currcon_ptr from fbcon_ops. And add a
Signed-off-by: line.  See:

http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt

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