Messages in this thread | | | Date | Mon, 16 Feb 2004 14:30:55 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: 2.6.3-rc3 radeonfb: Problems with new (and old) driver |
| |
On Tue, 17 Feb 2004, Benjamin Herrenschmidt wrote: > > > > That would just make the code more logical, and it should fix your > > concerns, no? > > Yes, I was looking into this at the moment. Who else but fbcon and > vgacon will need fixing ? I suppose all the xxxxcon in > drivers/video/console, do you "see" any other ?
I don't see that anybody else can possibly care. In fact, I doubt even vgacon actually cares. It's just a regular unblank, but with the information that we came from graphics mode. I think it would be cleaner to add a new parameter to the "con_blank()" function, which would also cause compiler warnings for non-converted consoles, which is good.
Right now we encode multiple things into the one existing "blank" parameter, which is just confusing. We have
-1: /* enter graphics mode (just save whatever state we need to save, possibly clear state to be polite) */ 0: /* regular unblank (restore screen contents, enable backlight) */ 1: /* regular blank */ 2..x: VESA blank type x-1.
and I'd suggest that the new case would be the "regular unblank", but with the new parameter saying that we're coming from graphics mode. For example, I don't think the vgacon_blank() function would change at _all_ (except for the new parameter that it would just ignore).
As far as I can tell, fbcon is the _only_ thing that wouldn't ignore the new information, exactly because fbcon might want to reset things like the graphics engine.
Linus - 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/
| |